[sr-dev] TCP and TLS connection handling

[Vadim Lebedev]

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 at 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
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20100226/185e3b26/attachment-0001.htm>