Hi, Yes this includes all previous patches (as of the last weeks) for filename snooping. 32 bits were arbitrarily choosen, 16bit could have been just as fine, and in my captures it did not show any collisions. though, for large captures with many many filehandles i guess the birthday paradox will make collisions likely.
the benefit is that the hash thingie does not consume any resources. the only way to pruduce a GOOD solution would be to replace the hash completely with a mechanism which tracks all seen fhandles and assignes a serial number for them. i.e. keep a hashtable for all seen filehandles with which serial number is assigned to that fhandle. everytime a new filehandle is seen in the capture, a new serial number is allocated for that fhandle this would guarantee that there could never be any collisions. it would be some more work, but not much when one is familiar with glib's hashtables. it would though consume additional memory which would not be deallocated until the capture is rescanned (or in tethereals case: never) which is why i presume such a feature must be enabled using a preference option. perhaps an option which when disabled: 1, the current or a 16bit xorhash or something else which does not eat memory will be used but when the option is enabled the hash will be replaced with 2, the guarantee-that-collissions-neve-occur "hash" as described above. i think the mechanism to identify the fhandle in both cases must use the same display filter, hf_nfs_hash or some such so that the semantics for filtering for specific fhandles is not dependant on which options are enabled. 1, above is clearly a hash value but 2, is not a hashvalue but a (capture file)unique identifier (does this matter?) should i change the displayfilter name then to something like hf_nfs_fid "File ID", or do you have any better suggestions what to call it? ----- Original Message ----- From: "Guy Harris" Sent: Saturday, January 12, 2002 9:28 PM Subject: Re: [Ethereal-dev] nfs : patch to snoop fhandle to filenames > On Sat, Jan 12, 2002 at 11:02:55AM +1100, Ronnie Sahlberg wrote: > > attached is a new patch for nfs name snooping, it fixes the bug where the > > '/' > > separating path components were sometimes missing. > > Checked in (with fixes to the preference names). > > Does this include all the previous name snooping patches you've sent? > > > it also adds a simple 32 bit xor hash value for every fh. > > using this hash makes it 'easier' to filter for specific fhandles. > > Sun's snoop generates a 16-bit hash; unfortunately, from personal > experience, I can testify that their hashing mechanism is not good > enough to avoid collisions in real life captures, which is a nuisance. > > They use the 16-bit hash in summary lines; we might want to think about > having ONC RPC protocols put more into the summary line than just the > version numbe, procedure name, call/reply indicator, and XID (i.e., have > subdissectors put some of the arguments and reply parameters into the > summary). > > _______________________________________________ > Ethereal-dev mailing list > [EMAIL PROTECTED] > http://www.ethereal.com/mailman/listinfo/ethereal-dev
