dbase dist once more

Marten,

  Thanks enormously for making this code available, and for passing the
prdb.db through it.  Your letting us at early versions of the code has
made it possible for us to get the PRDB dumps converted to 181 format,
(including the right internal names), and to hack our old implemtation 
to recognize those new names.  Rick has also been able to peek at the
dbserver implementation and adjust his thinking (if not his dbserver
code, yet).  I will be able to look at syntax.pl to check about integrating
our yacc parser there (and handling multiple-line attributes).

  Unfortunately the Route Server machines arrived Friday as well as
your software distribution; we've shipped Laurent off to California
to help with the initial system administration of those machines so
that we can get them out to the NAPs.  Laurent should be back sometime
this week, at which point he can begin bringing up your new
distribution.  (Our new Routing Registry machine also arrived, so we
even have a spiffy new place to put it).

  Thanks again for making this stuff avaiable to us, and for beginning
to look at our data.

--Dale

PS:
> Thursday yet, and it works fine). If you have cycles to make a faster
> indexing program (I am thinking of Laurents programming skills here)
> I'd be interested. No doubt a C program could do all of this faster.

Rick has written a similar C program, though I think he then replaced it
by moving to Perl-5.  Rick?

==========================================================================


> From marten at ripe.net Fri Oct 14 14:45:22 1994
> To: dsj at merit.edu, lpj at merit.edu, rlr at merit.edu
> Subject: DB release 
> Cc: Tony Bates <tony at ripe.net>, Daniel Karrenberg <dfk at ripe.net>
> From: Marten Terpstra <Marten.Terpstra at ripe.net>
> Date: Fri, 14 Oct 1994 19:45:16 +0100
> Sender: Marten.Terpstra at ripe.net
> 
> 
> Folks,
> 
> I have put together a dbase distribution (of some sort) with some
> updated documentation. The docs are nowhere near complete but all
> modules are in there, and it explains how to do classless indexes and
> all. 
> 
> The distribution is not up for ftp yet for anyone, I would like you
> all to have a look at it first. Plan is to announce it to a sligly
> wider audience on Sunday or Monday or so.
> 
> You can find it in my home directory on fox.merit.edu. If you want to
> see what things look like when they are installed, have a look on
> ns.ripe.net in /dbase (or /nccfs3/dbase) which is where this is
> currently running.
> 
> The indexing is not particulary fast, but in my view, it does not need
> to be. Once the guarded attribute procedure is gone, cleaning would
> only be needed once a week or so.
> 
> I'll be here most of tomorrow and sunday (for PRIDE guide stuff) so if
> you have questions, shoot. I'll be in the first half of next week,
> then I am off to Interop in Paris for just over a week. I'll try and
> answer and clarify if I can anyways.
> 
> I have some hints on how to improve things if you have different DBM
> linked in with perl, but I am too tired now ;-) It basically now
> recognizes the 1K bucket size max for the SUN supplied version of DBM
> and will generate overflow files if it needs to put in more data than
> 1K for a certain key (needed for classless tree). The 1K limit is now
> hardcoded in cldb.pl.
> 
> Also (I keep coming up with new things here) if you run a cleandb, you
> do not have to do a classless index again. The classless indexes do
> NOT contain file offsets, but point to the unique key of the various
> objects which does not change when doing a cleandb. It basically will
> recognize IP numbers (in whatever format) and will do a recursive
> lookup. First from IP address to a certain (set of) unique keys, and
> then it will lookup these keys like it would normally do.Classless
> cleaning only needs to be done once a week or so. Have a look with
> showdbm and you'll see what I mean.
> 
> -Marten
> 
> PS Tony and Daniel, if you want to try and install, you can find it in
> /nccfs3/dbase.dist/dbase-beta.tar.gz.

----------------------------

> From marten at ripe.net Sun Oct 16 13:26:28 1994
> To: dsj at merit.edu, lpj at merit.edu, rlr at merit.edu
> Subject: dbase dist once more
> Cc: Tony Bates <tony at ripe.net>, Daniel Karrenberg <dfk at ripe.net>
> From: Marten Terpstra <Marten.Terpstra at ripe.net>
> Date: Sun, 16 Oct 1994 18:26:23 +0100
> Sender: Marten.Terpstra at ripe.net
> 
> 
> Folks,
> 
> I just put a new version of dbase-beta.tar.gz in my home dir on fox.
> The last version did not index inet-rtr interface addresses properly.
> That is fixed. There is one problem however which I do not understand
> yet. I tried to index the prdb you have on fox, and for some reason
> the DBM index grew to 170 Mbytes and I ran out of disk space. This is
> strange because I also have indexed the complete Internic database
> (80,000+ nets) and that had a normal size DBM file. I am talking about
> the real size of the DBM file, not the size ls reports. The only
> different is that you have routes, internic only nets. We tried on
> another machine as well (I thought it could have to do with disk
> fragmnentation or whatever) with the same results..... It is the
> classless index that generates this massive file. It is probably the
> dbm version we use (the standard sun one) but I have not been able to
> do a test with another dbm just yet. Please have a go and see what it
> does for you ....
> 
> -Marten
> 
> PS I also took the same file, only used the "rt:" lines and indexed
> and that went fine. The difference there is that if there is a origin,
> the key is the route, a tab, and then the origin. I do not understand
> why this would make such a different .... I'll play some more when I
> have the time. I ran out of disk space 1000 routes before the end ;-(
> 
> PPS The classless indexing is quite slow, however it needs to be done
> once every week or so only (I have not classless reindexed ours since
> Thursday yet, and it works fine). If you have cycles to make a faster
> indexing program (I am thinking of Laurents programming skills here)
> I'd be interested. No doubt a C program could do all of this faster.

-------------------



-------- Logged at  Tue Oct 18 18:20:54 MET 1994  ---------