[openbeosnetteam] Re: Time to put up or shut up!

>
> [netcache]
> > - provide ipv4 <-> ethernet MAC address translation
> > - provide a quick means of looking up routing information
> > - ipv6 <-> ethernet MAC
> > - ipv6 router details
> > - list of ipv4/ipv6 addresses for an interface
> > Now, using a hash is a good idea as it should provide good
> > performance, but
> > the hashing methd will need to be flexible as an ipv4 address is 32
> > bits, v6
> > is 128 bits! Also in v6 there is a need to do lookup's using parts of
> > the
> > address, i.e. using only the first 10 bits for checking we only have
> > a
> > single link-local address registered with an interface.
>
> Although it makes sense to have the same code dealing with all that
> kind of caching, it doesn't make sense (to me) to have a unified cache
> for these things - I hope you didn't mean that.

Nope.

> Using a hash to do some sort of a "fuzzy" search wouldn't be too good.
> If this is really required often and arbitrary, we could connect
> different 8 (or whatever) bit hash tables together. But I am not sure
> if this is the right "container" for such a thing.

OK, I've done more looking at this and you're probably right that having a
single container isn't ideal.

So, we should probably start looking at seperate cache's.  Their performance
is critical (though that can come in a while) as they get heavily used.

However, the IPv6 stuff I've been doing has pointed out that we need to look
at a broader spectrum of scenarios than plain old arp.  That was where I was
coming from.

Still think we can do something along the lines of a netcache though, maybe
just have different types.

netcache_arp (ipv4, mac)
netcache_ipv6 (ipv6, mac)
etc

I mean these are almost identical apart from the number of bits.  NB an ipv6
address can be ipv4 compatible, so we'd have to be careful :)

We should probably also think about routing tables and so on.

david

Other related posts: