常识 | 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

你可能感兴趣的:(常识,什么都来点,网络)