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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
