[zeromq-dev] Handling disconnections; was:Questions about socket errors

Brian Granger ellisonbg at gmail.com
Thu Feb 11 20:48:51 CET 2010


Martin,

> There is a way. Do a non-blocking send. If the queue is full, it'll
> return EAGAIN.

Great, that is an easy way to handle this.

> The current PUB/SUB pattern is based on the idea of never-ending stream
> of messages from the publisher. Individual subscribers join the stream,
> receive messages, then leave the stream. In such a pattern, the
> publisher is not interested in whether particular message is delivered
> to anyone - same way as TV transmitter is not interested in whether
> there's at least one TV set receiving the signal.
>
> Maybe you have a different messaging pattern in mind? Describing the use
> case would be helpful.

I just sent another longer email describing our message routing
patterns in more detail.
In brief, we would like to use topics to route messages, but the
original sender needs to know for sure that the message gets to its
destination.

>>> 3. Each 0MQ socket handles N "connections". Supposing the connections are
>>> anonymous the disconnection notification would simply state "one of the
>>> connections was broken" - which is not of much use aside of keeping track
>>> of
>>> number of opened connections. What's the use case here?
>>
>> I am coming from more of an RPC style of thinking so thinking in terms
>> of messages
>> is different for me.  In an RPC context, it is typically perfectly
>> clear which connection
>> was broken and when.  It probably doesn't make sense to track
>> individual connections
>> being broken.
>
> In current messaging systems this problem is being solved by a "dead
> letter queue" - i.e. a queue where undeliverable messages are written.
> Maybe that would a good point to start thinking about disconnection issues?

OK, I didn't know what that meant.  That might be a nice way of handling this.
This gives a concrete way for the application to discover which messages were
not deliverable and then  make the appropriate decisions.

> Yes, please. The use cases is the most valuable contribution you can make!

See my latest email.

Cheers,

Brian

> Martin
>


-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list