重设REQ/REP套接字状态

Question

使用简单的ZeroMQ REQ/REP模式时，依赖于固定的send()->recv() / recv()->send()序列。正如这文章所描述的，当参与者在请求中间断开连接时，您就会遇到麻烦，因为您不能仅仅从接收来自另一个连接的下一个请求开始，但是状态机将迫使您向断开连接的请求发送请求。

既然这篇文章已经写好了，有没有一种更优雅的方法来解决这个问题？

是重新连接解决这一问题的唯一方法(除了不使用REQ/REP，而是使用另一种模式)

Answer 1

好消息是，从ZMQ3.0和更高版本(现代时代)开始，您可以在套接字上设置超时。正如其他人在其他地方所指出的，您必须在创建套接字之后，但在连接它之前，这样做：

zmq_req_socket.setsockopt( zmq.RCVTIMEO, 500 ) # milliseconds

然后，当您实际尝试接收回复时(在您向REP套接字发送了一条消息之后)，您可以捕获如果超过超时将被断言的错误：

 try:
   send( message, 0 )
   send_failed = False

 except zmq.Again:
   logging.warning( "Image send failed." )
   send_failed = True

不过！当发生这种情况时，正如其他地方所观察到的，您的套接字将处于一个有趣的状态，因为它仍然期待响应。此时，除了重新启动套接字之外，我找不到任何可靠工作的东西。请注意，如果您断开套接字，然后重新连接()它，它仍将处于这种糟糕的状态。所以你需要

def reset_my_socket:
  zmq_req_socket.close()
  zmq_req_socket = zmq_context.socket( zmq.REQ )
  zmq_req_socket.setsockopt( zmq.RCVTIMEO, 500 ) # milliseconds
  zmq_req_socket.connect( zmq_endpoint )

您还会注意到，由于我关闭()d套接字，接收超时选项“丢失”，因此在新套接字上设置该选项非常重要。

我希望这能帮到你。我希望这不是这个问题的最佳答案。:)

Answer 2

由于被接受的答案在我看来非常可悲，我做了一些研究，发现我们所需要的一切实际上都在文档中。

具有正确参数的.setsockopt()可以帮助您重新设置套接字状态机，而不会残忍地销毁它，并在前一个死尸之上重建另一个。

(是的，我喜欢这张照片)。

ZMQ_REQ_CORRELATE:与请求匹配应答 REQ套接字的默认行为是依赖于消息的排序来匹配请求和响应，这通常就足够了。当此选项设置为1，时，REQ套接字将在传出消息前加上一个包含请求id的额外帧。这意味着完整的消息是(request id，0，user frames…)。REQ套接字将丢弃不以这两个帧开头的所有传入消息。 期权值类型int 期权价值单位0，1 默认值0 适用的套接字类型ZMQ_REQ ZMQ_REQ_RELAXED:放宽了请求和回复之间的严格交替 默认情况下，REQ套接字在收到对前一个套接字的答复之前，不允许使用zmq_send(3)启动新请求。当设置为1，时，允许发送另一条消息，并具有将底层连接断开到预期应答的对等点的效果，从而触发对支持该消息的传输的重连接尝试。请求应答状态机被重置，一个新的请求被发送到下一个可用的对等点。 如果设置为1，还可以启用1以确保请求和答复的正确匹配。否则，可以将对中止请求的延迟答复报告为对替代请求的答复。 期权值类型int 期权价值单位0，1 默认值0 适用的套接字类型ZMQ_REQ

这里

Answer 3

对此有一个解决方案，那就是在所有调用中添加超时。由于ZeroMQ本身并不真正提供简单的超时功能，所以我建议使用ZeroMQ套接字的一个子类，该子类为所有重要调用添加一个超时参数。

因此，不是调用s.recv()，而是调用s.recv(timeout=5.0)，如果响应在5秒内没有返回，它将返回None并停止阻塞。当我遇到这个问题时，我做了一个徒劳无功的尝试。