[Python-Dev] PEP 3156 - Asynchronous IO Support Rebooted

[Glyph]

On Jan 4, 2013, at 8:51 PM, Guido van Rossum <guido at python.org> wrote:

> On Fri, Jan 4, 2013 at 8:19 PM, Glyph <glyph at twistedmatrix.com> wrote:
>> 
>> On Jan 4, 2013, at 3:56 PM, Guido van Rossum <guido at python.org> wrote:
>> 
>>> On Mon, Dec 24, 2012 at 2:58 PM, Glyph <glyph at twistedmatrix.com> wrote:
>>>> In my humble (but entirely, verifiably correct) opinion, thinking of this as
>>>> a "default" is propagating a design error in the BSD sockets API.  Datagram
>>>> and stream sockets have radically different semantics.  In Twisted,
>>>> "dataReceived" and "datagramReceived" are different methods for a good
>>>> reason.  Again, it's very very easy to fall into the trap of thinking that a
>>>> TCP segment is a datagram and writing all your application code as if it
>>>> were.  After all, it probably works over localhost most of the time!  This
>>>> difference in semantics mirrored by a difference in method naming has helped
>>>> quite a few people grok the distinction between streaming and datagrams over
>>>> the years; I think it would be a good idea if Tulip followed suit.
>>> 
>>> Suppose PEP 3156 / Tulip uses data_received() for streams and
>>> datagram_received() for datagram protocols (which seems reasonable
>>> enough), what API should a datagram transport have for sending
>>> datagrams? write_datagram() and write_datagram_list()?
>> 
>> Twisted just have a different method called write() which has a different signature (data, address).  Probably write_datagram is better.  Why write_datagram_list though?  Twisted's writeSequence is there to provide the (eventual) opportunity to optimize by writev; since datagrams are always sent one at a time anyway, write_datagram_list would seem to be a very minor optimization.
> 
> That makes sense (you can see I haven't tried to use UDP in a long time :-).
> 
> Should write_datagram() perhaps return a future? Or is there still a
> use case for buffering datagrams?

There's not much value in returning a future even if you don't buffer.  UDP packets can be dropped, and there's no acknowledgement from the remote end either when they're received or when they're dropped.  You can get a couple hints from ICMP, but you can't rely on it, because lots of networks just dumbly filter it.

Personally I think its flow control should work the same way as a TCP stream just for symmetry, but the only time that this becomes important in an application is when you're actually saturating your entire outbound network, and you need to notice and slow down.  Returning a future would let you do this too, but might mislead users into thinking that "once write_datagram completes, the datagram is sent and the other side has it", which is another pernicious idea it's hard to disabuse people of.

-glyph