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
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev