> This won't work. The peer can be a device rather than an endpoint. In > such case you should expect to get arbitrary number of responses from a > single connection.
My bad... The code should loop on the RCVMORE condition and send a full message. Also, take note that it only discard a socket from the wait queue once a END signal is received, forwarding all preceding messages. > > 2- It lock the patch socket until all reply came back. May be it's > > better this way, given that a single request can generate 1000 > > replies but it can also completly lockdown the full tree if one > > socket downstream fail to answer. In this case, setting a maximum > > timeout (in the poll call above)is the only viable solution > > Bingo! That's the main problem. A pattern that allows single failed or > mis-behaved node to block the whole topology cannot be really called > scalable. That's why the pattern really needs the timeout/deadline to > be an inherent part of it. Letting the endpoint socket set the timeout required the socket to know quite information about the topology, like how many messages it should expect. If too long also, it will cap the socket capacity to this period. It also can be done quite easily using a poller, without any modification. By putting the timeout in the polling of the PATCH socket, this will allow the sockets to go to their maximum capacity, ending a call as soon as it terminates, returning an error if no answer were return after a reasonable amount of time. However, I still think that using the PATCH as is can be useful. Calls that required only a subset of the nodes to answer or that required an asynchronous pattern (like mongrel2 handlers) cannot be done with such strict collecting policy (one point for your proposal on this case ;) ). Fabien _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
