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

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

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

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