From: Brian Candler Date: 2009-01-23T21:36:30+09:00 Subject: Re: Choosing the most appropiate Ruby version and programming model to develop a SIP server I単aki Baz Castillo wrote: > my aim is designing it in a way that it could be > scalable by adding more servers in parallel and all of the sharing > some resources (storing them in DB for as first approach, using DRB or > whatever). > There will be a SIP proxy before my server, so the proxy would > distribute the requests using some dispatcher algorithm. Well, you could use a Rails-like multi-process deployment model; unfortunately, your SIP TCP connections are likely to be persistent, so there will be a lot of open connections and threads being maintained in each process. Considering this, it's easy to appreciate why so many SIP implementations only support UDP :-) >> http://www.stacken.kth.se/project/yxa/ > > I already know it. However it's a SIP proxy implementation, not a SIP > server/B2BUA which is very different. OK, but there's a lot of stack you should be able to rip out and re-use. I think Erlang supports state machines very nicely too, which is good for the various levels of protocol timeouts you referred to in your initial post. Ruby's timeout() mechanism is fundamentally broken - see posts passim - and so you may end up writing your own timeout list plus job queue implementation from scratch, when Erlang's mailboxes give you that straight away. As you say, there are many versions of Ruby to choose from, which may be a blessing or a curse depending on how you look at it. I think you'll certainly need to test them in your own application. When you say "Ruby 1.8 and 1.9: ... the garbage collector is not good enough", is this based on your own experience? Having said that: applications which handle hundreds of TCP connections via hundreds of green threads in a single process are bound to stress Ruby badly. Having N separate processes which handle 1/Nth of the connections will certainly help. It would be really good if you could map the problem domain onto HTTP somehow, because there is so much infrastructure available for scaling Ruby with HTTP. But then, building a front-end SIP proxy so that it forwards requests over HTTP is probably as hard as making the SIP backend scale. Cheers, Brian. -- Posted via http://www.ruby-forum.com/.