Dealing with multiple processes?

bigmoose has asked for the wisdom of the Perl Monks concerning the following question:

Most glorious Monks,

I started learning Perl 2 or 3 months ago, and my first 'project' is to write some that will capture RTP packets (with Net:Pcap) and eventual decode the resulting payload (with Net::RTP::Packet). All in a VoIP respect.. to be clear.

While planning something on paper, to roughly judge how I will code this, I realised that I wasn't sure how I could have this deal with multiple instances of RTP packets being captured.

For example.. 1 call begins and the script picks this up and begins to output the payload to a file. While this call is occuring a 2nd call begins -...

That's where I can't percieve how the script will react? I imagined looping the capture would be the right thing to do.. but would it begin to capture a 2nd call without the 1st one having finished?

I perhaps feel like I'm not aware of a concept, as Perl is my first programming language.

Thanks for any direction you can give.

Thank you Monks,

Ben

Comment on Dealing with multiple processes?

Replies are listed 'Best First'.
Re: Dealing with multiple processes? by fisher (Priest) on Aug 05, 2011 at 15:49 UTC
I think you need general dispatcher and spawned handlers for a particular call. In main loop, receive packet, if it is a new call, spawn a handler, register it (make a link between call and handler) and give him this packet. If it is a packet for registered call, give it to particular handler. Otherwise just drop it. Handlers will decode packets in context of current session; if session ends, handler exits.	[reply]
Re^2: Dealing with multiple processes? by bigmoose (Acolyte) on Aug 05, 2011 at 15:53 UTC
Ahaha! handlers are the concept I was looking for.. I think Thanks wise one ^_^	[reply]
Re: Dealing with multiple processes? by Perlbotics (Archbishop) on Aug 05, 2011 at 15:54 UTC
If I understood you correctly, I think you need to implement the concept of a session which is created/used/closed. Maybe it is sufficient to use the methods `$packet->source_ip()` and `$packet->source_port()` of Net::RTP::Packet to compose a unique session ID? If that isn't unique, you need to further inspect the payload. At the point where you have a session ID, you can demultiplex each stream into a proper file or internal data structure.	[reply] [d/l] [select]
Re: Dealing with multiple processes? by sundialsvc4 (Abbot) on Aug 05, 2011 at 20:26 UTC
The way I would approach a problem like this one is to take inspiration from a fast food restaurant. One process has the role, “May I take your order, please?” This process takes your order and enqueues it for subsequent processing, but doesn’t do anything toward getting the work done. Meanwhile, a moderately-sized pool of processes are watching that queue, waiting for something to arrive and then performing their appointed role. (The “fry guy,” the “burger-meister,” the “liquids lady,” and so on. They do their job, but don’t interact directly with the customers.) There are foreground and background activities: you might get to mop the floor if nobody’s in the store, but with strict instructions to drop your mop and put on your fry-guy hat double quick if a tour-bus materializes in the parking lot. It is possible for a bottleneck to appear, in which case the “manager on duty” can make appropriate adjustments in real-time, but the number of processes is never 1:1 linked to the number of orders that are being worked on. The workers may find themselves “100% busy,” but they are never overloaded. These principles map directly to computer software, and they work there just as well. There are plenty of “thread-safe queues,” and even complete workload-management systems, e.g. POE, readily available in CPAN.	[reply]
Re: Dealing with multiple processes? by zentara (Archbishop) on Aug 06, 2011 at 14:33 UTC
My first thought would be to put each packet handler in it's own thread. They won't interfere with each other at all. The perl module might not be threadsafe, but it seems to be threadsafe on googling for it. The only way is to try. You can collect or manage information in the threads thru shared variables. I'm not really a human, but I play one on earth. Old Perl Programmer Haiku ................... flash japh	[reply]


No such thing as a small change
	PerlMonks