From: "Iñaki Baz Castillo" <ibc@...>
Date: 2009-01-24T00:54:05+09:00
Subject: Re: Choosing the most appropiate Ruby version and programming model  to develop a SIP server

El Viernes, 23 de Enero de 2009, Brian Candler escribió:
> 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)

Could you please explain this last point?


> - timeouts can be done by means of a timer queue

Any example of it?


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

I don't need it to be portable, but I 'm afraid of the complexity the code 
would get if it's done with EventMachine. Should then I really discard 
EventMachine for this project?


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

Yes, the SIP proxy (OpenSer) does this task very well, it can dispatch all the 
transactions of a dialog to the same server. But anyway I need to share other 
states between all the servers (not just SIP dialog related).



> 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/

This sounds great but I don't need it, the SIP proxy already does it :)


Thanks again.

PD: Would you *strongly* recommend me to avoid Ruby for this task?
PPD: If not, any Ruby "version" and programming model implementation 
(mantained and robust) running on that Ruby version? (I know my question is 
very difficult to answer, but I would really appreciate it).



-- 
Iñaki Baz Castillo