[zeromq-dev] ROUTER not routing?

[Justin Karneges]

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
>