dbase dist once more
Tony Bates
Tue Oct 18 18:20:08 CET 1994
"Dale S. Johnson" <dsj at merit.edu> writes: * 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, Dale, one small comment on this. I notice you are using mail addresses in the tech-c and admin-c for the prdb dumps. This is in fact illegal syntax. Just a minor nit. * (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). * This is something I would like to see if we can. The code right now for syntax.pl is pretty nasty (I did all this mess and I cant code so that will explain this ;-)).We can talk off line about this if you need a hand to get the pasrer in there. The main thing it needs to do is also produce useful messages upon ERROR or WARNING which if I remember the original way you did this made it quite difficult to do. AS nicer way would be to pass the whole object to the pasrer perhaps. * 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). * sounds great - we would appreciate some others getting into the code and seeing where we can get speed ups as Marten mentioned already. * 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:53:47 MET 1994 ---------
[ rr-impl Archive ]