Guido van Rossum [mailto:guido@python.org] wrote:

...

On Fri, Jan 31, 2003, Geoffrey Talvola wrote:

...

Ben Laurie [mailto:ben@algroup.co.uk] wrote:

...

Doesn't seem quite right to me yet - the problem is that if data arrives 1 byte at a time with just less than the timeout between each byte, then you can get n*timeout as the actual timeout (where n is potentially very large). You need to reduce the timeout after each select, surely?

Hmmm. The question is, how should the timeout be interpreted?

The patch I submitted interprets it as the timeout for activity on the underlying socket itself, since that's the object on which you set the timeout by calling sock.settimeout(). You're suggesting that it should be interpreted as the timeout for the call to read() or write() on the ssl object, which involves potentially many separate socket operations.

Anyone else have any opinion on the correct interpretation? I lean toward the one I've already implemented, since it requires no new work :-)

I'm in favor of it referring to network activity, since that's the interpretation used by non-SSL timeouts. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/

I don't understand what Aahz meant, but if this is the only issue, I'm with Geoff. In general, the timeout gets reset whenever a byte is received.

I think that's exactly what Aahz meant. In that case, my patch on SF should be good. I've assigned it to you to check in. While you're at it, you might also take a look at patch 678257 which fixes a case where socket.sendall() would return before its timeout period expired. Basically, it was only waiting for timeout on the first pass through the loop instead of on every iteration. - Geoff