On 05.05.24 11:30, Olle E. Johansson wrote:
On 4 May 2024, at 20:19, Daniel-Constantin Mierla
via sr-dev
<sr-dev(a)lists.kamailio.org> wrote:
core: new udp receiver mode - one multi-threaded process
- activated with udp_receiver_mode=1
- one process is created that starts one receiver thread per UDP socket
- SIP messages are pushed to "udp" async tasks group
- sending is still done by any of processes
Wow. That sounds like a huge improvement.
It is built reusing existing components such as async task groups and
sworker, but indeed it could change quite a bit how everything was
handled so far for UDP. Still the config execution is down with
dedicated processes created for the async task group, the modules should
not be impacted.
Thanks for documenting this in the commit.
Adding to wiki will follow, the whole affair is still kind of work in
progress, because I plan to add support for mixing old style
pool-of-processes per socket with the new style of multi-threaded
receiver for a group of processes.
Can you elaborate a bit more on what you think are the main advantages
of this compared with the current behaviour with many processes
handling incoming UDP? Any special situation where the new
multithreaded architecture is better?
There are situations when Kamailio has to be configured to listen on
many IPs or ports and on many of them the volume of traffic is rather
low. There is the option to sent the number of workers per socket, but
even having a single process per socket can become a hassle (e.g., too
many database connections), say when you have to listen on 10s/100s of
UDP sockets.
TCP/TLS has a single pool of processes, so it is not impacted by number
of sockets as it was UDP, but a similar multi-threaded approach could be
considered as a configurable option as well.
Cheers,
Daniel
--
Daniel-Constantin Mierla (@
asipto.com)
twitter.com/miconda --
linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services --
asipto.com