常识 | zmq通信

一对一：REP-REQ

发送端：                                                           接收端
socket(context, REP)                                        socket(context, REQ)
bind("tcp....")                                                     connect("tcp.....")
                                                                          send(req) // 先发送
recv(&req)     // 先等待                             
send(reply)                                                        
                                                                          recv(&reply)

是阻塞式的，必须要client先发送请求给server，然后server才可以返回一个response给client，否则server不会主动发消息

一对多：PUB-SUB

发送端：                                                           接收端
socket(context, PUB)                                        socket(context, SUB)
bind("tcp....")                                                     connect("tcp.....")
----------------------------------  循环 ------------------------------------
send(msg)                                                         recv(&msg)
----------------------------------  循环 ------------------------------------                    
                                                        
服务端会管自己pub，接收端能不能收到不关服务端的事情。数据单向流通，数据的过滤是在接收端。

一对多对一：PUSH-PULL

worker对上是connect，对下是send

中间的多称为一组worker，负责接收上端任务、（并行）处理、并均匀分配给下端

---

提问：如果一个接收端需要接受来自多方的信息.......

——尝试pub-sub其中的反过来写

“绑定”和“连接”背后的驱动概念是，一方通常被认为更可靠(并且通常会有更少的节点)，而另一方被认为是更短暂的(并且可能存在更多节点)。可靠的一面将被视为您的“服务器”，您应该在那一侧bind()，瞬态一侧将被视为您的“客户”(或客户端)，您应该在那一侧connect()。

通常情况下，我们会想到一个稳定的“服务器”不断向许多“客户”用户发布信息。这可以在您看到的示例中表示：bind on pub，connect on sub。

但是，您可以轻松地拥有一个稳定的“服务器”来订阅连接到它的许多“客户”发布者的任何输出，接受他们在可用时发送的任何信息。使用该连接策略没有任何缺点...只要它适合您的目的。（说得真好啊啪啪啪啪啪）

---

Pub-Sub的丢失数据问题

1. 慢连接导致的丢失，pub端起来了，sub还没起，就会丢掉开始的几个数据
解决：1. pub sleep
           2. sub起来后先给pub发消息，然后pub再发

2. 多个pub给sub发大量消息，sub接收丢包
没办法= =广播的方式为了获取效率必须牺牲可靠性。好在丢包率可以忍受 大概1/1000