Hi Pieter,
> > Just want to clarify something in the documentation for ZMQ_PUB:
> >
> > "When a ZMQ_PUB socket enters an exceptional state due to having reached
> the
> > high water mark for a subscriber, then any messages that would be sent
> to
> > the subscriber in question shall instead be dropped until the
> exceptional
> > state ends."
> >
> > So, if I start sending on a pub channel with no connections, it
> will
> > queue up a bunch of messages and then "not block", just stop queuing and
> I
> > assume zmq_send will not return an error if you keep calling it? This
> is
> > all fine except it is problematic overall as it is unneeded and can
> cause
> > some problems.
>
> Kelly, if there are no connections, no subscribers, then the PUB
> socket can't enter an exceptional state. If you send to a PUB socket
> without any connections the messages are dropped.
Thanks for the clarification: that had me all hot and bothered when
I started looking at possible issues for my little status monitor services
when ported to zmq. Just a thought, it may be a good idea to specifically
state that is the case in the documentation. I.e. "If there are no
connections, all messages are simply dropped." Just a little clarification
for the specific case. (I didn't see it described anywhere at least.)
I still would like a response to the last item, which I imagine you
didn't read past the obvious misunderstanding so was easily missed. :)
So, if I have a subscriber to a pub socket, is there any indication
that I missed a message because for some random reason I lost temporary
connection, got rerouted, the machine decided to think about God for a
couple minutes whatever?
If not, does it make sense to maybe post a zero length message on
PUB channels (maybe only if they set a flag?) so anything which "must"
receive all messages without interruption can detect a case where it fell
behind and missed something? The obvious answer is to add an id to my
messages, which I've already added back when I thought about this issue.
But, for simple pubs that's literally 1/4th of the bandwidth just to make
sure that the data is uninterrupted.
KB
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
