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

[Ben Anderson]

> > A transform of GPS, to be useful in propegating data in the correct
> > direction without having to do whole-network broadcast
> > discovery, is no more
> > secure than just giving people the gps co-ordinates, it has to be a
> > reversable algorithm.
>
> True, but a transform could be simpler to handle, since all you need to
know
> is which way to send the thing,if it's not me.

Subtraction is pretty easy to do.  And it'll give you a nice accurate vector
to bang the thing off at.
though if you can find a cheaper (computing power wise) way of doing a
transform/process/inversetransform, let me know :)


> > Your language makes sense...  I have a couple of problems
> > with the technical
> > detail...  First, can you define "networkID" and "stationID" more
> > accuratly...  I'm guessing networkID is the GPS style
> > address, and stationID
> > is just a uniquie identifier, like an ip address.
>
> Basically, yes.  Network ID in a wireless context really is identifying
the
> current AP that the notebook is talking to, which is relatwed to the
> physical coordinates of the AP (since the notebook has to be close to get
> in).

Yes, I've considered this for wireless nodes... but the problem is, in the
future fixed computers are likely to get scarcer as wireless becomes more
prevalent and ubiquitous.  And such, will lead to scaling difficulties as
wireless nodes become the dominant ones on the network :)


> > For a node with no physical location address, for a node to be able to
> > arbitarily say "i want to send a packet to 10.87.33.55" that
> > packet is then
> > going to be have to sent to the whole network, as there's no
> > way to figure
> > out which way to start propegating the packet.  (fixed-home
> > node cache is
> > what I proposed to fix this).  For fixed nodes, it doesn't sound any
>
> Exactly.  Fixed nodes can be cached, but mobile ones can only be cached
> until(1) the cache expires, or (2), the mobile node moves to a different
> cell.  If it's an adjacent cell, it may be possible for the packet to be
> redirected to the new AP.  The mobile replying from a different network ID
> should _NOT_ disrupt communications, since the application is only
> interested in the station ID (i.e. IP address), but the nodes within range
> of the traffic get their caches updated with no extra traffic involved.
> >
> > Good enough, how'd I go on the interpretation?
>
> Pretty good.  Some people indicated this aspect may have already been done
> and covered by RFCs.  You may want to check out the references given and
see
> if this is indeed the case, or at least if there's a working base to start
> from.

I've looked at them in detail about 8 months ago... Haven't checked
recently... I should go look again :)

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