(RADIATOR) Port limit accuracy

[MStefan at enertel.nl]

Having the standard set-up with Prim/Sec Radiator server with a backend with
Prim/Sec database let's suppose we would like to implement the port limit
check(per DNIS) by means of dedicated AuthByPortlimit or Simultaneous-use
check+Sessiondatabase

My question is about performance and accuracy of the counters in case of
failure( I suppose only for the backend)


I can think of two scenarios

1. When a database from the backend goes down then the other one takes over.
The second one I suppose has "quite an old update" due to of any possible
replication mechanism. If this is the case then the port limit check is not
quite accurate from now on. Question here is how we can synchronise the
database with the NAS(if the NAS type is not mentioned). Can we run a
command(from Radiator) in the middle of the night to interrogate all NAS's
in order to have this synchronisation back?

2. Setting two sessiondatabases one for the primary database and one for the
secondary database but the drawback here could be the performance due to two
extra queries(insert/delete) to the backend(maybe I am wrong)


Does anybody have an experience about this?What would be the best set-up
versus performance?

Thanks in advance

Kind Regards

Marius Stefan



#***************************************************************************
# 
# Dit e-mailbericht met eventuele attachments is uitsluitend bestemd voor de
# geadresseerde(n) en bevat mogelijk vertrouwelijke gegevens en/of is
# beschermd door intellectuele eigendomsrechten. Bent u niet de
# geadresseerde, neemt u dan zo spoedig mogelijk contact op met de afzender
# en verzoeken wij u het e-mailbericht en eventuele attachments van uw
# computer te verwijderen. Elk gebruik van de inhoud van dit e-mailbericht
# en eventuele attachments (waaronder verveelvoudiging, verspreiding of het
# anderzins openbaar maken in welke vorm dan ook) door andere personen dan
# de bedoelde geadresseerden is verboden. De weergegeven mening is puur
# persoonlijk en hoeft niet noodzakelijk over een te komen met die van
# Enertel. Enertel is niet aansprakelijk voor de inhoud van dit
# e-mailbericht en eventuele attachments.


===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.