[sr-dev] Migration of Open IMS Core to sip-router

[Andrei Pelinescu-Onciul]

On Jul 29, 2009 at 14:58, Dragos Vingarzan <dragos.vingarzan at gmail.com> wrote:
> I see... so it seems quite complicated to add all the required locks and 
> to redesign the process_no and my_pid() for not much of a benefit. I did 
> not see this before.
> 
> Well, if this is final and the conclusion is that the restrictions 
> should be in place there on dynamically forked processes, then I'll 
> start redesigning my module. It's a not a huge deal, but now the code is 
> much clear, easier to manage and also potentially faster if each 
> Diameter TCP connection has it's own process.

We might be able to add some limited dynamic processes support. It
depends a lot on when you fork and what do you want to be able to do
from the dynamically forked processes.
For example we could make drop_my_process() only mark an entry in the
process table as empty and make fork_process() search the table for
empty entries. This would keep process_no valid, but it won't allow tcp
use for processes forked after startup (you probably already have this
problem) and it might have some strange side effects with statistics (a
dyn. forked process might "inherit" the stats of another terminated dyn.
forked process).

> But this is not a must and 
> one universal acceptor/receiver forked at the beginning could do all the 
> ops, much like the TCP structure from ser, right? Where there any 
> performance issues due to some bottlenecks or something like that?

There are 2 possibilities:
 - 1 process that handles all the I/O (based on
   epoll/kqueue/poll/sigio). This is fast but does not scale well with the
   number of cpus.
 - 1 process that only accept()s new connections and then sends them to
   some workers (similar to ser tcp). This is fast and scales well and
   doesn't have the disadvantage of running one process or thread for
   each connection.
The main disadvantage is much more complex code.

> 
> (I'll probably still keep also my original design too for when you use 
> this CDiameterPeer standalone, outside of ser...)
> 

Andrei