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