Just a feature request. It would be nice if restarting a process wouldn't lose messages left inside TCP buffers. I'm not sure of the best way to handle this, but here's a proposal:
On the write side, a close command may be received from a peer TCP connection. Upon receiving a close command from the peer, the zmq socket would stop moving messages between the write queue and that underlying TCP connection. It would also send an end of stream packet across that connection (or shutdown could be used for a partial close). No changes needed in the application.
On the read side, there'd need to be a couple of new functions added: zmq_shutdown_read, and zmq_is_read_finished or such (or these could be sockopts). Shutting down read on a zmq socket would send a close command to all the underlying TCP connections of that socket. The application could then continue to read any remaining messages from the socket until there are none left, at which point it could call zmq_close.
Note that this is not a reliability mechanism, and there are no retransmissions or anything like that. It's simply a clean closing mechanism to ensure messages in transit aren't dropped unnecessarily.
pthreadself
commented
7 years ago
Just a feature request. It would be nice if restarting a process wouldn't lose messages left inside TCP buffers. I'm not sure of the best way to handle this, but here's a proposal:
shutdowncould be used for a partial close). No changes needed in the application.zmq_shutdown_read, andzmq_is_read_finishedor such (or these could be sockopts). Shutting down read on a zmq socket would send a close command to all the underlying TCP connections of that socket. The application could then continue to read any remaining messages from the socket until there are none left, at which point it could callzmq_close.Note that this is not a reliability mechanism, and there are no retransmissions or anything like that. It's simply a clean closing mechanism to ensure messages in transit aren't dropped unnecessarily.