- What About Wireless?
- Meshes and Trees
- The Nice Thing About Standards
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Meshes and Trees
Network topology is an interesting research area. I'm sitting at home writing this article, and in the next terminal over I have a connection to my machine on campus, under a mile away. If I trace the route that those packets take, it goes via London—not exactly a direct route with almost a 400-mile round trip.
The reason for the long route is that this is the closest connection between my ISP's network and the campus connection to the Internet. Both networks look roughly like trees, which are joined at their root nodes to another network.
Now, imagine that I installed a wireless access point on top of one of the buildings on campus and pointed it at my house. Then I could get to my home machine directly. This would have the side benefit of freeing some capacity on the links between here and London.
A lot of the Internet has these little anomalies, in which packets go out of their way geographically due to the way in which the network is designed. Putting in shortcut routes is a nice idea, but not that common in practice. The reason is that every packet passes through a number of routers as it travels over the Internet. Each of these routers typically is connected to a small number of links, and for each packet the router has to decide which link to use. The router has to make these decisions very quickly, because otherwise people complain about delay in their VoIP traffic or lag in their games. The more possible routes to a given destination, the harder the decision. Defining a static, tree-like topology makes routing very easy, which makes it cheap.
A wireless network with no fixed routes typically is called a mesh. In a mesh network, two machines within range of each other talk directly. If they're not within range of each other, they need some mechanism for finding the shortest path between them. Conceptually, the simplest way of doing this is to send out a broadcast packet and track the return route; the route with the shortest path is the one to use. The problem is that you need to send a broadcast packet over the entire network every time you want to connect to a new machine. (The problem is even worse if the machines in the mesh are moving physically.)
Some interesting work has been done in this area, but it's really feasible to use a pure mesh topology only on a relatively small scale. However, it's relatively easy to use a hybrid approach—a number of fixed-base stations, all of which allow a small amount of meshing to extend their range.
If you want to talk to someone a long distance away, using a fiber connection is still likely to be the best option. How you get to that fiber is the tricky issue. If you're walking near a house with a wired Internet connection and a wireless access point, you might be able to use that network for the long-distance route. If you're part of a local mesh network, a few dozen connections might be shared in this way. Some might be open access, some might want payment. Routing then becomes a partially economic question: Do you use the hop that guarantees low latency but wants payment, or the free one with no quality-of-service guarantees? And how do you pay the owner of the network you're using for the next 10 minutes before you switch elsewhere?