Re: mesh network vs broadcast/multicast question
On Wed, 2007-06-27 at 15:18 +0200, Alexander Larsson wrote: On Tue, 2007-06-26 at 11:34 -0400, Michail Bletsas wrote: The key point to remember in order to derive answers to these questions is that our mesh network operates at layer-2 For all practical purposes, there aren't any differences between broadcast and multicast frames and every node maintains a table of recently forwarded broadcast frames so that they are not broadcasted multiple times. One can limit the radious of the (layer-2) neighborhood be means of controlling the Mesh TTL field. That is a global setting though, and not something we want applications to touch. Is there a way for a program to figure out which of a list of ip addresses are neighbours in the mesh (i.e. 1 hop away)? Some combination of the ARP cache and the forwarding table from the firmware would probably be able to give us that information. For each node that is 1 hop away in the fowarding table, check the ARP cache and grab the IP address. '/sbin/iwpriv msh0 fwt_list' gives you the FWT info, though the fields are a bit hard to discern unless you've got the driver source. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
You can find the (layer-2) neighbors using the iwpriv msh0 fwt_list_neigh n command. Combining that information with a (persistent) ARP table can give you the IP addresses. The mesh TTL field will eventually be tunable on a per packet basis. M. Alexander Larsson [EMAIL PROTECTED] 06/27/2007 09:20 AM To Michail Bletsas [EMAIL PROTECTED] cc Dan Williams [EMAIL PROTECTED], olpc-devel devel@lists.laptop.org Subject Re: mesh network vs broadcast/multicast question On Tue, 2007-06-26 at 11:34 -0400, Michail Bletsas wrote: The key point to remember in order to derive answers to these questions is that our mesh network operates at layer-2 For all practical purposes, there aren't any differences between broadcast and multicast frames and every node maintains a table of recently forwarded broadcast frames so that they are not broadcasted multiple times. One can limit the radious of the (layer-2) neighborhood be means of controlling the Mesh TTL field. That is a global setting though, and not something we want applications to touch. Is there a way for a program to figure out which of a list of ip addresses are neighbours in the mesh (i.e. 1 hop away)? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Wed, 2007-06-27 at 11:22 -0400, Michail Bletsas wrote: The mesh TTL field will eventually be tunable on a per packet basis. Yeah, and we really want that. What's left to make that happen? (Frankly, I thought it was done already.) --Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 15:22 +0200, Alexander Larsson wrote: Hi dan, I have some questions on the mesh network for the updates work. What is the broadcast domain for a laptop on the mesh? (I.E. how far are broadcast messages sent)? Is it just the set of nodes reachable from your machine, or are broadcasts forwarded by the mesh? Michail? This affects how avahi works, as avahi only uses local broadcasts. Another question is on multicasts. How many hops do multicast packets live on the mesh? And are there any other limits than nr of hops to avoid multicast loops? (Otherwise its likely that nodes see multicast packages many times, especially in dense networks.) Michail? I read on the olpc wiki about the mesh using three different channels. My understanding on this is that these pretty much generate three separate mesh networks that are routed between by the school server, and that laptops can end up on any channel. Right. We have only one radio in the laptops, and therefore we can only tune to one channel at a time. However, having all laptops on one channel would be detrimental from a bandwidth perspective, since all laptops share the bandwidth of the channel, which isn't large (54Mbps but that's certainly not seen in the real-world). Does this mean that two laptops next to each other can be on two completely different networks? This means broadcasts (and by extension Yes. But if they are at school, then you'll be able to see that person because you'll both be connected to the school server. We only (ideally) run into problems when one or the other laptop can't connect to the school server, and they are on different channels. Avahi) cannot reach from one laptop to the other. Is this true? And are we doing something to work around this (like letting users manually switch channels)? We are letting users manually search for friends, which is a fairly lengthy process that involves jumping to each channel, searching for friends and activities using mDNS, then to the next channel, etc. You'll be warned if you do something that will make you jump to a different channel, and therefore break stuff. Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: mesh network vs broadcast/multicast question
On Tue, 2007-06-26 at 17:10 -0400, Frank Ch. Eigler wrote: Hi - On Tue, Jun 26, 2007 at 04:49:40PM -0400, Dan Williams wrote: [...] Does this mean that one needs a school server/bridge in order to talk to two differently-channeled friends ? Yes. You must spread the XOs between channels to maximize the overall system bandwidth [...] Is it obvious that this benefit (increased aggregate bandwidth) is worth the cost (the necessity for a special bridge - possibly hamstringing an ad-hoc mesh away from the schoolhouse)? How bandwidth-hungry are common XO activities anyway? It depends, but packing 50 normal laptops onto a single radio channel _today_ with infrastructure APs doesn't really work well, especially when they all start to talk. We're likely to have that many laptops in a single classroom, and when you get a couple classrooms next each other... Dan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
