Arbeitsgruppe Chat

Unser Funknetz ermöglicht theoretisch noch immer Kommunikation unter den einzelnen Knotenbetreibern, selbst wenn alle zentrale Infrastruktur ausgefallen ist. Da aber nur wenige Leute überzeugt werden können, einen bestimmten dezentralen Instant Messenger zu installieren, muss eine Alternative her:

Der olsrd, der auf allen Knoten läuft, ist über Plugins in der Lage, beliebige Nachrichten über das Netz zu verbreiten ("zu flooden"). Normalerweise werden eben die Routinginformationen übertragen, genauso könnte man aber die derzeitige GPS-Position des Knotens mitsenden, den Ladezustand eines Akkus (bei Solarnodes) oder eben Chatnachrichten! Dabei werden diese Informationen nur von den Knoten auch verarbeitet, die das entsprechende Plugin installiert haben. Jeder Knoten leitet die Information aber an alle anderen weiter.

Es fehlt also nur noch eine Verbindung zwischen dem olsrd (bzw. einem zu entwickelnden "Chat-Plugin") und der Darstellung der Nachrichten auf der Weboberfläche des Routers.

Diese Schnittstelle können zum Beispiel einfache "Flat Files" sein: Textdateien, an die das Plugin empfangene Nachrichten anhängt (und den Anfang bei Überschreiten einer gewissen Größe der Datei abschneidet - die Größe der Datei bzw. die Anzahl der Zeilen könnte z.B. auf der Webseite des Chatplugins wählbar sein) bzw. aus denen es die zu übertragenden Nachrichten "abholt".

Mitarbeiter:

• Aaron: kümmert sich darum, dass so ein Plugin funktioniern würde bzw. wird es entwickeln
• Gregor: Schnittstelle Plugin/Webinterface
•  ???

Update:

• Das Webinterface ist soweit fertig, fehlt nur noch das Plugin... Coders wanted! ;-)

• Nachdem es zur Zeit nicht zur Programmierung des Plugins kommen wird, wäre eine Alternative sich unter den an einem netzinternen Chat interessierten Personen auf einen LAN-Messenger zu einigen und diesen auszutesten.
• Liste von eingen LAN-Messengern: http://en.wikipedia.org/wiki/Comparison_of_LAN_messengers
• Vorzuziehen wäre einer der sowohl auf Linux als auch Windows funktioniert, wie z.B. http://sourceforge.net/projects/netc/

Details

Schnittstelle Router/Client: Webinterface des Routers / AJAX

Ein Bild folgt in Kürze...

Am Client wird die Datei chat.html geladen (über Freifunk-Firmware/Administration). Nachrichten, die im Eingabefeld eingegeben werden, werden per AJAX an outbox.html übergeben, von dieser in outbox.txt eingetragen und an die Inbox von chat.html zurückgegeben. outbox.html muss prüfen ob das Plugin läuft, damit outbox.txt nicht übergeht! Vom Plugin wird die Nachricht aus outbox.txt abgeholt, dort gelöscht und per olsr übertragen...

Ankommende Nachrichten werden vom Plugin nach inbox.txt geschrieben. Überschreitet die Länge von inbox.txt einen vorgegebenen Wert, wird automatisch die älteste Nachricht gelöscht. Anschließend wird der Wert in counter.txt um eins erhöht, außer der Wert ist schon gleich der Anzahl an Nachrichten in inbox.txt.

chat.html fragt in regelmäßigen Abständen bei inbox.html nach neuen Nachrichten. Ist der Wert n in counter.txt ungleich Null, liegen neue Nachrichten vor. inbox.txt holt die letzten n Nachrichten aus inbox.txt ab, überträgt sie an die inbox von chat.html und setzt counter.txt auf Null. (Beim Start des Chats holt inbox.html ungeachtet von counter.txt alle Nachrichten aus inbox.txt und setzt counter.txt auf Null)

Dateien

 /www/cgi-bin/chat.html   - Chatseite für das Webinterface
 /www/cgi-bin/98olsrchat  - Menüpunkt für das Webinterface
 /www/cgi-bin/inbox.html  - Script zur Beanwortung der AJAX-Anfragen
 /www/cgi-bin/outbox.html - Script zur Beanwortung der AJAX-Anfragen
 /www/inbox.txt           - Link nach /tmp/chat/inbox.txt
 /www/outbox.txt          - Link nach /tmp/chat/outbox.txt
 /www/counter.txt         - Link nach /tmp/chat/counter.txt
 /tmp/chat/inbox.txt      - Container für die empfangenen Nachrichten. Ist vom Plugin beim Systemstart zu erstellen!
 /tmp/chat/outbox.txt     - Container für die zu sendenden Nachrichten. Ist vom Plugin beim Systemstart zu erstellen!

Offene Fragen

• Was ist die maximale Nachrichtenlänge, die OLSR übertragen kann???

(einerseits detektiert der olsr die mtu eh selber (interface-specific), andererseits können pakete dann eh auch fragmentiert werden, allerdings ohne reliability im broadcast, machen solche riesenpakete dann wohl recht wenig freude (wenn nur teile ankommen),..)

• Soll ein Benutzername wählbar sein?
• Soll der Name des Routers mit den Nachrichten mit übertragen werden?
• Sollte man eine primitive Möglichkeit für Channels implementieren? (z.b. 1 byte channel-identifier)
  • Hm... Es wäre natürlich sinnvoll, die dafür nötigen Voraussetzungen schon jetzt einzuplanen. Allerdings bezweifle ich, dass bei der zu erwartenden Nutzerzahl fürs Erste Bedarf dafür besteht... Außerdem: Kann man dann nur in einem Channel gleichzeitig sein? Falls nein: wo sollen die unterschiedlichen Channel aufscheinen, wie kann man zwischen ihnen wechseln?

(egal, hauptsache das feature ist drin, evt kann man das system dann auch für andere zwecke nutzen, nicht nur fürn webchat)