Zeromq 2 req/rep允许嵌套谈话

Question

我希望以下发生：

有一个main_socket，任何人都可以与之交谈。

客户端将发送"读取"并等待服务器的"确定"。

客户将在获得"确定"时发送"写"，这将意味着他们可以执行写作。每个人都应该等待这个。因此，我认为另一个嵌套在主循环中的REQ/REP频道。服务器将开始侦听write_socket上的消息，当客户端编写时，它将向write_socket发送消息。

但不幸的是，这不起作用，我不知道为什么。

server.py

import time
import zmq
context = zmq.Context()
main_socket = context.socket(zmq.REP)
main_socket.bind("tcp://*:5555")
write_socket = context.socket(zmq.REP)
write_socket.bind("tcp://*:5556")
print("ready to receive")
while True:
    #  Wait for next request from client
    print("server receiving main")
    message = main_socket.recv()
    print("server received main", message)
    if message == b"WRITE":
        main_socket.send(b"WRITE")    
        print("server receiving write")
        message = write_socket.recv()
        print("server received write", message)
        write_socket.send(b"OK")    
    else:
        main_socket.send(b"OK")

客户端

import zmq
import time
context = zmq.Context()
#  Socket to talk to server
print("Connecting to main server…")
main_socket = context.socket(zmq.REQ)
main_socket.connect("tcp://localhost:5555")
print("Connecting to write server…")
write_socket = context.socket(zmq.REQ)
write_socket.connect("tcp://localhost:5556")
print("starting")
t1 = time.time()
for i in range(10000):
    print("client sending main", b"WRITE")
    main_socket.send(b"WRITE")
    print("client receiving main")
    message = main_socket.recv()
    print("client received main", message)
    print("client writing")
    print("writing...")
    print("client written")
    time.sleep(5)
    print("client sending write", b"WRITE")
    write_socket.send(b"WRITE")
    print("client receiving write")
    message = write_socket.recv()
    print("client received write", message)

这将打印以下内容：

服务器

ready to receive
server receiving main
server received main b'WRITE'
server receiving write

客户

Connecting to read server…
Connecting to write server…
starting
client sending main b'WRITE'
client receiving main
client received main b'WRITE'
client writing
client written
client sending write b'WRITE'
client receiving write

我该如何使这种情况起作用？

Answer 1

这只是一个直觉，但是：问题可能是可以成功绑定 0.0.0.0:5556，即使也有一个绑定套接字为 localhost:5556，即 127.0.0.1:5556。

在这种情况下，绑定到0.0.0.0:5556的插座将继续接收到除 127.0.0.1以外的任何其他地址的连接;并包括IPv6，但是与127.0.0.1:5556的连接尝试将由其他位置的另一个TCP服务器套接字进行accept。

Answer 2

您的设计概念在两个主要层中脆弱：

因此，即使仅解决前者也将使您绝对无能为力。

---

1传输级的固有脆弱性：
首先，相关的运输级水平脆弱性(未获得先前释放或外部使用的TCP端口(。鉴于此，可能会移动某些共同定位的体系结构，将信号/消息服务移动到一些基于非TCP的运输类上，很可能有些其他{ inproc:// | ipc:// | vmci:// }，但这并不能解决LAN/WAN分配的操作方案，此外它仍然包含不解决第二种脆弱性的显着风险，这也需要一些强大的解决方案：

---

[2] REQ/REP可缩放正式持续性模式的固有脆弱性：任何严重的应用程序设计都应牢记，基础(原始(REQ/REP模式容易陷入不可抗衡的相互死亡锁中。对于详细信息关于这种主要危险，请查看我在Zeromq上的其他帖子，REQ/REP僵局非常频繁地发生碰撞，但主要是在这里说，如果该应用程序要认真对待某种应用程序的意义现场部署，然后友善地忘记使用"裸" -REQ/REP原始的，否则，您将应用程序放在层次结构FSA僵局中，无法从您的应用程序内部进行自我发现，因此无法进行反应性处理，因此或打捞。

好消息是，Zeromq中还有许多其他简单的模式原型作为构建块，使人们可以集成和快速型，一种强大的信号/消息传递应用程序基础工作。因此，请不要犹豫，通过更丰富的节点信号/消息传递授权您的应用程序，这不会互相僵局(任何一到任何基础设施范围内的僵局都越少...(。

以此方式进行，您同时 try: / except: assert exception Handlers and dock { .recv() | .send() } - 否则，未指出的条件将会出现(并且确保 it - 早晚 - 将出现(in-Vivo。