[zeromq-dev] ROUTER not routing?

Laurent Alebarde l.alebarde at free.fr
Fri Feb 14 22:35:44 CET 2014


Le 14/02/2014 19:44, Justin Karneges a écrit :
> Having the local socket tell the remote peer about the mapping it has
> created seems very roundabout. How about just allowing the mapping in
> the local socket to be replaced anytime identity information is received
> from the remote peer?
That's what does the existing IDENTITY option.
>
> I don't know how this works at the ZMTP level, but I assume that
> explicit identities are traded (if set on either side) at every
> connect/reconnect. I also assume that if the local socket receives
> identity information from a remote peer for which it already has a
> mapping, then it ignores the data.
You should check the last weeks messages in the list, it was discussed 
and I think there was a patch on that. If I remember correctly, the 
previous behaviour was to fall back to the built-in identity when the 
received one was already used, and now it is rejected.
> If these assumptions are true, then
> the solution is for the local socket to not ignore subsequent identity
> data and instead modify its mapping.
>
> Am I wrong in my assumptions?
>
> On 02/14/2014 12:50 AM, Laurent Alebarde wrote:
>> The existing IDENTITY socket option is useless for your purpose because
>> it is transmitted at the end of the handcheck in the metadata. When a
>> ROUTER receives a new connection, it assigns to it a own forged identity
>> (random for the first peer and then incremented for the next ones). It
>> is a 5 bytes blob, the first one is always zero, the 4 others are mapped
>> to a int.
>>
>> So, when the peer reconnects, it is seen as a new peer and the handcheck
>> is reprocessed, whatever you do with the IDENTITY option. IMHO, I don't
>> see any use case for this option.
>>
>> So, the only way I foresee is to have the ROUTER transmit to its peer
>> the identity it has assigned to it. The best place I think is in the
>> greeting's feeler: 31 bytes available not used (cf ZMTP). On the peer
>> side, before it reconnects, it shall set a new identity option you shall
>> add to libzmq, with the value previously retrieved.
>>
>> So, you should have one option used by the ROUTER, both to transmit the
>> assign 5 bytes identity to the peer in the greeting's filler, and to get
>> the one transmitted by the peer To have it work, use 6 bytes in the
>> filler, one would be a validity flag, because it wouldn't be a good idea
>> that the peer transmit an identity of its own, to avoid collisions. So
>> first time it connects, the blob is {0, 0, 0, 0, 0, 0}. ROUTER will send
>> say {1, 0, 5, 240, 72, 13}. Peer will have to send {2, 0, 5, 240, 72,
>> 13}when it reconnects. It is better to differentiate how the blob has to
>> be interpreted. 0: not valid, do nothing, 1: here is how I have
>> identified you, 2: I reconnect, please use this to identify me. This
>> would be necessary in the case of ROUTER-ROUTER, and ease greatly the
>> use of this architecture.
>>
>> And you should have one option to be used by the peer to retrieve and
>> resend the identity at the next connexion.
>>
>> Hope it helps,
>>
>>
>> Laurent.
>>
>>
>>
>> Le 13/02/2014 23:51, Justin Karneges a écrit :
>>> I'd like to move forward with fixing this. Can I get a confirmation that
>>> I should proceed? Basically I want to make it so if a connection
>>> reconnects, and an explicit identity is received from the peer, then it
>>> should overwrite any previously set identity for that peer.
>>>
>>> Also I tried to log an item in the Jira but I'm not sure how. Maybe I
>>> need special access rights? I created an account at least. Also, I see
>>> issues in github too. Which is the right place to log things?
>>>
>>> Thanks.
>>>
>>> On 02/08/2014 11:53 AM, Justin Karneges wrote:
>>>> Here's an even simpler example using REQ/ROUTER:
>>>> https://gist.github.com/jkarneges/1fa64e9763561f53daef
>>>>
>>>> It doesn't demonstrate the routing problem but it does demonstrate the
>>>> identity binding oddity. You can see the ROUTER side that the envelope
>>>> id is always the first id it has ever seen, even if the id printed by
>>>> the REQ side is different every time.
>>>>
>>>> On 02/07/2014 02:33 PM, Justin Karneges wrote:
>>>>> Here's some small sample code to reproduce the issue:
>>>>> https://gist.github.com/jkarneges/ab2b1abea1ee4cfc1332
>>>>>
>>>>> A (ztest1.py) creates REQ and ROUTER sockets. B (ztest2.py) creates REP
>>>>> and ROUTER sockets. B binds and provides a random identity to its ROUTER
>>>>> socket. A connects its sockets to B. A queries for B's id using the REQ
>>>>> socket, and then attempts to send a message via the ROUTER socket right
>>>>> after that. This is repeated every 2 seconds.
>>>>>
>>>>> A and B can be started in any order. A can be restarted and things will
>>>>> still work. If B is restarted, then A's ROUTER socket will never work
>>>>> again until A is restarted also.
>>>>>
>>>>> A uses ZMQ_ROUTER_MANDATORY to show that the failures are on A's side.
>>>>>
>>>>> On 02/07/2014 02:16 PM, Justin Karneges wrote:
>>>>>> It is my understanding that being able to route requires the socket to
>>>>>> have an identity mapping in its routing table for the peer.
>>>>>>
>>>>>> For peers that do not explicitly specify their own identity, then I
>>>>>> believe you are correct that routing is not possible until at least one
>>>>>> message has been received from the peer. It is at this point that the
>>>>>> ROUTER socket will make up an identity for this peer and store it in its
>>>>>> routing table.
>>>>>>
>>>>>> However, for peers that *do* explicitly specify their own identity (as I
>>>>>> am doing), then this identity information is delivered immediately after
>>>>>> the connection is established, allowing routing to the peer even if the
>>>>>> peer has not sent a message yet.
>>>>>>
>>>>>> I should have been more clear in my original message. The B program is
>>>>>> explicitly specifying a random UUID as the identity of its socket before
>>>>>> binding.
>>>>>>
>>>>>> On 02/07/2014 02:06 PM, Panu Wetterstrand wrote:
>>>>>>> I did not quite get the problem but could this be because (I think)
>>>>>>> router is not able to route messages to socket from which it has not
>>>>>>> reveived data first...
>>>>>>>
>>>>>>> 7.2.2014 22.51 kirjoitti "Justin Karneges" <justin at affinix.com
>>>>>>> <mailto:justin at affinix.com>>:
>>>>>>>
>>>>>>>          Hi,
>>>>>>>
>>>>>>>          1) ROUTER in program A is set to connect to a bind socket in program B.
>>>>>>>          2) Both programs are started, and the connection is established.
>>>>>>>          3) A determines B's socket identity out-of-band, and is able to send
>>>>>>>          messages to B.
>>>>>>>          3) B is terminated and the connection is lost.
>>>>>>>          4) B is started again, and the connection is re-established.
>>>>>>>          5) A determines B's socket identity out-of-band, and is no longer able
>>>>>>>          to send messages to B.
>>>>>>>
>>>>>>>          It seems this problem does not happen if B retains the same socket
>>>>>>>          identity across reconnects. However, if it uses a random identity (to be
>>>>>>>          discovered out-of-band by A), then routing will never work again after
>>>>>>>          the first restart of B. The A program must be restarted in order to make
>>>>>>>          things right again.
>>>>>>>
>>>>>>>          My guess is that each connect queue on a ROUTER socket is somehow bound
>>>>>>>          for life against the first identity it sees. Is this intentional
>>>>>>>          behavior?
>>>>>>>
>>>>>>>          Thanks,
>>>>>>>          Justin
>>>>>>>          _______________________________________________
>>>>>>>          zeromq-dev mailing list
>>>>>>>          zeromq-dev at lists.zeromq.org  <mailto: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
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>> _______________________________________________
>> 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/20140214/9a9c246a/attachment.htm>


More information about the zeromq-dev mailing list