[Standards-JIG] Re: What happened to the ACK proposal?

Ian Paterson ian.paterson at clientside.co.uk
Tue Aug 16 15:13:53 UTC 2005


> Except that the server has no way of knowing that you are  
> online.  All the server knows is that you were online at
> some point within the last 60 seconds.  The server can 
> then put the message into your socket and pray.  Meanwhile,
> it tells the sender that the message was delivered.
> Unfortunately, your connection was interrupted 20 seconds
> ago, so the message is dropped. Silently.

The server should not tell the sender the message was delivered until it
receives the TCP ACK. If it doesn't receive the ACK within a configured
time then it should close the stream and store the message for later
delivery (assuming it can't be delivered to another resource).

> The next time the server tries to write to your socket (or
> maybe the time after that, depending on how often you get
> messages), it will get a write error and fail.

This is a problem with the implementation of TCP. The application should
be told as soon as the previous ACK fails to appear within the
configured time.

> That's what you get for using a protocol designed for 
> interconnecting networks over high-loss physical 
> connections as your transport layer. Ain't the Internet
> grand?

This case does not highlight a problem with TCP. It highlights a problem
with bad TCP implementations (which unfortunately seem to be the norm).


XMPP devolves to the transport layer responsibility for a) confirming
delivery over a hop, and b) detecting broken connections. XMPP isn't
supposed to know or care which transport layer is being used. Should RFC
3920 be changed just because implementations of TCP are bad?

The fact that TCP ACKs every single packet sent should be sufficient to
provide a) and enable b) - via whitespace pings. (These pings are
optional with TCP since most protocols that run over it don't need
them.)

Perhaps we need an informative JEP that describes exactly how XMPP may
be transported over the TCP *protocol* in a perfectly reliable way? The
JEP would document the way applications currently extend the TCP
transport layer with pings.

One section of the JEP could discuss the problems with various existing
TCP implementations, thus providing a basis for our efforts to get TCP
implementations fixed. We could then have this discussion somewhere
else, to encourage the people responsible for the bad implementations to
fix them. After all, XMPP applications aren't the only ones that would
benefit.

IMHO the implementors will listen. [Until recently many OSes, including
Linux, could not maintain tens of thousands of inactive connections.
Linux 2.6 introduced new APIs to fix the problem.] We might end up with
a new connection class for Java.

However, if we don't get any joy from the TCP implementors, then perhaps
the TCP transport JEP could also define an optional extension to the
TCP-transport layer which works around the problems with bad TCP
implementations. This would work above the TCP layer but *underneath*
the XMPP layer (i.e. at exactly the same level as whitespace pings and
JEP-0124 HTTP Binding do today). This protocol might be similar to the
one Justin proposed, but it would be negotiated *before* the stream. It
could conceivably (but not necessarily) be transported in the character
data between stanzas (i.e. without XML).

- Ian




More information about the Standards mailing list