Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Andere mochten auch
Andere mochten auch (8)
Ähnlich wie Feedbox - ServerPush Implementierung
Ähnlich wie Feedbox - ServerPush Implementierung (20)
Feedbox - ServerPush Implementierung
- 1. Feedbox Clemens Heimlich & Martin Wöginger
- 3. Wer sind wir • Clemens Heimlich http://openweb-berlin.de/ • Martin Wöginger http://www.exasoft.net/mw/
- 4. Erfahrungen • Palabea: Community mit Videochat, Skype ähnliches Kommunikationsfenster • dailyme: mobiles Video • i2-Proxy • Sixbreak: Online - Quiz
- 7. Daten in Realtime vom Server zum Client
- 8. Kommunikation • Simplex • Half-Duplex • Full-Duplex
- 10. Http ist ein Client/ Server Protokoll
- 13. Daten in Realtime vom Server zum Client!!!
- 14. Polling • einfache Implementierung • hohe Serverlast • hohe Latenzzeit, die sich aus dem Pollinginterval ergibt
- 15. Polling • einfache Implementierung • hohe Serverlast • hohe Latenzzeit, die sich aus dem Pollinginterval ergibt
- 16. Polling • einfache Implementierung • hohe Serverlast • hohe Latenzzeit, die sich aus dem Pollinginterval ergibt
- 17. Juggernaut • simpel • Flash basiert • propietäres Protokoll
- 18. Comet • Beschreibung einer Lösung • Sammlung HTTP Techniken • Low Latency Data
- 19. Streaming • HTTP/1.1 Response • Transfer-Encoding chunked
- 20. Forever Frame • hidden iframe • lädt im Hintergrund • schlechte Userexperience mit Internet Explorer
- 21. XHR mit Streaming- Response • XMLHttpRequest • bietet beste Performance • wieder IE: erst ab Explorer 8 • xhr.onreadystatechange
- 22. Probleme mit http/1.1 'Transfer-Encoding chunked' • Proxies • PEP: Performance Enhancing Proxy • Firewalls • Download only
- 23. Long Polling • HTTP/1.0 Response • Content-Length Header
- 29. Long Polling
- 30. Long Polling • kompatibler • Reaktion möglich • etwas höhere Latenzzeit gegenüber Streaming • mehr Overhead
- 31. Comet Server • Connection Managment: Threading • Erlang, C, Python und Java
- 32. Off-board Comet vs. On-board Comet
- 35. Serverlösungen • Orbited • Glassfish • Jetty • http://cometdaily.com/maturity.html
- 37. noch mal die Aufgabenstellungen • Quiz • Spiel einladen • Fragen beantworten • Fragen synchron ausliefern
- 38. Eigene Lösung • HTTP • Port 80 • Einfachheit und Flexibilität bei der Nutzung • hohe Skalierbarkeit der serverseitigen Anwendung
- 39. Feedbox
- 40. Feedbox fcgi • Autor: Andreas Heimlich, www.heimb.de • in C geschriebene fcgi - Anwendung • fixed threaded
- 54. Protokolle
- 55. Bosh • Bidirectional-streams Over Synchronous HTTP • XMPP Erweiterung • XML basierend • Long Polling
- 56. XMPP • offener Standard • komplett • erweiterbar • komplex • verbose
- 60. Bayeux • cometd.org (Dojo Foundation) • JSON • Publish - Subscribe • de facto Standard: Basis der meisten Comet Lösungen
- 61. Stomp • Streaming Text Orientated Messaging Protocol • einfach & straight forward • 8 Kommandos
- 63. gesammelte Probleme • Mobile Client: RAM • Browser: HTTP Connection Limit • Push Server: Ticket Hijacking
- 64. Aber: Comet ist ein Hack!!!
- 65. WebSockets
- 66. Google Wave
- 67. Neue Anforderungen • Chat, Notifications, Mulitplayer- Spiele, Collaboration, Live Ticker, Reporting, Monitoring, Rich User Interface • Tunneling (anderer Protokolle wie XMPP)
- 68. Fragen & Antworten ?
- 69. Danke!!
Hinweis der Redaktion
- 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&#xFC;nglich um grosse Dokumente in den Browser zu laden. Vorteil: echtes Down-Streaming, keine verbindungsbedingte Latenz Nachteil: aufw&#xE4;ndige Umsetzung, per Client Anpassungen (Safari 256 Byte Bl&#xF6;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&#xFC;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&#xE4;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&#xFC;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.. &#xDC;berleitung zum Long Polling
- Der Client schickt wie gewohnt einen Request an der Server..
- aber der Server die Response so lange zur&#xFC;ckh&#xE4;lt bis er Daten verf&#xFC;gbar hat,
- Wenn die Daten verf&#xFC;gbar sind, weil etwa ein bestimmtest Ereignis eingetreten ist,
- schickt der die komplette Response zur&#xFC;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&#xE4;chsten Request auf. Falls die Verbindung abbricht, schl&#xE4;gt der clientseitige Timeout durch, dann muss der Client eine neue Verbindung auf.
- Gegen&#xFC;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&#xF6;here Latenz: Gap zwischen Requests, frequent Updates schwieriger, ein Problem kann bspw. auch entstehen wenn man viele Clients gleichzeitig broadcastet - M&#xF6;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&#xF6;sungen aus Erlang, C bieten sich an, und auch Python und Java machen sich hier sehr gut.
- Cometl&#xF6;sungen lassen sich in zwei Gruppen einteilen, die Onboard und die Offboardl&#xF6;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&#xFC;r eine Anwendung wie Meboo macht Offboard keinen Sinn, w&#xE4;hrend f&#xFC;r Facebook keine Onboardl&#xF6;sung in Frage kommen w&#xFC;rde.
- Grafik Webapp - Message Broker PushServer Grunds&#xE4;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&#xF6;sungen sind hier gemeint. URL, Orbited: Python L&#xF6;sung, basiert auf twistet, popul&#xE4;rster Cometserver, scheint unter den reinen Cometservern der beste Ansatz zu sein, Einschr&#xE4;nkung: Betastadium (0.7-Version), kaum doku, doch ein paar schmerzhafte Bugs. Eingebauten Messagebroker, oder externen &#xFC;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&#xF6;sung gemacht, viele verschiedene Ans&#xE4;tze untersucht und bestehende L&#xF6;sungen angesehen bzw. diese auch schon produktiv eingesetzt. (s. bestehende L&#xF6;sungen). Beschr&#xE4;nkung auf freie Protokolle: http, kein flash etc. Zur Nutzung soll kein Plugin n&#xF6;tig sein, wichtig u.a. f&#xFC;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&#xFC;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&#xFC;hren, Handshakes zu regeln, Publish/Subscribe Mechanismen anzubieten, oder das Versenden einer Message zu regeln. Hier gibt es vorwiegend drei Standardl&#xF6;sungen:
- eine Erweiterung um XMPP &#xFC;ber HTTP tunneln zu k&#xF6;nnen um Jabber Clients auch hinter Firewalls benutzen zu k&#xF6;nnen. Connectionmanager &#xFC;bersetzt XMPP auf BOSH over HTTP
- XMPP bietet weit mehr als reines Instant Messaging, wie die am besten bekannte Erweiterung namens Jabber vermuten l&#xE4;sst. Einige sehen es als zentralen Punkt um Realtime web umzusetzen. Ua. setzt Google XMPP auch f&#xFC;r Collaboration ein, darauf werden wir sp&#xE4;ter noch einmal kurz zur&#xFC;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&#xFC;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&#xFC;r Chats geeignet ist.
- Wenn man sich mit Comet besch&#xE4;ftigt, begegnet einem sehr schnell das 2.te Protokoll, B. Das Protokoll wurde von der Dojo Foundation speziell f&#xFC;r Comet entwickelt und ist heute die Basis der meisten Comet Implementierungen. Bayeux bietet haupts&#xE4;chlich eine API f&#xFC;r PubSub Mechanismen unabh&#xE4;ngig vom Verbindungsmanagment. Insgesamt gibt es schon grosse &#xDC;berschneidungen zwischen den beiden, was man sagen, dass Bosh eher Transport- und Bayeux eher Semantik orientiert ist, JSON vs. XML. So m&#xFC;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&#xFC;sste. Es gibt zwei Javascript Implementierungen, Dojo selbst und eine f&#xFC;r jQuery. cometd ist die Referenzimplementierung von Bayeux, eine Javal&#xF6;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&#xFC;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 &#x201E;a&#x201C;, 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&#xF6;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&#xE4;ren Daten Schwierigkeiten macht.Referenz-implementation (ActiveMQ) fehlerhaft, Fehler wurde reproduziert. Nichtsdestotrotz ist Stomp f&#xFC;r die meisten einfachen F&#xE4;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&#xF6;glichen Full-Duplex Verbindung vom Browser aus, native TCP Socketverbindungen auch &#xFC;ber Domaingrenzen hinweg, naja fast. bestimmtes Handshakeverfahren notwendig, &#xC4;hnlich wie https wird die Verbindung &#xFC;ber http connect aufgebaut und danach genunnelt. orbited hat bspw. eine TCPSocket Implementierung, die wenn m&#xF6;glich auf HTML5 setzt, ansonsten &#xFC;ber die Alternativverfahren tunnelt. Man bleibt also kompatibel, je nach Browserm&#xF6;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&#xFC;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&#xE4;ndige) Nachricht in Realtime auf deren Bildschirmen. Sie k&#xF6;nnen noch w&#xE4;hrend die Nachricht vervollst&#xE4;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&#xFC;bergreifend &#xFC;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&#xFC;r das bessere Protokoll als das Http Request/Response Paradigma, vermutlich werden in Zukunft vermehrt Webanwendungen auch vermehrt Messagebroker im Backend haben werden.