[zeromq-dev] ROUTER not routing?

Justin Karneges justin at affinix.com
Fri Feb 14 00:19:16 CET 2014


The new peer asserts its own identity. There is not a question about 
whether the new peer is the same as before. The peer very clearly is or 
is not the same, based on the identity it provides. The problem is that 
remote identities are only honored for the first peer.

On 02/13/2014 03:00 PM, Ahmet Kakıcı wrote:
> It's not about zmq, just imagine someone comes to you and you say him
> "you are x", after he left someone came too, so without his identity how
> will you decide if he is the same person or not?
>
>
> On Fri, Feb 14, 2014 at 12:51 AM, Justin Karneges <justin at affinix.com
> <mailto:justin at affinix.com>> wrote:
>
>     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>
>      >>>> <mailto: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>
>     <mailto: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 <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 <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 <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 <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 <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
>




More information about the zeromq-dev mailing list