[zeromq-dev] Double connect problem in XREP to XREP

Antonio Delgado Peris antonio.delgado.peris at cern.ch
Thu Mar 10 10:28:22 CET 2011


Hi Martin,

Thanks a lot for the prompt reply. Please see some comments inline.

> Hi Antonio,
>
>> The problem comes when a peer tries to connect to one that has already
>> connected to it: first A connects to B, then B connects to A, then at
>> the next send (on either peer) I get:
>>
>>       Assertion failed: ok (xrep.cpp:61)
>
>
> This should not happen. Instead, the connection with duplicate 
> identity should be rejected by the peer. 
Ok, so when that is the case, the second connection attempt will fail 
and the code will be able to act accordingly.

> I've created a ticket for the problem:
>
> https://github.com/zeromq/zeromq2/issues/176
Thanks.
>
>> So, first, is this expected? If so, how could I avoid it? E.g., is there
>> a way to list the identities already known by the XREP socket, so that a
>> peer does not try to connect to one that is already there? Although for
>> me, the most reasonable behaviour in this case would be that the second
>> connect was translated to a no-op, given that there is already a
>> connection to that identity (with same address).
>
> More generally speaking, it is the problem of automatic detection of 
> loops in the topology. It's a complex problem and it's not likely to 
> be solved anytime soon.
Just to be sure, there is no way to list identities known to my XREP 
socket, right?

>> Otherwise, I guess a solution for me would be to have two different
>> XREPs, one for outgoing connections and one for incoming connections but
>> that would mean that in some cases I would have repeated sockets A->B,
>> B->A. Maybe that's not a problem, but I would rather give a try to
>> understanding if the double connect problem is solvable before
>> circumventing it.
>
> That's one option. The other option is simply using auto-generated 
> identities instead of fixed ones.
Because auto-generated identities are different for bind and connect, 
analogous to the example you show below? Otherwise I fail to see the 
difference...

> The third option is having multiple identities on one socket, this way:
>
> s = socket (ZMQ_REP)
> s.setsockopt (ZMQ_IDENTITY, "A")
> s.bind (...);
> s.setsockopt (ZMQ_IDENTITY, "B")
> s.connect (...);
Ah, I didn't know that was possible. Nice.

>
> However, AFAIU, you are trying to create a circular topology, which 
> IMHO doesn't make any real sense.
Well, it's not my intention to have double links between nodes, one is 
enough and when a node knows about a peer already connected, it's happy 
with that but AFAIK, a node can only know that somebody connected to its 
XREP on reception of first message (i.e. that the other end has 
connected is not notified and is not queryable). In my early tests peers 
may discover and try to connect to each other at almost the same time, 
resulting in the described problem. If the second connect was rejected 
that would be already good because it would show that the node is 
already connected.

It's clear to me that another solution to my problem is to have a more 
ordered discovery and peer connection process so that double connect 
attempts never occur. That may well be the case when my system is more 
mature but I wanted to understand this problem first.

All in all, I think your answer gives me the tools to resolve my problem 
in one way or another (even more when the issue you posted is solved).

Thanks.

Antonio

>
> Martin




More information about the zeromq-dev mailing list