<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Andrei ,<br>
<br>
Thanks a LOT for the info, now it is much clearer in my head....<br>
Would you mind to comment on the general architecture espacially <br>
why to use fork and not pthreads...<br>
Initially i thought it maybe for stability (if child dies you simply
fork again ) but it <br>
seems that SR is not handling SIGCHILD in that way....<br>
<br>
Thanks<br>
Vadim<br>
<br>
<br>
Andrei Pelinescu-Onciul wrote:
<blockquote cite="mid:20100226143950.GA1646@shell.iptel.org" type="cite">
<pre wrap="">On Feb 26, 2010 at 14:25, Vadim Lebedev <a class="moz-txt-link-rfc2396E" href="mailto:vadim@mbdsys.com"><vadim@mbdsys.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap=""><!---->
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:
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/pipermail/sr-dev/2009-July/003034.html">http://lists.sip-router.org/pipermail/sr-dev/2009-July/003034.html</a>
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
</pre>
</blockquote>
<br>
</body>
</html>