I think it would be helpful in the Flow-Control section, along with the info that generally UDP flow-control is supported but BSD systems are not fully supported.
My english is not as good as it used to be, so feel free to modify the following snippet: 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>, DatagramProtocol 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. Note: On BSD systems (OS X, FreeBSD, OpenBSD, NetBSD, etc.) the flow-control is not supported because send-failures caused by writing too many packets cannot be detected easily. Am Montag, 24. Februar 2014 20:02:47 UTC+1 schrieb Guido van Rossum: > > Can you suggest a sentence or two and the exact point where they should be > inserted into the docs? > > > On Mon, Feb 24, 2014 at 10:39 AM, Christopher Probst < > [email protected] <javascript:>> wrote: > >> Regarding the ENOBUFS issue: >> >> You are right, this info does not tell enough to use it for >> pause_writing. And some BSD version drop packets silently if the queue is >> full. But on Linux or Windows this technique is useful. Maybe a small >> annotation in the docs could help for other users experiencing the same >> issue with BSD systems. >> >> Am Montag, 24. Februar 2014 19:22:46 UTC+1 schrieb Guido van Rossum: >>> >>> Hm, so it sounds like the ENOBUFS error is intended as an improvement: >>> it at least tells the caller that the packet was dropped immediately, which >>> is a useful thing, even if the absence of that error does not constitute a >>> guarantee. Unfortunately it doesn't look like we can use this directly to >>> call pause_writing(), because there's no reliable way to tell that things >>> are going to work again, except by trying. >>> >>> Regarding "reliable" UDP, I guess if you're really implementing TCP on >>> top of UDP, you're not going to beat the performance of TCP. You're still >>> going to need all the same AKCs etc. But don't let me stop you, I'm sure >>> you have a good reason to do this. >>> >>> >>> On Mon, Feb 24, 2014 at 12:49 AM, Christopher Probst < >>> [email protected]> wrote: >>> >>>> This is from FreeBSD mailing lists, it definitely says that sendto does >>>> not block (select won't help, unfortunately it is like a file handle, it's >>>> always writable). >>>> http://lists.freebsd.org/pipermail/freebsd-hackers/ >>>> 2004-January/005369.html >>>> >>>> Well, I think it is safe to say that tulips Datagram control-flow will >>>> never really work on any BSD system. The sendto method simply never blocks. >>>> It's also easy to explain the behavior you get: One mail says that >>>> FreeBSD might drop packets, instead of raising ENOBUFS, so you get >>>> dramatic >>>> packet loss instead of an error. >>>> >>>> >>>> Am Montag, 24. Februar 2014 01:07:17 UTC+1 schrieb Guido van Rossum: >>>>> >>>>> "Reliable UDP"? Isn't that a contradiction? >>>>> >>>>> On Sunday, February 23, 2014, Christopher Probst < >>>>> [email protected]> wrote: >>>>> >>>>>> Thanks for your help so far, I really appreciate it. >>>>>> >>>>>> A manual backoff seems the best solution for this weird behavior for >>>>>> now, since reliable udp heavily depends on timing this is not such a bad >>>>>> thing anyway. >>>>>> >>>>>> Meanwhile I try to figure out the cause for this issue. >>>>>> >>>>>> >>>>>> Am Montag, 24. Februar 2014 00:31:24 UTC+1 schrieb Guido van Rossum: >>>>>>> >>>>>>> I still can't repro it with your code. But that doesn't mean it's >>>>>>> not a real condition. It sounds like the kind of odd corner of entirely >>>>>>> legitimate UDP behavior that is hard to provoke but which a robust app >>>>>>> should handle. >>>>>>> >>>>>>> Note that the default behavior in Tulip appears to be to ignore >>>>>>> OSError coming out of sendto() -- the transport calls >>>>>>> protocol.error_received(), which by default does nothing. Since there >>>>>>> are >>>>>>> many other cases where a packet may silently be dropped on the floor, >>>>>>> this >>>>>>> behavior is technically correct -- the question is whether it is the >>>>>>> best >>>>>>> default behavior we can imagine. >>>>>>> >>>>>>> Unfortunately turning it into a pause_protocol() call in your >>>>>>> error_received() handler is a little tricky -- the transport remembers >>>>>>> whether it has paused the protocol or not, but this state is not >>>>>>> public. So >>>>>>> you shouldn't call your own pause_writing(), since you'd never receive >>>>>>> a >>>>>>> resume_writing() call from the transport. Perhaps you can set a flag >>>>>>> internal to your protocol that just causes you to back off for a brief >>>>>>> period of time? The optimal back-off time should be tuned >>>>>>> experimentally. >>>>>>> >>>>>>> --Guido >>>>>>> >>>>>>> On Sun, Feb 23, 2014 at 2:45 PM, Christopher Probst < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> I made a simpler test, without using tulip, just using plain >>>>>>> sockets<http://stackoverflow.com/questions/21973661/os-x-udp-send-error-55-no-buffer-space-available/21973705?noredirect=1#comment33297277_21973705> >>>>>>> . >>>>>>> >>>>>>> from socket import * >>>>>>> >>>>>>> udp = socket(AF_INET, SOCK_DGRAM) >>>>>>> udp.setsockopt(SOL_SOCKET, SO_REUSEADDR, True) >>>>>>> >>>>>>> udp.bind(('0.0.0.0', 1337)) >>>>>>> udp.setblocking(False) >>>>>>> udp.setsockopt(SOL_IP, IP_TTL, 4) >>>>>>> udp.connect(('8.8.8.8 >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> --Guido van Rossum (on iPad) >>>>> >>>> >>> >>> >>> -- >>> --Guido van Rossum (python.org/~guido) >>> >> > > > -- > --Guido van Rossum (python.org/~guido) >
