Re: Force packetise and interesting phenomena with two listening sockets
Re: Force packetise and interesting phenomena with two listening sockets
- Subject: Re: Force packetise and interesting phenomena with two listening sockets
- From: email@hidden (David E. Gelhar)
- Date: 16 Oct 2008 22:06:46 -0400
--- Liwei <email@hidden> wrote:
You mean I should prefix say the first 6 bytes to specify a simple
header with the length of the message that follows? I've got a
question though. How do I know that I'm not mistaking my header for
the actual message that looks like a header, other than escaping them?
I'm supposed to be able send any form of data with it, so a clash is
likely. Is escaping the only method? I thought having to escape a
whole phrase with a variable length number would be either quite
complex, computationally intensive or inefficient.
--- end of quote ---
No escaping needed. As long as you always write <header><message> <header><message>...
there's never any doubt.
--- You wrote:
Rephrase: How do actual data transport mechanisms do it anyway? What
prevents, say TCP or UDP from knowing that what it is receiving is a
real header (TCP or UDP header here, not my message header) and not
part of the payload if you can't be certain of the link quality (since
if a loss occurs from the start of the payload to exactly the end, to
the receiving side it'll just look like a header followed by another
header)?
I have a feeling that the answer may be that there is just no way to
know and the best method would be to use a sufficiently comprehensive
header such that it can detect and reject most errors. But just in
case there is a way... ;)
--- end of quote ---
Fortunately, it's nowhere near that hard! TCP provides a reliable byte stream,
so you don't need to worry your transmission being garbled by a low-quality link.
If you are using TCP, you can count on the fact that the data you write() on one
end will come out exactly the same when you read() the other end, regardless of
how bad the network in between is. It may be *slow* on a bad link, if TCP has
to retransmit packets that were not received correctly, but you don't need to
fear that the data you receive has been corrupted in transit.
Still, it's not a bad idea to include a "magic number" in your header that you
can use as a consistency check to ensure you're not out of sync. Not because the
network might screw up, but in case there's a bug in your code that somehow causes
you to lose track of where the next header should begin.
As to how TCP itself does this:
Even though TCP provides a byte-stream interface to you, at a lower level it's
built upon packet-oriented protocols. So figuring out where the header begins
is never a problem for TCP; packet boundaries are handled at a much lower level
(like in the ethernet hardware). The network protocol stack (TCP, IP, ethernet)
has multiple levels of CRCs and checksums to detect data loss/corruption. Whenever
a corrupted packet is discovered it is simply dropped; the TCP retransmission
mechanisms will take care of re-sending it.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden