Re: CSocket problem

From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 06/11/04


Date: Thu, 10 Jun 2004 21:28:42 -0400

TCP won't lose bytes. Your program might fail to read them properly, or accidentally
discard them, but the network stack will not fail to deliver them. So if you don't see
them, it is an error in your program.
                                joe

On Fri, 11 Jun 2004 00:05:06 +0200, "Riverwind" <riverwind@heaven-dk.NEJ_TIL_SPAM> wrote:

>"Joseph M. Newcomer" <newcomer@flounder.com> skrev i en meddelelse
>news:933hc0pgkiofrbevdpd3b086735lo3inoa@4ax.com...
>> You have confused "message" with "stream". A byte stream means exactly
>that: you get a
>> stream of bytes. The amount you receive in a given receive call has
>nothing to do with the
>> number that were sent by a send call. It is ALWAYS legitimate for a
>receive call to return
>> you fewer bytes than a send call; you must do multiple receive calls to
>get the data you
>> want.
>>
>> The only guarantee TCP gives you is that eventually, through a sequence of
>receive
>> operations, you will receive every byte that was sent, in order, with no
>duplicates and no
>> drops, or both the sender and the receiver will get an error code
>indicating this could
>> not be done. Otherwise, there are no promises. You have assumed that if
>you send, say, 8K
>> bytes, your receive will receive 8K bytes. This is extremely unlikely.
>>
>> You will have to put in some form of message delimiter, byte count, or
>something else, if
>> you want to impose some concept of :"message" on the byte stream. TCP has
>no concept of
>> messages, and has no responsibility to deliver other than what it
>promises.
>> joe
>
>Maybe I was a bit vague in describing the problem, but the application does
>interpret the byte stream as messages, through a count, which tells me
>exactly how long the message is, so basically I have no problem with
>messages split over several calls to Receive(..). I will have to check the
>sender code to see if it handles the WSAEWOULDBLOCK return value, as Scott
>writes.
>Right now the problem is that apperantly some bytes are lost, and I will go
>totally off track reading the message length.
>Thanks for the help.
>
>/Riverwind
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm



Relevant Pages

  • Re: KB192570 done right: Asynchronous sockets in threads
    ... that it will lose data, not report any errors, fail in a Unicode build, fails in a 64-bit ... build, and pretty much gets sockets, threading, and synchronization completely wrong. ... MVP Tips: http://www.flounder.com/mvp_tips.htm ...
    (microsoft.public.vc.mfc)
  • Re: RAPI problems
    ... Jon Skeet [C# MVP] wrote: ... Unless ActiveSync ... >> fail. ...
    (microsoft.public.dotnet.framework.compactframework)
  • kdelibs portupgrade prob
    ... This is one of the numerous kde* ports that fail to upgrade for 1 reason or ... *** Error code 1 ...
    (freebsd-stable)
  • Re: How to tell when execv has succeeded
    ... fail. ... Start new program running ... If step 2 fails, it returns with an error code, but the descriptors ... The kernel must be left in a consistent state. ...
    (comp.unix.programmer)
  • Re: Error code:0x000000d1(0x00000000, 0x0000002,0x0000008, 0x0000000)
    ... running on MEMTEST32 but no error found on the RAM. ... Please recheck the Bug Check code in the Stop Error code. ... Does it occur in Safe Mode? ... Run scan disk and disk defragment (Fail) ...
    (microsoft.public.windowsxp.general)