Yes, I was talking about the model of a ROUTER connecting to another socket, in my case, a ROUTER. ROUTER <-> ROUTER connections seem to be difficult without out-of-band data informing each node of network topology.
If the ROUTER socket in 4.0 receives the aforementioned CMD messages on connect/disconnect, is that event exposed to the user-level API? If so, that is a compelling reason for me to attempt using 4.0 (or whichever branch of 3.0-experimental this particular functionality of 4.0 is eventually migrated to, as seems to be the topic of discussion today). -E On Sat, Oct 29, 2011 at 3:35 PM, MinRK <[email protected]> wrote: > > > On Sat, Oct 29, 2011 at 13:49, Elliot Saba <[email protected]> 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 >> <[email protected]>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 >>> [email protected] >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> >> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
