HELP! 'networkupdate', diskussion on short names of
- Previous message (by thread): HELP! 'networkupdate', diskussion on short names of attributes
- Next message (by thread): Draft/Proposed Agenda for the DB-WG Meeting at RIPE 25
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
davidk at ISI.EDU
davidk at ISI.EDU
Fri Sep 20 23:29:16 CEST 1996
Hi Markus, > Markus Bock writes : > > who gave me quick response to my 'cry for help'. > Thank you very much for your suggestions and for > taking time to think about that problem with the > 'networkupdate' client programm. Below you can > read more about the progress in that case. > And no, there is no reason to say sorry for > a 'delayed response'. I'm pleased about your > quick and helpful reactions. > Thank you again! Thanks! > 2. More about the problem with 'networkupdate' > ============================================= > > Yes, great. I think with the direct network update-method > one has many potentialities to develope client-server > based applications with a two task architecture like you > see in the sketch below (just an example). Agreed. > > Maybe I make something wrong or this effect has something to do with > > > running under Slowaris 2.5 ... ? > > > May be, may be not. Could you try the C version of networkupdate > > (available from ftp.ripe.net/tools/whois-tools*) and see if the same > > problem happens ? > > Yes I did it. The same problem happens NOT. > I performed several tests with the C version and everything is > working fine giving the estimated results. Good, then the problem is not in the server. I did some tests with the perl version at RIPE and it seems to work under Linux & SUNOS. I leave it to you & the new database maintainers to see if you can find a solution for this Solaris specific behavior (no need to CC the db-wg list anymore ...) > Just for information: > --------------------- > I had to do the following changes inside the makefile of > the C versions of the ripe whois tools to compile it > successful at our site under Solaris 2.5 with gcc: > > - define '-DSYSV' added This one is in the documentation I believe... > - additional LIBS 'LIBS= -lresolv -lsocket -lnsl' added > - changing the syntax to call install > # install: ${PROG} > # $(INSTALL) -c ${DESTDIR} -s -m 755 ${PROG} networkupdate > # $(INSTALL) -c ${MANDIR}/whois.1 -m 444 whois.man Could you send a message with a copy of your Makefile to the new database maintainers <ripe-dbm at ripe.net> so that they can update the whois source code? > Yes, I did it. > - With the perl version I didn't received the message that tells me > that I'm not authorized to do network updates. There is an analogical > problem like I described in my 'cry for help'. 'networkupdate' > terminates immediately. > > - With the C version I received the estimated message > % ERROR: ***You are not authorized to do network updates***. > > With this results I agree with you that the problem is problably > in the client side of the software. I tried to find out what Correct. > is potentially wrong in the software by taking the examples for a > client and a server from L. Walls camel book and comparing it with > the RIPE DB SW (I assume that the same mechanisms are used by the > RIPE DB SW). Yes, but a bit more sophisticated. > that these examples are able to handle the input of multiple lines > (I'm not familar with 'command buffering or not' stuff) or > to produce an analogical failure like decribed above. This stuff is indeed very, very trickey in perl. Best advise is usually to unbuffer all output & input although that is certainly not always most efficient. > Has anyone tested the perl version of the networkupdate programm > succesfully at his site ? > > If yes, in which enviroment (OS, version, HW etc.) ? Yes, see above. > 3. Comments on short names of attributes > ======================================== > > First: > ------ > > While testing the RIPE DB for use to store own data objects I > examined the following cases: > > > Assume that you have to store 30 or more new database objects > with about 300 (or more) new attributes in a (SPLIT) RIPE database > (I already did it). Because you will have problems to find > sensefull short names for attributes you use a numbering > scheme like this: > > # DB-object dummy A1 > ATTR A1 dummy_longname_1 > ATTR A2 dummy_longname_2 > ATTR A3 dummy_longname_3 > > > # DB-object dummy A1 > OBJ A1 ATSQ A1 A2 A3 > OBJ A1 MAND A1 > OBJ A1 MULT A2 A3 > OBJ A1 UNIQ A1 > OBJ A1 KEYS A1 > > Seems ok. > > *** But be careful. Don't use uppercase letters > *** for naming database objects and attributes > *** in a SPLIT database. > > The side effects > are that at first everything is working fine (indexing, dbupdate > updates via email etc.). The data will be stored correctly. > But if you query the database via whois and whoisd you ever > get the message that will be displayed if no match was found > (have a look in your ripedb-config file). What happened ? > After I had a look at the source code of the whoisd I think > one can find the explanation in this section > > # sub findsplitdbs { > > I think that with this the software is not able to find the datafiles, > i.e. > which are named by this konvention > > /whereever/it/is/SOURCE.db.OBJECT > /whereever/it/is/SOURCE.db.OBJECT.pag > /whereever/it/is/SOURCE.db.OBJECT.dir > > where OBJECT is in uppercase letters. > > Does somebody agree with me ? I think that it will go wrong already earlier in the code. The database code is more or less case-insensitive and no attempt has been made to preserve caase of the attribute names. This can be changed of course, but I don't know if it's a good idea to make a difference between attribute 'A1:' and 'a1:'. > Second: > ------- > > Above I wrote about a problem to find sensefull short names if > you have to store many new database objects with many > (many) attributes. What you have at least for this is a two > letter code with all alphabetic characters (in lowercase) > and all digits. So you have > > (26+10) * (26+10) = 1296 (I hope it is correct...) > > possibilities for short names. This seems to be enough. > But you have still the problem to find sensefull short names > for a large amount of database objects and attributes. > Maybe I see a problem 'where no problem is' but I can > assume that in future even the RIPE database (if it will > growth by objects and attributes) will reache the border > finding sensefull names for short attributes. > So my questions are: > > - Is it possible to use in future only the long names > of attributes and objects or I agree with this. There are also better/other reasons: the datasize differences are not that much, the code will be simplified (less bugs) and faster. > - needs this change too much manpower and time ? It doesn't need that much manpower. The bigger problem is the backwards compatibility. That certainly needs some work for converting back long->short names when doing -F queries. > 4. Comments on whois -i option > ============================== > > Wow ! I really like this option. > > If you have a somewhat clever data modelling you can > realize something like a 'where clause' which is known from SQL. > > Another thing is that you can realize something like a > 'join' over two database objects. > > You just have to play a little bit around with the 'KEY' and > 'REC' terms inside the definition of your database objects. Yup, this feature allows for a whole buch of new ideas and proposals ;-). > 5. Question on destination for emails > ===================================== > in 'RIPE DB' context > ==================== > > I don't know if the database working group is the right address > to report everthing in context RIPE database. > > Should one better report only for i.e. problems with implementation > and porting the software directly to the database maintainer > at RIPE NCC <ripe-dbm at ripe.net> ? > > and on the other side > > Should one better report only i.e. issues about the database concepts > directly to the database working group ? > > Is there somewhat like a rule for this ? <ripe-dbm at ripe.net> is the RIPE mail box for bug reports & questions I think that the database lists need some reorganizing (may be good topic for next RIPE meeting!): db-wg - database working group list for design & working group discussions rr-impl - not very much used db-beta - not very much used But I leave this subject for the working group to decide ... David K. ---
- Previous message (by thread): HELP! 'networkupdate', diskussion on short names of attributes
- Next message (by thread): Draft/Proposed Agenda for the DB-WG Meeting at RIPE 25
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]