On Wed, Nov 28, 2001 at 01:41:17AM +0100, Oskar Sandberg wrote:
> > > I'm getting the keys from TreeRoutingTable.refTable.elements(). I
> > > discard
> > > the 32 (hex) digit ones, because they don't look like keys to data.
> > > Does this seem legit to you?
> >
> > Yes. All the real keys will be 23 bytes and end in 0x0302 or 0x0203.
> > The others are probably there from seeding the routing table either
> > manually or as a result of another node announcing itself. What do
> > they end in? 0x0000?
>
> Can we use some matching of the keytype bytes instead of the length of
> the keys to determine this? It is not ok to assume that that keys will
> always have any length. Any distribution of the keys should be based
> only on the first single or half byte anyways.
I just mentioned the current 23-byte length by way of explanation, not
as a rule to depend on. The right rule would be to have fake keys end
in 0000, which iirc is true for those resulting from a manual --seed.
I think it must be your announcing code that is putting the 16-byte
fake keys in there that don't end in 0000 - ?
> Also, wouldn't it be nicer if we got this on the same port as the http
> access? It really needs some sort of authorization, and so should fit
> with http based administration access. Using the same visualization
> stuff for the Diagnostics data would be nice as well (feel free to add
> more diagnostics fields).
You can't cleanly put it on the same port as fproxy since fproxy sucks
up the whole URI, thus defeating the mechanism for running multiple
servlets on the same port. So you'd have to hack it into fproxy itself.
--
:: tavin cole (tcole at espnow.com) ::
if there's been a way to build it
there'll be a way to destroy it
things are not all that out of control
- stereolab
_______________________________________________
Devl mailing list
Devl at freenetproject.org
http://lists.freenetproject.org/mailman/listinfo/devl
