Yes, if I reduce the write buffer size the problem occurs later but it does occur. size ~ time to crash. I read about a kernel setting on OSX called "sysctl kern.ipc.maxsockbuf" which actually relates to the real udp socket sndbuf size.
The only real fix I could imagine would be to catch the OSError and check for number 55 on OSX(probably BSD, too) to manage flow control, it's ugly I know. But OSX does not seem to be very udp flow-control friendly. 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" > <[email protected]<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 < >>> [email protected]> 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) >>> >>
