[Python-Dev] ssl module, non-blocking sockets and asyncore integration (original) (raw)

Giampaolo Rodola' gnewsg at gmail.com
Wed Sep 17 03:24:06 CEST 2008

I've tried to modify my existing asyncore-based code but I'm encountering a lot of different problems I didn't manage to fix. It seems that playing with the do_handshake_on_connect flag doesn't make any difference. I guess that without some kind of documentation describing how to deal with non-blocking "ssl-wrapped" sockets I won't get too far. I try to ask two questions in case the answers may help me in some way:

1 - What pending() method is supposed to do (it's not documented)? 2 - By reading ssl.py code I noticed that when do_handshake_on_connect flag is False the do_handshake() method is never called. Is it supposed to be manually called when dealing with non-blocking sockets?

In the meanwhile I noticed something in the ssl.py code which seems to be wrong:

def recv (self, buflen=1024, flags=0):
    if self._sslobj:
        if flags != 0:
            raise ValueError(
                "non-zero flags not allowed in calls to sendall()

on %s" % self.class) while True: try: return self.read(buflen) except SSLError, x: if x.args[0] == SSL_ERROR_WANT_READ: continue else: raise x else: return socket.recv(self, buflen, flags)

I don't know the low levels but that while statement which continues in case of SSL_ERROR_WANT_READ seems to be wrong (blocking), at least when dealing with non-blocking sockets. I think the proper way of doing recv() here is letting SSL_ERROR_WANT_READ propagate and let the upper application (e.g. asyncore) deal with it.

Hope this helps,

--- Giampaolo http://code.google.com/p/pyftpdlib/downloads/list

On 15 Set, 04:50, Bill Janssen <jans... at parc.com> wrote:

Hi, Giampaolo.

If you look a bit further in Lib/test/testssl.py, you'll see a non-blocking use of the "dohandshake" method. Basically, the flag "dohandshakeonconnect" says whether you want this to happen automatically and blockingly (True), or whether you want to do it yourself (False). In the test suite, the function "testNonBlockingHandshake" does the async client-side handshake; the server side logic is just the same, only it would happen in the server's "handle new connection" code -- you'd have to add a state variable, and bind handlers for "readevent" and "writeevent", which would consult the state variable to see whether they had finished the handshake yet. I just made the server do it automatically to make life easier. The hard part isn't really doing the non-blocking, it's trying to figure out how to use asyncore correctly, IMO. Giampaolo Rodola' <gne... at gmail.com> wrote: > I'm interested in using the ssl module with asyncore but since there's > no real documentation about how using ssl module with non-blocking If you'd like to contribute a doc patch, that would be great. Here's what it current says for dohandshakeonconnect: The parameter dohandshakeonconnect specifies whether to do the SSL handshake automatically after doing a socket.connect(), or whether the application program will call it explicitly, by invoking the SSLSocket.dohandshake() method. Calling SSLSocket.dohandshake() explicitly gives the program control over the blocking behavior of the socket I/O involved in the handshake. and here's what the docs for dohandshake() says: SSLSocket.dohandshake()¦ Perform a TLS/SSL handshake. If this is used with a non-blocking socket, it may raise SSLError with an arg[0] of SSLERRORWANTREAD or SSLERRORWANTWRITE, in which case it must be called again until it completes successfully. For example, to simulate the behavior of a blocking socket, one might write: while True: try: s.dohandshake() break except ssl.SSLError, err: if err.args[0] == ssl.SSLERRORWANTREAD: select.select([s], [], []) elif err.args[0] == ssl.SSLERRORWANTWRITE: select.select([], [s], []) else: raise Bill

Python-Dev mailing list Python-... at python.orghttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe:http://mail.python.org/mailman/options/python-dev/python-dev2-garchiv...

More information about the Python-Dev mailing list