[zeromq-dev] Can we customize a behaviour for in-mem queued messages after reconnect?

[Justin Karneges]

Yup. It's kind of ironic that TCP is viewed as a "reliable" protocol 
when in practice it barely provides it at all. What it does provide is 
automatic redelivery attempts which is quite handy, along with in-order 
delivery and flow control. These are great things, but an application 
desiring reliability will need to know about data receipt as well.

HTTP, SMTP, SIP, XMPP, etc, all provide their own ways of indicating 
successful data receipt, independent of TCP. It's redundant, but it's 
the way of the world.

On 12/20/2013 01:18 PM, Lindley French wrote:
> Yes and no. In general, yes, you're absolutely right. On the other hand,
> if you don't mind opening a new TCP connection for each transaction (not
> always ideal, but not always bad; it depends), then a successful TCP
> close is equivalent to a transaction ack.
>
> I'm starting to think a *lot* of reliability protocols built on top of
> TCP could be done more efficiently if TCP could expose some read-only
> information about its internal ACKing....
>
>
> On Fri, Dec 20, 2013 at 4:13 PM, Stephen Hemminger
> <stephen at networkplumber.org <mailto:stephen at networkplumber.org>> wrote:
>
>     On Fri, 20 Dec 2013 15:01:04 -0500
>     Lindley French <lindleyf at gmail.com <mailto:lindleyf at gmail.com>> wrote:
>
>      > The problem, in my view, is that normally you can trust TCP to
>     get your packets through intact.
>
>     Applications only know it made it to the socket queue, not that TCP
>     ever sent it and got
>     an acknowledgment or that the remote application got the message. To
>     do reliable communication
>     you need an end-to-end acknowledgment. This doesn't have to be on a
>     per-packet basis but
>     on a per-transaction basis. Think of what SCP/FTP do for file transfer.
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>