[zeromq-dev] ROUTER not routing?

Laurent Alebarde l.alebarde at free.fr
Fri Feb 14 10:13:46 CET 2014


The greeting's signature would be an easier place (8 bytes available).

Le 14/02/2014 09:50, Laurent Alebarde a écrit :
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140214/a6d5b15a/attachment.htm>


More information about the zeromq-dev mailing list