Hi, Thanks for the feedback for this. My motivation is related to an active-active scenario and supposing that redis db becomes unavailable => topology info will then become unavailable. Now that I am double thinking about DMQ sync, I think you are right. If DMQ does not sync fast enough, there will be no topology info available too... Looking in existing code, and doing some tests with redis, I see topos does 2 types of redis store: 1. for dialog "d:..." 2. for each transaction "b:..." I. Suppose a BYE comes to a kamailio => topos needs to have the nr 1. already synced or will send back "404 Not here" and not forward the BYE II. Suppose a 200OK for that BYE comes to a diiferent kamailio => topos needs to have the nr 2. already synced or will have bad Via header and log error Thank you, Stefan On Mon, Oct 21, 2024 at 10:02 AM Henning Westerholt <hw(a)gilawa.com> wrote:

Hi Stefan, thanks for the reply. DMQ is usually fast, but it can have data loss or data synchronization issues if you are using in concurrent access scenarios. Regarding using the shared memory as a cache, this is of course frequently used in usrloc module or others. It would certainly help for short unavailability of the database. It also should improve the performance if combined with a timer-based write-back mode, like in usrloc. Cheers, Henning From: Stefan Mititelu &lt;stefan.mititelu(a)net2phone.com&gt; Sent: Monday, October 21, 2024 5:05 PM To: Henning Westerholt &lt;hw(a)gilawa.com&gt; Cc: Kamailio (SER) - Development Mailing List &lt;sr-dev(a)lists.kamailio.org&gt; Subject: Re: [sr-dev] topos module with storage "shm" So far I've been thinking of this topos SHM htable stuff as a replacement for existing storages (redis/mysql). Now, I am thinking of this topos SHM htable as a cache between kama procs and existing storages. So this should happen: 1. on store, always keep in shm htable and write in storage db 2. on load, check shm htable first, and if not found, load from storage db in shm htable Should be an improvement to existing active-active setups, when redis db becomes unavailable. Of course, DMQ sync of this topos SHM htable can be done, in best effort way. Can happen that db storage is unavailable and DMQ sync is too slow at the same time => topos will still fail. Thanks, Stefan On Mon, Oct 21, 2024 at 4:28 PM Stefan Mititelu <stefan.mititelu@net2phone.com<mailto:stefan.mititelu@net2phone.com>> wrote: Hi, Thanks for the feedback for this. My motivation is related to an active-active scenario and supposing that redis db becomes unavailable => topology info will then become unavailable. Now that I am double thinking about DMQ sync, I think you are right. If DMQ does not sync fast enough, there will be no topology info available too... Looking in existing code, and doing some tests with redis, I see topos does 2 types of redis store: 1. for dialog "d:..." 2. for each transaction "b:..." I. Suppose a BYE comes to a kamailio => topos needs to have the nr 1. already synced or will send back "404 Not here" and not forward the BYE II. Suppose a 200OK for that BYE comes to a diiferent kamailio => topos needs to have the nr 2. already synced or will have bad Via header and log error Thank you, Stefan On Mon, Oct 21, 2024 at 10:02 AM Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>> wrote: 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<mailto:sr-dev@lists.kamailio.org>> Sent: Friday, October 18, 2024 10:45 AM To: sr-dev@lists.kamailio.org<mailto:sr-dev@lists.kamailio.org> Cc: Stefan Mititelu <stefan.mititelu@net2phone.com<mailto: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

Hi Stefan, Thanks for the follow up on this topic. On the first thought, I am not 100% sure if integrating the htable module into another module is the best way to go forward. Don’t you think a direct integration of a shared memory cache (e.g. like usrloc module, dialog module etc..) would be more efficient and easier to use? You will also loose direct feedback about errors or delay for DMQ synchronisation if you channel it over another module. I think it would be also good to have an own “message topic” for the DMQ synchronisation that the traffic can be clearly attributed to the topos module and not have it integrated into the htable DMQ traffic. I understand the motivation of not writing everything from the scratch. Not sure how feasible this is, but perhaps it’s possible to create a generic memory cache layer that can be used from modules and not using the htable module which exports functionality for the configuration script. Maybe other people that worked recently with these specific modules can share their opinion as well. Cheers, Henning From: Stefan Mititelu via sr-dev &lt;sr-dev(a)lists.kamailio.org&gt; Sent: Montag, 28. Oktober 2024 18:53 To: Kamailio (SER) - Development Mailing List &lt;sr-dev(a)lists.kamailio.org&gt; Cc: Stefan Mititelu &lt;stefan.mititelu(a)net2phone.com&gt; Subject: [sr-dev] Re: topos module with storage "shm" I am going to look into the following dev idea: 1. from htable module try export a bind() API functions (e.g. similar to usrloc) and check that basic htable module ops can be done from another module 2. next, create a topos_htable module that will work with those htable module API functions 3. last, add new storage("htable") to topos module This way, topos can use all features of htable module (e.g. standalone SHM storage and DMQ sync if/when needed) Thanks, Stefan On Tue, Oct 22, 2024 at 10:07 AM Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>> wrote: Hi Stefan, thanks for the reply. DMQ is usually fast, but it can have data loss or data synchronization issues if you are using in concurrent access scenarios. Regarding using the shared memory as a cache, this is of course frequently used in usrloc module or others. It would certainly help for short unavailability of the database. It also should improve the performance if combined with a timer-based write-back mode, like in usrloc. Cheers, Henning From: Stefan Mititelu <stefan.mititelu@net2phone.com<mailto:stefan.mititelu@net2phone.com>> Sent: Monday, October 21, 2024 5:05 PM To: Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>> Cc: Kamailio (SER) - Development Mailing List <sr-dev@lists.kamailio.org<mailto:sr-dev@lists.kamailio.org>> Subject: Re: [sr-dev] topos module with storage "shm" So far I've been thinking of this topos SHM htable stuff as a replacement for existing storages (redis/mysql). Now, I am thinking of this topos SHM htable as a cache between kama procs and existing storages. So this should happen: 1. on store, always keep in shm htable and write in storage db 2. on load, check shm htable first, and if not found, load from storage db in shm htable Should be an improvement to existing active-active setups, when redis db becomes unavailable. Of course, DMQ sync of this topos SHM htable can be done, in best effort way. Can happen that db storage is unavailable and DMQ sync is too slow at the same time => topos will still fail. Thanks, Stefan On Mon, Oct 21, 2024 at 4:28 PM Stefan Mititelu <stefan.mititelu@net2phone.com<mailto:stefan.mititelu@net2phone.com>> wrote: Hi, Thanks for the feedback for this. My motivation is related to an active-active scenario and supposing that redis db becomes unavailable => topology info will then become unavailable. Now that I am double thinking about DMQ sync, I think you are right. If DMQ does not sync fast enough, there will be no topology info available too... Looking in existing code, and doing some tests with redis, I see topos does 2 types of redis store: 1. for dialog "d:..." 2. for each transaction "b:..." I. Suppose a BYE comes to a kamailio => topos needs to have the nr 1. already synced or will send back "404 Not here" and not forward the BYE II. Suppose a 200OK for that BYE comes to a diiferent kamailio => topos needs to have the nr 2. already synced or will have bad Via header and log error Thank you, Stefan On Mon, Oct 21, 2024 at 10:02 AM Henning Westerholt <hw@gilawa.com<mailto:hw@gilawa.com>> wrote: 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<mailto:sr-dev@lists.kamailio.org>> Sent: Friday, October 18, 2024 10:45 AM To: sr-dev@lists.kamailio.org<mailto:sr-dev@lists.kamailio.org> Cc: Stefan Mititelu <stefan.mititelu@net2phone.com<mailto: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