Cloud Messaging

Moderne Instant-Messaging-Protokolle, wie zum Beispiel Jabber, erlauben es bereits mit mehreren Clients gleichzeitig online zu sein. Auch das Problem der durch mehrere Rechner verteilten Nachrichtenhistorie kann mit Tools wie IMPULS, über das wir auch schon berichtet haben, gelöst werden.

Übrig bleibt das Problem, dass eingehende Nachrichten nur bei einem der angemeldeten Clients erscheinen. Bei Jabber ist das der Client mit der höchsten Priorität. Sitzt man gerade an einem der anderen Rechner, hat man Pech und wird über die Nachricht nicht informiert. Auch, wenn man den Rechner wechselt oder der Gesprächspartner an eine bestimmte Ressource schreibt, erfährt man von der Nachricht erst, wenn man genau den Zielclient öffnet.

Es fehlt ein System, bei dem man auf allen angemeldeten Clients jederzeit denselben Zustand vorfindet. Inklusive der aktuellen Nachrichten. Das entspräche auch der Vorstellung des Geprächspartners, der oft gar nicht weiß, welche Infrastruktur man selbst hat und welche Nachricht wo empfangen wird.

Der Begriff “Cloud Messaging” für dieses Konzept ist vom Cloud Computing abgeleitet, bei dem es ja auch darum geht, an jedem beliebigen Ort seine Daten und Applikationen vorfinden zu können. In diesem Fall geht es nicht allgemein um die Berechnung, sondern um Kommunikation, also eine Unterkategorie des Computings.

Es gibt eine einfache Lösung, die ich für ICQ schon lange anwende: Der Client (licq) läuft als Konsolen-Applikation in einer virtuellen Konsole mit screen. Über ssh kann ich mich mit meinem Server verbinden und dann auch auf mein ICQ zugreifen. Die Lösung erfüllt alle oben gemachten Forderungen. Sie hat aber drei Nachteile:

  1. Ich brauche dafür einen Server, auf dem meine Software laufen kann.
  2. Die Hardware, mit der ich zugreife, muss eine entsprechende Konsole darstellen können. Bei einem Handy wird das schon schwierig. Das Benutzerinterface lässt sich nicht an das jeweilige Gerät anpassen.
  3. Da die Kopplung zwischen Applikation und Betriebssystem durch ssh und screen sehr lose ist, können spezielle Mechanismen des Zielgeräts – zum Beispiel das Abspielen eines Sounds bei eingehenden Nachrichten – nicht genutzt werden. Die Integration ist sehr schlecht.

Gerade offene Protokolle mit entsprechenden Client-Bibliotheken laden dazu ein, auf das jeweilige Gerät angepasste Applikationen zu schreiben. Deshalb muss das Cloud Messaging über das Protokoll realisiert werden.

Möglich ist zum Beispiel folgende Lösung: Der Server versendet nicht sofort die Nachrichten, sondern informiert alle Clients über die anstehende Nachricht. Falls sich Clients anmelden, wenn noch wartende Nachrichten vorhanden sind, werden diese ebenfalls informiert. Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde. Effektiv werden damit keine Nachrichten mehr verschickt, sondern Informationen über eine Änderung des Messaging-Zustandes des betroffenen Nutzers. Dieser liegt auf dem Server, wie das auch derzeit mit nicht abgerufenen Nachrichten der Fall ist.

Wenn dieses Konzept auf den Status erweitert wird, ist es außerdem möglich, transparent mit nur einem Gerät zu erscheinen, während man gleichzeitig mit dem Desktop-PC, dem Notebook und dem Handy online ist und die Wahl hat, auf welchem der Geräte man die Nachricht empfangen und die Antwort verfassen möchte.

4 thoughts on “Cloud Messaging

  1. LeSpocky

    Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde.

    Naive Frage: muss an dem Punkt nicht der Nutzer eingreifen? Wie stellst Du Dir das vor?

    Idee 1: ich bin auf drei Rechnern online und habe keine Chatfenster offen. Es kommt eine neue Nachricht, mein Tray-Icon blinkt, ich klicke drauf und habe damit die Nachricht effektiv angenommen.

    Wie ist das nun, wenn ich schon ein Chatfenster offen habe, mich aber an einem anderen Rechner befinde und eine Nachricht eingeht? Bekomme ich dann trotzdem die Benachrichtung im Tray und kann dem Client mit dem offenen Fenster die neue Nachricht wieder wegreißen?

    Reply
  2. Tux

    Die Historie ist sowieso in allen Clients gleich. Wenn zwei Chatfenster offen sind, sollten die also auch das gleiche anzeigen — unabhaengig davon, welcher Client nun signalisiert, dass die Nachricht angenommen wurde.

    Dass man die Nachricht gesehen hat, kann auf unterschiedliche Arten signalisiert werden. Zum Beispiel durch das Klicken auf das Tray-Icon. Oder durch Aktivitaet in einem der Chat-Fenster, was auch ein Hinweis darauf ist, dass man sich anschaut, was passiert ist.

    Das ist ja auch erstmal eine Idee mit Diskussion eines Loesungsvorschlags, kein fertiges technisches Konzept. ;)

    Reply
  3. madcynic

    Die history ist eh in allen Clients gleich, schreibst du. Heißt das dann, du hast irgendwo eine zentral gespeicherte History? Ist das nicht ein Sicherheitsrisiko?

    Reply
  4. Tux

    Das ist genauso ein Sicherheitsrisiko wie ein Mail-Server, Google-Docs oder jede andere Form von gespeicherten Daten. Wie gut man an die Daten herankommt, haengt letztendlich davon ab, wie gut der Storage-Service implementiert ist.

    Ich sehe aber kein direktes Sicherheitsrisiko, das dadurch erzeugt wird, dass ich Daten an einer zentralen Stelle speichere, statt sie lokal abzulegen.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *