[zeromq-dev] SUB abandon receiving a multipart message

2018-08-08 Thread Al Grant
Counterpart to my question about abandoning a multipart send... A subscriber might decode part way through receiving a multipart message, that it's not interested in the rest (and the condition isn't simple enough to do as a topic match - or it might be a resource issue). The subscriber needs to

Re: [zeromq-dev] Abandon a multipart message?

2018-08-08 Thread James Harvey
The multipart send is already available in the C++ higher level libraries. I am sure other libraries based on zeromq will offer their own version. https://github.com/zeromq/cppzmq/blob/master/zmq_addon.hpp#L45 From: zeromq-dev On Behalf Of Al Grant Sent: 08 August 2018 16:10 To: ZeroMQ

Re: [zeromq-dev] Abandon a multipart message?

2018-08-08 Thread Al Grant
On Wed, Aug 8, 2018 at 2:04 PM, James Harvey wrote: > You could send a zero length message with no (SND_MORE) flag to signify > that’s the last part. > > I could, or I could send a part with a special payload, but either way the sender and receiver have to agree on how to recognize an abandoned

Re: [zeromq-dev] Abandon a multipart message?

2018-08-08 Thread James Harvey
You could send a zero length message with no (SND_MORE) flag to signify that’s the last part. From: zeromq-dev On Behalf Of Al Grant Sent: 08 August 2018 12:56 To: zeromq-dev@lists.zeromq.org Subject: [zeromq-dev] Abandon a multipart message? Is there a way to abandon a multipart message if

[zeromq-dev] Abandon a multipart message?

2018-08-08 Thread Al Grant
Is there a way to abandon a multipart message if for some reason I can't complete sending all the parts? I.e.: zmq_send(pubsock, ... ZMQ_SNDMORE) ... decide I don't want to send the rest of the message ... zmq_abandon(pubsock); // does this exist Without this, there's a risk that the

[zeromq-dev] PUB message HWM dropping policy

2018-08-08 Thread Al Grant
The docmentation of zmq_socket states: "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." I can see two

Re: [zeromq-dev] Blocking when receiving multipart messages

2018-08-08 Thread James Harvey
Hi, Yes the message is atomic and you can assume all parts are available immediately once the first part has arrived. In general if I create anything that cares about blocking on the receive side I always end up using zmq_poll() and handle it that way. Part of the reason being it leaves it

Re: [zeromq-dev] Blocking when receiving multipart messages

2018-08-08 Thread Luca Boccassi
On Wed, 2018-08-08 at 10:58 +0100, Al Grant wrote: > I'm receiving multipart messages on a SUB socket and I want to make > my > code non-blocking. The docs say that a multipart message is delivered > atomically. Can I read that as a guarantee that, if there is a 'more' > indication > after a

[zeromq-dev] Blocking when receiving multipart messages

2018-08-08 Thread Al Grant
I'm receiving multipart messages on a SUB socket and I want to make my code non-blocking. The docs say that a multipart message is delivered atomically. Can I read that as a guarantee that, if there is a 'more' indication after a previous part, a zmq_recv() on the next part will never block but