28.02.2014 Aufrufe

Implementierung & Evaluation eines JavaScript-basierten ... - KOPS

Implementierung & Evaluation eines JavaScript-basierten ... - KOPS

Implementierung & Evaluation eines JavaScript-basierten ... - KOPS

MEHR ANZEIGEN
WENIGER ANZEIGEN

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!