[zeromq-dev] ROUTER-DEALER missing connects/messages.

[Dowd, Brian]

HI Chuck,
   Cheers for that, it's along the lines I was thinking, I guess the FAQ entry you refer to is the difference of bind vs connect..
So I guess this will happen for every client that connects to the server..

I have changed the test code to be as you suggested, and it does work cleaner now with a lower timeout, although it was only a test
example, the real one would have one client per process etc ...

Two final questions :
 1. What is a reasonable timeout, I've seen 1 second arbitrarily use, I assume that is ample time unless
     client/server are opposite sides of the globe ?
 2. Will this always be the case ? or is there support planned for this to be handled internally to the pattern in time ?

Many thanks for the help,
Brian.

-----Original Message-----
From: zeromq-dev-bounces at lists.zeromq.org [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Chuck Remes
Sent: 25 September 2012 16:30
To: ZeroMQ development list
Subject: Re: [zeromq-dev] ROUTER-DEALER missing connects/messages.


On Sep 25, 2012, at 10:05 AM, Dowd, Brian wrote:

> HI Michel,
>   Yes it is a multi-part message on the send side, however the first 
> part is just the identity/destination/address details (i.e. 
> client-1/client-2 etc), and the setIdentity() call in the "Client" 
> side of things associates thw two so that when the "client-1" is set 
> in the first part the ZMQ layer knows to send that message to the 
> "Client" that connected with identity "client-1" .... Also, just in case I did double check the rtdealer.c and it behaves exactly equivalently in that it does not loop as you suggest, but does it the same way as my java example more or less, I imagine looping woudl make sense when you are not using ROUTER/DEALER and do not know in advance how many parts there are ...
> 
> I dont believe it is the issue here.



I believe your issue is due to a race condition during startup. Simply put, when the ROUTER socket binds to an endpoint it does not actually create an outgoing queue *until* a client connects to it. So any messages written to the ROUTER socket will be dropped at first. Take a look at its behavior as documented in the zmq_socket man page. This dropping behavior (when there are no connected clients) may not be clear from that man page, but we do have it in the FAQ.

http://www.zeromq.org/area:faq

Putting a "sleep" in your server corrects this behavior because it gives the client threads a chance to start up and actually connect to the bound endpoint. When the ROUTER socket sees a peer, it creates an outgoing queue for it. Any subsequent writes to that ROUTER socket can now be placed in the queue (subject to any HWM limits).

To solve this, I recommend changing your client. Instead of each client thread creating its own context and socket, your main thread should create a single context and spawn all of the sockets that you will ever need, connect them, and then sleep briefly. Pass this connected socket to your thread constructor.

Also, anyone using ROUTER/DEALER sockets should read this write-up: http://www.zeromq.org/tutorials:dealer-and-router

cr

_______________________________________________
zeromq-dev mailing list
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev