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@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