How do I check for pending UDP input?

Colin Brown cbrown at metservice.com
Mon Mar 17 15:52:06 EST 2003


Hi Dennis

I agree with you that your solution will make sure that the socket
connection
does not get the chance to build up and under some circumstances would be
preferable to the solution I propose, especially if there may be a large
delay
between port reads.

Let me describe (one instance of) my situation in more specific detail. I
have
a daemon process gathering incoming serial port data. Every 50 milliseconds
a standalone 24 byte packet delivery is attempted to a number of UDP ports.

If no socket receiver is connected the data is lost. Active python socket
receivers appear to read and buffer packets irrespective of whether or not
one is reading the received data from the socket (internal list?). I had a
mimic
module that I was limiting the read & display to once every 200 ms and the
updating was falling many seconds behind. By reading-till-clear there is now
minimal UDP python buffering and the display follows "real-time" input. In
other interactive modules I wished to keep (UDP) ingest time minimal.

The code I had using "select" also worked, but lacked elegance.

Thanks again for your input and comments
Colin
"Dennis Lee Bieber" <wlfraed at ix.netcom.com> wrote in message
news:i6ffk-r03.ln1 at beastie.ix.netcom.com...
> Colin Brown fed this fish to the penguins on Sunday 16 March 2003 03:15
> pm:
>
> > I revisited the problem over the weekend and carefully reread the
> > socket docs with an open mind. My solution to 'asynchronously'
> > reading the last available datagram if it exists is now as follows.
> >
> > Set up socket to be non-blocking in class initialisation.
> >
> > Reader method :-
> >     def recv(self,size=512):
> >         data = ''
> >         while 1:
> >             try:
> >                 d = self.skt.recv(size)
> >                 data = d
> >             except:
> >                 return data
> >
> > One could handle socket errors in the except statement if desired.
> >
>
>         I don't see where this will solve your problem of not reading the
UDP
> socket fast enough to avoid problems...
>
>         <snipped layers of quotes>
>
> >> > > slows right down because I am not clearing the circuit faster
> >> > > than the data comes in. Using "select" with a timeout means that
>
>         While the above /will/ empty the socket when called (assuming the
> sender is slightly slower than the read loop), it does not answer the
> case where the processing of the data itself consumes time. As I read
> the above, somewhere in your code some logic has to call the above
> method -- and waits for the method to return (which is supposed to
> happen when the socket runs out of pending data). If you don't call
> this method often enough, you still have a socket buffer getting filled
> with a lot of data.
>
>         That rough sketched example I gave, using threads and a Lock
around
> the data variable should never result in the socket buffer itself
> become back-logged -- it may need fine-tuning to ensure you get
> "complete" packets (are they fixed size, or do they have some other
> means of determining when one is complete).
>
>
> --
>  > ============================================================== <
>  >   wlfraed at ix.netcom.com  | Wulfraed  Dennis Lee Bieber  KD6MOG <
>  >      wulfraed at dm.net     |       Bestiaria Support Staff       <
>  > ============================================================== <
>  >        Bestiaria Home Page: http://www.beastie.dm.net/         <
>  >            Home Page: http://www.dm.net/~wulfraed/             <
>






More information about the Python-list mailing list