> 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4