[zeromq-dev] Discussion on ROUTER action

Pieter Hintjens ph at imatix.com
Sun Dec 9 22:30:38 CET 2012


Min,

I think it's accurate to return EAGAIN when the pipe is full, as
compared to EHOSTUNREACH when the identity is unknown, and both
triggered by the same ZMQ_ROUTER_MANDATORY option.

-Pieter

On Sun, Dec 9, 2012 at 10:22 PM, Yu Dongmin <miniway at gmail.com> wrote:
> Hello,
>
> OK, now an issue seems to be
>
> - Do an application need to distinguish between the target pipe is full and
> doesn't exist
> - What would be a desired action when pipe is full ? (Now it silently drops
> and returns a success)
> - What is the expected behaviour on ZMQ_ROUTER_MANDATORY when pipe is full
> or pipe doesn't exist
>
> Basically, we must have a way to know the ROUTER failed to send when the
> target pipe is full.
>
> My first assumption ware
>
> - An application need to tell them
> - An application wants the ROUTER to handle the full until the pipe is
> ready.
>
> Another thought was
> - If an application has to handle the failure (by resending or logging),
> because a peer can reconnect, knowing the cause might not be meaningless
> - A thread should not block when one of peer is full.
>
> My pull request was based on the second. Application has to deal with the
> failure whatever the reason is and I have to rewrite all the router-router
> proxy (device) to add a retry.
>
> But I still miss a third option that the ROUTER handle the by returning
> EAGAIN. :)
>
> It could be easier in a situation than adding a retry to every router when
> an application wants to handle the full.
>
> Thanks,
> Min
>
> On Dec 9, 2012, at 7:13 PM, Doron Somech <somdoron at gmail.com> wrote:
>
> Hi,
>
> Min i took a look at the code and in case of pipe full or identity doesn't
> exist you are returning the same error, right? i think it better in case the
> pipe is full to return eagain, then the SocketBase send method will continue
> to try sending the message until timeout or message is sent. also at the
> application code i can see a different handling of pipe is full and pipe
> doesn't exist.
>
> Doron
>
> What do you think?
>
> On Fri, Dec 7, 2012 at 3:24 PM, Min <miniway at gmail.com> wrote:
>>
>> OK,
>>
>> I'm going to send a pull request as the ZMQ_ROUTER_MNDATORY covers the
>> counterpart full case also.
>>
>> Thanks
>> Min
>>
>> 2012. 12. 7. 오후 9:24 Pieter Hintjens <ph at imatix.com> 작성:
>>
>> > Hi Min,
>> >
>> > I think you could extend ZMQ_ROUTER_MANDATORY to this. Mandatory means
>> > the message must be deliverable, or you get an error.
>> >
>> > -Pieter
>> >
>> > On Thu, Dec 6, 2012 at 4:36 AM, Yu Dongmin <miniway at gmail.com> wrote:
>> >> Hello,
>> >>
>> >> As we all know, ROUTER drop messages when 1) a counter part doesn't
>> >> exist and 2 ) a counter part is full.
>> >>
>> >> In case of 1) we can catch the case by setting ZMQ_ROUTER_MANDATORY.
>> >> But in case of 2) ROUTER drop message silently and the send returns 0.
>> >>
>> >>
>> >> Server side ROUTER-DEALER pattern including the proxy (a.k.a device) is
>> >> hard to use as I need another treatment at client side.
>> >>
>> >> To make a client simple and avoid the second case of silent dropping, I
>> >> have to increase the HWM or unlimited but it could blow memory.
>> >>
>> >>
>> >> We might need an another option to detect second case. By detecting the
>> >> case, ROUTER user can decide whether he drop it silently (default action),
>> >> resend it or wait the counter part is ready.
>> >>
>> >>
>> >> My idea is (please ignore option names, they are just examples) in the
>> >> case of 2)
>> >>
>> >> if ZMQ_ROUTER_WAIT set router.xsend returns -1 with EAGAIN so system
>> >> can wait the counter part is ready
>> >> Otherwise returns -1 as user can do his treatment.
>> >>
>> >> Thanks
>> >> Min
>> >> _______________________________________________
>> >> 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
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list