Hi Stefan,

certainly, a new storage mode “shared memory” could be added, to avoid any additional dependencies for topos. This sounds useful.

I personally don’t see a large case for adding also DMQ synchronisation capabilities for it. The DMQ synchronisation is not 100% reliable in all corner cases, there are no locks or other synchronization mechanism implemented. As a loss of topology related information would cause immediate issues for message processing, it might be not the best choice especially as there is already redis as a distributed in memory storage available.

But maybe I just misunderstood the motivation for the DMQ synchronization for topos information. If its e.g. more about an active/passive fail-over setup, data-consistency issues are of course not a big issue.

Cheers,

Henning

From: Stefan Mititelu via sr-dev <sr-dev@lists.kamailio.org>
Sent: Friday, October 18, 2024 10:45 AM
To: sr-dev@lists.kamailio.org
Cc: Stefan Mititelu <stefan.mititelu@net2phone.com>
Subject: [sr-dev] topos module with storage "shm"

Hi,

I am thinking of this idea to add shm storage for topos module. Main motivation for this is that if db backend is not available, there will be no store/load happening.

Did anyone else thought of this or is doing something similar already?

I see 2 milestones here:

1. Add code in topos to keep a shm hash table with all the information needed, guarded via locks. The api functions should be very similar to what tps_storage.c has, just it will do ops directly in memory not on db.

2. Find a way to synchronize this topos hash table among multiple kamailios. This should be similar to how htable module syncronize via DMQ. Sync may happen either for each new cell, for batches or for entire topos hash table.

What do you think of this? Any opinions, comments, appreciated.

Thank you,

Stefan Mititelu