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.develo...@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)

Reply via email to