Changes between Version 4 and Version 5 of gsoc2010-ideas
- Timestamp:
- 03/10/10 19:47:47 (6 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
gsoc2010-ideas
v4 v5 34 34 Fast moving nodes always have the problem of adjusting their routing information in time. They can choose to send more routing information, so that their environment can adjust to them but stationary nodes won't do the same and increase the mobile node's adaption time greatly. However, when a B.A.T.M.A.N. node detects that his local environment changed quickly he will enter the starvation mode. In this mode the node will actively try to confirm a working route as fast as possible by sending a "batman ping" to its new neighbors. Each B.A.T.M.A.N. neighbor will try to forward the message to its destination, once arrived there it will travel back. If the mobile node receives the reply it can change its route towards the new neighbor without waiting for normal OGM flooding as the route has been verified. The goal of this project is to implement the starving mode together with the "batman ping". 35 35 36 = Optimize multicast performance=36 == Optimize multicast performance == 37 37 '''Brief description:''' Avoid broadcasting multicast traffic to nodes not belonging to a certain multicast group. 38 38 39 39 Multicast packets would have a great advantage especially in wireless mesh networks: The number of recipients of multicast packets (i.e. for zeroconf service announcements or audio/video streams) is a lot higher then with unicast packets. batman-adv currently handles multicast packets the same way as broadcast packets, they simply get flooded through the mesh network. Instead, those packets should be flooded on a subgraph containing the nodes of a certain multicast group and other connecting nodes only. 40 40 41 = Dynamic OGM intervals=41 == Dynamic OGM intervals == 42 42 '''Brief description:''' A batman-adv node shall select originator interval rates according to the dense and dynamics in its closer environment. 43 43 44 44 Depending on the usage scenario, people can adjust the bandwidth being used for batman-adv's route finding algorithms. Usually people were advised to increase the originator interval if the mesh network is small but needs fast route refresh rates or to decrease it if the mesh network is mostly a static setup with a lot of nodes. It would be great if a batman-adv node could determine the dynamics of the mesh network it is currently participating in on its own so that this option would not have to be administrated from a person anymore. For instance in combination with the 'B.A.T.M.A.N. protocol overhead reduction' project, the local broadcasts could be automatically increased if there are not that many direct neighbors. 45 45 46 = More batctl ping/traceroute options=46 == More batctl ping/traceroute options == 47 47 '''Brief description:''' Add useful options for administrating a mesh network to batctl. 48 48 49 49 batctl is the nicer frontend for configuration and debugging batman-adv. There are still some options that could be added like showing the MTU of hops with traceroute along a path to make it easier to spot MTU issues. Or outgoing interface selection to be able to manually probe the way and quality of an alternative path. Feature proposals that make the administration of a complex mesh network more easy are welcome. 50 50 51 = Live VIS in map=51 == Live VIS in map == 52 52 '''Brief description:''' Building tools that visualize the dot output of the vis server with additional gps coordinates on a map. 53 53 54 With every new technology, a bridge to non-technical people should be provided as well. batman-adv is being used in routers of every-day users, that do not have an insight in the B.A.T.M.A.N. routing protocol itself, nevertheless a good visualization can widely increase the acceptance of a new technology and get young people interested in it. batman-adv has a built in vis-server which produces a raw dot-file when activated. With the help of graphviz-tools, those dot-files can be rendered as graphs which are still more interesting for 'technical' people. It would be great to have a tool that maps the information provided by the dot-output and additional geo coordinates in Google-Maps or OpenStreetMap (OpenLayers) in realtime. Then 'normal' people could find out and solve dead zones without technical support all on their own without having to use fancy command line tools. This feature would be useful for anyone administrating (parts of) a mesh network.54 With every new technology, a bridge to non-technical people should be provided as well. batman-adv is being used in routers of every-day users, that do not have an insight in the B.A.T.M.A.N. routing protocol itself, nevertheless a good visualization can widely increase the acceptance of a new technology and get young people interested in it. batman-adv has a built in vis-server which produces a raw dot-file when activated. With the help of graphviz-tools, those dot-files can be rendered as graphs which are still more interesting for 'technical' people. It would be great to have a tool that maps the information provided by the dot-output and additional geo coordinates in Google-Maps or !OpenStreetMap (!OpenLayers) in realtime. Then 'normal' people could find out and solve dead zones without technical support all on their own without having to use fancy command line tools. This feature would be useful for anyone administrating (parts of) a mesh network. 55 55 56 = Multiple interfaces per node support in Mesh3D=56 == Multiple interfaces per node support in Mesh3D == 57 57 '''Brief description:''' Adapting Mesh3D to handle the new visualization format features from current batman-adv. 58 58 59 59 Mesh 3D is an application written in C and maintained by one of the batman-developers which is able draw a 3 dimensional graph from batman's vis output in dot-format. The latest additions in batman-adv's vis output that now features a differentiated visualization, in that interface connections between nodes are now being shown separately. This new format feature has not been ported to Mesh3D yet. Also a concept for visualizing overlapping links in Mesh3D would probably have to be planed (adding transparency to Mesh3D for instance). 60 60 61 = Multiple switch ports for redundancy=61 == Multiple switch ports for redundancy == 62 62 '''Brief description:''' Allow multiple bridge uplinks to wired networks 63 63
