Feedbox - ServerPush Implementierung

1,991 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,991
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Unser Thema heute, der HP, also die server-initiierte Datenübertragung vom Server zum Client, und das möglichst in Realtime. Der ist in HTTP so nicht vorgesehen, darum kann es sich nur um eine Simulation, bzw. Annäherung handeln. Wir werden euch einen technischen Überblick verschaffen, anhand eines konkreten Problems von unserer Reise auf der Suche nach einer Lösung berichten, bzw. von den Erfahrungen die wir bislang dabei gewonnen haben, erzählen.
  • Einige gemeinsame Projekte haben uns an das Thema herangeführt. Zunächst hatten wir für eine Community zum Sprachenlernen einen Text, Audio und Videochat programmiert. Für diesen Zweck gibt es eine Skype ähnliche Kommunikationshilfe. Bei Dailyme konnten wir einige Erfahrungen mit mobilen Endgeräten sammeln und für Marktforschungszwecke haben wir mit einem Filterproxy Webinhalte modifiziert, Werbung ein/aus, und haben dabei einigen Spass mit HTTP und diversen Browsern. Das Projekt dass uns aber zu diesem Vortrag geführt hat, ist ein Onlinespiel, Sixbreak.
  • gleichzeitige Auslieferung der fragen. info: Experiment, noch nicht produktiv
  • Es gilt die Latenzzeit möglichst gering zu halten.
  • Grundsätzlich gibt es drei Arten der Kommunikation. Die Begriffe stammen aus der Nachrichtentechnik
    Radio, Fernsehen - Walkie talkie - Die bidirektionale Verbindung oder Full Duplex, entspricht dem Telefon, jeder kann gleichzeitig reden, und das ist das was wir wollen.
  • TCP ist auf Transportebene Full-Duplex fähig. Der Datenstrom kann über eine Verbindung gleichzeitig in beide Richtungen fliessen. Die Reihenfolge der Datenströme ist beliebig und unabhängig voneinander.
  • Wir nutzen auf Anwendungsebene das HTTP Protokoll, was aber an das Request-Response Paradigma gebunden ist. Hier kann Server nur dann Daten schicken kann, wenn der Client sie explizit anfordert.
  • Wichtig dabei ist, das zuerst der Request kommen muss, dann erst der Response folgen kann. So trivial das ist, daß sind zwei wichtige Einschränkungen die sich dadurch ergeben. Einerseits muss diese Reihenfolge genau so eingehalten werden, und kann nicht wie bei einer Duplexverbindung gleichzeitig geschehen, ...
  • ... wie hier unten auch noch mal anhand einer Zeitachse zu sehen ist. Anderseits kann der Server kann nur reagieren und nicht agieren, hat also keine Möglichkeit dem Client selbstständig Daten zu schicken.
  • Der naivste Ansatz, wenn der Server keine Daten schicken kann, ist es, den Server immer wieder zu fragen, ob es denn was neues gibt. Das ist im eigentlichen Sinne keine Pushlösung. Ist sicher den meisten klar, das ist keine Option, aber es gibt aber durchaus auch Umsetzungen, wie zum Beispiel Friendfeed, einem Aggregator für soziale Netzwerke, mit ihrem Simple Update Protocol (SUP), dass auf Polling basiert. Ebenso kommt bei Flickr Polling zum Einsatz. Diese Sites sind aber nicht auf Realtime updates angewiesen. Ansonsten überwiegen bei diesem Ansatz aber die Nachteile und für unsere Zwecke keine Option, das erzeugt zu hohe Last.
  • Der naivste Ansatz, wenn der Server keine Daten schicken kann, ist es, den Server immer wieder zu fragen, ob es denn was neues gibt. Das ist im eigentlichen Sinne keine Pushlösung. Ist sicher den meisten klar, das ist keine Option, aber es gibt aber durchaus auch Umsetzungen, wie zum Beispiel Friendfeed, einem Aggregator für soziale Netzwerke, mit ihrem Simple Update Protocol (SUP), dass auf Polling basiert. Ebenso kommt bei Flickr Polling zum Einsatz. Diese Sites sind aber nicht auf Realtime updates angewiesen. Ansonsten überwiegen bei diesem Ansatz aber die Nachteile und für unsere Zwecke keine Option, das erzeugt zu hohe Last.
  • Die nächste Lösung, die einem in der Railswelt begegnet ist ein Plugin names Juggernaut. einfach zu installieren und zu implementieren, arbeitet mit Eventmachine im Hintergrund und funktioniert quasi out of the box. Ist aber auch keine HTTP Pushlösung, da er nicht auf HTTP basiert, sondern mit Flash Sockets arbeitet. Flash Leute sind immer erstaunt über die Diskussionen rund um den HTTP Server Push, da sie Flash als Teil des Browsers sehen. Die meinen dann: „Keine Ahnung was ihr für ein Problem habt, das geht doch alles.“ oder „Ihr tut immer so als ob es kein Flash gäbe“. Grundsatzdiskussion, Für und Wider, aber Tatsache: Läuft nicht über Apache, keine gute Erfahrung gemacht unter Last, cron job, alle 24h neustart. man bekommt es nicht mit, wenn Verbindung abbricht etc.
  • Somit kommen wir zum eigentlichen Thema: Comet. Dabei handelt es sich ähnlich wie Ajax weniger um eine Technologie als um eine Beschreibung einer Lösung, um Patterns. Es werden weniger bekannte Features der http Spec ausgenutzt, gepaart mit einem intelligenten Management von Verbindungen. Wir unterscheiden prinzipiell 2 Ansätze:
  • chunked Encoding: ursprünglich um grosse Dokumente in den Browser zu laden. Vorteil: echtes Down-Streaming, keine verbindungsbedingte Latenz
    Nachteil: aufwändige Umsetzung, per Client Anpassungen (Safari 256 Byte Blöcke , <br> elemente notwendig)
  • von Anfang an ein Hidden Frame, in dem Javascript Code geladen wird. Hier wird die Tatsache ausgenutzt, dass in den meisten Browsern Javascriptcode ausgeführt wird, sobald er geladen wird, selbst wenn Laden nix fertig. Nachteil, Seitenladen angezeigt, am schlimmsten: beim IE behandelt jeden Chunk wie einen Pageload und klickt. Google umgeht das mit Active X Component. Der Frame bläht sich auf, muss man also von Zeit zu Zeit flushen um Memory Leaks zu umgehen.
  • XHR-Streaming: Verwirrender Begriff, da es nicht um den Request geht sondern um die Response sauberere Variante. der IE erlaubt das Auslesen der response erst wenn die Connection closed ist.
  • http 1.1 - 10 Jahre alt, 1999, doch damit gibts immer noch viele Probleme, einerseits was den Browser betrifft, aber auch die Infrastruktur und die Serversoftware, Proxies, UMTS 1.2.3.4
    Es werden eben nicht nur Bilder komprimiert, sondern auch Header verstümmelt und Informationen (z. B. Kommentare) entfernt.: Proxies buffern partielle HttpResponse, limitieren die Dauer einer Http Response, machen http/1.1 streaming Response (chunked encoding) kaputt machen. download only.. Überleitung zum Long Polling
  • Der Client schickt wie gewohnt einen Request an der Server..
  • aber der Server die Response so lange zurückhält bis er Daten verfügbar hat,
  • Wenn die Daten verfügbar sind, weil etwa ein bestimmtest Ereignis eingetreten ist,
  • schickt der die komplette Response zurück
  • und der Client initiiert einen neuen Request. D.h. das muss clientseitig geregelt werden. Connection Manager. Requesttimeout wird im Browser eintreten und dann wird irgendwann der Request beenden. Um das zu vermeiden schickt der Server eine leere Response, worauf auch der Client den nächsten Request auf. Falls die Verbindung abbricht, schlägt der clientseitige Timeout durch, dann muss der Client eine neue Verbindung auf.
  • Gegenüberstellung zu Streaming:
  • Reaktion: im Gegensatz zum Steaming, wo die Daten ja einfach nur in chunks geschickt werden, kann mit dem neuen Request kann zb. ein ACK Flag geschickt werden. höhere Latenz: Gap zwischen Requests, frequent Updates schwieriger, ein Problem kann bspw. auch entstehen wenn man viele Clients gleichzeitig broadcastet - Möglichkeit Nachrichten zusammenzufassen. auch im mobilen bereich ein problem, mind. abstand zwischen den nachrichten wegen der hohen latenzzeiten.
  • Diese Technologien stellen neue besondere Anforderungen an das Connection Managment eines Comet Servers. Das vorwiegend herrschende Thread per Request Modell funktioniert hier nicht mehr, da viele parallele Requests gehalten werden ohne etwas zu tun. Lösungen aus Erlang, C bieten sich an, und auch Python und Java machen sich hier sehr gut.
  • Cometlösungen lassen sich in zwei Gruppen einteilen, die Onboard und die Offboardlösungen.
    Off-board Comet: Multilanguage, Architektur trennbarer, hat aber andererseits das schwierigere Setup. Bei Onboard muss man nicht zwischen Comet und nicht Comet Aufrufen unterscheiden, bzw. kann hier leichter Stati sharen, insgesamt einfacher. Gibt aber auch andere Aspekte, wie zum Beispiel für eine Anwendung wie Meboo macht Offboard keinen Sinn, während für Facebook keine Onboardlösung in Frage kommen würde.
  • Grafik Webapp - Message Broker PushServer
    Grundsätzlicher Aufbau wie wir es haben wollen

    Grafik wie wir uns das vorstellen, kurze beschreibeung,.... das wollen wir haben, deswegen machten wir uns auf die google suche....
  • Software Lösungen sind hier gemeint. URL, Orbited: Python Lösung, basiert auf twistet, populärster Cometserver, scheint unter den reinen Cometservern der beste Ansatz zu sein, Einschränkung: Betastadium (0.7-Version), kaum doku, doch ein paar schmerzhafte Bugs. Eingebauten Messagebroker, oder externen über Stomp (internes Protokoll), Tunneling anderer Protokolle, Jetty gewinnt in letzter Zeit vermehrt Bedeutung.
  • So haben wir uns auf die Suche nach einer eigenen Lösung gemacht, viele verschiedene Ansätze untersucht und bestehende Lösungen angesehen bzw. diese auch schon produktiv eingesetzt. (s. bestehende Lösungen). Beschränkung auf freie Protokolle: http, kein flash etc. Zur Nutzung soll kein Plugin nötig sein, wichtig u.a. für mobile Clients. Damit es keine Probleme mit Firewalls, Proxys etc. gibt sollten nur Standardkommunikationswege eines Webbrowsers genutzt werden: http auf Port 80.
  • wie sieht sie aus
    Herausforderungen
    Zustand des Clients nicht immer klar,
    Gaps zwischen den Verbindungen
  • 010
  • 020
  • 030
  • 050
  • 060
  • 070
  • 080
  • 090
  • 100
  • Wenn wir im Webbereich eine Kommunikation in Form einer bidrektionalen Verbindung einführen, macht es durchaus Sinn diese zu standardisieren. Man muss nicht das Rad zweimal erfinden denn viele der auftretenden Issues sind Standardprobleme. Es geht zB. darum ein QoS einzuführen, Handshakes zu regeln, Publish/Subscribe Mechanismen anzubieten, oder das Versenden einer Message zu regeln. Hier gibt es vorwiegend drei Standardlösungen:
  • eine Erweiterung um XMPP über HTTP tunneln zu können um Jabber Clients auch hinter Firewalls benutzen zu können. Connectionmanager übersetzt XMPP auf BOSH over HTTP
  • XMPP bietet weit mehr als reines Instant Messaging, wie die am besten bekannte Erweiterung namens Jabber vermuten lässt. Einige sehen es als zentralen Punkt um Realtime web umzusetzen. Ua. setzt Google XMPP auch für Collaboration ein, darauf werden wir später noch einmal kurz zurückkommen. XMPP is fast. XMPP is secure. XMPP is extensible. XMPP ist aber auf TCP direkt aufgebaut.
  • Positivbeispiel einer XMPP basierten Anwendung. Die machen Hardcore Collaboration mit Filesharing etc.. Die gemeinsam arbeitenden User loggen sich im Hintergrund in einem Chatroom ein. Die arbeiten auch sehr buzzworddriven, so fehlt zum Beispiel auch kein Cloud Computing. Als Backend haben sie ejabberd im Einsatz und im Frontend benutzen sie Strophe als Client lib. Eine Javascript Bibliothek die XMPP in den Browser bringt. auch in C; An jquery angelehnt (function chaining), funktioniert auch gut in kombination. Die Site zeigt insgesamt erfolgreich, dass XMPP nicht nur für Chats geeignet ist.
  • Positivbeispiel einer XMPP basierten Anwendung. Die machen Hardcore Collaboration mit Filesharing etc.. Die gemeinsam arbeitenden User loggen sich im Hintergrund in einem Chatroom ein. Die arbeiten auch sehr buzzworddriven, so fehlt zum Beispiel auch kein Cloud Computing. Als Backend haben sie ejabberd im Einsatz und im Frontend benutzen sie Strophe als Client lib. Eine Javascript Bibliothek die XMPP in den Browser bringt. auch in C; An jquery angelehnt (function chaining), funktioniert auch gut in kombination. Die Site zeigt insgesamt erfolgreich, dass XMPP nicht nur für Chats geeignet ist.
  • Wenn man sich mit Comet beschäftigt, begegnet einem sehr schnell das 2.te Protokoll, B. Das Protokoll wurde von der Dojo Foundation speziell für Comet entwickelt und ist heute die Basis der meisten Comet Implementierungen. Bayeux bietet hauptsächlich eine API für PubSub Mechanismen unabhängig vom Verbindungsmanagment. Insgesamt gibt es schon grosse Überschneidungen zwischen den beiden, was man sagen, dass Bosh eher Transport- und Bayeux eher Semantik orientiert ist, JSON vs. XML. So müsste jeder gegebenfalls genauer anschauen was einem eher liegt. d.h. wenn man aber schon XMPP im Backend hat, macht Bayeux im Frontend wenig Sinn, da bspw. jede Nachricht in Bayeux umgewandelt werden müsste. Es gibt zwei Javascript Implementierungen, Dojo selbst und eine für jQuery. cometd ist die Referenzimplementierung von Bayeux, eine Javalösung mit Jetty als Application Server. Ist nicht unumstritten, da es, aber das betrifft auch Bosh, insgesamt zu komplex sei.
  • Als dritte Alternative Stomp. Kommt aus einer anderen Ecke, das ist ein Message - Passing- Protokoll, dass vermehrt in Comet Applikationen Verwendung findet, aber ursprünglich aus dem Messaging Bereich kommt. Vorteil ist dass ein Parser in wenigen Zeilen geschrieben ist, weil das Protokoll so simpel ist. So gibt Clients bereits in 14 verschiedenen Sprachen Die Nachrichten werden hier in Klartext als einfache Frames versendet,
  • .. wie wir hier beispielhaft einer einfachen Stomp Nachricht sehen. Hier wird eine Nachricht an eine queue Names „a“, der Name ist beliebig, gesendet. Die kann aber zb. auch auf JMS Ziele gemappt werden, was allerdings nicht standardisiert ist, und von Server zu Server unterschiedlich gelöst wurde. Der Frame kann noch erweitert werden um beispielsweise Transaktionen zu senden, man kann eine Content-length angeben. Der Frame wird mit einem Nullbyte terminiert, was aber bei binären Daten Schwierigkeiten macht.Referenz-implementation (ActiveMQ) fehlerhaft, Fehler wurde reproduziert. Nichtsdestotrotz ist Stomp für die meisten einfachen Fälle ausreichend.
  • Aber um ehrlich zu sein, so richtig sauber ist das alles nicht. Fehlertoleranz!!! Und das wird auch so bleiben bis HTML5 ein Standard wird.
  • ein Bestandteil von HTML5, ermöglichen Full-Duplex Verbindung vom Browser aus, native TCP Socketverbindungen auch über Domaingrenzen hinweg, naja fast. bestimmtes Handshakeverfahren notwendig, Ähnlich wie https wird die Verbindung über http connect aufgebaut und danach genunnelt. orbited hat bspw. eine TCPSocket Implementierung, die wenn möglich auf HTML5 setzt, ansonsten über die Alternativverfahren tunnelt. Man bleibt also kompatibel, je nach Browsermöglichkeit. Microsoft hat sich vor zwar kurzem auch der Kommission angeschlossen nachdem MS ja lange auf XHTML2 gesetzt hat. Allerdings stehen die da eher auf der Bremse, die Vermutung liegt nahe, dass sie wegen Silverlight da natürlich ein Problem haben.
  • Eine Wave ist eine Nachricht, die an eine oder mehrere Personen geschickt werden kann. Sobald die Empfangenden definiert sind, erscheint die (vielleicht noch nicht einmal vollständige) Nachricht in Realtime auf deren Bildschirmen. Sie können noch während die Nachricht vervollständigt wird, Antworten und Bemerkungen in die Wave einschreiben, die wiederum beim Erstsender in Realtime angezeigt werden. Google setzt auf HTML5, XMPP, Google Wave Federation Protocol Over XMPP. Btw. Adobe hat ja auch eine Adobe Wave ins Leben gerufen, nur bekommts keiner mit ;-) --- ist aber auch AIR
    an anderer Stelle wird aber behauptet Google setzt auf long polling, und Jetty als Application Server / hat sich von Tomcat verabschiedet
    Realtime communication and collaboration platform & protocol
  • Erkenntnis: der Webbrowser wird immer mehr zum zentralen Programm das platformübergreifend überall vorhanden ist. Usererwartungen steigen mit jeder neuen Anwendung. Die Kommunikation wird zu einem zentralen Punkt im Web2.0 Umfeld. Dadurch ergeben sich aber ganz neue Anforderungen und Messaging ist hierfür das bessere Protokoll als das Http Request/Response Paradigma, vermutlich werden in Zukunft vermehrt Webanwendungen auch vermehrt Messagebroker im Backend haben werden.
  • Feedbox - ServerPush Implementierung

    1. 1. Feedbox Clemens Heimlich & Martin Wöginger
    2. 2. HTTP-Serverpush
    3. 3. Wer sind wir • Clemens Heimlich http://openweb-berlin.de/ • Martin Wöginger http://www.exasoft.net/mw/
    4. 4. Erfahrungen • Palabea: Community mit Videochat, Skype ähnliches Kommunikationsfenster • dailyme: mobiles Video • i2-Proxy • Sixbreak: Online - Quiz
    5. 5. Daten in Realtime vom Server zum Client
    6. 6. Kommunikation • Simplex • Half-Duplex • Full-Duplex
    7. 7. TCP Übertragungsebene
    8. 8. Http ist ein Client/ Server Protokoll
    9. 9. HTTP Request/ Response Paradigma
    10. 10. HTTP Request/ Response Paradigma
    11. 11. Daten in Realtime vom Server zum Client!!!
    12. 12. Polling • einfache Implementierung • hohe Serverlast • hohe Latenzzeit, die sich aus dem Pollinginterval ergibt
    13. 13. Polling • einfache Implementierung • hohe Serverlast • hohe Latenzzeit, die sich aus dem Pollinginterval ergibt
    14. 14. Polling • einfache Implementierung • hohe Serverlast • hohe Latenzzeit, die sich aus dem Pollinginterval ergibt
    15. 15. Juggernaut • simpel • Flash basiert • propietäres Protokoll
    16. 16. Comet • Beschreibung einer Lösung • Sammlung HTTP Techniken • Low Latency Data
    17. 17. Streaming • HTTP/1.1 Response • Transfer-Encoding chunked
    18. 18. Forever Frame • hidden iframe • lädt im Hintergrund • schlechte Userexperience mit Internet Explorer
    19. 19. XHR mit Streaming- Response • XMLHttpRequest • bietet beste Performance • wieder IE: erst ab Explorer 8 • xhr.onreadystatechange
    20. 20. Probleme mit http/1.1 'Transfer-Encoding chunked' • Proxies • PEP: Performance Enhancing Proxy • Firewalls • Download only
    21. 21. Long Polling • HTTP/1.0 Response • Content-Length Header
    22. 22. Long Polling
    23. 23. Long Polling • kompatibler • Reaktion möglich • etwas höhere Latenzzeit gegenüber Streaming • mehr Overhead
    24. 24. Comet Server • Connection Managment: Threading • Erlang, C, Python und Java
    25. 25. Off-board Comet vs. On-board Comet
    26. 26. Serverlösungen • Orbited • Glassfish • Jetty • http://cometdaily.com/maturity.html
    27. 27. noch mal die Aufgabenstellungen • Quiz • Spiel einladen • Fragen beantworten • Fragen synchron ausliefern
    28. 28. Eigene Lösung • HTTP • Port 80 • Einfachheit und Flexibilität bei der Nutzung • hohe Skalierbarkeit der serverseitigen Anwendung
    29. 29. Feedbox
    30. 30. Feedbox fcgi • Autor: Andreas Heimlich, www.heimb.de • in C geschriebene fcgi - Anwendung • fixed threaded
    31. 31. Protokolle
    32. 32. Bosh • Bidirectional-streams Over Synchronous HTTP • XMPP Erweiterung • XML basierend • Long Polling
    33. 33. XMPP • offener Standard • komplett • erweiterbar • komplex • verbose
    34. 34. Bayeux • cometd.org (Dojo Foundation) • JSON • Publish - Subscribe • de facto Standard: Basis der meisten Comet Lösungen
    35. 35. Stomp • Streaming Text Orientated Messaging Protocol • einfach & straight forward • 8 Kommandos
    36. 36. SEND destination:/queue/a hello queue a ^@
    37. 37. gesammelte Probleme • Mobile Client: RAM • Browser: HTTP Connection Limit • Push Server: Ticket Hijacking
    38. 38. Aber: Comet ist ein Hack!!!
    39. 39. WebSockets
    40. 40. Google Wave
    41. 41. Neue Anforderungen • Chat, Notifications, Mulitplayer- Spiele, Collaboration, Live Ticker, Reporting, Monitoring, Rich User Interface • Tunneling (anderer Protokolle wie XMPP)
    42. 42. Fragen & Antworten ?
    43. 43. Danke!!

    ×