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

[Dhammika Pathirana]

On 7/7/10, Martin Lucina <mato at kotelna.sk> wrote:
>
>  On 7/7/2010, "Dhammika Pathirana" <dhammika at gmail.com> wrote:
>
>  >But how is this different from network or remote host queuing/dropping
>  >messages?
>  >Sending queued messages doesn't really guarantee delivery of messages.
>
>
> Of course this change doesn't *guarantee* anything has been delivered.
>  But that's not the point. Imagine you're using a standard TCP socket,
>  and you do:
>
>   accept (...);
>   write (...);
>   close (...);
>
>  Surely you expect that the data you sent down that socket with the
>  write() should pop out the other end *if that other end is still there*?
>


Not really, TCP close() just indicates "done reading and writing". But
the OS can still send a RST (ie. receiving more data for the closed
socket), and terminate the connection.


>  With the current zmq_close() semantics that won't happen. Bringing this
>  in line with the standard close() semantics is what my change proposes.
>


I see, but there's this subtle TCP behavior.