i have 8 children specified in default file and in cfg file i have:
listen=192.98.101.10:5060; listen=udp:127.0.0.1:5070; listen=udp:127.0.0.1:5070; listen=tcp:127.0.0.1:5070; listen=udp:127.0.0.1:5080; listen=tcp:127.0.0.1:5080; listen=tcp:127.0.0.1:6060;
that results in 8 tcp receiver processes but 3 x 8 udp receiver processes:
# sip-proxy_ctl ps 30720 attendant 30721 udp receiver child=0 sock=192.98.101.10:5060 30722 udp receiver child=1 sock=192.98.101.10:5060 30723 udp receiver child=2 sock=192.98.101.10:5060 30724 udp receiver child=3 sock=192.98.101.10:5060 30725 udp receiver child=4 sock=192.98.101.10:5060 30726 udp receiver child=5 sock=192.98.101.10:5060 30727 udp receiver child=6 sock=192.98.101.10:5060 30728 udp receiver child=7 sock=192.98.101.10:5060 30729 udp receiver child=0 sock=127.0.0.1:5070 30730 udp receiver child=1 sock=127.0.0.1:5070 30731 udp receiver child=2 sock=127.0.0.1:5070 30732 udp receiver child=3 sock=127.0.0.1:5070 30733 udp receiver child=4 sock=127.0.0.1:5070 30734 udp receiver child=5 sock=127.0.0.1:5070 30735 udp receiver child=6 sock=127.0.0.1:5070 30736 udp receiver child=7 sock=127.0.0.1:5070 30738 udp receiver child=0 sock=127.0.0.1:5080 30740 udp receiver child=1 sock=127.0.0.1:5080 30752 udp receiver child=2 sock=127.0.0.1:5080 30754 udp receiver child=3 sock=127.0.0.1:5080 30755 udp receiver child=4 sock=127.0.0.1:5080 30756 udp receiver child=5 sock=127.0.0.1:5080 30758 udp receiver child=6 sock=127.0.0.1:5080 30760 udp receiver child=7 sock=127.0.0.1:5080 30761 slow timer 30763 timer 30765 ctl handler 30803 TIMER NH 30805 TIMER RT 30806 tcp receiver child=0 30808 tcp receiver child=1 30810 tcp receiver child=2 30812 tcp receiver child=3 30813 tcp receiver child=4 30844 tcp receiver child=5 30846 tcp receiver child=6 30847 tcp receiver child=7 30849 tcp main process
why cannot one udp receiver process handle all listening addresses like tcp processes seem to be able to do? the above seems like waste of resources.
-- juha
On Thursday 04 August 2011, Juha Heinanen wrote:
i have 8 children specified in default file and in cfg file i have:
listen=192.98.101.10:5060; listen=udp:127.0.0.1:5070; listen=udp:127.0.0.1:5070; listen=tcp:127.0.0.1:5070; listen=udp:127.0.0.1:5080; listen=tcp:127.0.0.1:5080; listen=tcp:127.0.0.1:6060;
that results in 8 tcp receiver processes but 3 x 8 udp receiver processes: [..] why cannot one udp receiver process handle all listening addresses like tcp processes seem to be able to do? the above seems like waste of resources.
Hi Juha,
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.
Best regards,
Henning
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.
-- juha
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel-Constantin Mierla writes:
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.
either would be ok if it is too difficult to dispatch udp requests to common pool of processes.
-- juha
-
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen