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: Liwei <email@hidden>
- Date: Fri, 17 Oct 2008 03:43:02 +0800
Okay thank you both Ladd and Scott for the help. I think Quinn advised
trying the TCP_NODELAY option as well.
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.
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... ;)
2008/10/17 Scott Ribe <email@hidden>:
>> Well, I guess I'm too lazy to devise and write a protocol that allows
>> me to know clearly when each "packet" of data arrives.
>
> Prefix each logical unit (I'd call them "messages") with a length; that's
> all there is to it.
>
> Well, on the sending side anyway. On the receiving side you will have to
> write a loop that builds up the message, because you can't guarantee that a
> single read will get the whole message before returning.
>
> --
> Scott Ribe
> email@hidden
> http://www.killerbytes.com/
> (303) 722-0567 voice
>
>
>
_______________________________________________
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