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.
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.
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.Thanks for documenting this in the commit.
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