[sr-dev] [Fwd: Re: [Kamailio-Users] TCP supervisor process in Kamailio]

[Klaus Darilion]

Andrei Pelinescu-Onciul schrieb:
> On Jul 09, 2009 at 13:50, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
>>
>> Andrei Pelinescu-Onciul schrieb:
>>> On Jul 09, 2009 at 10:27, Klaus Darilion <klaus.mailinglists at pernau.at> 
>>> wrote:
>>>> Andrei Pelinescu-Onciul schrieb:
>>>>> On Jul 07, 2009 at 15:53, Klaus Darilion <klaus.mailinglists at pernau.at> 
>>>>> wrote:
>>>>>> Hi Andrei!
>>>>>>
>>>>>> Do you think this is also relevant for sip-router's TCP implementation?
>>>>> The elevated priority for tcp_main is a good idea. I'll add a config
>>>>> option for it (right now there are real time prio config options, but
>>>>> only for the timer processes).
>>>>> The rest of the paper does not apply to sr or recent ser versions
>>>>> (fd cache was implemented long time ago, tcp timers are much better,
>>>>> there is no known dealdock a.s.o.).
>>>> Hi Andrei!
>>>>
>>>> How are incoming TCP messages handled in detail? e.g. if there is 
>>>> incoming data on a TCP connection: which process reads the data and 
>>>> constructs the SIP message? Is this the supervisor (which handles only 
>>>> full messages over to the TCP workers) or a worker?
>>> It's the worker ("tcp_receiver" in sercmd ps output).
>>> The supervisor ("tcp main") passes entire connections to the workers and
>>> not messages.
>>> When there is new data on a connection, tcp_main passes it to the
>>> workers (round-robin). The worker that gets the connection will read
>> >from it until it exhausts all the received data. After that it will start
>>> a 5 s timeout. If no new data is received in this interval, it will
>>> give-up the connection back to tcp_main. If new data is received, the
>>> timeout will be extended (this timeout will keep connection with heavy
>>> traffic in the same worker all the time allowing fast handling and it
>>> will also accommodate traffic peaks).
>>>
>>> So a worker will read the data from the tcp connection, build the sip
>>> message and run the routing script.
>> So, a worker will read from multiple connections concurrently and as 
>> soon as it received a full SIP message from any of these connections, it 
>> will process this single message. After message processing it continues 
>> reading from the connections. E.g:
>>
>>             |------
>> tcpcon1---->|tcp_receiver
>> tcpcon2---->|
>>             |------
>>
>> 1. data is available on con1: read the data, e.g. a half SIP message
>> 2. data is available on con2: read the data, e.g. a half SIP message
>> 3. data is available on con1: read the data, e.g. the second part of the 
>> SIP message
>> 4. a complete message is available (con1), process the message
>> 5. data is available on con2: read the data, e.g. the second part of the 
>> SIP message
>> 6. a complete message is available (con2), process the message
>>
>> Is this description correct?
> 
> Yes, it is.

So, reading is completely non-blocking? Can it happen that the read from 
the connection (polling) can block for any reason (in the supervisor or 
worker)?

What about sending? If TCP asynch mode is enabled, who is sending - the 
worker or the supervisor process? Is it possible that the sending blocks 
(e.g. due to sending timeout, window-size 0, ...)?

regards
klaus