Ok, I tried it now with 180 bytes packet and it does not occur, I guess 
that my lan connection(gigabit) is too fast that those packets get queued 
up. Or OSX decide whether or not to queue those packets based on the size. 
But this seems to be heavily os dependent .

Am Sonntag, 23. Februar 2014 20:12:46 UTC+1 schrieb Guido van Rossum:
>
> Have you tried reducing the write buffer size?
> On Feb 23, 2014 10:41 AM, "Christopher Probst" 
> <foxnet.d...@googlemail.com<javascript:>> 
> wrote:
>
>> I saw this in the official 3.4rc1 doc.
>>
>> The doc says, that flow-control callbacks are valid for Protocols and 
>> SubprocessProtocols, but DatagramProtocol is not specified.
>>
>> Though I'm happy that Datagram control flow is officially supported I 
>> have now an other problem which is directly connected with this issue.
>> Using OSX10.9.1 and python 3.3 sending a lot of udp packets actually does 
>> not cause the flow-control to be activated but throws an OSError(55 *No 
>> buffer space available)* .
>>
>> After googling around for hours I found out that this is a BSD(probably 
>> OS X only) thing. On linux the control-flow works as expected. 
>>
>> I listed an issue for this in your tulip repo:
>> Issue 153 <https://code.google.com/p/tulip/issues/detail?id=153>
>>
>> I think that this is really not a python bug, but the way BSD/OSX handles 
>> too much udp packets (the socket sdnbuf option is kind of ignored by OSX). 
>> I've read that windows actually handles udp overload in a similiar way as 
>> BSD does. Though i don't have a windows machine this should probably be 
>> tested to confirm or disprove this issue.
>>
>> PS:
>> 18.5.3.2.5. Flow control 
>> callbacks<http://docs.python.org/3.4/library/asyncio-protocol.html#flow-control-callbacks>
>>  
>>
>> These callbacks may be called on 
>> Protocol<http://docs.python.org/3.4/library/asyncio-protocol.html#asyncio.Protocol>
>>  and 
>> SubprocessProtocol<http://docs.python.org/3.4/library/asyncio-protocol.html#asyncio.SubprocessProtocol>
>>  instances:
>> BaseProtocol.pause_writing()<http://docs.python.org/3.4/library/asyncio-protocol.html#asyncio.BaseProtocol.pause_writing>
>>  
>>
>> Called when the transport’s buffer goes over the high-water mark.
>> BaseProtocol.resume_writing()<http://docs.python.org/3.4/library/asyncio-protocol.html#asyncio.BaseProtocol.resume_writing>
>>  
>>
>> Called when the transport’s buffer drains below the low-water mark.
>>
>>
>>
>>
>> Am Sonntag, 23. Februar 2014 18:56:42 UTC+1 schrieb Guido van Rossum:
>>>
>>> This looks like a bug in the docs; the intention is that datagram 
>>> protocols also support flow control. Where does it say so in the docs? Is 
>>> it the PEP or the CPython Doc tree?
>>>
>>>
>>> On Sat, Feb 22, 2014 at 5:12 PM, Christopher Probst <
>>> foxnet.d...@googlemail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> after looking into the implementation I saw that, for instance, _
>>>> SelectorDatagramTransport calls _maybe_pause_protocol and it's 
>>>> counterpart, but the doc says that only Protocol and SubprocessProtocol 
>>>> has 
>>>> flow-control support and DatagramProtocol does not.
>>>>
>>>> I know that udp flow-control is not the same as tcp flow-control, but 
>>>> I'm concerned about filling up the internal buffer when writing a lot of 
>>>> datagrams. If this is not supported, I would argue that the udp 
>>>> support is pretty much broken for data intense application because how 
>>>> would the writer know when the internal buffer (and/or kernel level 
>>>> buffer) 
>>>> are full ?
>>>>
>>>> So, is the doc just not up-to-date or is it an implementation detail of 
>>>> tulip ?
>>>>
>>>>  And other question that came up: Are there any plans for coroutine 
>>>> methods for udp (like StreamWriter/Reader for TCP) ? 
>>>>
>>>> Also, are there any "dirty" corners somebody heavily working with udp 
>>>> have to know ? I'm implementing reliable udp and I would like to use the 
>>>> coroutine style instead of callbacks.
>>>>
>>>>
>>>> Regards,
>>>> Chris
>>>>
>>>>
>>>
>>>
>>> -- 
>>> --Guido van Rossum (python.org/~guido) 
>>>
>>

Reply via email to