Skip to content

Real Time Web für Server

Das Problem

Seit dem ich für mein Blog die Wordpress App benutze, um über neue Kommentare informiert zu werden, nervt mich ein Problem: Die App muss regelmäßig abfragen, ob etwas neues im Blog vorhanden ist. Will man zeitnah informiert werden, muss man die Frequenz der Abfrage relativ hoch stellen. Das hat allerdings zur Folge, dass der Client zum großen Teil unnötige Abfragen produziert, die sowohl beim Server wie beim Client ziemlich sinnlos Ressourcen (Akku am Client, Traffic am Server) verbrauchen. Erschwerend kommt hinzu, dass die Wordpress App ständig aufhört, regelmäßig abzufragen, und für diesen Anwendungsfall für mich nutzlos wird.

Das gleiche Problem hatte ich auch bei Superious, meinem Posterous Client für Android. Hier ist es richtig schwierig, eine passende Abfrage Frequenz einzustellen. Bei Posterous kommt tagelang nichts (in denen der Client erfolglos nach neuem sucht) und dann entwickelt sich an manchen Tagen eine Diskussion, die man zeitnah verfolgen möchte. Die optimale Abfrage Frequenz ist also unterschiedlich.

Google hat dazu mal in einem Video ein gutes Metapher gefunden: Es ist wie eine Autofahrt mit kleinen Kindern, auf der diese ständig fragen: "Sind wir schon da? Sind wir schon da?!" Die Eltern würden sich wünschen, dass die Kinder mit der sinnlosen Fragerei aufhören würden, und statt dessen darauf warten würden, dass der Fahrer sagt: "JETZT sind wir da."

Beispiel RSS

Das Web funktioniert immer noch in vielen Bereichen wie die beschriebene Autofahrt. Ein prominentes und gut zu verstehendes Beispiel sind die RSS Feeds von Blogs. Blogs veröffentlichen diese mit den aktuell verfügbaren Artikeln. Clients (Feedreader) lesen die Feeds und bereiten sie auf. Dabei müssen die Reader mit einer intelligenten Frequenz beim Blog die RSS Feeds auslesen und mit vorherigen Aufrufen vergleichen, ob es etwas neues gibt.

Man würde sich wünschen, dass das anders laufen würde: Der Server (das Blog, Posterous, ..) meldet in dem Moment, da er etwas neues hat, an seine Clients: "JETZT habe ich etwas neues." Auf diese Weise würde der Server nicht mehr mit ständigen Anfragen konfrontiert, der Client könnte sich mit anderem beschäftigen (oder in den Sparmodus wechseln), trotzdem würden Änderungen sofort am Client bekannt werden, wenn sie entstehen. Im Gegensatz zu der herkömmlichen Technik, die man Pull nennt (der Client "zieht" sich Informationen), wäre dies eine Push Technik (der Server "drückt" Informationen, wenn sie vorhanden sind).

Für Server zu Server Kommunikation gibt es so etwas schon seit längerem: z.B. Pubsubhubbub.

Pubsubhubbub

Dieser sperrige Name, der auch gerne abgekürzt als PuSH bezeichnet wird, ist ein Push Service Protokoll, das Google eingeführt hat. Das Protokoll und seine Möglichkeiten sind recht gut bei DrWeb beschrieben, deshalb beschreibe ich es hier nur kurz. Im Wesentlichen geht es darum, dass zwischen der Informationsquelle und dem Client ein weiterer Server zwischen geschaltet wird (hier HUB genannt).

Eine Informationsquelle meldet sich nun jedes mal, wenn neue Inhalte erzeugt wurden, beim PuSH HUB. Dieser verteilt diese Information an alle Clients, die sich dort als Interessenten eingetragen haben. Dabei ist das Protokoll dezentral gehalten: Der HUB kann ein beliebiger Server sein, der das PuSH Protokoll implementiert, im Extremfall könnte es auch die Informationsquelle selbst sein. Clients, die an einer Informationsquelle interessiert sind, können über standardisierte Mechanismen bei der Quelle nachfragen, welcher HUB gerade für die Quelle zuständig ist und sich danach bei dem HUB als Interessent eintragen. Ab dann ist der Client über den HUB mit der Quelle über einen PuSH Service verbunden. Er muss nun also nicht mehr kontinuierlich nachfragen, ob es etwas neues gibt, er wird ab jetzt informiert, wenn dies der Fall ist.

Google hat dies bei einigen Services implementiert. Wenn man seinen RSS Feed bei Feedburner hat, dann hat man für sein Blog z.B. bereits alles getan, was als Informationsquelle nötig ist. Der Feedburner Feed ist mit einem PuSH HUB verbunden und um die Information angereichert, welcher HUB von Clients für das Protokoll verwendet werden soll. Zu Feedburner muss man allerdings sagen, dass der PuSH hier nur emuliert sein kann, denn die neuen Informationen entstehen ja nicht dort sondern auf dem angeschlossenen Blog, das Feedburner nicht notwendiger Weise über neues informiert. Außerdem scheint Feedburner im Sterben zu liegen, seine API wird zumindest in den nächsten Tagen abgeschaltet.

Wer ein Blogspot oder Livejournal Blog hat, hat allerdings bereits einen echten PuSH Feed, für Wordpress gibt es mehrere Plugins und für Serendipity schreibe ich gerade eines.

Der PuSH Client

Der Google Reader ist ein Client, der solche PuSH HUB Informationen in Feeds auswerten kann (und somit neue Artikel immer extrem zeitnah darstellen kann). Dabei ist er nur aus Sicht des PuSH Protokolls ein Client, technisch ist dies ein  permanenter Server im Web. Und hier ist auch ein großes Problem des PuSH Protokolls: Damit der HUB einen Client über Neuigkeiten informieren kann, muss dieser regelmäßig erreichbar sein. Bei Clients, die auf Webservern gehostet sind wie der Google Reader, ist dies natürlich kein Problem, aber bereits ein Desktop RSS Reader oder gar ein mobiler Reader ist eine Herausforderung, da diese Clients ständig ihre IP ändern, wenn sie denn überhaupt ansprechbar (also online) sind.

Vermutlich ist dies auch der Grund, warum das PuSH Protokoll zwar inzwischen als Standard gilt, jedoch außerhalb des Google Universums keine erkennbare Verbreitung gefunden hat. Es scheint zu wenige Anwendungsfälle zu geben.

In der letzten Zeit habe ich mir einige Gedanken dazu gemacht, wie man mobile Clients trotzdem an so einen Push Service anbinden kann. Dies kann man bauen: Mein Androide meldet mir z.B. seit einiger Zeit sofort (und unabhängig von der Wordpress App), wenn ein neuer Kommentar in meinem Blog eingegangen ist. Ich habe also inzwischen mein Eingangsproblem elegant gelöst.

Mein Androide muss dazu nicht teuer kontinuierlich bei meinem Blog nachfragen (wie es die Wordpress App tut und dabei sogar scheitert), sondern wird von meinem Blog sofort darüber informiert falls bzw. sobald der Client online ist. Ich habe mir dafür eine Brücke zu GCM gebaut. Ich bekomme inzwischen immer mehr Ideen, wie man diesen Mechanismus für noch ganz andere Anwendungsgebiete erweitern könnte und baue mir gerade einen Service dafür. Er nennt sich Hermodr, aber dazu mehr in einem anderen Artikel.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

BenW

BenW am :

Sehr interessanter Artikel. Zufälliger Weise schreibe ich genau über diese Problematik meine Diplomarbeit.

BenW

BenW am :

Ich beabsichtige bis Ende November abzugeben. Werde dir dann nen Link zum Download zukommen lassen.

onli

onli am :

Pubsubhubub wollte ich ja per Plugin in s9y nachrüsten. Zweimal. Kam aber jeweils an den Punkt, dass es hätte funktionieren müssen, aber nichts bewirkte. Frustrierend.

Dokumentation und Beispielclient von Google waren damals aber auch in einem miserablen Zustand, was das Testen nicht einfacher machte.

Grischa

Grischa am :

Hmm.. Ich bin noch nicht so weit für Tests, aber irgendwie muss das doch gehen.

Ich schaue dann mal, ich hoffe, man kommt inzwischen etwas weiter. Ich vermute, seit Deinen Versuchen ist ein wenig Zeit vergangen?

Welchen Hub hattest Du eigentlich benutzt? Den von Google, Superfeeder oder einen Testhub?

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Dieses Blog erlaubt Dir, Audio Kommentare über audioboo.fm hinzuzufügen. Erstelle einen neuen Boo und gib hier den Link auf die Seite Deines Boos ein.
record
Wenn Du Deinen Twitter Namen eingibst wird Deine Timeline in Deinem Kommentar verlinkt.
Bewirb einen Deiner letzten Artikel
Dieses Blog erlaubt Dir mit Deinem Kommentar einen Deiner letzten Artikel zu bewerben. Bitte gib Deine Blog URL als Homepage ein, dann wird eine Auswahl erscheinen, in der Du einen Artikel auswählen kannst. (Javascript erforderlich)
(Bedingung: 1 Kommentare geschrieben)
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
tweetbackcheck