Of keys and MAXHANDLE

	Cool, that what i was looking for. If i undestand the
unique key is in the format: %X<value> where X = 0 for an AS,
X = 3 for a person, etc... Except there is no relation between
the number and the attribute name (*in, *an, ect...) which adds another
level of pain.
	As for the 'normal keys' (the one without the %X), why not getting
rid of then? When you look up a query, you look at the key the user
provide, and you try to gess the type. For instance if the key
is 35.0.0.0 i do not think the user if looking for a person name.
Same thing with AS1755. And if the lookup fails you can always try another
type.
		Laurent

PS: the new prtraceroute is on merit.edu:~ftp/pub/meritrr/prtraceroute.tar.Z
(anonymous FTP).
The code for the ALC server (a new name for YAP :-) is not yet publicly
available. Maybe next week. But if your insterested in the protocol yuo can
look at the code of prtraceroute. (and no ALC server is currently running,
so you won't be able to try it)
 
> OK, let me try and explain the key generation in a bit more detail.
> For each object a set of keys is generated (eg firstname and lastname
> for persons) PLUS a unique key, which is only used when
> adding/deleting objects, never for normal lookups. The unique key for
> an object is defined in the config, with the addition of something
> special which makes it different from another object that might have
> the same unique key. The special bit added is the sort key (also
> defined in the config) with a % sign added. So, for instance for an AS
> the unique key would for instance be %0as1755, and a person with name
> AS1755 would have unique key %3as1755. The idea is basically the same.
> There is only one unique key per object. The reason why it is never
> used in queries is that from a query you (usually) cannot determine
> what kind of object you are looking for (person as1755 or autonomous
> system as1755) so that is where the normal keys are used (as1755 as
> key would point to both the person and the autonomous system object).
> 
> When updating an object, you know the object type, so you can use the
> unique key to uniquely locate the object. You can see all the keys by
> doing a showdbm on one of the databases. We know this increases the
> numberof keys quite significantly, but it helps making things easier.
> The routines that generate the keys in the RIPE s/w are enukey.pl for
> the unique key, and enkeys.pl for all other keys.
> 
> Is this what you are looking for? If not, could you explain why you
> would like to see what you propose? The change is indeed quite simple,
> although there might be some timing issues, but it could be done.
> 
> -Marten
> 


-- 
Laurent Joncheray,                                 E-Mail: lpj at merit.edu
    Merit Network Inc, 1071 Beal Avenue,           Phone:  +1 (313) 936 2065
    Ann Arbor, MI 48109, USA                       Fax:    +1 (313) 747 3745
"This is the end, Beautiful friend. This is the end, My only friend, the end" JM



-------- Logged at  Thu Apr 7 21:39:25 MET DST 1994  ---------