Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups: comp.programming,comp.unix.programmer
Subject: Re: hash function over IP address
Date: Fri, 06 Apr 2012 17:13:48 +0100
Lines: 29
Message-ID: <87ehs0g7nn.fsf@sapphire.mobileactivedefense.com>
References: <jliber$ocn$1@speranza.aioe.org> <jlir5m$dd8$1@dont-email.me> <jlk3um$pog$1@speranza.aioe.org> <87bon65l7n.fsf@sapphire.mobileactivedefense.com> <jlkb2b$d5f$1@speranza.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: individual.net Kw1ZuTayMal0pqG4m7fLtwXPoHzjb0Nj60YH7VDJ0pYmqBU9E=
Cancel-Lock: sha1:e6zzX30+NkiM26VBrRnF930iXrs= sha1:8xV3WOFS2IK3MOMZISSKbZOiCAI=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref: csiph.com comp.programming:1444 comp.unix.programmer:2385

"Mark" <mark_cruzNOTFORSPAM@hotmail.com> writes:
> "Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message 
> news:87bon65l7n.fsf@sapphire.mobileactivedefense.com...
>>> So the search was based on 'struct nhlfe_key'. Now, what I'm trying to 
>>> add
>>> support for multiple next hops, that is I add a linked list in 
>>> nhlfe_entry:
>>> struct nhlfe_entry{  u_int32_t nhlfe_ix;  u_char opcode;  ...  struct 
>>> list
>>> *nhkey_list;}where 'struct list' is struct listnode that embeds 'void 
>>> *data'
>>> pointer to caller'sprivate data, and this is 'struct nhlfe_key'.So I'm
>>> trying to find the way to generate key based on multiple elements in the
>>> list to store/search nodes in the tree.
>>
>> The simplest solution would be to concatenate all 'next hops' in
>> order to form a key.
>
> Number of next hops is variable, thus anyway it would require to delete the 
> node and re-insert it back with a new key generated, right? (that's not an 
> issue though). How would you suggest to concatenate 32-bit long unsigned 
> integers, in what form -- convert to strings, concatenate and use such 
> string as a key?

I would consolidate each pair into a 64-bit integer, using 0 in place
of a possibly-missing 'second 32-bit number' and then do 'string
comparions' on 64-bit integer strings of some length. Whether I would
rather store an explicit length together with such a string or use a
(64-bit) null terminator would depend on the actual circumstances.