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?
Thanks Vadim
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
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
-
Andrei Pelinescu-Onciul -
Vadim Lebedev