[zeromq-dev] OOB abort of previously sent msgs?

[Martin Sustrik]

On 08/10/2010 03:13 PM, Matt Weinstein wrote:
> I figure I'll just treasure packets in the device until I know so I don't have to special case the code.
>
> I haven't looked at the REQ code but figured the sender's ypipe didn't show ready until the last packet of a train was received which would offer that opportunity.
>
> Otherwise an uncooperative writer could hang the device waiting for no MORE bit.
>    

Yes. That's the case.

Multi-part messages are just messages, nothing complex. They are 
assembled at the sender and sent in one atomic go.

Martin

>
>
>
>
>
>
> On Aug 10, 2010, at 5:29 AM, Pieter Hintjens<ph at imatix.com>  wrote:
>
>    
>> On Tue, Aug 10, 2010 at 2:30 AM, Matt Weinstein<mattweinstein at gmail.com>  wrote:
>>
>>      
>>> What I'd prefer is a zmq_abort(socket) that kills the most recent
>>> train of packets, as long as a SNDMORE == 0 packet has not been sent.
>>> These are likely to be sitting in a ypipe somewhere along the chain.
>>>        
>> I suspect the frames are sent out as soon as possible.  The atomic
>> delivery is actually done by receivers.  If you want the ability to
>> abort a multipart message, you either need to build it in memory, as
>> you're doing, or else add your own operational control on top.
>>
>> Here is a simple scheme: specify that the last frame in the request is
>> an operation, either EXECUTE or CANCEL.  Then to abort a job send a
>> CANCEL frame with SNDMORE=0.
>>
>> -Pieter
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>      
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>