[Kamailio-Users] no free tcp receiver

Klaus Darilion klaus.mailinglists at pernau.at
Tue Dec 9 12:41:49 CET 2008



Gawith schrieb:
> 
> Klaus Darilion schrieb:
>>> That's the point. The server does nearly nothing:
>>> I have 10 TCP childs and only about 2 INVITEs/sec.
>> Then there is probably something going wrong.
>>
>> I would:
>> - stop the proxy and all clients
>> - start tcpdump or wireshark (without capture filter)
>> - start the clients (if you have clients)
>> - make a single call, hang up
>> - repeat the single call, hang up.
>>
>> Then analyze the capture file: Are there "strange" SYN packets trying to 
>> establish a connection which does not work? Are there other TCP errors 
>> (RST, FIN ...)
>>
>> I suspect that workers are trying to establish new tcp connection which 
>> do trigger a timeout - and as TCP handling in Kamailio is blocking the 
>> TCP workers are busy when new requests are received.
>>
> 
> I've check the traces and can not see any suspicious SYNs etc. All looks 
> fine.
> But I recognized that the "no free tcp receiver" comes along with a 
> "CRITICAL:core:handle_io: empty fd map" messages. Nevertheless, I have 
> no clue at all...
> 
> Just for clarification: if I have 5 TCP children, then only 4 childs are 
> worker processes. If a sip peering partner with 4 different SIP server 
> has a network split, all my worker childs are blocked and wait for TCP 
> timeouts. In the meantime, no calls to anywhere else is possible. Right?

It depends. e.g.

- Kamailio receives request which should be sent to 
sip:user at 1.1.1.1;transport=tcp: Kamailio will open TCP connection, will 
write to the socket in blocking mode. That means that one single worker 
process (either a UDP worker if the request was received via UDP or a 
TCP worker if the request was received via TCP) is blocked until the TCP 
ACK is received from the destination and the writing to the socket 
returns. Then this TCP connection is moved to the connection pool and 
then this worker process is free for some other tasks.

If the server on 1.1.1.1 does not answer to TCP packets, this single 
processed is blocked. For example, if you send 4 INVITE requests to the 
proxy afdressing 4 servers which do not exist - then 4 workers will 
block until the TCP handshake timeout will trigger.

But if everything is fine you can have handle hundreds of TCP connection 
  with a few worker processes - the requests are processes one after the 
other and the currently not needed TCP connections will be put to the 
TCP connection pool meanwhile.



regards
klaus







More information about the sr-users mailing list