If I may chime in here, my biggest problem with the identities concept, is that there is no way to have a ROUTER connect to a socket, and then know how to talk to that socket. Identities are exchanged by the underlying zmq transport layer on successful connection I believe, but the user has no way of knowing what the identity of the other peer is without doing something drastic like connecting a REQ socket to that peer and directly asking the application to transmit it's identity. This is wasteful and slow.
I would love to see some method of either (a), being able to get the identity (generated or user-set) of a peer you have just connected to, or (b) being able to use the address string of a peer (e.g. "tcp://w.x.y.z:abcd") or some hash/derivative thereof, as the identity when sending through a ROUTER socket. As it stands right now, it is not possible to have two ROUTER sockets talk to eachother without out of band information, and this precludes the implementation of many peer-to-peer protocols. I think if you are contemplating large changes regarding the LABEL and IDENTITY portions of ZMQ, this topic should be something worth discussing. -E On Sat, Oct 29, 2011 at 11:08 AM, Gregory Szorc <gregory.sz...@gmail.com>wrote: > On 10/29/2011 3:25 AM, Martin Sustrik wrote: > > 1. Revert the LABEL stuff from 3.0. > > I hate to see it go because I too feel it is a step in the right > direction (coming from empty message delimiters). But if it makes the > release more stable and 2.1 behavior is persisted, go for it. > > I /think/ reverting this also means that 2.1 and 3.0 will speak the same > wire format. Or, is there something else that changed besides adding the > LABEL bit to the per-message flags? > > > The feature that makes mess of the codebase, on the other > > hand, is buffering messages on sender when peer with explicit identity > > id offline/dead. We can thus remove the code for the latter (thus > > backporting the drastic simplifications of the codebase in 4.0 to 3.0 > > while keeping the route-to-identity feature. > > +1. The old method was broken anyway since durable peers could disappear > and cause memory leaks due to sockets buffering indefinitely. This is > one of the changes that makes 3.0 a must have for me. > > Greg > > _______________________________________________ > 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
