(Bram Cohen responded to this but his message got bounced by the list. I'm forwarding it here for the rest of the list.)
---------- Forwarded message ---------- From: Bram Cohen <[email protected]> Date: Tue, Feb 25, 2014 at 1:33 PM Subject: Re: [python-tulip] Does DatagramProtocol get notified for pause/resume (flow control) events ? To: Guido van Rossum <[email protected]> Cc: Christopher Probst <[email protected]>, python-tulip < [email protected]> UDP doesn't have any congestion control. If a packet is lost then, well... it just never shows up. I'm guessing that the OSError happening here is being caused by the operating system, specifically complaining that you're sending so fast that it can't send that quickly to the network card, or something like that. I've never seen this happen, and it will inevitably be very dependent on the operating system, drivers, and physical hardware which you have installed. It should be treated like any other UDP failure - the packet simply didn't arrive. You have to implement your own corrective mechanisms to handle that case. This one you just happen to be told about immediately. You can also be told about network unreachable immediately with UDP, so this sort of immediate error message isn't unprecedented. On Sun, Feb 23, 2014 at 3:31 PM, Guido van Rossum <[email protected]> wrote: > 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 >
