[Python-Dev] ssl module integration with asyncore (original) (raw)

Bill Janssen janssen at parc.com
Thu Nov 29 06:00:09 CET 2007

IMO, it's not reasonable since the application could use something different than select.select(), like select.poll() or something else again.

As I said before, you can do away with select or poll altogether if you write a state machine for your asyncore dispatcher. Asyncore will tell you when you can read or write the socket; you just need to know what to do with that information.

I guess that the best thing to have in such case would be having an "ssl-ized" wrap of the socket which follows the same behaviour of a classical non-blocking socket, then it would be up to the application deciding what to do with it.

That's what you get if you use "do_handshake_on_connect=False". Your application is expected to do the SSL handshake in its own time. You can do it whichever way you want, as long as you keep calling "do_handshake" appropriately until it fails to raise an error.

I think it's simpler to let the SSL module do it, even though it comes at the expense of blocking the thread till the handshake is complete.

That way the asynchronous application which wants to switch to a secure connection would just need to wrap the socket by using ssl.wrapsocket() without altering the existing code.

That's essentially what happens already. The question is whether the SSL setup code is allowed to block the non-blocking socket till the SSL handshake is complete.

Bill

More information about the Python-Dev mailing list