4 Aug
2011
4 Aug
'11
11:17 a.m.
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
4 Aug
4 Aug
2:50 p.m.
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
9:42 p.m.
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
5 Aug
5 Aug
6:57 p.m.
On 8/4/11 8:42 PM, Juha Heinanen wrote:
Henning Westerholt writes:
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
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)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
6:16 p.m.
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
4858
days inactive
4859
days old
4 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen