一对一：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