[SR-Users] udp vs. tcp receiver processes

Daniel-Constantin Mierla miconda at gmail.com
Fri Aug 5 17:57:49 CEST 2011



On 8/4/11 8:42 PM, Juha Heinanen wrote:
> Henning Westerholt writes:
>
>> this is the result of the different server design for UDP and TCP. For
>> TCP
>> AFAIK one main dispatcher accepts all the connections and then
>> distribute them
>> to the workers. For UDP the workers listen directly on the (one) network
>> socket, so there is no dispatcher. It looks like a waste of resources,
>> but its from a implementation POV much easier.
> in that case, it would make sense to be able to define per udp listen
> address, how many processes are spawned, since seldom all addresses are
> equally busy.

This would be useful -- I wanted to look how feasible is and maybe 
implement it, but no time yet -- maybe someone will do the patch.

The waste of resources is mainly passive, but still will be some 
benefits, at least esthetically -- in some cases I use 127.0.0.1 just to 
send xmlrpc for admin purposes which are very rare and don't need the 
same number of workers as for SIP over UDP.

One idea was to add udp_children and sctp_children parameters (or just 
one like socket_children) that will count as they are set and will 
affect next listen, like:

socket_children=2
listen=127.0.0.1
socket_children=8
listen = ...

The other idea was to define a socket block, like:

socket {
   listen=...
   children=2
   # -- other attributes per socket when needed
}

First option would be easier, since does not introduce much new stuff, 
the second is more structured.

Cheers,
Daniel
>
> -- juha
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda




More information about the sr-users mailing list