Hi, I would say the zmq_close behaviour should mimic Berkeley socket close behaviour, including SO_LINGER option and all the shutdown modes it provides.
(One thing that strikes me is that there's no timout for trying to send the data in the default case, which just begs to be exploited in a DoS attack. But that's beside the point.) The only real problem is zmq_term behaviour. 0MQ context is meant to play the same role as OS plays for BSD sockets. Following the analogy, closing context should drop all the pending data same way as OS drops all the data pending in TCP tx buffers on shutdown. The problem with this approach is that the behaviour is non-deterministic (you don't know whether data were sent when shutting down). Non-deterministic behaviour is OK for OS shutdown, but doesn't work well for application shutdown (i.e. zmq_term). A straightforward behaviour for zmq_term would be to block until all the sockets are deallocated -- each depending on it's SO_LINGER policy. (This could obviously result in deadlock on zmq_term, but that's beside the point once again I think.) Thoughts? Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
