Có, bạn có thể đảo ngược và không có bất lợi khi sử dụng chiến lược kết nối đó ... miễn là nó phù hợp với mục đích của bạn.
Trong ZMQ, khái niệm lái xe phía sau "ràng buộc" và "kết nối" là một bên thường được coi là đáng tin cậy hơn (và thường sẽ có ít nút hơn) và mặt kia được coi là thoáng qua hơn (và có thể có nhiều nút hơn). Phía đáng tin cậy sẽ được coi là "máy chủ" của bạn và bạn nên bind() ở phía đó, mặt thoáng qua sẽ được coi là "khách hàng" của bạn (hoặc khách hàng s) và bạn nên connect() ở bên đó.
Thông thường, chúng tôi nghĩ về thông tin xuất bản "máy chủ" ổn định liên tục, cho nhiều người đăng ký "khách hàng" có thể đến và đi. Điều này được thể hiện trong các ví dụ mà bạn thấy: liên kết trên pub, kết nối trên sub.
Nhưng, bạn có thể dễ dàng có "máy chủ" ổn định đăng ký bất kỳ đầu ra nào từ nhiều nhà xuất bản "khách hàng" kết nối với nó, chấp nhận mọi thông tin mà họ đang gửi trong khi họ có mặt. Liên kết trên phụ, kết nối trên quán rượu.
Bạn không bị giới hạn ở một máy chủ, đó là ví dụ đơn giản nhất - tuy nhiên, bạn bị hạn chế hơn nếu bạn đang chạy tất cả các ổ cắm trên cùng một máy tính. Ràng buộc trên cùng một địa chỉ với nhiều hơn một socket sẽ tạo ra xung đột, nhưng bạn có thể kết nối nhiều ổ cắm với cùng một địa chỉ như bạn muốn.
Trong nhiều trường hợp, cả hai mặt của giao tiếp thực sự đáng tin cậy và hoạt động lâu dài, trong trường hợp đó là hữu ích khi nghĩ đến nút gửi thông tin như máy chủ và nút nhận nó như là máy khách . Trong trường hợp đó, chúng ta quay lại ràng buộc trên pub, kết nối trên sub.