Check out my rewording: http://codereview.appspot.com/68210044
On Mon, Feb 24, 2014 at 11:15 AM, Christopher Probst < foxnet.develo...@googlemail.com> wrote: > 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 < >> foxnet.d...@googlemail.com> 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 < >>>> foxnet.d...@googlemail.com> 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 < >>>>>> foxnet.d...@googlemail.com> 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 < >>>>>>>> foxnet.d...@googlemail.com> 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) >> > -- --Guido van Rossum (python.org/~guido)
