[zeromq-dev] Router to router delay

[Cem Karan]

I'm afraid that pub-sub was the only way I could find to fix my problem, and that building some control structures on top of it worked for me.  On the other hand, my use case is probably very different than yours.

The only other suggestion I can make would be to define some kind of control on top of your router-router connections and basically ping the remote end until you get a message back.  If you put that in a moderately tight loop, say, one ping message every 10 milliseconds or so, you'll eventually get through, and the fact that you get a return tells you the connection is up.  I know that that is not ideal because you'll end up with a long queue of pings that you can't get rid of after you've received a reply, but it is all I can offer as a suggestion.

Good luck,
Cem Karan

On Jul 30, 2012, at 4:33 AM, Bjorn Reese wrote:

> We are straying off-topic.
> 
> I also use publish-subscribe in my system, but I need router-router for
> point-to-point interaction.
> 
> So my original problem about messages being silently discarded before
> the identity exchange is finalized is still relevant.
> 
> Let me elaborate on the original problem with an example. The example
> is against https://github.com/zeromq/zeromq3-x and error handling
> has been removed for brevity (but it is present in my original code)
> 
>   void *client = zmq_socket(context, ZMQ_ROUTER);
>   zmq_setsockopt(client, ZMQ_IDENTITY, identity, strlen(identity));
>   zmq_connect(client, endpoint);
> 
>   sleep(1); /* Wait for identity exchange to finish */
> 
>   zmq_msg_t message;
>   zmq_msg_init_size(&message, strlen(data));
>   memcpy(zmq_msg_data(&message), data, strlen(data));
>   int rc = zmq_sendmsg(client, &message, 0);
>   assert(rc == 0);
> 
> If the sleep() function above is removed, then the subsequent message
> is silently ignored.
> 
> 
> On 2012-07-28 20:48, Cem Karan wrote:
>> OK, you're doing something similar to what I'm trying to do, except that you're planning on expanding to a WAN.  I'm going to outline what I'm doing, but I want to note that what I have are a number of pieces of test code that let me make sure that the way I'm using zmq makes sense.  I haven't tried to push large amounts of data through yet, so it may break.  With that disclaimer in mind...
>> 
>> I started out with router-router connections, but switched to pub-sub over epgm and administratively scoped multicast addresses (http://en.wikipedia.org/wiki/Multicast_address#Administratively_Scoped_IPv4_Multicast_addresses) for precisely the reasons you outlined in your original email; it isn't easy distributing the addresses.  In my code, each node has one publisher socket and one subscriber socket.  All publishers and all subscribers are connected to the same address and port.   This means that I effectively have a reliable broadcast channel (epgm ensures that all receivers get the message, in the correct order, etc.).  I wrote a simple control layer/protocol on top that allows all nodes to communicate some minimal control information, which in your case might include zmq URIs.  That should allow router-router connections.
>> 
>> I don't know if the IANA has any addresses in the ad-hoc block (http://en.wikipedia.org/wiki/Multicast_address#AD-HOC_block) which are open to individual developers, but that is another thing to look at; if you can get permission to use an address in there, then the pub-sub trick would work across the internet.
>> 
>> Thanks,
>> Cem Karan
>> 
>> On Jul 28, 2012, at 8:11 AM, Bjorn Reese wrote:
>> 
>>> On 2012-07-28 13:02, Cem Karan wrote:
>>>> Can you describe your system a bit more?  Are the peers on the same LAN, or do they need to peer across the internet?  Do the peers already know about each other (as in, a small group with well-known identities), or do they have to discover each other?  etc...
>>> 
>>> Initially, all peers are on the same LAN where they discover each other
>>> via ZeroConf (Bonjour). These local peers constitutes one cluster.
>>> Later this has to be extended to several clusters communicating over
>>> WAN. The exact means for this has not been determined yet.
>>> 
>>> 
>>> _______________________________________________
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1581 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120730/5ac8523b/attachment.bin>