26 Feb
2010
26 Feb
'10
2:39 p.m.
On Feb 26, 2010 at 14:25, Vadim Lebedev <vadim(a)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