Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Re: Efficient non-blocking UDP server

by calin (Deacon)
on Mar 20, 2004 at 16:47 UTC ( #338313=note: print w/replies, xml ) Need Help??

in reply to Efficient non-blocking UDP server

Think your UDP-receiving code as an interrupt handler and try applying common sense from there. An interrupt handling routine should finish in short, quasi-constant time, and definitely its execution time should not depend on circumstances outside its control.

I suggest pushing your received packets onto a safe queue right away (without deciding upon their content), and let other thread/process handle them. (Thread::Queue looks interesting).

Replies are listed 'Best First'.
Re: Re: Efficient non-blocking UDP server
by liz (Monsignor) on Mar 20, 2004 at 21:25 UTC
    I would be surprised if Thread::Queue would have the performance needed for handling hundreds of UDP packets.

    If you realise that a shared array (to which Thread::Queue is a very simple frontend) stores its valus both in the current thread as well as in the hidden background thread. Not very performance friendly.

    If you want to try Thread::Queue for this application, make sure that you have Perl 5.8.1 or higher, as 5.8.0 has a severe memory leak with shared arrays.


      liz, thanks for feedback. I didn't realize Tread::Queue could be so costly ; my suggestion was the result of a mere query on CPAN by the word queue ; the module looked interesting.

      There's another thing: I suppose the OP requires hundreds of packets per second as a burst condition, right? The perspective of coping with a sustained condition like that, I mean receiving and processing that amount in pure Perl, in real time, looks dim. Even if the receiving routine is fast enough, the queue would quickly fill up. (there's a discussion on what the "processing" amounts to). Anyway, that calls for optimized C code, IMHO.

      All in all, I think the main idea of my original reply (treat your network code as an interrupt handling routine) is still valid in the context of datagram protocols.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://338313]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (3)
As of 2018-01-19 07:29 GMT
Find Nodes?
    Voting Booth?
    How did you see in the new year?

    Results (216 votes). Check out past polls.