[zeromq-dev] i can't see what i am doing wrong

[Andrew Hume]

okay, i gather you sleep before you start. fine.

i can do a handshake around the exit thing IF i can find out if
the context is finished its work. is there a way to do that?

On Jul 6, 2010, at 3:23 PM, Brian Granger wrote:

> On Tue, Jul 6, 2010 at 9:52 AM, Martin Lucina <mato at kotelna.sk> wrote:
>> ellisonbg at gmail.com said:
>>> I have run into this many times.  The issue is that the SUB socket
>>> doesn't get the messages until it actually connects:
>>>
>>> If the PUB starts before the SUB, the PUB will start broadcasting
>>> before the SUB starts and the SUB won't get those messages that were
>>> sent before the SUB connects.  A PUB socket is like a radio  
>>> broadcast.
>>>  If you aren't listening, you don't get the messages.
>>>
>>> BUT (this is more subtle).  If the SUB starts before the PUB, you  
>>> will
>>> still miss messages.  This is because it takes a little bit of  
>>> time (I
>>> think 0.1 sec) for the SUB socket to realize the PUB socket has
>>> started.  In that short time interval, the PUB socket has already
>>> started sending and you miss a few.
>>
>> This should be a non-issue in the simple case where a user starts the
>> subscriber (process b in the example) 1st, then switches to  
>> another window
>> and starts the publisher (process a) 2nd.
>
> It depends on which side does the bind and which does the connect.  If
> the SUB socket does the connect you will still miss messages
> if you start SUB first.  The SUB socket will attempts to connect every
> 0.1 seconds and during that time it will miss them.
>
>> There is a more subtle thing going on here though which is that in  
>> process
>> a zmq_send() is async so this just means "queue for sending". If  
>> you queue
>> quicker than the *actual* send to the network happens and call  
>> zmq_term()
>> you will lose outstanding data.
>
> Yep, but hopefully that will be fixed.
>
>> There's no real solution to this right now except adding a sleep 
>> (100) in
>> the publisher, or as Brian says using some other way to  
>> synchronize "Start
>> of data" and "End of data".
>
>> -mato
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
>
> -- 
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>

------------------
Andrew Hume  (best -> Telework) +1 732-886-1886
andrew at research.att.com  (Work) +1 973-360-8651
AT&T Labs - Research; member of USENIX and LOPSA



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100706/371da3cf/attachment.htm>