[Python-Dev] ssl module integration with asyncore
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.wrap_socket() 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