Implementierung & Evaluation eines JavaScript-basierten ... - KOPS
Implementierung & Evaluation eines JavaScript-basierten ... - KOPS
Implementierung & Evaluation eines JavaScript-basierten ... - KOPS
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
3.2 Backend<br />
Die generelle Funktionsweise von JSXC ist wie folgt: Zuerst kontrolliert die Anwendung ob mehrere<br />
offene Tabs vorhanden sind. Danach wird überprüft, ob eine Verbindung wiederhergestellt werden<br />
kann, oder ob eine neue aufgebaut werden muss. Wenn eine Verbindung steht, werden eingehende<br />
Nachrichten dargestellt und ausgehende ggf. verschlüsselt und versendet.<br />
Als Verbindungsprotokoll zum XMPP-Server wird BOSH (Abschnitt 2.3.5) benutzt mit einer<br />
zu Diaspora unabhängigen <strong>Implementierung</strong>. Dadurch kann JSXC in jede beliebe Webanwendung<br />
eingefügt werden.<br />
Alle Informationen die persistent über die Lebensdauer einer einzelnen Seite hinaus verfügbar<br />
sein müssen, werden im Web Storage gespeichert. Wie zum Beispiel die letzten 10 Nachrichten <strong>eines</strong><br />
jeden Benutzers, der private Schlüssel 1 oder Informationen 2 über den Status des OTR Protokolls.<br />
3.2.1 Interne Kommunikation<br />
Mit dem Begriff ”<br />
interne Kommunikation“ ist die Kommunikation der einzelnen Tabs untereinander<br />
gemeint. Diese geschieht über den Web Storage, denn dieser feuert in jeder Instanz ein Event wenn<br />
ein Wert geändert wird. Auf dieses Event kann man lauschen und ggf. darauf reagieren. Somit<br />
muss Tab A nur einen Wert in den Storage schreiben, um mit den Anderen zu kommunizieren.<br />
(Abbildung 3.5)<br />
Browser<br />
Webstorage<br />
Schreibe<br />
Event<br />
Event<br />
Tab A<br />
Tab B<br />
Tab C<br />
Abbildung 3.5: Funktionsweise des Webstorage und dessen Events.<br />
3.2.2 Rollenbestimmung<br />
Von mehreren geöffneten Tabs ist immer einer für die Kommunikation mit dem XMPP-Server<br />
zuständig, diesen nennen wir ”<br />
Master“. Alle anderen ”<br />
Slave“, diese kommunizieren mit dem Haupt-<br />
Tab. Wenn eine Seite neu geladen wird, muss zuerst überprüft werden, ob ein Master existiert oder<br />
ob man selbst diese Rolle übernehmen muss. (Abbildung 3.6)<br />
Danach sendet der Master in einem festen Intervall ein Keep-Alive Signal, damit alle Slaves<br />
wissen, dass er noch nicht geschlossen wurde. Sollte das Signal ausbleiben 3 muss ein neuer Master<br />
bestimmt werden. Dazu warten die Tabs eine zufällige Zeit, welche kleiner drei Sekunden ist und<br />
starten danach mit dem Senden <strong>eines</strong> Pings. Da Ping, Pong und das Keep-Alive Signal auf dem<br />
1 In Kapitel 5.3.4 werden die dazugehörigen Sicherheitsaspekte beleuchtet.<br />
2 Einzelheiten werden in Abschnitt 3.2.5 behandelt.<br />
3 Der Master-Tab wurde geschlossen.<br />
15