I'm not sure about how 190 can be fixed by separating the semantic of the ROUTER from the req/rep socket; propagating a disconnection from one edge to another could be quite hard and probably hardly possible if you have any fairqueuing in-between.
However, one way to be more transparent is to mark a frame as being "added" to the original message instead of using the empty delimiter. This will allow REQ/REP to work directly without change. The flag need to be pass between sockets however (just like the MORE flag) and so this is not compatible with the current queue device. However, if the API were setting the flag inside the msg_t struct, this would have been completly transparent, will remove some potential beginner bug (like sending a RCVMORE msg without the SNDMORE flag in a device) and, I'm pretty sure we can make it semantically meaningful (by calling it FOLLOWED for example). Just some personnal thoughts on the current API. Fabien ----- Message d'origine ----- > On 05/07/2011 12:09 PM, Pieter Hintjens wrote: > > > Martin, you tend to disparage anything you don't like or understand as > > "a hack" or "confusion". There is really no confusion *between* XREP > > and ROUTER except perhaps in your mind. > > The two patterns (routing vs. req/rep) are semantically different. So > far I've artificially kept the implementation in such state that single > socket type can be used for both. It had to be done in 2.x series to > keep the backwards compatibility. > > However, this can't hold forever. Check issue 190, for example. Once > it's fixed, the router pattern will break. At that point there won't be > any other way out that explicitly separating the patterns. > > Martin > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
