On Tue, Jan 8, 2013 at 8:39 PM, rbit <p...@liquibits.com> wrote: > Thank you. I will gladly port to Python 3 if there is interest from > the community.
Python 3 is where it's at! :-) > Regarding PEP 3156: asynchronous use of unreliable network protocols > makes for an interesting use case. In particular, it forces > applications to deal with packet loss under some circumstances. But don't you have to deal with that when doing synchronous I/O as well? It's a datagram protocol after all. > One > such situation occurs during DTLS's handshaking phase: if no response > is received from the peer after some period of time, we must assume > that our most recent datagram has been lost, and so we need to > retransmit. Is this something the transport can handle, or does the protocol (and hence the application) need to be involved here? > The event loop interface as outlined in the PEP makes this > a bit difficult (as did the asyncore module). One possible way to make > things easier would be by adding two parameters to add_reader: a > callable to retrieve the current timeout, and a callable that is > invoked if that timeout expires before the descriptor becomes > readable. Each loop iteration would then collect all given timeouts, > and pass the minimum of that set to whatever polling facility it > invokes. If that timeout expires, the corresponding timeout handler > would be invoked prior to the next loop iteration. Hm, this would add a fair amount of complexity to the event loop. It's true that I don't have the complete story for timeouts yet, but I am hopeful that things like this can be implemented by using call_later() with some callback that does the retransmit (and resets some internal state), and cancelling that callback whenever a packet is received (i.e. in the protocol's datagram_received() method). > The PEP also considers only stream transports when referring to > "transport." Datagram transports do not, for example, have the > property that calling t.write(b'abc'); t.write(b'def') is equivalent > to calling t.write(b'abcdef'). Yeah, obviously this invariant only applies to stream protocols. The PEP currently doesn't really specify datagram support (it's just in the Open Issues section). > I'm not sure what sort of impact this > omission of datagram transports has for an implementation. Though I > would certainly like to see datagram transports be treated as > first-class citizens, despite not being nearly used as often as stream > transports. I would hope that an implementer of, say, RTP over UDP, > can tie into the same event loop as someone implementing a > single-process, single-threaded Web server. Yeah, at the level of the eventloop proper (the APIs that deal with callbacks, not futures, transports and protocols) datagrams won't be a problem. There will have to be separate specifications for the transport and protocol interfaces used with datagrams. > Implementing DTLS as a tulip transport sounds interesting. Is the > tulip package available somewhere so that I can try it out? Absolutely -- it is very much in flux, but you can check out the latest source from http://code.google.com/p/tulip/source/checkout using Mercurial. --Guido > Ray > > On Tue, Jan 8, 2013 at 6:53 AM, Guido van Rossum <gu...@python.org> wrote: >> This sounds exciting. Are you considering a Python 3 port? It might make a >> nice demo of PEP 3156. >> >> >> On Monday, January 7, 2013, rbit wrote: >>> >>> I would like to announce Datagram Transport Layer Security for >>> Python. From the top of the project README: >>> >>> PyDTLS brings Datagram Transport Layer Security (DTLS - RFC 6347: >>> http://tools.ietf.org/html/rfc6347) to the Python environment. In a >>> nutshell, DTLS brings security (encryption, server authentication, >>> user authentication, and message authentication) to UDP datagram >>> payloads in a manner equivalent to what SSL/TLS does for TCP stream >>> content. >>> >>> DTLS is now very easy to use in Python. If you're familiar with the >>> ssl module in Python's standard library, you already know how. All it >>> takes is passing a datagram/UDP socket to the *wrap_socket* function >>> instead of a stream/TCP socket. Here's how one sets up the client side >>> of a connection: >>> >>> import ssl >>> from socket import socket, AF_INET, SOCK_DGRAM >>> from dtls import do_patch >>> do_patch() >>> sock = ssl.wrap_socket(socket(AF_INET, SOCK_DGRAM)) >>> sock.connect(('foo.bar.com', 1234)) >>> sock.send('Hi there') >>> >>> The project is hosted at https://github.com/rbit/pydtls, and licensed >>> under >>> the Apache license 2.0. PyPI has packages. I can be reached >>> at code AT liquibits DOT com for questions, feedback, etc. >>> >>> <P><A HREF="http://pypi.python.org/pypi/Dtls/0.1.0";>Dtls 0.1.0</A> - >>> Datagram Transport Layer Security for Python. (07-Jan-13) >>> -- >>> http://mail.python.org/mailman/listinfo/python-announce-list >>> >>> Support the Python Software Foundation: >>> http://www.python.org/psf/donations/ >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> >> -- >> http://mail.python.org/mailman/listinfo/python-list >> -- --Guido van Rossum (python.org/~guido) -- http://mail.python.org/mailman/listinfo/python-list
