[zeromq-dev] Fundamental question on ZMQ. How to determine message fail/success without HWM-arking?

[artemv zmq]

Ok ...

But if back to ZMQ.  Why setting hwm to 0 or negative value  doesn't help?
 Shouldn't this render the fact that user wants to get success/fail upon
send immediately?

I much hoped  that hwm=0 would help. Because it sounds logical -- no hwm,
just try send message and fail.  But send  is passing (!!)  even with
hwm=0. Is not this bug?


BR
-artemv


2013/12/5 Lindley French <lindleyf at gmail.com>

> No, there's no contradiction. The requirement to know whether or not
> something was delivered doesn't imply that thing has to be delivered.
>
> I recently implemented a messaging framework (unrelated to ZMQ) that went
> out of its way to let the sender know whether or not delivery was
> successful. Here are the difficulties I encountered:
>
> 1) I used TCP as the underlying protocol. Since you can't get at TCP's ACK
> packets directly, you either need to do your own ACKing above TCP, or else
> use one connection per message. Neither option is ideal. A better choice
> would have been to use raw sockets so more TCP information is available, or
> else build a new protocol on top of UDP.
>
> 2) ACKing only ensures that the sender knows for sure that something has
> been delivered. If the ACK gets lost, then the sender might *think* it has
> not been delivered, when it really has been. To solve this, you need a
> second ACK (an ACK-ACK, if you will); and furthermore, you can't deliver
> the message to the receiver until it has received the ACK-ACK from the
> sender. This can impose extra latency.
>
>
> On Thu, Dec 5, 2013 at 1:46 PM, Laurent Alebarde <l.alebarde at free.fr>wrote:
>
>>  "we don't care if message will get lost on a network" + "we don't need
>> guarantee deliveri"
>>
>> isn't it contradictory with:
>>
>>
>> "for every single message how to know : whether it was delivered or not"
>>
>> Probably PUB/SUB is what your architect is looking for.
>>
>> Le 05/12/2013 19:25, artemv zmq a écrit :
>>
>> I personally has been thinking about next solution:
>>
>>  - message sender sets send_hwm=0. And that's it.  But problem is that
>> socket.send()  returns "true"  even if I send to unexisting peer.
>>
>>
>> 2013/12/5 artemv zmq <artemv.zmq at gmail.com>
>>
>>> Hi,
>>>
>>>  My name is Artem. I stay with ZMQ (on java) a year or so. Got a cool
>>> question for you, ppl!
>>>
>>>  Here's my story. Recently I entered a new company (gambling games),
>>> after working few weeks, after getting accustomed with a code, I found that
>>> they are building very-unnecessarly-complex-distibuted-application ...  I
>>> was unhappy few days, because couldn't even imagine how to support ALL THAT
>>> CRAP in an upcoming future. So I suggested ZMQ hoping that ZMQ will "open
>>> eyes" to others.  But, as a feedback I got one big fundamental concern
>>> (from chief architects):
>>>
>>>  - we have to know only one thing about every message: it has been
>>> delivered onto remote peer or not
>>>
>>>  And few additional comments:
>>> -we don't care if message will get lost on a network
>>>  - we don't need guarantee deliveri
>>> - no RPC / everything is asynchronous
>>>  - we don't need HWM
>>>
>>>
>>>  So I'm here, because I really can't address this question: "for every
>>> single message how to know : whether it was delivered or not" .
>>>
>>>  Thanks in advance. And appreciate for your help.
>>>
>>
>>
>>
>> _______________________________________________
>> zeromq-dev mailing listzeromq-dev at lists.zeromq.orghttp://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131206/c3f11957/attachment.htm>