On 7/7/10, Martin Lucina <m...@kotelna.sk> wrote: > > On 7/7/2010, "Dhammika Pathirana" <dhamm...@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. _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
