UDP reading on multiple sockets

[Steve Howell]

On May 18, 6:19 am, thomas.vo... at likeabird.de wrote:
> On 17 Mai, 04:22, Grant Edwards <gra... at visi.com> wrote:
>
> > On 2009-05-17, Thomas Vogel <thomas.vo... at likeabird.de> wrote:
>
> > > I'm currently have the problem that I try to read UDP messages from
> > > multiple sockets in parallel. So let's say I get UDP packets from the
> > > same IP on the ports 2000, 2001, 2002,...
>
> > Is there any reason you can't do it the easy way by using
> > select?
>
> >http://docs.python.org/library/select.html
>
> > --
> > Grant
>
> The only honest answer would be that I'm totaly unfamiliar with select
> and also the documentation I found wasn't able to clear the picture.
> So are there examples of using select together with sockets available?
>

My two cents on this issue is that you should stick with asyncore for
now and just figure out how to debug better what's going on.

I understand the rationale behind the alternatives--there are
certainly advantages (even in debugging) to using something closer to
the metal, like select, or in using something that might be a better
abstraction, like Twisted.

But really, if you look at the source code for asyncore, it's just a
thin layer on top of select.select, and the entire module is under 600
lines of code.  Asyncore is much maligned, and there are some
legitimate beefs with it, but it does well, for the most part, what it
intends to do, which is to solve some of the more difficult, or at
least tedious, problems with regards to dealing with select.select.

My fear is that if you try to do this without asyncore, via select,
you'll end up reinventing lots of asyncore with lots of your own
bugs.  I have less fear about going higher in the stack, except that
it just puts another layer on top of the problem, and I think the
issue you're dealing with is fairly low-level.

So my suggestion is to figure out a good debugging strategy, either by
getting a bit more familiar with asyncore internals (with a debugger,
print statements, analysis, etc.), or by better using system tools
(like snoop, truss, etc.) to see what's happening at the I/O level, or
both.

Good luck!



Steve