Re: [Fwd: [Forces-protocol] Presentation of the options forLFB-level multicast]

["Joel M. Halpern" <joel at stevecrocker.com>]

This is an important question.
I agree that tables will develop holes.  However, because the index has no 
operational significance, it will be very easy and natural to reuse those 
holes.  Hence, the tables will not become progressively more sparse.  The 
mechanisms must cope with hole.  But we do not have to expect tables where 
only 1 in every three indices are used or some such.

Yours,
Joel

At 09:03 AM 11/12/2004, Wang,Weiming wrote:
> Joel,
>
> One more thing is, for index based searching, after some operation such as 
> add,
> delete and modify, the table actually will also become a random table rather
> than a linear one regarding the index. In this case, I see that the index
> actually plays no more efficient role other than a general content searching,
> i.e., it has actually become content(the content is the index) based 
> searching.
> Therefore, in this case, I cannot see any advantage to explicitly define Index
> in the protocol over to just define the 'index' as a field in the table
> structure. For latter, the path will not include any explicit index 
> anymore, to
> do index based operation is to assign an  'index'  field value.
>
> Cheers,
> Weiming


_______________________________________________
Forces-protocol mailing list
Forces-protocol at ietf.org
https://www1.ietf.org/mailman/listinfo/forces-protocol