JensMuellerRestricted: Difference between revisions

From
Jump to navigation Jump to search
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 / ExOR)
* 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.:
* click (i386, mips)
* madwifi (-"-)


IvyCruise - dependencies with Cruise Control
=> Besseres Engineering


=Gateway=
config.xml CruiseControl
ns2
click (i386, mips)
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:
==WRAP and LEDs==
** 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=
* [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]


=Crpyto Acceleration in Linux=
== Nsclick ==
* [http://www.logix.cz/michal/devel/cryptodev/index.xp?show_selected=1&msgid=48#feedback_form /dev/crypto]
* [http://ocf-linux.sourceforge.net/ OCF]

=Embed Click into JiST=
This is done via JNI.

= Nsclick =


+-----------+
+-----------+
Line 85: Line 115:
| | FromDevice
| | FromDevice
+-------------+
+-------------+



==Click==

Tried to implement an element by inheritance (a diamond), which is possible in C++. But it did not worked in Click. Maybe someone has a working example. I tried virtual and so on, but it did not compile. Now I use use the delegation pattern to bypass the diamond.


==Crpyto Acceleration in Linux==
* [http://www.logix.cz/michal/devel/cryptodev/index.xp?show_selected=1&msgid=48#feedback_form /dev/crypto]
* [http://ocf-linux.sourceforge.net/ OCF]

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

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
       +-------------+