wonder2-praesentation

View Github Repository Open presentation in a new window

jhamfler

See all presentation from jhamfler

wonder2-praesentation

0 0

wonder2-praesentation

presentation of the WONDERv2-Framework which goes with the WONDERv2 bachelor thesis

On Github jhamfler / wonder2-praesentation

Kolloquium

Analyse der „Signalling-On-The-Fly“-Interoperabilitäts-Lösung für WebRTC sowie Entwurf und prototypische Realisierung eines optimierten Signalisierungskonzeptes

-

Gliederung

-

Gliederung

  • Einleitung
  • Zielstellung
  • Nachladeproblematik
    • Signalisierungsprotokolle
    • Frameworkmodule
  • Signalisierung zwischen WONDERv2-Frameworks
    • Login
    • Call
    • Datenkanal
  • Fazit
  • Ausblick -

Einleitung

SigOFly-Mechanismus

  • Dynamisches Nachladen von Signalisierungsprotokollen
  • Messaging Stubs stellen Schnittstellen zu den Signalisierungsprotokollen bereit
    • Javascript-Code
    • Verbindung zwischen Framework und Signalisierungsprotokoll
    • Verbindung zwischen Netzwerk und Signalisierungsprotokoll
-

WONDERv1-Framework

  • Javascript-Framework zur Nutzung von SigOFly und WebRTC
  • Messaging Stubs wurden dynamisch nachgeladen
  • Ermöglicht Kommunikation unter WebRTC-Anwendungen in verschiedenen Signalisierungsdomänen
-

Zielstellung

-

Zielstellung

  • Modularisierung des WONDER-Frameworks
  • Separierung logischer Komponenten
  • Erstellung einfacher Schnittstellen für Anwendungsentwickler
  • Realisierung von mehr als zwei Codecs für den Datenkanal
  • Verbesserung des Identitätsmanagements
  • Einfache Gestaltung des Setup

Zielarchitektur

-

Nachlade-problematik

- Danny ist eher auf Code-Teil eingegangen - Ich werde eher auf High-Level-Sicht eingehen

Signalisierungsprotokolle

Stubinstanziierung

- Immer der Letzte gewinnt - Mit Require.js tritt das auch auf, wenn Stubs Namen haben #### Lösung: - URIs referenzieren Stubs anstatt Namen

Signalisierungsprotokolle

Signalisierungsservernutzung

- Immer der eigene Stub gewinnt, da "Require.js module.config().connectURL Variable" #### Lösung: - URIs der MsgSrv in Identität vorhalten

Signalisierungsprotokolle

Schnittstellentiefe im Stub

- Idp.getInstance().createIdentity(function(identity){...that.basestub.send(message)...}) #### Lösung: - Speicherung einer Funktion und einer URI im Stub - WONDERinterne funktionen werden von WONDER ausgeführt

Frameworkmodule WONDERv1

- Viele Abhängigkeiten - Große Aufruftiefe #### Lösung: - Auflösen der gegenseitigen Abhängigkeiten - Spezialfunktionen mit Rückgabewerten

Frameworkmodule WONDERv2

- zusätliche Abstraktionsschicht WONDER-Klasse - wenig gegenseitige Abhängigkeiten (Aufrufe) - Ansicht zeigt Aufrufabhängigkeiten für Two-Party-Call

Signalisierung zwischen WONDERv2-Frameworks

- High-Level-Sicht

Login WONDERv1

- idp.createIdentity muss vom Implementierer kommen - Stub URIs kommen mit der Identität - MsgSrv Addresse im Stub erscheint erstmal positiv, da man sich die nicht erst von woanders holen muss

Login WONDERv2

- wonder.login ähnlich wie bei WONDERv1 - Identität hat mehr Informationen als bei WONDERv1

Gegenüberstellung Login

WONDERv1 - WONDERv2

- jetzt möglich verschiedene MsgSrv mit einem Stub zu kontaktieren - für jede Identität zusätzliche Codecs vorhanden

Call Alice to Bob WONDERv1

- Alice fragt eigenen IdP - Wenn Bob in anderer Domäne, dann muss die Domäne im IdP sein - kein standardisierter IdP, keine vernetzung mit anderen IdPs

Call Alice to Bob WONDERv2

- keine tiefe Schnittstelle - nicht nur Stur-URIs, sondern auch MsgSrv-URIs und Codec-URIs

Gegenüberstellung Call Alice to Bob

WONDERv1 - WONDERv2

-

Datachannelmessage WONDERv1

Datachannelmessage WONDERv2

Gegenüberstellung Datachannelmessage

WONDERv1 - WONDERv2

Datenkanalzuordnung

- from alice to bob - from bob to alice ... enden nicht auf gleichem codec

Fazit

-

Fazit

  • Modularisierung verbessert
  • Ausführliche Dokumentation vorhanden
  • Automatisierung in der Entwicklung erreicht
  • Unabhängige Stubs erstellt
  • Implementierungsschnittstellen vereinfacht
  • Erste Schritte mit WONDER vereinfacht
  • Nachladen von Codecs, Module und Stubs ermöglicht
  • Wiederverwendbarkeit von Stubs erreicht
  • Separate Server bzw. logische Komponenten vorhanden
  • Vorbereitung für Multi-Party-Calls getroffen
  • Schnittstellentiefe verringert
  • Medienanforderungen vereinfacht
  • Mehrere Codecs für Datenkanäle
  • Unabhängige Stubs: verschiedene Messaging Server möglich, verschiede Domänen
  • Wiederverwendbare Stubs: Stubs können losgelöst von Wonder funktionieren
  • Erste Schritte: wonder.call() und Server Setup einfach

Ausblick

Ausblick

  • Parallele Nutzung mehrerer Datenkanäle mit unterschiedlichen Payload-Typen
  • Übertragung von Statusinformationen
  • Unterstützung von Multi-Party-Konversationen
  • Nutzung von ECMA-Script 6 Import / Export
  • Authentifizierung mit OpenID Connect - Satusinfos: Presence, Frameworkstatus, Verbindungsstatus

Vielen Dank für Ihre Aufmerksamkeit!

Johannes Hamfler