1 Aug
2005
1 Aug
'05
11:50 a.m.
Hi Andy!
Another problem: nathelper uses the in memory location table to ping
natted clients. Thus, also nathelper would have to query the database
and we need a process to watch the expires and delete outdated entries.
regards,
klaus
Greger V. Teigre wrote:
Hi Andreas,
You are probably one of the people on the list with the most experience
with replication. AFAIK, you are correct on all statements below. I
assume you have SERs on different locations since TCP connect timeout is
a problem?
But I'm not sure why removing the cache would help you?! Unless you
want to move to a cluster or DB layer replication?
IMHO, there are only two valid paths for replication in SER: Either
develop a SIP-layer replication with guaranteed deliveries, queue,
non-blocking etc (which ends up being proprietary SER) or patch up SER
to better be able to handle DB-based replication.
I lean towards DB-based replication. Two prominent things that must be
handled: Storing the Path information for proper routing of messages to
UAs behind NAT and a cache that checks the DB if location is not found
in memory.
I would be very interested in patches for this in the experimental CVS
module ;-)
g-)
Andreas Granig wrote:
Hi all,
we use DNSSRV balancing and forward_tcp() to replicate registrations
from one SER to the other SERs in the system.
Now when one machine completely crashes, all other SER processes on
all other machines hang when processing a REGISTER until tcp-connect
times out, leading to a system load of ~16 per machine assuming 16
child processes per SER, and no other messages can be processed.
I understand that replicating using UDP would solve this issue, but
then replicated registrations get lost every now and then because of
unreliable transmission, and as far as I found out t_replicate() can
only be used for replicating to *one* other SER.
This really gets me thinking about patching out the internal location
cache and lookup every location from memory, because this additional
lookup really doesn't hurt because of ~10 other DB queries per call.
IMHO in systems with more than two SERs this cache is just a big pain.
Andy
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers