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.

"Real Time Web für Server" vollständig lesen

GCM: Aktive Benachrichtigung am Android Gerät

Apple hat schon seit je her einen Push Notification Service für die iOS Geräte. Hierbei kann sich ein Service bei Apple anmelden und Nachrichten auf die für diesen Service registrierten Clients pushen. Der Client kann also "schlafen" und wird aktiv informiert, wenn etwas neues passiert. Da iOS Clients keine Hintergrund Tasks ausführen können / dürfen, ist dieser Service sogar ein sehr notwendiger, ansonsten hätte ein Client keine Chance, über Neuigkeiten an einem Service informiert zu werden.

Android Clients haben an dieser Stelle mehr Möglichkeiten "von sich aus". Sie können ohne weiteres Hintergrund Tasks starten und angeben, zu welcher Uhrzeit und in welcher Frequenz diese ausgeführt werden sollen. Android Clients können also selbst nachfragen, ob sich etwas an einem Service getan hat. Ein Push Service war für Android Devices bisher also nicht notwendig. Sie benutzen Pull Requests, um auf dem laufenden zu bleiben.

Push Services haben allerdings in vielen Bereichen einen großen Vorteil: Man muss sich nur einen Messaging Service vorstellen wie ein Chat. Würde der Client hier in einer vorgegebenen Frequenz neues abholen, würde das zum einen heißen, dass er unnötiger Weise immer wieder nachfragt und zum anderen können Neuigkeiten eben nicht sofort sondern nur in der Frequenz der Abfrage eintreffen. Chat artige Programme wie Whatsapp oder auch das IMAP Mail Protokoll müssen somit einen Socket oben halten, um mit einem eigenen Protokoll einen zeitnahen Update zu haben. Der Service hat über diesen Socket also einen "eigenen Push".

Seit kurzem bietet nun aber auch Google einen Push Service für die Android Geräte an, der dem von Apple sehr ähnelt, allerdings technisch (IMHO) etwas ausgereifter ist: Google Cloud Messaging. Auch hier gibt es einen zentralen Google Server, über den sich Services mit ihren Clients verbinden und aktiv an diese Nachrichten verschicken können. Technisch besser ist dieser Service vor allem im Detail:

"GCM: Aktive Benachrichtigung am Android Gerät" vollständig lesen
tweetbackcheck