Re: Root level prodir combined results

pays@faugeres.inria.fr Sun, 17 April 1994 11:58 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13286; 17 Apr 94 7:58 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13282; 17 Apr 94 7:58 EDT
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id aa22431; 17 Apr 94 7:58 EDT
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.01487-0@haig.cs.ucl.ac.uk>; Sun, 17 Apr 1994 12:33:19 +0100
Via: uk.ac.nsfnet-relay; Sun, 17 Apr 1994 12:33:07 +0100
Received: from faugeres.inria.fr by sun3.nsfnet-relay.ac.uk with Internet SMTP id <sg.12289-1@sun3.nsfnet-relay.ac.uk>; Sun, 17 Apr 1994 12:32:40 +0100
X400-Received: by /PRMD=inria/ADMD=atlas/C=fr/; Relayed; 17 Apr 94 13:32:24+0200
Date: 17 Apr 94 13:32:24+0200
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: pays@faugeres.inria.fr
To: Piete.Brooks@computer-lab.cambridge.ac.uk, pays@faugeres.inria.fr
Subject: Re: Root level prodir combined results
cc: /DD.Common=tech-support/@nexor.co.uk, osi-ds@cs.ucl.ac.uk, panamas@paradise.ulcc.ac.uk, prodir-support@nexor.co.uk
Message-ID: <766582344.813.0-faugeres.inria.fr*@MHS>

> 
> >   The trick to have one single fault-tolerant DSA was to
> >   register (in conformance with the X.500 model) one single
> >   server but which PSAP contains the NSAPs of both physical servers
> 
> Yeah that's what I do -- so it's legal is it ?

Absolutely, there is absolutely nothing preventing to do so
  as long as any of the physical servers behave as the
  "manager" of the given naming-context
Another point, but this is not conformance, is that one have
  to ensure that the 2 (several) physical DSA are well "synchronised".

It's perfectly legal and a very cheap way to provide
  excelent availability and robustness agains any type
  of failure (soft, hard, network)

> 
> > From my understanding the results contain
> >   1. a global availability result
> 
> i.e. try all presentation addresses for a given name and see if *any* responds.
> 
> >   2.a second unidentified entry
> 
> Oops -- maybe that's me :-(
> 
> My root.dsas has:
> 
> DsaDN               c=FR@o=CNRS@cn=opaxdsa
> OrgName             unknown
> PSAPaddr            "opaxdsa+8888"/TELEX+00728722+RFC-1006+03+134.157.4.5+8888|TELEX+00728722+RFC-1006+03+157.136.14.5+8888|TELEX+00728722+X.25(80)+01+20807513094606+CUDF+03010100|TELEX+00728722+X.25(80)+01+20809123019316+CUDF+03010100

apparently this is perfect as it contains 4 NSAPS
  1 RFC1006 and 1 X.25 for each physical server

> MasteredEntries     -2                  
> ManagerName         unknown
> ManagerEmail        unknown
> ManagerPhone        unknown
> 
> and the attempts are only 166 instead of 326 for most of the other ...
> 
> so one probing site appears to have the wrong info.
> 
> Hmmm -- looking at the root stats it appears that my info isn't used for the
> root data. So I assume that the same thing hold -- one of the two probing sites
> has a duplicate, as the info is:
> 
> 
>  99.40 Unknown Organisation, opaxdsa, CNRS, FR                      166
>      1 Timed out after 60 seconds
> 
>  93.25 Unknown Organisation, opaxdsa, CNRS, FR                      326
>      2 Unavailable 
>      8 Timed out after 60 seconds
>      9 Host is unreachable
>      3 Connection refused
> 
> i.e. *both* are unidentified.
> 
> 
> >     (which may correspond to one of the physical servers)
> >     what is measured exactly?
> 
> For which ?
> 
> >     why do we have 2 entries and not either 1 or 3?
> 
> One probing site with duff data ?
> 
> 

Well, I hope that the probing sites will check their data
for the french master

best regards,

-- PAP