[zeromq-dev] Feedback on new PATCH socket
sustrik at 250bpm.com
Sun May 8 08:09:11 CEST 2011
On 05/08/2011 07:25 AM, Fabien Ninoles wrote:
> 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.
That's not what 190 asks for. It's more of a heuristic: If next *hop*
downstream disconnects, immediately drop any queued requests you've got
from it. The rationale being that there's noone to send the replies to
> 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).
I would love to replace multi-part messages by message+labels system,
however, this is not backward compatible and thus unlikely to happen in
0MQ. You will probably find it in the future implementations such as
Linux kernel implementation.
More information about the zeromq-dev