[zeromq-dev] zmq_close() semantics and handling outstanding messages

[Dhammika Pathirana]

But how is this different from network or remote host queuing/dropping
messages?
Sending queued messages doesn't really guarantee delivery of messages.

This gets even worse as TCP sends RST (ECONNRESET) on receiving data
to a closed socket. In http world they work around this by sender
doing a half close, receiver reading EOF and closing its end.



On 7/6/10, Martin Lucina <mato at kotelna.sk> wrote:
> Hi all,
>
>  while implementing a 0MQ architecture which needs to dynamically create and
>  destroy sockets during operation I ran into the current behaviour of
>  zmq_close() being semantically different from the standard close() system
>  call.
>
>  Consider a scenario where we wish to send a bunch of messages, then close
>  the socket:
>
>   zmq_send (s, ...)
>   zmq_send (s, ...)
>   zmq_send (s, ...)
>   zmq_close (s)
>
>  The current behaviour is that zmq_close() will discard any messages which
>  have been queued ("sent") with zmq_send() but have not yet been pushed out
>  to the network. Contrast this with the behaviour of the close() system call
>  on a standard socket where the call means "please make this socket go away,
>  but finish sending any outstanding data on it asynchronously if you
>  can"[1].
>
>  In my opinion the proper solution is to use the same semantics as the
>  close() system call, in other words, zmq_close() shall invalidate the
>  socket from the caller's point of view so no further operations may be
>  performed on it, but 0MQ shall send any outstanding messages in the
>  background *as long as a endpoint for those messages still exists* before
>  destroying the socket "for real".
>
>  This would mean a second change to the API which would make zmq_term() a
>  blocking call, since it would need to wait until all outstanding messages
>  are sent. The analogous functionality for the close() system call is
>  handled by the OS kernel -- obviously if the OS shuts down then data will
>  be lost.
>
>  The downside is that zmq_term() could freeze for an arbitrary amount of
>  time if the remote end is "stuck". For applications where this is
>  undesirable it would mean adding a "KILL" flag or separate zmq_term_kill()
>  function which means "we don't care, really go away now".
>
>  Please let me know your opinions on this change; ultimately I think it's
>  the right way to go especially if OS integration of 0MQ sockets is (a long
>  way) down the road.
>
>  -mato
>
>  [1] This behaviour can be changed using the SO_LINGER option, we'd probably
>  want to implement a similar option for 0MQ sockets.
>  _______________________________________________
>  zeromq-dev mailing list
>  zeromq-dev at lists.zeromq.org
>  http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>