Re: [Boost-users] [asio] skipping data in tcp stream

Subject: Re: [Boost-users] [asio] skipping data in tcp stream
From: Rudolf Leitgeb (r.leitgeb_at_[hidden])
Date: 2009-03-30 03:34:32

> 1) if header is corrupted under some cases (header crc says body len
> could be wrong) then as I understand we must skip all body data and
> read the next message.
> How to skip? async_read_until seemed to be the solution, but manual
> told that it may read surplus data into streambuf - it will be hard to
> deal with that data because I am reading directly from socket to some
> allocated memory (as was told above)

How do you know the number of bytes you have to skip? If you determine
that your header is corrupted, the length info can't be trusted any  
more.

You'd have to employ some framing method for your packets so you can
reliably detect the next packet start. In this case you shouldn't skip
a given number of bytes but rather until a new frame start can be  
detected.

> 2) actually, can it be that in tcp stream data will be corrupted? I
> guess, yes - so header contains bodylen and crc for body and for
> header? is such solution an overhead?

It's theoretically possible, but very unlikely. Note that TCP/IP
employs checksums itself and should retransmit any packet which is
detected as faulty. IIRC it's only a 16 bit checksum, so if you throw
completely mangled data every 65536th packet would make it through
the check sum (statistically of course). Note that you'd have to have
a very unreliable media for that to be of concern, something which
would make normal communication next to impossible.

> 3) maybe I do some global design mistakes?

Before you delve into check sum protection for you data too much,
you should check what TCP/IP already has to offer. Do you have an
analysis of your expected error pattern (bit errors, dropped bytes,
erased bits, bundle errors) ? What's the acceptable error rate of
the data you transfer ? What's the error rate of your TCP/IP channel ?