9 Jul
2009
9 Jul
'09
7:56 a.m.
On Jul 09, 2009 at 13:50, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei Pelinescu-Onciul schrieb:
Yes, it is.
Andrei
On Jul 09, 2009 at 10:27, Klaus Darilion
<klaus.mailinglists(a)pernau.at>
wrote:
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?
Andrei Pelinescu-Onciul schrieb:
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. On Jul 07, 2009 at 15:53, Klaus Darilion
<klaus.mailinglists(a)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?