Boost Users :
Subject: Re: [Boost-users] [asio] skipping data in tcp stream
From: Rudolf Leitgeb (r.leitgeb_at_[hidden])
Date: 2009-03-30 07:00:14
> I was thinking about it and got an idea, that I will read data until
> byte with 0 value is detected
> After this there will be a try to read the header. If the read header
> is corrupted (probably we are on the
> middle of the message body) then try again and again.. until normal
> header is read.
This sounds like a protocol with message framing like HDLC.
> I guess, connections will be very different - standard wire
> connections, gprs, 3g, wifi..
But note that apart from TCP/IP capabilities some of these
transfer media have their own error detection or correction
schemes in their underlying layers.
> And the aim is to provide max reliability with minimal cost - I try to
> count every byte and so also thinking about need to implement own
> additional checks for packet corruption.
Do you have any practical tests which show excessive error rates
for one of these channels (apart from dropped packets) ?
If these are indeed you channels, I would expect very low error
rates. Chances are a decent check sum over your whole packet would
do the job. If a packet turns out corrupt, you may as well drop the
connection and start from scratch. If it's imperative that you
maintain the connection, packet framing might be inevitable. If
you expect rare bit errors, a simple FEC scheme might be the solution,
since it avoids a lot of protocol overhead for data retransmits.
> Also I'm thinking about using UDP - as I understand, I will have lower
> reliability, but I will not need to skip any data - each message is
> delivered separately.
UDP introduces a number of additional hurdles which TCP/IP handles
for you: correct ordering of packets, handling of dropped packets,
simpe bit error detection. Be sure you know these implications before
you drop TCP/IP
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net