sockets and classes

Robert Amesz reqhye72zux at mailexpire.com
Sun Aug 5 17:33:26 EDT 2001


TheDustbustr wrote:

Well, Steve Holden gave you an answer with respect to the returning-of-
None problem (I'm sure he's right about it). I also have the distinct 
impression that the parse() member function does not parse things the 
way the RFC intended, but I'm too lazy to look it up. I do remember 
that there is a general way to parse it into command/arguments/data, 
which does not depend on the type of command.


>     data = irc.sock.recv(2048)
>     log.raw.write(data)
>     arg = irc.parse(data)


That is not the way to do it. The manual says:
   recv(bufsize[, flags]) 
     Receive data from the socket. The return value is a string
     representing the data received. The maximum amount of data to be
     received at once is specified by bufsize. See the Unix manual
     page recv(2) for the meaning of the optional argument flags; it
     defaults to zero.

So there's no guarantee about how much data actually is read in 'data', 
except that in your case  (len(data) >= 1) and (len(data) <= 2048).
Moreover, you can't expect 'data' to contain exactly one line of data. 
On a good connection, especially a local one,  this might be the case 
because the server probably will sent its data a line at a time, and if 
that line it fits into a packet it will probably get to the receiving 
end as a single unit, but when that packet gets routed across many 
nodes (which can split and combine packets when they feel like it) 
things might not work out so neatly.

As long as the connection persists TCP/IP guarantees that data will 
arrive intact and in the order it was sent. It doesn't guarantee, 
however,  *when* it will arrive, and what the size is of the chunks it 
arrives in. Caveat emptor.


Robert Amesz



More information about the Python-list mailing list