I didn't follow all of that, but sendto() exists on the selector loop. You should ignore errors from it, since it's just as likely that the kernel accepts the packet (so sendto() succeeds) but some other layer or router drops it. There's absolutely no point in buffering and retrying based on the error returned by sendto() -- most likely if it returns an error there's bad congestion somewhere and retrying will make things worse. If you don't want your users to have to write a Protocol themselves, write some helper library. You could also work directly with the socket if you really want to.
On Thu, Feb 26, 2015 at 9:16 AM, Antoine Pitrou <[email protected]> wrote: > On Thu, 26 Feb 2015 17:47:53 +0100 > Victor Stinner <[email protected]> > wrote: > > > > It's already hard enough to explain asyncio to developers using > > eventlet. I don't want to show them protocols. > > > > It's already very hard to justify that the code must be modified to > > add a few yield-from. > > > > Why don't you want to give the choice to user between > > transport/protocols and streams API? > > I am just explaining you how to write a UDP server without a "yield > from" facility. You can write such a facility if you want. Frankly, I > have never found protocols difficult to understand: it's just > event-driven programming... > > That said, if your UDP server only ever receives datagrams and never > sends them, and doesn't do anything complicated with them, then a > synchronous server is probably just as good (IMHO). > > Regards > > Antoine. > > > -- --Guido van Rossum (python.org/~guido)
