Jan Janak wrote:
On 30-05-2005 14:11, Greger V. Teigre wrote:
For the sake of the readers, here is how I understand SER's operations today:
- Usrloc is always written to cache, DB write is controlled through
write-through parameter 2. Replication is handled by t_replicate 3. Management of cache is not needed, the cache is always updated. However, an updated DB (and thus dirty cache) will not be detected
I am working on that already. The entries in the usrloc cache will have an additional expires value and if that value expires then the usrloc code will refresh it from the database. Also there will be no full cache anymore -- usrloc will cache only a portion of the whole location database and old entries will be using LRU scheme.
Excellent news!
The cache will be empty upon startup. When SER calls lookup then usrloc will search the cache -- if there is no entry or if it is expired then it will load it from the database and store in the cache for limited period of time. If there is no entry in the database then it will create a negative cache entry (to limit the amount of unsuccessful database queries).
Database updates will not assume anything about the state of the database so it should not matter if the entry still exists / does not exists / has been modified..
I assume another ser server receiving an update must both write to DB and do a t_replicate to other ser servers who then do save_memory() as Paul responded in his last email to Karl?
There is one drawback though -- nathelper as it is implemented right now will not work anymore -- we would need to rewrite it to use the contents of the database.
Are you referring to the ping feature only or are there other things as well? Reading all NATed devices from DB every 30 seconds?
I must admit I often fall for the argument: "let each system do what it is best at." Following that, replication should only be done at an application level if the underlying database is not capable of doing it (if we agree that a DB is good at replication). The only thing I see a DB is not capable of, is handling the NAT issues. So, if a given usrloc has to be represented by different location (ex. the registration server), then the DB cannot do replication. However, if the NAT issue is handled through some other means, ex. Call-Id aware LVS with one public IP, then the usrloc should be the same across DBs and the DB should handle the replication.
Another approach would be to let the user agent handle NATs. Sipura phones, for example, can register with two proxy servers.
Yes, good point. But I'm not aware of many other user agents with such support yet?!
g-)