[CUWiN-Dev] SoC ideas

[Sascha Meinrath]

added!

keep 'em coming.

--sascha

Chase Phillips wrote:
> 1 Create a scheme for harvesting and publicizing node data
> 
>     Community wireless networks are frequently created based largely on
>     volunteer effort.  As nodes in a CUWiN-based mesh are set up, there
>     is no automatic data publication or harvesting that happens that gives
>     network implementors a vision of their network's size, its strengths
>     and weaknesses, and where future volunteer effort should be spent.
>     Any effort to create this list is purely manual.
> 
>     Implement a central authority for a wireless "cloud" that receives
>     node status updates.  The authority will receive reports sent by a
>     daemon on each node which you will also implement.  This project is
>     less overall work than "Configuration information store" or they could
>     be combined if a team of students chose to work together.
> 
> 2 Implement a testing system for CUWiN's routing protocol and metric
> 
>     CUWiN networks use HSLS (hazy-sighted link state) as a routing
>     protocol to determine how the network is laid out.  Among other
>     information, this protocol provides a way for node A to know how to
>     talk to node C by finding out that both A and C can talk to node B.
>     Each node has a "map" of the network and uses that to update its local
>     routing table.
> 
>     As the network grows in size, the protocol can succomb to scaling and
>     complexity issues.  The daemon that implements the protocol and metric
>     can succomb to software bugs and performance problems.  Since no test
>     harness currently exists to test our HSLS implementation for bugs or
>     for its capabilities, most of our testing happens in the field and
>     under uncontrolled circumstances.
> 
>     Implement a test harness for our HSLS implementation that will
>     demonstrate CUWiN's current capabilities and provides an environment
>     to validate the software we issue to community wireless networks.
> 
>     The test harness should allow us to set conditions on testing to
>     ensure certain pre-existing environments work as expected and for
>     attempting to create reproduceable test cases in this lab.  We should
>     also be able to use it for testing other routing protocols to compare
>     their performance as network size and configurations grow.  (For
>     example, other routing protocol implementations can be found in the
>     quagga daemon which is included on a CUWiN node.)
> 
> Chase
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
> 
> 


-- 
Sascha Meinrath
Policy Analyst    *  Project Coordinator  *  President
Free Press       *** CUWiN               *** Acorn Active Media
www.freepress.net *  www.cuwireless.net   *  www.acornactivemedia.com