Andrei ,

Thanks a LOT for the info, now it is much clearer in my head....
Would you mind to comment on the general architecture espacially
why to use fork and not pthreads...
Initially i thought it maybe for stability (if child dies you simply fork again ) but it
seems that SR is not handling SIGCHILD in that way....

Thanks
Vadim

 
Andrei Pelinescu-Onciul wrote: 
On Feb 26, 2010 at 14:25, Vadim Lebedev <vadim@mbdsys.com> wrote:
  
Hello,

I'm investigation possiblity to implement DTLS support and in this context
I wonder if some kind soul can point me to an overview explaining how SR 
is handling
TCP and TLS  connections.
I'd like to understand  how are they assigned to child processes and and 
what happens when for example child A
receives a request which should be forwarded to the connection handled 
by the child B?
    

They are assigned in round-robin fashion. What's important to note is
that a connection will spend time assigned to a worker only so far as it
has data available for reading + 5s (after 5s idle time it will be sent
back to the master tcp process).

When child A wants to send on a connection it does not currently handle,
it looks to see if it has the fd for the connection cached. If it
doesn't it asks tcp main for the fd, adds it to its local fd cache and
then sends on it.
Inn async mode (default), if the connection has already data queued on
it, it doesn't bother getting the fd for master, it just queues its data
at the end.

For more details see:
http://lists.sip-router.org/pipermail/sr-dev/2009-July/003034.html

For DTLS, I don't think you need to go the TCP/TLS way. Using UDP
sockets it means you can just have them open in all the processes (like
for UDP and SCTP, open them on startup and every process will inherit
them). The tricky part is handling the write-that-wants-read case that
can appear during key renegotiations.


Andrei