Python sockets/select

[Thomas Wouters]

On Wed, Jun 21, 2000 at 05:49:18AM +0000, Donn Cave wrote:
> Quoth "David Allen" <s2mdalle at titan.vcu.edu>:

> | When I select() sockets for reading, writing, and error conditions,
> | there are sockets (usually connected to clients who have already
> | quit or died unexpectedly) that don't show up in the error queue,
> | but continually flag select() as being readable.  When I read them,
> | of course, '' comes back.

> | For some reason, sometimes '' comes in for valid clients, so I 
> | can't just disconnect a client because I get that from them.  Is
> | there a way to detect which clients are alive and which aren't?
> | What causes a client to send '' when I didn't tell it to, according
> | to select()?  (The clients are also written in python)

> When you get 0 bytes back from a read, that's EOF (End Of File.)
> As you apparently surmised.  That is indeed a readable event, at
> least the first time.  I'd say behavior after the first 0 byte
> read is probably undefined, but anyway it's not going to do anyone
> any good.

Actually, there are some possibilities to get 0 bytes on a return without
hitting EOF: if you are using a wrapper object that possibly eats up some
bytes (for protocol negotiation, for instance.) Telnetlib is a good example
of this:

"""
It is possible to pass a Telnet object to select.select() in order to wait
until more data is available.  Note that in this case, read_eager() may
return '' even if there was data on the socket, because the protocol
negotiation may have eaten the data.  This is why EOFError is needed in some
cases to distinguish between "no data" and "connection closed" (since the
socket also appears ready for reading when it is closed).
"""

If you do something similar in your own sockets, this may well be the case.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!