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

[reply]

      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.

[reply]

In Section Seekers of Perl Wisdom