RE: [Python-Dev] the new 2.3a1 settimeout() with httplib and SSL
Ben Laurie [mailto:ben@algroup.co.uk] wrote:
I've asked Ben Laurie to review the patch for me. Once he says it looks OK I'll assign both the bug and the patch to Guido to deal with. Hopefully it's finally right.
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 :-)
Apart from that, it looks good. Apologies for delay, I managed to overlook this.
No problem. - Geoff
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/ "Argue for your limitations, and sure enough they're yours." --Richard Bach
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/)
Guido van Rossum 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.
The point is that in the standard case, a byte on the network is a byte in the application, so you either get a byte or you time out in the specified time. In the SSL case, you could neither get a byte nor time out, at the application layer, until much, much later than you thought you specified. This seems broken to me, and POLA would suggest I'm right (i.e. if I say time out in 1 second, I'll be pretty astonished when that turns into a day). Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
The point is that in the standard case, a byte on the network is a byte in the application, so you either get a byte or you time out in the specified time.
In the SSL case, you could neither get a byte nor time out, at the application layer, until much, much later than you thought you specified.
This seems broken to me, and POLA would suggest I'm right (i.e. if I say time out in 1 second, I'll be pretty astonished when that turns into a day).
Any buffering scheme built on top of recv() has this problem. Tough. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
The point is that in the standard case, a byte on the network is a byte in the application, so you either get a byte or you time out in the specified time.
In the SSL case, you could neither get a byte nor time out, at the application layer, until much, much later than you thought you specified.
This seems broken to me, and POLA would suggest I'm right (i.e. if I say time out in 1 second, I'll be pretty astonished when that turns into a day).
Any buffering scheme built on top of recv() has this problem. Tough.
OK, so long as we're clear on the failure mode, its fine by me. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
participants (4)
-
Aahz -
Ben Laurie -
Geoffrey Talvola -
Guido van Rossum