[Standards-JIG] reliability: fuel for the fire

Dave Cridland dave at cridland.net
Mon May 8 23:02:19 UTC 2006

On Mon May  8 23:38:42 2006, Tijl Houtbeckers wrote:
> On Tue, 09 May 2006 00:22:20 +0200, Peter Saint-Andre 
> <stpeter at jabber.org>  wrote:
>> http://iang.org/ssl/reliable_connections_are_not.html
> That's a good collection of some of the things we've been saying 
> for a  while now on the list.

Yes, although it's worth noting that TCP isn't intended to be 
reliable in the sense of "the data will get there", but only in the 
sense of "the data, if it gets there, will be ordered". Any 
acknowledgement which might make reliability happen can get lost, 
whether or not the data got there, so there's no way of knowing if 
the data arrived or not. I'm somewhat confused by the article 
claiming that you need to reimplement TCP as a result (you don't, you 
need to add in the additional pieces), or that this is somehow a 
failing in TCP (it's not, it's just logic in play) or the 
application's interface (the application can fail well after receipt 
of data, so this point is moot).

>  The other subject it touches can be intresting too,  using TCP in 
> practise doesn't garantue the data you send arrives intact  either 
> (despite checksums and all that). That's less of a fundamental  
> problem though, I think.

Ah, yes, the "Game mode", or, more generally, broken ALG. That's very 
much an edge case, for a start, and also I'm not even sure it really 
happens anymore. Besides which, from a protocol design point of view, 
this is not something anyone should worry about - in effect, it's 
impossible to fix - if your router is messing about with packets, 
then nothing will work anyway.

           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

More information about the Standards mailing list