Re: Socket programming

[thenaz]

I agree with zwon that forking or spawning a thread each time a UDP datagram shows up is probably not the way to go (especially since Perl ithreads are somewhat resource intensive).

You may choose to use an event loop, which is much lighter-weight, and offers the ability to process things asynchronously. Check out IO::Poll. But reading your last paragraph/question, I'm not sure that's really what you want.

In UDP, every packet is independent (i.e. UDP is connectionless), so you don't end up with a client socket object that you can dispatch to a thread (like you would in TCP). What you might want to do, is to pre-fork, or pre-spawn some threads, and then as you read packets off the socket in the main thread, examine them as needed and route to the appropriate child thread/process.

Of course, depending on what you are doing, I can't shake the feeling that you may not actually need threads at all. Why can't you just receive a packet, process it, then receive another, etc--all on the same thread?

[Anonymous Monk]

I think you're correct. I can handle the incoming packets on the same thread. This was actually very helpful because I forget that UDP is stateless - hopefully my bone-headed question helps someone out in the future.

My goal is to create a simple SIP proxy in our very non-standard environment. So, what I should do is create a fork (or what-have-you) for each new unique conversation identifier (as required in SIP) and do exactly what you said in your third paragraph.

[Corion]

Also see Net::SIP, which should have large parts of a SIP client and server.