On Tue, May 14, 2024 at 01:20:14AM +0200, Neels Hofmeyr wrote: > On Mon, May 13, 2024 at 09:05:26AM +0200, Harald Welte wrote: > > IMHO yet another reason to give named counters a try, as we discussed. They > > might have other problems,but if we don't try, we never know. > > Is your idea to use a named counter that remains persistent even if the hNodeB > disconnects, in order to avoid the race?
The idea was to have a named counter whose name doesn't get recycled, and thereby there's no chance of the race you described. A persistent one might also be an alternative, but of course only in scenarios where the hNBs are a static set. I believe we have seen cases at other customerswhere the hNB comes back with a different identity every time it connects, so one would be leaking counters if they were persistent, as in reality every reconnect a new one would be allocated and all old ones would be stale. -- - Harald Welte <[email protected]> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
