Hello,

Hi Daniel - great work. 

On Tue, 8 Jul 2025, 19:20 Daniel-Constantin Mierla, <miconda@gmail.com> wrote:

Hello,

some updates: during the past several days I added a new mode controlled by the new parameter tcp_main_threads. If set to 1, the tcp main process create a thread for each Kamailio process and the tls read and encode operations are done by these threads. Each Kamailio process when needs to do tcp read or encode passes the task to the corresponding tcp main thread via in memory IPC (pipes and shared memory).

Thanks Daniel!  Just to be clear - you are converting TLS function calls into RPC-style where the 'remote' actually does all the work?

The remote in this case, is a multi-threaded service that handles actual OpenSSL function calls - (IOW a TLS-offloading service).

yes, it is rpc-style, passing a pointer to a structure in shared memory to tcp-main-process threads via in memory pipes, so nothing on the net.

I think it can be optimized more over the time, by allocating tls-encoding input-buffers in shared memory at startup and reused, and maybe other operations ... but for PoC, I didn't want to change much in the existing code, and the initial tests does not show any noticeable difference in running classic style vs new style.

The spiralling over 8 connections back to Kamailio was done to simulate also trunk-style connections, with many messages on the same connection. Probably needs to be double-checked, but the read/encode tls callbacks should be run under tcp-connection read/write locks, which should be thread safe, if not some pthread mutexes have to be added, but still it will be as a pair for the tcp-connection read/write locks, so it should not make big difference comparing with the old style.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy, Training and Development Services -- asipto.com