Luca --- 1) Yes and No. We absolutely need to keep this material for the newbies - it cuts the support load way down. But we do need to cleanup the interface. I propose that (post 3.0) we just pick a small graphic ... something like the (?) we have on the About menu. Anywhere there is explanatory stuff, we use that to link to an appropriate help page. Then all we have to train people is to "Click the (?) if you want more information". We can use the tooltip/title tag to explain what is available.
For example on the active TCP sessions page, instead of the full explanation: The color of the host link indicates how recently the host was FIRST seen 0 to 5 minutes 5 to 15 minutes 15 to 30 minutes 30 to 60 minutes 60+ minutes We would have just the (?) at the top of the column. The tool tip would be "The color of the host link indicates how recently the host was FIRST seen. Click to see the ranges." And clicking would take you to an expanded version of 0 to 5 minutes 5 to 15 minutes 15 to 30 minutes 30 to 60 minutes 60+ minutes perhaps with instructions on how to change the values. 2) I don't think they disappear, in fact I think we need more controls, knobs and tweaks. But not as command line parameters, but rather - as we discussed a while back - they should move to a setup-type page. The beauty of this approach is that we can imbed as much explanation as is necessary. If you look at what I've done to the netFlow plugin, that's a model. I actually have this partly working - my parmsPlugin.c (current version attached), which allows you to change (most of) those run time options that can be safely changed. All that needs to be added - in concept - is storage in prefsCache.db. Then the only things that have to be set at run time are those that control the crude setup of the internals and those which prevent ntop from running, e.g. --sched-yield and ilk. That's my post 3.0 plan! -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Luca Deri > Sent: Monday, February 23, 2004 5:37 AM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop-dev] New sorting routines in cvs - these are post > 3.0pre1 - TEST NOW OR HOLD YOUR WATER > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Burton, > I appreciated some of the last changes you made to the source. > Nevertheless I personally dislike the "about sorting this column" link. > I want to remove it from the place where it is now and maybe moving to a > help page. The same applies to many help/comments that somehow are > useful for new users but useless to people who already use ntop. After > 3.0 is out these things will be also moved to help. > > Another issue is the amount of options that have been added to ntop. > After 3.0 all the options that start with -- (e.g. --p3p-cp) will need > to disappear or at least to be reduced significantly. I don't want to > require people to hold a Ph.D. in order to start ntop. > > Cheers, Luca > > > Burton M. Strauss III wrote: > > | I've completely rewritten the 'host' sorting routines, based on the > | acrimonious discussion and research over the last 4-5 days. > | > | It works for me. > | > | Your challenge is to test it. Now. > | > | This routine still isn't perfect and guess what - it still isn't... > | always... quite sorting what you see. It is, however, now sorting > | things with some plan and intelligence. > | > | Read the page "about sorting this column" for more details than you > | ever want. Read the comment in utils.c for the skinny (quoted at the > | bottom of this message). > | > | > | The epiphany was that I realized that the 1st piece I was doing (and > | talked about on Friday) would only go so far, because the > | makeHostLink() routine - probably the 2nd most troublesome piece of > | code in ntop (after the now gone hash resize) - was taking the > | fixed-up names and mucking with them further AFTER THEY HAD BEEN > | SORTED. So what you saw was sometimes nowhere near what was being > | sorted. > | > | When I realized this, it woke me out of a sound sleep at 2:45 am on > | Saturday Morning and I worked on it until 5 a.m. I've spent the > | better part of the last two days polishing it and working out the > | edge cases. > | > | This represents a lot of internal cleanup. > | > | hostSymIpAddress has been renamed to the more correct > | hostResolvedName and a hostResolvedNameType flag added so we know > | what type it represents. Flag values are in globals-defines.h - look > | for FLAG_HOST_SYM_ADDR_TYPE_ > | > | There is a routine, setResolvedName() to use when you change this. DO > | NOT JUST ARBITRARILY RESET IT. The routine lets you change only from > | a less preferred name to a more preferred one (e.g. MAC address -> > | DNS name). > | > | If you turn on the debug, you can actually SEE ntop resolve the host > | as it learns more about it: > | > | DEBUG_CMPFCTN: setResolvedName(0x08a31ff0) 0 -> 5 3COM > | CORPORATION:XX:XX:XX - hash.c(1150) DEBUG_CMPFCTN: > | setResolvedName(0x08a31ff0) 5 3COM CORPORATION:XX:XX:XX -> 6 > | 192.168.xxx.xxx - hash.c(948) DEBUG_CMPFCTN: > | setResolvedName(0x08a31ff0) 6 192.168.xxx.xxx -> -7 pooh.yyy.yyy - > | address.c(68) > | > | (Neat, eh?) > | > | The compare function to use is cmpFctnResolvedName - this not only > | knows how to sort based on hostResolvedNameType, it knows how to sort > | on the underlying fields if the resolved version is unavailable! > | > | All of the routines that sorted hostSymIpAddress have been adjusted > | and a few additional ones too - it can't HURT to use the smarter > | sort, even if the table has been preselected to have only one type of > | entries. > | > | It works for me - but I've only been able to test in a limited, > | mostly TCP/IP and MAC environment. > | > | ToDos: > | > | 1) Somebody with NetBIOS and AppleTalk needs to test it. > | > | 2) The FibreChanel stuff was touched, albeit with some care, but > | there's still one TODO tag in util.c where I think we need to add the > | proper FibreChanel test - it may be the one in CMP_FC_PORT, I'm not > | sure. In fact, it may be possible to remove CMP_FC_PORT totally and > | just use cmpFctnResolvedName. But I don't have enough data to test > | this - the test file Dinesh sent me only has one HA. > | > | 3) Everybody with edge cases (oddball things) should probably test > | this. > | > | > | My plan is to wait a few days, collecting and fixing minor problems, > | then package and put out a 3.0pre2. > | > | > | -----Burton > | > | From util.c: > | > | /* ********************************************* */ /* > | ********************************************* */ /* > | hostResolvedName compare function */ /* > | ********************************************* */ > | > | int cmpFctnResolvedName(const void *_a, const void *_b) { > | > | /* This function is ugly, but critical, so bare with... > | > | It takes two HostTraffic entries and performs a standardized compare > | of the hostResolvedName fields, reaching into OTHER fields as > | necessary. > | > | The SOLE goal is to provide a stable comparison. > | > | Hopefully the results are PREDICTABLE and EXPLAINABLE, but that's > | totally secondary. > | > | Why? Because sorts don't handle non-transitive compares very well. > | > | If A>B but B !< A, the sort will probably CHOKE. > | > | Since the hostResolvedName field contains something like six or nine > | possible types of 'names' for a host, a simple alphabetic compare > | won't cut it. Especially as hostResolvedName may not be valued at > | the time of the compare... > | > | We also can't simply just use the next valued field in the sets, > | because we run the risk of intransitive compares, where > | > | primary(a) > primary(b) > | > | but > | > | secondary(a) < secondary(b) > | > | and if we have say primary for a and c, but not b, risk that just > | because a<b and b<c a !< c... this completely hoses the sort. > | > | > | So instead in this routine, we practice a gracefull, explicit > | fallback: > | > | 1. If the HostTraffic pointers are NULL, we return equality. > | > | 1A. If one of the HostTraffic pointers is NULL, we return THAT entry > | as < > | > | 2. If both of the hostResolvedName fields are NOT NULL, and both of > | the hostResolvedNameType fields are NONE, we: > | > | 2A. Check the hostResolvedNameType fields for both A and B. > | > | 2A1. If they are identical, we perform the approprate apples to > | apples compare. > | > | For example using hostNumIpAddress for a meaningful IP address sort > | (where 9.0.0.0 < 10.0.0.0). > | > | 2A2. If the hostResolvedNameType fields are NOT identical, we do the > | sort on the hostResolvedNameType field itself. > | > | > | 2A1+2A2 means that we sort all of the NAMES alphabetically, followed > | by all of the IP addresses sorted NUMERICALLY, followed by... > | > | 3A. If precisely ONE of the hostResolvedName fields is NULL or > | precisely ONE of the hostResolvedNameType fields is NONE, we return > | the valued field < the unvalued one (so unresolved things fall to the > | end of the sort). > | > | 3B. If both of the hostResolvedName fields are NULL, we fall back > | gracefully, seeking - in the order of the _TYPE flags, a field which > | is valued in BOTH a and b. > | > | 4. Finally if nothing matches, we return a=b. > | > | */ > | > | > | > | > | _______________________________________________ Ntop-dev mailing list > | [EMAIL PROTECTED] > | http://listgateway.unipi.it/mailman/listinfo/ntop-dev > > > > - -- > Luca Deri <[EMAIL PROTECTED]> http://luca.ntop.org/ > Hacker: someone who loves to program and enjoys being > clever about it - Richard Stallman > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFAOeX3mMhDxnkh3zQRAnveAJ46hTJKX5NCHBGrs/VaUrrUJ9YEkQCgoo3v > X8J2hn58/4tRlnPs0ZB0hYA= > =7gYY > -----END PGP SIGNATURE----- > > > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev >
parmsPlugin.c
Description: Binary data
BMS0358-parms-plugin.patch
Description: Binary data
