JensMuellerRestricted: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
=Routing in Wireless Multi Hop Networks= |
|||
ExOR |
|||
* entgegengesetzt zu Network Coding, denn ich weiß nicht, wer das Paket bekommen wird (aber aus der Menge meiner Nachbarn) |
|||
* verwende nur Broadcasts und der Knoten am nächsten zum Ziel leitet das Paket weiter (Problem, wenn das Netz voll ist; Broadcasts "zerstören" sich gegenseitig oder erweitertes RTS/CTS?) |
|||
* dichte Netze als Vorraussetzung |
|||
* Verwendung mehrerer Kanäle um "Self-Interference" zu vermeiden (oder erweitertes RTS/CTS?) |
|||
Routing in wireless Networks |
Routing in wireless Networks |
||
Things to consider |
Things to consider |
||
Line 19: | Line 8: | ||
** Broadcast nature |
** Broadcast nature |
||
Optimizing problems: |
|||
Ideas: |
|||
* Minimizing transmissions (Network Coding |
* Minimizing transmissions (via Network Coding and ExOR) |
||
* Minimizing collisions (difficult) |
* Minimizing collisions (difficult: extended RTS/CTS? and using 802.11 non overlapping channels) |
||
==Enigineering== |
|||
Routingprotokolle aus Nachrichtensicht |
Routingprotokolle aus Nachrichtensicht |
||
Layer 3 |
Layer 3 |
||
Line 36: | Line 26: | ||
Die Idee ist, dass alle Routingprotokolle Nachrichten versenden müssen. In diese Nachrichten-Elemente steckt man dann nur noch den Payload. |
Die Idee ist, dass alle Routingprotokolle Nachrichten versenden müssen. In diese Nachrichten-Elemente steckt man dann nur noch den Payload. |
||
=Cruise Control= |
|||
Kann man das Routing auch adressunabhängig implementieren (mittels Polymorphie) |
|||
Need to added further project with dependencies to CruiseControl. |
|||
E.g.: |
|||
⚫ | |||
* madwifi (-"-) |
|||
IvyCruise - dependencies with Cruise Control |
|||
=> Besseres Engineering |
|||
=Gateway= |
|||
config.xml CruiseControl |
|||
ns2 |
|||
⚫ | |||
testsuite |
|||
This is about the implementation of self-configuring internet access for BRN using Click mainly. |
|||
IvyCruise |
|||
(Need to explain design and implementation here (from the official gateway wiki site).) |
|||
Planned versions: |
|||
* GatewayTester: |
|||
Gateway - Wann neue Gatewaymetrik propagieren |
|||
** ICMP ping based |
|||
Wann wechselt der GatewaySelector das Gateway (nicht nötig bei Google-Ansatz)? |
|||
** User traffic based |
|||
Wie merke ich, dass das Gateway wegbricht (ICMP Nachricht)? |
|||
** DNS query based |
|||
NAT Probleme |
|||
** Challenge response based (with other mesh nodes) |
|||
* Handling of TCP: |
|||
⚫ | |||
** A GatewaySelector, which respects open TCP connections |
|||
** A centralized "master" gateway (mesh gateways tunnel packets to) |
|||
** Maybe handing TCP connections over to other mesh node? |
|||
ToDO |
|||
* Recognize and handle NATed gateways |
|||
* Is the GatewaySelector able to determine, if a mesh node is a gateway? |
|||
* User feedback via LEDs |
|||
Further and dependent issues: |
|||
* Connecting mesh nodes via ip tunnels |
|||
* Connection mesh nodes via ethernet |
|||
* Difficult to recognize, if an attached node is a client or a mesh node? |
|||
==Known problems== |
|||
⚫ | * Tried to implement an element by inheritance (a diamond), which is possible in C++. But it did not worked in Click. Maybe somebody has a working example. I tried virtual and so on, but it did not compile. In Click's configure method, you can only get an element. I wanted to convert an element of type A to type B without knowing the precise type of the given element. |
||
E |
|||
/ \ |
|||
/ \ |
|||
/ \ |
|||
A B |
|||
\ / |
|||
\ / |
|||
\ / |
|||
? |
|||
This is not possible (my experience), since I don't know what ? is. I would need to cast the given element of type E to ? and then cast ? to A. |
|||
You can use the delegation pattern to bypass the diamond. |
|||
⚫ | |||
* [http://wiki.bsdforen.de/index.php/OpenBSD_-_WRAP gpioclt in OpenBSD on WRAP] |
* [http://wiki.bsdforen.de/index.php/OpenBSD_-_WRAP gpioclt in OpenBSD on WRAP] |
||
* Using the LEDs of wgt634u |
* Using the LEDs of wgt634u |
||
=Sentry5 - the netgear SoC (system on a chip)= |
|||
==Sentry5== |
|||
* [http://linuxdevices.com/news/NS6049226781.html Sentry5] |
* [http://linuxdevices.com/news/NS6049226781.html Sentry5] |
||
* [http://www.linux-mips.org/wiki/Broadcom_SOCs Sentry5 at linux-mips.org] |
* [http://www.linux-mips.org/wiki/Broadcom_SOCs Sentry5 at linux-mips.org] |
||
* [http://www.netbsd.org/Ports/sbmips/ NETBSD/sbmips] |
* [http://www.netbsd.org/Ports/sbmips/ NETBSD/sbmips] |
||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
=Embed Click into JiST= |
|||
This is done via JNI. |
|||
⚫ | |||
+-----------+ |
+-----------+ |
||
Line 85: | Line 115: | ||
| | FromDevice |
| | FromDevice |
||
+-------------+ |
+-------------+ |
||
==Click== |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ |
Revision as of 23:18, 11 February 2006
Routing in Wireless Multi Hop Networks
Routing in wireless Networks Things to consider
- Negative effects
- self interference
- Postive effects
- Broadcast nature
Optimizing problems:
- Minimizing transmissions (via Network Coding and ExOR)
- Minimizing collisions (difficult: extended RTS/CTS? and using 802.11 non overlapping channels)
Enigineering
Routingprotokolle aus Nachrichtensicht Layer 3 - Flooding - Multicast - Unicast
Layer 2 - Broadcast (lokal) - Multicast - Unicast
Die Idee ist, dass alle Routingprotokolle Nachrichten versenden müssen. In diese Nachrichten-Elemente steckt man dann nur noch den Payload.
Cruise Control
Need to added further project with dependencies to CruiseControl. E.g.:
- click (i386, mips)
- madwifi (-"-)
IvyCruise - dependencies with Cruise Control
Gateway
This is about the implementation of self-configuring internet access for BRN using Click mainly. (Need to explain design and implementation here (from the official gateway wiki site).)
Planned versions:
- GatewayTester:
- ICMP ping based
- User traffic based
- DNS query based
- Challenge response based (with other mesh nodes)
- Handling of TCP:
- A GatewaySelector, which respects open TCP connections
- A centralized "master" gateway (mesh gateways tunnel packets to)
- Maybe handing TCP connections over to other mesh node?
ToDO
- Recognize and handle NATed gateways
- Is the GatewaySelector able to determine, if a mesh node is a gateway?
- User feedback via LEDs
Further and dependent issues:
- Connecting mesh nodes via ip tunnels
- Connection mesh nodes via ethernet
- Difficult to recognize, if an attached node is a client or a mesh node?
Known problems
- Tried to implement an element by inheritance (a diamond), which is possible in C++. But it did not worked in Click. Maybe somebody has a working example. I tried virtual and so on, but it did not compile. In Click's configure method, you can only get an element. I wanted to convert an element of type A to type B without knowing the precise type of the given element.
E / \ / \ / \ A B \ / \ / \ / ?
This is not possible (my experience), since I don't know what ? is. I would need to cast the given element of type E to ? and then cast ? to A. You can use the delegation pattern to bypass the diamond.
WRAP and LEDs
- gpioclt in OpenBSD on WRAP
- Using the LEDs of wgt634u
Sentry5 - the netgear SoC (system on a chip)
Crpyto Acceleration in Linux
Embed Click into JiST
This is done via JNI.
Nsclick
+-----------+ | | | MAC | | | +-----------+
| | wie FromHost () +------------------> +-----------+ | | | Click | ToDevice | | +------------ +-----------+ | ^ | | | | V | +-------------+ | | | | | PHY +--------------+ | | FromDevice +-------------+