size of socket.recv buffer

[Mike C. Fletcher]

socket.recv is letting you specify the maximum amount returned, it 
doesn't wait for new information to fill the buffer before returning, it 
just returns up to maximum from what has been received at the current 
time.  It will only wait for information if there is _nothing_ yet 
received and you've specified blocking sockets (default).


Here's a simplified timeline (caveat, I don't use TCP much, just UDP, so 
I might be getting some of the TCP semantics messed up):

packetReceivedByPort -> puts fractional message into OS-level buffer

packetReceivedByPort -> puts fractional message into OS-level buffer

OS-level buffer is now full, OS TCP stack signals server to stop sending 
packets, as it can't deal with any new data until the OS-level buffer is 
read/recv/cleared [I'm assuming TCP does this explicitly, I normally do 
with my own networking code]

[repeat these two steps]
mySocket.recv( ..., X ) -> gets up to X bytes from the OS-level buffer

OS TCP stack tells the server to continue sending, as it can down deal 
with the new data.  Buffer re-fills.


When mySocket.recv( ..., X ) -> returns "", your TCP connection is no 
longer sending information, you got the whole thing, charge onward.


Note:
	Special case for blocking sockets if there is nothing currently in the 
buffer is to wait for the next packet before returning.  Also note that 
with length-of-data information, you can stop reading when the length of 
the received data == reported length (changing X so that the max 
returned == just enough to get the last byte of the desired information).

Look at the standard library's various network-aware code, you'll see 
lots of while loops for reading from sockets :) .  I'd personally 
suggest asyncore as a good module for study (it uses non-blocking 
sockets by default, incidentally).

HTH, and enjoy,
Mike

Locke wrote:
> The argument to recv is supposed to be the buffer, acording to the
> documentation. But the doc doesnt say: buffer measured in what? Is it bytes?
> Octets? (by the way, what is the diff between a byte and an octet?)
> 
> See, I am writing a pop3 client type thing, after requesting a message from
> the server, my first s.recv tells me how long the message will be in octets.
> So then I call s.recv again passing the number of octets as the argument to
> s.recv. Shouldn't this download the entire message? What actually happens is
> that it cuts off right in the middle of the message.
> 
> What's my problem? Is there an upper limit on what the buffer argument can
> be to recv? Or does pop3 just refuse to send the whole message with one call
> to recv? I don't think it is that, because what it sent me was like 600some
> characters, which isnt a power of two or any other computer-ish number.
> 
> Thanks
> 
> 
> 


-- 
_______________________________________
   Mike C. Fletcher
   http://members.rogers.com/mcfletch/