I have an architecture where each of my components implements a RESP socket to respond to a handful of C2 (command and control) messages. One message that all components must implement is “status”.
One of my components periodically queries each component, in turn, for its status and aggregates the result into an overall system health. This is an independent thread, and it creates a new REQ socket for each request. The socket is configured with ZMQ_RCVTIMEO=1000, ZMQ_LINGER=0, and ZMQ_IMMEDIATE=1. I create a new socket, because it was the easiest way to recover from a timeout. I have a couple of components that seem “slow of speech”. More often than not, the request times out. On the server side, there is no indication of the request. I captured some network traffic, and what I see is the initial ZMTP “greeting” being sent, but no response. After the 1 second timeout, my client destroys the socket, but the server doesn’t completely acknowledge this until a successful request/response has been sent on another socket. In TCP terms, the client sends the [FIN] packet, but the server holds off on replying with his own [FIN] until a good message has been sent. For example, if my first request is a 0, the client closes the socket at 1, but the server doesn’t close until 15. Similarly, another request comes in at 5, and another at 10. Finally, a successful request/response is achieved at 15, at which point, all of these sockets are closed. What can be causing this behavior? Both client and server are on the same host; network traffic is traversing the loopback interface. Is there something fundamentally flawed about my architecture? Is there a quick fix, versus redesigning? -- Jim Melton (303) 829-0447 http://blogs.melton.space/pharisee/ [email protected]
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
