[MLB-WIRELESS] Re: Node x is over this way -was- Applications

[Ben Anderson]

> >It's possible, sure.  But the number gets **rediculously large** as you
> >scale to large numbers... Just think about a million different prime
> >numbers, all multiplied together...  and now propegate that around the
> >network every 10 seconds to deal with nodes roaming around.  Run out of
> >bandwidth, don't we ;)
>
> darn those roaming nodes :-)
> i have a hunch there's a way around that,

Well, when it solidifies to more than a hunch, please elaborate :)


> >   is it essential that network
> >  > _location_ be that secure, as opposed to content and _personal_
> >>  identity?  besides, we don't have to factorise for unknown primes,
> >>  just simple division
> >
> >Even if the guy in the black mask doesn't know my real name, I don't want
> >him kneecapping me as I go to check the snail-mail.
>
> yeah but it's not a meatspace location anyway, and i have some vague
> thoughts about hiding each hop in the chain

I was talking about the GPS co-ordinates as the actual method for getting
packets to their destination, with some fairly static shortcut routes
maintained network-wide.  I haven't found any alternatives that scale...
Please elaborate on the scheme you're infering you know about :)


> >  and stop passing the
> >hello on after x hops.  Which means nodes beyond x don't know of that
nodes
> >existance, and can't talk to that node.
>
> but a small number of long-range links that leapfrog over the shorter
> mesh links dramatically improve the mutual knowledge in the network.

Correct.  Though long range links are generally expensive...  Perhaps
tunneling over the internet could be useful in removing the need for
network-wide broadcast discovery...  Hmm, that and mobile-mesh could work
quite well...  That'd save a lot of engineering...  But still, it doesn't
incorporate a decent encryption layer, or a 'mojo' layer either...
I think I'm going to have to sleep on this... I'm still thinking there's
some issues with this method I'm not considering yet...


> >Hopefully I haven't rained on your parade enough to discourage you...
Some
> >interesting ideas, the primes one actually had me thinking for a few
minutes
>
> and your replies ditto
>
> maybe a hybrid of the primes method and the six degrees,
> multiplication and passing of primes restricted to x/2 and "where is
> brian" requests ditto...  then you don't have a million primes
> multiplied together, just a few thousand over here, a few thousands
> over there...

No real point in passing around primes, as that's exactly the same info
that's transferred around with routing protocols like OSPF, RIP, etc.  And
they're more useful in they can provide QoS, loop detection, link cost
metrics, etc etc.  And most importantly it's already done, tested, and seems
to encapsulate what your talking about without significant additional
overheads.
Separating the broadcast domain is necessary, though where's the cutoff
point?  How are they defined?  And how do you stop a node on the edge of a
broadcast zone from broadcasting into the edge of the broadcast zone that
neighbours it?
Making this work could happen, though due to this non-automated zone (well,
at least I can't think of a good way of automating it, you?) management
that's required suggests that a central authority could become a bottleneck
in scaling.  And it also provides a central 'takedown' point for governments
etc to attack if they want to shut down the network.

> >  > ps mojo =  bandwidth as currency?
> >
> >Not quite...  it makes sense to reward people who run proxy servers with
> >mojo as well, as they can arguably add more bandwidth availability to the
> >network by caching stuff.
> >Mojo is just some magic number in a database somewhere (though I want it
> >distributed, with strong encryption to protect the little cookie like
> >objects).
>
> much like an anonymous digital currency

Yes, I suppose so.  Currency bought by routing others traffic, and providing
traffic-limiting services.
Perhaps we should consider utilising something like freenet, where the
network sort of becomes the storage device, information migrates towards the
nodes where it gets the most use, and gets cached there, etc.  The problem
with this, it means nodes with limited storage etc, will be disadvantaged in
the amount of 'other peoples traffic & storage' they can offer.  But again,
not providing service to others rightfully limits others ability to access
'premium' bandwidth.  Hmm, the more I think about this, the more it makes
sense to encapsulate into the system.  Caching effectivly 'becomes' the
network, rather than it being an application layer service.

> >Hopefully that last paragraph doesn't confuse you too much...
>
> still digesting

heheh..  Keep me informed of brain updates & stumbling blocks you come
across in your thinking :)

Ben.



--
To unsubscribe, send mail to minordomo at wireless.org.au with a subject of 'unsubscribe melbwireless'  
Archive at: http://www.wireless.org.au/cgi-bin/minorweb.pl?A=LIST&L=melbwireless
IRC at: au.austnet.org #melb-wireless