[Python-Dev] the new 2.3a1 settimeout() with httplib and SSL

[Geoffrey Talvola]

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