[zeromq-dev] 0MQ/3.0, 0MQ/4.0 and 0MQ process

[Elliot Saba]

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 <benjaminrk at gmail.com> wrote:

>
>
> On Sat, Oct 29, 2011 at 13:49, Elliot Saba <staticfloat at 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.szorc at 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 at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111029/b26fa616/attachment.htm>