Discussion in 'Python' started by Guido van Rossum, Jan 9, 2013.

  1. On Tue, Jan 8, 2013 at 8:39 PM, rbit <> 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
    using Mercurial.


    > Ray
    > On Tue, Jan 8, 2013 at 6:53 AM, Guido van Rossum <> 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:
    >>> 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(('', 1234))
    >>> sock.send('Hi there')
    >>> The project is hosted at, 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="">Dtls 0.1.0</A> -
    >>> Datagram Transport Layer Security for Python. (07-Jan-13)
    >>> --
    >>> Support the Python Software Foundation:

    >> --
    >> --Guido van Rossum (
    >> --

    --Guido van Rossum (
    Guido van Rossum, Jan 9, 2013
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. rbit

    Re: ANN: PyDTLS

    rbit, Jan 9, 2013, in forum: Python
  2. rbit

    Re: ANN: PyDTLS

    rbit, Jan 9, 2013, in forum: Python
  3. Neal Becker

    Re: ANN: PyDTLS

    Neal Becker, Jan 9, 2013, in forum: Python
    Neal Becker
    Jan 9, 2013
  4. Guido van Rossum

    Re: ANN: PyDTLS

    Guido van Rossum, Jan 9, 2013, in forum: Python
    Guido van Rossum
    Jan 9, 2013
  5. rbit

    Re: ANN: PyDTLS

    rbit, Jan 9, 2013, in forum: Python

Share This Page