That 1st one is wrong - a flipped sign. Raw IPs should be last - I've got that patch ready to go along with somne debug lines so we can resolve other issues.
Reason for what I have there is that it mirrors the usual way ntop learns. 1st it sees a packet with a MAC address, then decodes the packet to see the IP, then it resolves the IP. Post 3.0 I'll look at ways to make the sorting user dependent. For resolved items, you can already change it partly via the #define constants. Changing the unresolved item sort is trickier... -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark > Gibbons > Sent: Monday, February 23, 2004 3:09 PM > To: [EMAIL PROTECTED] > Subject: RE: [Ntop] New sorting routines in cvs - these are post 3.0pre1 > - TEST NOW OR HOLD YOUR WATER > > > Yes - a really big improvement. > > Not totally convinced that Raw IP's should come after resolved > hosts (even after reading 'About sorting of hosts') - Would have > thought that keeping strict alpha order would have been more logical. > > However, this is a minor 'debatable' point. > > Just to explain why I prefer IP's first: > > a) It IS proper alpha sorted order. > > b) For the local subnet, I am not so worried about IP's I know > about i.e ones that resolve - ones that do not resolve I want to > investigate. > > In relation to MAC addresses - tricky - either vendor identified > or not - these I would prefer as the last group. > > I accept that this is a totally *personal* and subjective viewpoint. > > At least now the sorting is consistent which helps enormously. > > Thank you for your work on this Burton > > > -----Original Message----- > From: Burton M. Strauss III [mailto:[EMAIL PROTECTED] > Sent: 23 February 2004 00:04 > To: Ntop; Ntop-Dev > Cc: Dinesh G. Dutt > Subject: [Ntop] New sorting routines in cvs - these are post 3.0pre1 - > TEST NOW OR HOLD YOUR WATER > > > 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 mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop > _______________________________________________ > Ntop mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop > _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
