Re: Incomplete lines received by a socket

From: William Ahern (william@wilbur.25thandClement.com)
Date: 04/21/03 

From: William Ahern <william@wilbur.25thandClement.com>
Date: Mon, 21 Apr 2003 13:26:20 -0700

Jacques Guellec <jguellec@free.fr> wrote:
> Kurtis D. Rader wrote:

>> If your server calls send() there is no guarantee that all the data will
>> be returned by a single recv() call in the client. TCP does not transport
>> messages, it transports individual bytes. The block of bytes presented to
>> the send() call may be transmitted in multiple IP packets. It is up to you
>> to code the data receipt function in the client to reconstruct application
>> messages. This is usually done by performing the recv() in a loop until
>> an entire application message has been captured.
>>
>> When Mr. Schwartz suggested you do a search for "tcp" and "byte-stream
>> protocol" he was assuming you knew about Google's searchable usenet
>> archives. Go here
>>
>> http://groups.google.com
>>
>> and enter the search terms Mr. Schwartz suggested.
>
> Hi, :-)
>
> Thanks for your answer,
>
> Yes, I know groups.google.com, but this time (don't know why) I thought Mr
> Schwartz was speaking only about docs and RFCs and I only made some search
> on standard google and in the doc he gave me.
>
> Ok, so you say the recv may be in a loop. I understand better now, the issue
> begin to clarify.
>
> I was currently trying to reinvent the wheel.

maybe not reinventing the wheel, 'cause by saying that it almost sounds like
your missinig the point. in Unix (and most modern operating systems) you
wait on an event, not poll for events. in other words, rather than
constantly checking for some condition over-and-over, the operating system
hides all of that (that's not to say the operating systems loops w/ a
sleep() call either). you tell the operating that you want to wait for N
amount of bytes to come in, through something like read(). usually it will
not return until all the bytes have arrived. there are exceptional
conditions which will return before the conditions you requested have been
met. you must be prepared for that, but avow yourself of thinking that you
have to constantly poll() for conditions (don't confuse this w/ the poll()
system call ;)

when you coneptualize how network programming works, there shouldn't be an
ethernet cable or any hardware devices in your imagination. imagine somebody
laying around, watching tv, and then the phone rings. the person isn't
hovering over the phone, picking it up every 10 seconds to see if there's a
call. the phone rings when there's a call. it tells you, you don't have
to keep watch over it.

Relevant Pages

  • Re: Messages being received out of order
    ... sure how much your data will be send in one packet, because if IP header is ... Are you saying that tcp assures you that if you send data1, ... then I only need to fix my client - specifically the recv handling? ...
    (microsoft.public.win32.programmer.networks)
  • Re: sending structure client server
    ... This is the basic algorithm for a client app, ... On a blocking socket, recv() will return when /any/ bytes are available, ... that's what's always done with stream sockets. ...
    (comp.unix.programmer)
  • Re: Segmented Data Over Sockets
    ... Just as others explained, if you sendN bytes from the client, it does not ... mean that a single corresponding recv() on the server will receive N bytes. ... each byte of the local structure on the receiving end, ...
    (microsoft.public.win32.programmer.networks)
  • Re: Receive binary file through recv
    ... I am trying to send a binary file from the client to the server. ... | the parameter ptr in recv() to the file descriptor of the newly ... a file descriptor because all that is really passed to the function ...
    (comp.unix.programmer)