Gruppenkommunikation in Sensornetzwerken

Der Router

Der Sensor Router ermöglicht die Verbidung von Sensorknoten für kanalbasierte Kommunikation.

Der Sensor Router (Program luaosrouter) stellt folgende Dienste zur Verfügung:

1. Gruppenverwaltung
2. Kommunikationsports für externe Verbindung
3. Virtuelle Schaltungen (Virtual Circuit VC, interne Verbindungen zwischen Router Ports)
4. Sicherhiet über Capabilities (fehlt noch)

Der Sensor Route nutzt zwei verschiedene Kommunikationsprotokolle:

1. HTTP für Sensorknoten-Router Interaktion (RPC)
2. WebSockets (als Upgrade einer HTTP Verbindung) für kanalbasierte Kommunikation zwischen Sensorknoten über den Router

Start Router Service

Es wird benötigt:

• lvm
• luaosrouter
• Optional luaos.out (LuaOS Bibliothek ohne HTTP WEB Service) und service.lua (nur zu Studienzwecken, zentrales Modul des Routers)

> lvm luaosrouter -h
usage: luaosrouter [-v -h] [-host IP/URL/?] [-port NUM] [-portHTTP NUM] [-portWS NUM]
> lvm luaosrouter
# Oder zum Testen
> lvm luaos.out service.lua

• Der HTTP Port kann mit -port NUM verändert werden (der WebSocket Prot ist standardmäßig port+1).

Die LuaOS Route Klasse

Jede Kommunikation mit dem Router und dann auch mit Peers (Sensorknoten) findet über eine Route Instanz statt:

local <route> = route:new(url:string)

• Testweise kann der Router mit einer Pingnachricht kontaktiert werden:

local result = <route>:ping()

Kommunikation

• Im nächsten Schritte muss eine WebSocket Verbindung mit dem router hergestellt werden:

local <port> = <route>:connect()

• Damit wird aud er Router Seite eine Kommunikationsport erzeugt, der nun mit anderen Peers verbunden werden kann:

local result = <port>:connect(uuid:string,bidirectional:boolen)

• Es können nun Nachrichten (Datentyp string oder table) empfangen und gesendet werden

<port>:write(string|table,destination?:string)
local data,err = <port>:read()

• Nachrichten können an alle mittels connect angeschlossenen Peers (Multicast) oder an einen bestimmetn (destination) Peer (Unicast) gesendet werden

• Die read Methode ist blockierend, und daher sollte es eine eigene Koroutine für den Empfang geben (alternativ):

local co = coroutine.create(function ()
  while <port>.state == "OPEN" do
    local data = <port>:read();
    -- Process data
  end
end)
coroutine.resume(co)

Gruppen

• Neben dem VC Service bietet der LuaOS Router auch ein Gruppenmanagement an:
  • Eine Gruppe mit einer (eindeutigen) ID kann erzeugt oder gelöscht werden
  • Es können Peers (durch UUIDv4) zu einer Gruppe hinzugefügt oder entfernt werden
  • Es können alle aktuell in der Gruppe enthaltenen Peers abgerufen werden

local status = <route>:create(grouip:string)
local members = <router>:ask(groupid:string)
local status = <route>:join(grouid:string,peerid:string)
local status = <route>:unjoin(grouid:string,peerid:string)

Garbage Collector

Der Router stellt auch einen Garbage Collector Service zur Verfügung. Dieser wird in periodischen Abständen ausgeführt:

1. Alle leeren Gruppen werden nach einem Timeout (z.B. 60s) gelöscht
2. Alle Peers in Gruppen die keinen aktiven Port mehr haben werden aus den Gruppen entfernt
3. Alle Peers die noch einen (scheinbaren) aktiven Port haben werden in Abständen mit einer internen ping Nachricht getestet. Wenn es keine Rückantwort gibt dann 2.

Der Garbage Colelctor wird automatisch gestartet.

LuaOS Koroutinen

• Eine Koroutine ist ein eigener Kontrollpfad

  • Der Programmablauf darf blockierende Operationen aufrufen (wie z.B. <port>:read oder sleep)
  • Alle Koroutinen werden aber von der selben VM Instanz ausgeführt und alle Koroutine teilen sich den gleichen global/glocal Scope

• Koroutinen können Schleifen enthalten die zum periodisch ausgeführt werden. Dazu in den Schleifenkörper die blockierende sleep(milli) Funktion verwenden (oder wie oben die read Opartion des Receivers für einen Kanal)

Aufgabe

1. Baue eine Gruppe "MISS" auf.
2. Jeder Knoten wird Mitglied in der Gruppe und jeder Knoten verbindet sich unidirektional mit allen anderen Knoten (Ports)
3. Erzeuge eine Clock Funktion die mit der milli Funktion + einem einmalig gewählten randomisierten Offset von ± 1000ms eine interne Knotenzeit zur Verfügung stellt. Die Uhr soll synchronisierbar sein, d.h., später durch einen Deltawert verstellbar sein
4. Alle Knoten der Gruppe "MISS" wählen einen Leader aus der seine Zeitreferenz im Netzwerk zur Verfügung stellt (Zeitserver)
5. Alle Knoten sollen ihre Uhren synchronisieren (mit Zeitreferenz vom ausgewählten Zeitserver)

Wahle eines Leaders (Zeitserver)

Naiver Ansatz:

Init: Jeder Knoten hat eine ID (UUIDv4) und eine zufällig
      erzeugte Priorität im Bereich {0,1,..,65535} (Es kann Dopplung geben!!)
1. Jeder Knoten sendet allen anderen Knoten das Tupel <UUID,PRIO> 
   als Nachricht "REQ <UUID,PRIO> "
2. Jeder Knoten empfängt in einem Zeitintervall [t0,t1] die 
   Nachrichten "REQ" beginnend mit der ersten Nachricht
3. Jeder Knoten wählt dann einen Leaderknoten aus wenn es einen einzigen 
   Knoten mit der größten PRIO gibt
4. Wenn ein Knoten einen Leader ausgewählt hat sendet er eine "ACK" Nachricht
   an alle anderen Knoten ("ACK <UUID>")
5. Wenn ein Knoten alle "ACK" Nachrichten erhalten hat steht der Leader fest
6. Ansonsten (nach einer Wartezeit [t1,t2]) startet eine neue Runde bis ein Leader gefunden wurde

Hinweis: Eine Nachricht wird über den Kanal als Tabelle versendet. Z.B. im Format:

local msg = { tag="ACK", id=1234 }
<port>:write(msg)

Uhrensynchronisation

• Nachdem der Zeitserver feststeht sollen alle Knoten der Gruppe von dem Zeitserver die Uhrzeit abfragen und damit ihre eigene Uhr synchronisieren (Delta Offset).

• Aber: Der Zeitstempel t in einer "TIME" Nachricht kommt immer um einen zeitlichen Versatz t+δ an (Zeit der Nachrichtenübertragung)

• Beispiel SNTP: