Re: Efficient non-blocking UDP server

[calin]

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).

[liz]

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

[calin]

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.