Designing socket messaging format

[David Bolen]

"Steve Holden" <sholden at holdenweb.com> writes:

> While the above steps are useful in datagram-based application protocols
> they should not be required over, say, TCP, when if communications take
> place at all they will be error-free.

Not quite true.  TCP has a checksum, but it can be fooled by certain
types of single bit errors occuring multiple times.  No, it's not a
high likelihood of corruption, but it's not guaranteed error free
either.  In a prior life, one of our backbone links exhibited just
that sort of corruption and could be hell on TCP sessions.

It isn't common, and for most uses there's no need to layer on
additional verification, but for anyone needing true verification,
adding your own CRC or data validation meta-data is advised,
regardless of the underlying protocols.

>                                       But stream-based datagrame protocols
> are tricky, and inevitably result in the re-implementation of some (or all!)
> of TCP's complexity at the application level, as you describe above. That
> was why the web accepted the overhead of a TCP connection per interaction
> for HTTP 0.9, and then went on to design keep-alive workarounds in later
> versions as an optimization.

Of course, that's why when HTTP first started to see its use ramp up,
most backbones absolutely _hated_ it.  (probably still do for non-HTTP
1.1 connections)

Here we had spent years tuning TCP slow start and congestion
avoidance, all of which work best over an established stream that has
some "history" of behavior, and HTTP came along and kept making and
breaking short lived TCP sessions, giving the protocol no real time to
tune or to avoid overloading things.  In particular, many TCP streams
over large pipes will settle on a very equitable sharing of the
bandwidth - but not if they are all being created/destroyed
constantly.  Adding persistent connections back into HTTP 1.1 was a
_major_ improvement over the earlier versions.

The same problem is exhibited by various game protocols that are
datagram oriented with their own higher level control mechanisms, most
of which didn't play nice with other users of the stream.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/