From: Brian Candler Date: 2009-01-23T23:25:24+09:00 Subject: Re: Choosing the most appropiate Ruby version and programming model to develop a SIP server 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/.