Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
Sender: gvanrossum@gmail.com
In-Reply-To: <CAAvW-fZOAiTY7BXKYYS4pb26wZX3YVKCvCLkJxU22MDumU7jtw@mail.gmail.com>
References: <CAAvW-fYH_n732uH4xEdQo_9RjHJM3Z4EiY-Bnu=_Drq37RgB8A@mail.gmail.com> <CAP7+vJ+Wop13D3qZ2Un6p1F-Oecjahc7dE2SgndtmcoOc1m5mg@mail.gmail.com> <CAAvW-fZOAiTY7BXKYYS4pb26wZX3YVKCvCLkJxU22MDumU7jtw@mail.gmail.com>
From: Guido van Rossum <guido@python.org>
Date: Tue, 8 Jan 2013 21:09:33 -0800
Subject: Re: ANN: PyDTLS
To: rbit <py@liquibits.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: python-list@python.org
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.306.1357708196.2939.python-list@python.org>
Lines: 129
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:36472

On Tue, Jan 8, 2013 at 8:39 PM, rbit <py@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 <guido@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)