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 04:06:36 +0800
Oh yes, anybody with any idea of why my application is having this
weird behaviour I mentioned in the first email?
2008/10/17 Liwei <email@hidden>:
> 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