Re: [Hampshire] TCP socket programming.

Top Page
Author: Andrew McDonald
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] TCP socket programming.

Reply to this message
gpg: failed to create temporary file '/var/lib/lurker/.#lk0x58605100.hantslug.org.uk.29457': Permission denied
gpg: keyblock resource '/var/lib/lurker/pubring.gpg': Permission denied
gpg: Signature made Thu Apr 5 18:55:34 2007 BST
gpg: using DSA key FCBBA9C8F2DEED36
gpg: Can't check signature: No public key
On Thu, Apr 05, 2007 at 04:47:17PM +0100, James Courtier-Dutton wrote:
> I have not done socket programming in a long time, so I was hoping
> someone from this list could help.
>
> Imagine a TCP session receiving data. This data is placed in a socket
> buffer until the application reads from the socket.
> a) Can the socket buffer be set to a fixed size?


By 'socket buffer' I'm assuming you mean the buffer you use in a recv()
call. If so, then yes, you get to decided how big this is. If there is
enough data the recv() will fill it, if there isn't enough data to fill
it then you'll get whatever is waiting for you. If there's too much to
fit in your buffer it will sit there until you ask for more.

> b) If the socket buffer gets full, will TCP backoff until the
> application has read from the buffer?
>
> My gut feeling is that TCP would have to back off, otherwise data
> would be lost, and in real life internet surfing, data is not getting
> lost, even if the application is a bit slow to respond.


Yes, the receiver advertises a window to the sender. The size of this
shrinks as the receiver's buffers fill up, and the senders flow control
slows down. If the sender was to send too much the receiver wouldn't
send an acknowledgement and the receiver would later retransmit it.

> Can someone point me to a document, or RFC possibly, that would
> explain clearly how things actually work.


With regards to sockets programming, a useful and practical overview
is:
http://beej.us/guide/bgnet/

The RFCs themselves aren't too helpful, because they are written for
TCP stack implementors rather than users. There are lots of RFCs
because TCP has been developed incrementally over the years. Though,
there is now a 'TCP roadmap' (RFC4614) which provides some sort of
overview of the complicated picture.

Andrew
--
Andrew McDonald
E-mail: andrew@???
http://www.mcdonald.org.uk/andrew/