On Sat, Oct 29, 2011 at 13:49, Elliot Saba <staticfl...@gmail.com> wrote:
> 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. You *do not* have to use an extra socket to get this information with current identity model. If sockets connecting to the ROUTER simply send a first 'hi, I'm here' message, the ROUTER will have their identity. This is, of course, not addressed if the ROUTER is the connecting socket. > > 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. > The ROUTER socket currently in 4.0 gets CMD messages on connect/disconnect of peers, so it always knows the identities of peers that are currently connected. > -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 > >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
