IƱaki Baz Castillo wrote:
> the SIP proxy will use a single TCP connection with my server (if
> there are server N processes in my server then there wuld be just N
> persistent TCP connections between the SIP proxy and my server).

Ah, then in principle it should scale Rails-like:
- each process accepts *one* inbound TCP connection (*)
- it listens for SIP messages, and sends SIP responses, on that one 
socket
- call state is held in regular objects (rather than threads)
- timeouts can be done by means of a timer queue

This to me seems simpler, more robust and portable than something like 
EventMachine.

As you've already said, you need some way to share state between these 
processes. You might want to consider if your SIP-aware front-end proxy 
can be "sticky", sending all messages relating to the same call down the 
same TCP connection.

Regards,

Brian.

(*) Or even just talks on stdin/stdout. This is easy to test standalone, 
and then you can launch the whole process from inetd.

Otherwise, you run N different processes running on N different ports. 
Maybe your front-end SIP proxy can distribute the load between them 
itself. If not, you can point it at a simple TCP proxy like pen, which 
will redirect the connections. pen can be configured not to make more 
than one connection to any particular backend process.
http://siag.nu/pen/
-- 
Posted via http://www.ruby-forum.com/.