Re: [zeromq-dev] ROUTER not routing?
On 02/13/2014 02:51 PM, Justin Karneges wrote: 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? Still hoping to get clarification on this. FWIW I was looking here: http://zeromq.org/docs:contributing Justin ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com
mailto:jus...@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)
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com
mailto:jus...@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
Re: [zeromq-dev] ROUTER not routing?
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?
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. 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,
Re: [zeromq-dev] ROUTER not routing?
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
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com mailto:jus...@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@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.comwrote: 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 jus...@affinix.com mailto:jus...@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@lists.zeromq.org mailto: zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com mailto:jus...@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 jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@affinix.com mailto:jus...@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
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com mailto:jus...@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@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] ROUTER not routing?
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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
I think you are creating new socket at step 4, then Router will assign new socket identites to incoming peers. https://github.com/zeromq/libzmq/blob/9c6aa1e9e00ab11a1c716e1fd2f1c56030972e30/src/router.cpp#L437 That's why you cannot send replies to a client with same identity. On Fri, Feb 7, 2014 at 10:51 PM, Justin Karneges jus...@affinix.com wrote: 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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
Yes, when B is run again, it creates a new bind socket. A's connect socket will then reconnect to it. B does not care what the identity is of A's socket, so I think this is not a problem. For example, I can restart A repeatedly and all is fine. On 02/07/2014 01:06 PM, Ahmet Kakıcı wrote: I think you are creating new socket at step 4, then Router will assign new socket identites to incoming peers. https://github.com/zeromq/libzmq/blob/9c6aa1e9e00ab11a1c716e1fd2f1c56030972e30/src/router.cpp#L437 That's why you cannot send replies to a client with same identity. On Fri, Feb 7, 2014 at 10:51 PM, Justin Karneges jus...@affinix.com mailto:jus...@affinix.com wrote: 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? ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
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 jus...@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@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com mailto:jus...@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@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ROUTER not routing?
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 jus...@affinix.com mailto:jus...@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@lists.zeromq.org mailto:zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
