ZeroMQ HEARTBEAT sockopts() 设置如何工作？答案

【问题标题】：How do ZeroMQ HEARTBEAT sockopts() settings work?ZeroMQ HEARTBEAT sockopts() 设置如何工作？
【发布时间】：2021-12-27 16:02:10
【问题描述】：

我正在使用 python 的 pyzmq==22.2.1，它应该支持 ZeroMQ 4.2.0（根据 API）

我正在尝试使用心跳套接字选项（ZMQ_HEARTBEAT_IVL、ZMQ_HEARTBEAT_TIMEOUT 和 ZMQ_HEARTBEAT_TTL）。但是，当我设置这些套接字选项时，我没有收到预期的 TimeoutException 或我的套接字上的任何异常。它似乎只是坐在那里无所事事。

设置这些套接字选项后的预期行为是什么？在服务器端，服务器如何检测客户端超时并错过心跳，客户端反之亦然（是否有异常或应该抛出的东西？）。

我在下面设置了一个简单的路由器经销商回显示例：

# Server Code:
import zmq
c = zmq.Context()
s = c.socket(zmq.ROUTER)
s.setsockopt(zmq.HEARTBEAT_IVL, 1000)
s.setsockopt(zmq.HEARTBEAT_TIMEOUT, 5000)
s.setsockopt(zmq.HEARTBEAT_TTL, 5000)
s.bind('tcp://127.0.0.1:5555')


while True:
    id, data = s.recv_multipart()
    s.send_multipart([id, data], zmq.NOBLOCK)



# Client Code
import zmq
import time
c = zmq.Context()
s = c.socket(zmq.DEALER)
s.HEARTBEAT_IVL = 1000
s.HEARTBEAT_TIMEOUT = 5000
s.connect('tcp://127.0.0.1:5555')
i = 0
while True:
    s.send(str(i).encode())
    print(s.recv())
    i += 1
    time.sleep(1)

【问题讨论】：

标签： python-3.x zeromq pyzmq

【解决方案1】：

问： _{设置这些套接字选项后的预期行为是什么？}

答：
嗯，
上述设置有两方面的效果。一，这实际上适用于您的设置目标（即发送和发送（很可能是 ZMTP/3.1）ZMTP_PING 面向连接的服务子层“ZMTP/3.1-service-packets”并且相反，不确定，但最常见的是，充分形成“ZMTP/{3.1|2.x|1.0}-service-packets”（希望已交付）。这些“service-packets”在有线线路上可见（如果存在 - inproc://-transport-class 和vmci://-transport-class 也没有典型用户可以连接和嗅探流量的实际线路，但是用于 RAM 映射的某种指针杂技），因此协议分析器将“看到”它们的 id解码如下：

a local-initiator
        MAY send:

+------+----+
| %xNN | 24 |
+------+----+
   0     1
 flags  size

+------+---+---+---+---+
| %xNN | P | I | N | G |
+------+---+---+---+---+
   2     3   4   5   6  
          ZMTP/3.1-Command name "PING"

+---+---+
|       |
+---+---+
  7    8  ping-ttl 2B

          MAY be zero  
          MAY be ttl stored as [0:15], being a 16-bit TTL in 1/100 [s] ~ max 6553 [s]
                 ttl provides a strong hint
                             to the other peer to disconnect
                             if no further traffic is received after that time. 

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  9   10  11  12  13  14  15  16  17  18  19  20  21  22  23  24

          ping-context (max 16B)
          
          MAY be zero
          MAY be context-specific context-payload, not more than 16B

a remote-peer
         SHALL respond:

+------+----+
| %xNN | 22 |
+------+----+
   0     1
 flags  size

+------+---+---+---+---+
| %xNN | P | O | N | G |
+------+---+---+---+---+
   2     3   4   5   6  
          ZMTP/3.1-Command name "PONG"

+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  7   8   9   10  11  12  13  14  15  16  17  18  19  20  21  22

          ping-context (echoed as obtained from PING)

ZMTP/3.1 v/s ZMTP/3.0 v/s ZMTP/2.xv/s ZMTP/1.0 的差异和细节在版本协商阶段得到解决，一旦连接设置服务的子层执行所有需要的低级别试图就版本、身份验证和安全相关原则达成一致的同行之间握手（重新）谈判

这些的第二个效果（在Context()-engine 实例的底层执行了协商）是您将永远不会看到与定义的 ZeroMQ-(abstract)-Message-Transport-Protocol (ZMTP) 的任何直接交互服务设置和维护流程。

我们只是享受（在 ZMTP 之上生成的）公开 API 调用来设置、配置和利用“我们的”用户级操作的信令/消息传递基础设施元平面，它基于“隐藏”下的所有专有技术- 引擎盖（并且应该保持这样 - 确定，除非有人决定卷起袖子帮助将 ZeroMQ 系统开发到下一代）

问： _{（是否有异常或应该抛出的东西？）}

一个：
这就是为什么必须首先告知以上所有内容，作为正当理由，对此你的第二个问题应该有一个公平和诚实的答案。

【讨论】：