30 May
2005
30 May
'05
3:56 p.m.
Jan Janak wrote:
Yes, good point. But I'm not aware of many other user agents with such
support yet?!
g-)
On 30-05-2005 14:11, Greger V. Teigre wrote:
Excellent news!
For the sake of the readers, here is how I
understand SER's
operations today:
1. 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. 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.