On Jul 09, 2009 at 10:27, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
On Jul 07, 2009 at 15:53, Klaus Darilion klaus.mailinglists@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.
What happens if a bad client only sends a half SIP message: is the process blocked until the full message is received or is it able to read from multiple connections concurrently?
No, each worker can handle as many concurrent connections as memory allows. If you are thinking about the recently publicized (but quite obvious to people writing proxies) "slowloris" HTTP DoS, it wouldn't work (either on sip-router or any other *ser, kamailio a.s.o).
Note that the tcp code is optimized for lots of connections (e.g. outbound proxy, registrar) and not for very few connections (e.g. inter-domain). Last time I've checked (older ser version pre 2.1) it could handle 120k tcp connections with traffic on them, on a 4Gb RAM machine (2Gb ser/ 2Gb free/kernel). After that the kernel will start to run out of mem.
Andrei