Re: Does TCP-based message corupption means a broken connection?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hi all,

Things are clear for me now.

Thanks alot,

"R.Wieser" wrote:

Hello Tran

The thing I'm wondering is that is there a chance a correct
message sent was corrupted on the way due to a network
error (e.g. it was changed or was partially received...) so
that the receiver could not parse the message?

Highly unlikely. As boris mentioned, there are several checksums inside a
such packets (the payload gets wrapped in several layers (like an union) all
adding their own checksums), and all of them getting "changed" exactly such
that the message is valid, but still broken is a *very* small chance.

Given that the receiver works ok, there are two possible issues:

There is at least a third you have to recon with : the message has not yet
arrived in full. A send message gets broken up in packets of no more than
(if my memory serves me correctly) 1.5 KByte, and get re-assembled in the
recievers buffer.

This means that when you read an incoming message you might only have a
partial header/message (the first packet of several), and you will have to
wait until you have read the whole of it (read: at least a headers worth of
data) before beginning to parse it.

Allso, when you read a message the header of the *next* message might be in
the tail of that one (you have to split the messages at application level)

So in the later case, does it worth to resend the message? Or does
"bad data" always mean the socket has broken and we should close
the connection immediately as it is no longer usable?

Most allways the latter. Received packets with bad checksums do normally
not ever reach the application-level, but get handled by the TCP/IP stack (a
"resend" command is issued for you).

In short : a TCP connection does all the checking and resending for you.
When your application gets the signal some data is waiting you may assume
that its payload is exactly as the other side send it.

Regards,
Rudy Wieser


-- Origional message
Tran <Tran@xxxxxxxxxxxxxxxxxxxxxxxxx> schreef in berichtnieuws
38DA8EA8-CBF1-4376-AC76-68AFF72816BF@xxxxxxxxxxxxxxxx
Hi Rudy,

Thanks alot for your comments. I know exactly what you mean. If the
message
was not well-structured by the sender or was not well-parsed by the
receiver
then it is application error. The thing I'm wondering is that is there a
chance a correct message sent was corrupted on the way due to a network
error
(e.g. it was changed or was partially received...) so that the receiver
could
not parse the message?

The use-case would be: The receiver detects that an expected message
header
does not appear at the begining of the receiving buffer. Given that the
receiver works ok, there are two possible issues:
- The sender has sent an unknown message. In this case receiver can close
the connection as the sender is untrustable.
- The message was corrupted on the way (e.g. it was changed or was
partially
received). In this case we may find the next message header by navigating
the
receiving buffer. The first part of the receiving buffer is considered
"bad
data".

So in the later case, does it worth to resend the message? Or does "bad
data" always mean the socket has broken and we should close the connection
immediately as it is no longer usable?





.

Relevant Pages

  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
    (comp.lang.perl.misc)
  • Re: Does TCP-based message corupption means a broken connection?
    ... that the receiver could not parse the message? ... A send message gets broken up in packets of no more than ... when you read a message the header of the *next* message might be in ... a TCP connection does all the checking and resending for you. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Sports Bar Hum Job Questions
    ... A certain amount of hum seems related directly to the Onkyo receiver ... CD player AC power was sourced from an outlet on the back of the ... Lots of hum when Onkyo fed by TiBook running on power supply. ... connection at a time and see the effect of each individual ...
    (rec.audio.pro)
  • Re: Deaf CAsyncSocket on Windows Service.
    ... To read them out I need a buffer to ... Short packets at the sender are coalesced into longer packets. ... THe receiver says "I have this much buffer space" and the sender is free to send ... You get an OnReceive notification if there is input data to be read. ...
    (microsoft.public.vc.mfc)
  • Re: Processs PreciseMail AntiSpam Gateway - any experience so far ?
    ... >> before closing the connection. ... Instead you have the sender picking the port ... if the receiver ESP can make that work. ...
    (comp.os.vms)