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

[Stephen Hemminger]

On Fri, 20 Dec 2013 16:18:52 -0500
Lindley French <lindleyf at gmail.com> 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> wrote:
> 
> > On Fri, 20 Dec 2013 15:01:04 -0500
> > Lindley French <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.
> >

TCP close is not a synchronization point. The OS may decide to drop
unsent, unacknowledged data there is no guranteed it got ack'd and even
less assurance that the server read it.