[MLB-WIRELESS] [TECH] Dipole antennas, and melbwireless structure

[Ben Anderson]

> >I think it's do-able, just not trivial :)  It should work, just with
minor
> >interruption - this isn't a major concern to me, the scalability issues
are
> >much more interesting...
>
> I might wanna run tram mobile on a Windows box LOL  (ppl who know me would
> believe this :) ).

errr... tram mobile on a windows box?  Are you talking about sticky seats
and blue screens?


> > > We must support tunneling, as it is the most feasible way to rapidly
link
> > > segments right now, until more wireless links take over.
> >
> >Yep, shortcutting the mesh is going to be *very* important to the overall
> >scalability of the network.
>
> And these routes can be statically specified.

well, semi-statically...  static stuff sucks ;)


> >Yes, though being able to limit the zone of this discovery to a couple of
> >hops, and not the entire network, is going to be an absolutly massive
> >advantage in scaling this to large networks.
>
> Well, this is where we can experiment.  We also need to know in rough
terms
> which directions are best for sending to certain destinations (here's
where
> the lat/long might be useful), based on previous "experience") for longer
> paths.

The long/lat stuff is useful in preventing the *whole* network from being
discovered by broadcast...


> > > Again, this suggests that a _LOT_ more than lat/long information is
> > > needed.  For example, here, the best route to a node north of me is
likely
> > > to be _away_ from it, to the south! :)  So we're back to some sort of
> >route
> > > discovery mechanism. :)
> >
> >The lat/long thing should _work_ -- it might not be optimal, but it
should
> >guarantee a reasonable method exists...  Plus, because the network is
> >effectilvy source routed, with broadcast auto source-route discovery,
there
> >could be an interface for the originating station to define more optimal
> >routes...  For example, static-shortcut lists could be propegated to all
> >nodes on a daily, or weekly basis for example without being a significant
> >overhead -- and that way the originating node could calculate how to most
> >effectilvy use the shortcuts to mimise the mojo cost for a particular
> >connection, or minimise the latency regardless the cost of mojo -- that
> >decisoion is a 'originating stations' choice...
>
> Static routing can be cached easily, as long as there exists a mechanism
to
> advertise the loss of a static route as well (i.e. a node is turned off in
> a controlled fashion).

Even in an uncontrolled fasion, other nodes in the same broadcast area
should be able to see a lack of ack for the packets being broadcast, meaning
they can stop re-broadcasting, and propegate nack's back through the network
(assuming it's a 'backwards' shortcut) -- in the case of a forward shortcut,
then the nodes just keep propegating the packets progressivly towards the
long/lat of the destination.

> >And it gets worse...  I don't know if there's even an interface to
getting
> >network layer access to windows network stack...  And if there's not,
> >getting raw ethernet access, and then trying to find a way to get
transport
> >layer access back to the operating system...  Arrrgh, my brains
hurting...
> ><back to thinking about scaling ;)>
>
> Apparently, it can be done, though not by a MS provided API.  But Windows
> will need support by _someone_.

Dibs on it not being me.


> > > One of those restrictions is that the equipment needs to be type
approved
> > > for the purpose by the ACA, AFAIK.
> >
> >Yep, but if we can get generic type approved radio interfaces, and then
wire
> >up the ADC/DAC backend...
>
> Hrm, maybe...  Dunno, I'm not a lawyer. :)

Nor am I...  Though, the mp3 argument might be useful -- once it's got to
critical mass (which should happen before the lawyers have even half a
look-in) it's going to be very difficult to stop.

It's certainly fun tech to play with, and at very least, once it's
developed, some large company is likely to see the usefulness in a
generalised network and either buy it up to stop it, or to impliment it
against potential competitors... Either way I should be rich *grin*

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