«

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 http://code.google.com/p/tulip/source/checkout
using Mercurial.

--Guido

> 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:
>>> 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/listi...-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)