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

Tony Langdon tlangdon at atctraining.com.au
Wed Mar 20 11:03:45 EST 2002


> 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.

> 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).

> 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.

---
Outgoing mail has been scanned for viruses
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.336 / Virus Database: 188 - Release Date: 11-Mar-02
 

This correspondence is for the named person's use only. It may contain
confidential or legally privileged information or both. No confidentiality
or privilege is waived or lost by any mistransmission. If you receive this
correspondence in error, please immediately delete it from your system and
notify the sender. You must not disclose, copy or rely on any part of this
correspondence if you are not the intended recipient.

Any opinions expressed in this message are those of the individual sender.


--
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



More information about the Melbwireless mailing list