Nice, very accurate.
Am Montag, 24. Februar 2014 20:47:24 UTC+1 schrieb Guido van Rossum: > > Check out my rewording: http://codereview.appspot.com/68210044 > > > On Mon, Feb 24, 2014 at 11:15 AM, Christopher Probst < > foxnet.d...@googlemail.com <javascript:>> 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) >
