[Python-Dev] ssl module, non-blocking sockets and asyncore integration

Giampaolo Rodola' gnewsg at gmail.com
Wed Sep 17 03:34:01 CEST 2008


Sorry, ignore my 2nd question, I see now that you already gave a very
clear answer in your first message.
I change my question: how am I supposed to know when the SSL hanshake
is completed? When pending() returns False?
If so I'd recommend to document the method.


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

On 17 Set, 03:24, "Giampaolo Rodola'" <gne... at gmail.com> wrote:
> 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,
>
> --- Giampaolohttp://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/test_ssl.py, you'll see a
> > non-blocking use of the "do_handshake" method.  Basically, the flag
> > "do_handshake_on_connect" 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 "read_event" and "write_event", 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 do_handshake_on_connect:
>
> >   The parameter do_handshake_on_connect 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.do_handshake() method. Calling SSLSocket.do_handshake()
> >   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 do_handshake() says:
>
> >   SSLSocket.do_handshake()¦ Perform a TLS/SSL handshake. If this is used
> >   with a non-blocking socket, it may raise SSLError with an arg[0] of
> >   SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, 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.do_handshake()
> >             break
> >         except ssl.SSLError, err:
> >             if err.args[0] == ssl.SSL_ERROR_WANT_READ:
> >                 select.select([s], [], [])
> >             elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
> >                 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...
>
> _______________________________________________
> 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...- Nascondi testo citato
>
> - Mostra testo citato -


More information about the Python-Dev mailing list