History

Service-Discovery

Per Service-Discovery soll eine möglichst einfache Findung und Zuordnung von Clients und Servern zueinander möglich sein. Ohne, dass auf den Clients großartig Configfiles angelegt werden müssen, sollen die Studentenrechner (Clients) zum Dozentenrechner (PVS-Konsole) verbinden.
Dabei sollen zum einen Sicherheitsaspekte berücksichtigt werden, damit nicht jeder Client unbemerkt vom Server (oder Dritten sich als Server ausgebenden) beobachtet oder gesperrt werden kann, zum anderen muss beachtet werden, dass die Zuordnung bei mehreren Computerräumen sinnvoll erfolgen muss, und nicht ein Client aus Raum A versehentlich dem Dozent aus Raum B zugeordnet wird.

Überlegungen zu verschiedenen Ansätzen

Technisch

Von der technischen Seite lässt sich das Ganze grob in 2 Verfahren teilen:
  1. Ein "richtiges" P2P-Netz wird zum Finden anderer Clients genutzt, d.h. jeder Teilnehmer in diesem Netz besitzt Informationen über andere Teilnehmer, die gerade Online sind (IP, Name, Student/Dozent)
  2. Die Findung wird über Broadcasts geregelt, wobei hier zwingend alle Computer eines Raums in einer Broadcastdomain liegen müssen
Der 2. Ansatz hat gleich mehrere Vorteile:
  • Einfachere Implementierung :)
  • Einfach zu Debuggen
  • Wenig Störanfällig, da eventuelle Bootstrappingvorgänge zum erstmaligen Auffinden eines P2P Netes entfallen
  • Arbeitet schneller
  • Veraltete Informationen schwirren nicht so lange im Netz umher

Zumindest nach den ersten Überlegungen spricht einiges für den Broadcastansatz. Jedoch bliebt zu Überlegen, ob es auch möglich sein soll, Netzübergreifend Clients und Server zu verbinden. Hierfür sollte zumindest noch ein manueller Weg offen bleiben, soll das Feature jedoch häufiger zum Einsatz kommen, ist zumindest eine Hybridlösung nötig.

Sicherheit/Logik

Wie bereits kurz erwähnt, ist neben der rein technischen Funktionalität auch noch ein möglichst unkomplizierter Weg nötig, die Teilnehmer sinnvoll zu verbinden. Vor Beginn eines Kurses müssen Studentenrechner (Clients) und der Dozenten-PC (mit der PVS-Konsole) einander zugeordnet werden. Hier wäre es schön, wenn nicht jeder Teilnehmer anhand seines Rechnernamens oder der IP-Adresse manuell als zum Raum gehörend (oder eben nicht) identifiziert werden muss.
Hier gilt es, einen Kompromiss aus Bedienbarkeit und Sicherheit zu finden. Hierhinein zählen auch Überlegungen zu Mehr-Wege-Systemen (bspw. Finden über Netz, Bestätigung auf anderem Wege)
  • Findung über globalen Request -> wie erwähnt schlecht, da dann jeder erstmal überlegen muss, ob es sich um den richtigen Dozenten handelt, oder nicht (Lediglich ein Kanal)
  • Findung über Töne: Alle Clients oder der Server brauchen ein Mikrofon, könnte etwas irritierend sein, wie störsicher ist das ganze? (Rückfragen bei anderem Lehrstuhl, die dieses bereits für andere Zwecke einsetzen)
  • Findung über Private/Public Key: Jeder Dozent hat einen eigenen Schlüssel, die Clients können diesen dann zulassen oder ablehnen, evtl mit zeitlicher Befristung
  • Findung über Shared Secret: Der Dozent schreibt anfangs ein "Passwort" an die Tafel welches alle Studenten in ihrem Client eingeben

Nicht unwichtig hierbei ist wohl, wie der durchschnittliche Student mit dem System umgehen würde.
Da z.B. die Zertifikate bei HTTPS für die meisten schon an Voodoozauber grenzen ist die Frage, ob bei dem Ansatz über einen privaten Schlüssel die Kursteilehmer überhaupt irgendwas an der aufpoppenden Meldung prüfen würden (Fingerprint des Keys), oder einfach nur auf akzeptieren klicken würden, egal wer eigentlich anfragt. Auch würde ein eventueller Keystore wahrscheinlich von den wenigsten Studenten gewartet werden.
Zur Zeit gefällt mir hier noch der letzte Ansatz am besten. Der Dozent schreibt Anfang des Kurses "12345" an die Tafel, jeder tippt es schnell auf seinem PC ein. Broadcasts/Verbindungsanfragen mit anderem Passphrase werden einfach ignoriert, für den Dozenten mit dem richtigen Passphrase kommt eine kurze Verbindungsbestätigung.
Weitere Verbindungsversuche sollten evtl. mit einer Warnung versehen werden.
Der Aufwand dürfte, selbst wenn das ganze jedes mal durchgeführt werden muss, für die Nutzer erträglich sein.
Geschickterweise könnte man aus dem Passphrase auch direkt einen Schlüssel für AES o.ä. berechnen, um die Kommunikation zusätzlich zu sichern.