Wie funktioniert eigentlich „Direct Push“?

Noch vor kurzer Zeit war Microsoft bzw. der Exchange-Server im Verhältnis zum Blackberry-Dienst technisch nahezu in der Steinzeit. Mit der Exchange-Version 2010 (und vor allem dem Servicepack 1) hat sich auf diesem Gebiet einiges geändert. Obwohl die Steuerung von mobilen (Blackberry-)Geräten über den Blackberry-Server nach wie vor unschlagbar ist, konnte Microsoft mit der Weiterentwicklung seiner ActiveSync-Technologie einiges aufholen. Wir wollen an dieser Stelle der Frage nachgehen, wie die von Mircrosoft genutzte Push-Technolgie für einen nahzu Echtzeitabgleich eigentlich technisch funktioniert.

„Direct Push“ nennt Microsoft die Versorgung von mobilen Geräten sobald eine Änderung im Postfach des Benutzers erfolgt. Damit wird es für iPhone, iPad, aber auch für Android- und andere Geräte möglich, eine sofortige Verständigung bei eingehenden Mails (aber auch Kalender- und Kontakteinträgen) zu erhalten. Bedingung dafür ist, dass das mobile Endgerät und die genutzte (Email-)Applikation den aktuellen ActiveSync-Standard unterstützen. Kleiner Tipp am Rande: Prüfen Sie Ihr Programm vor dem Kauf, ob dieses auch tatsächlich eine vollständige Synchronisierung unterstützt. Manche begnügen sich auf den Posteingangsordner. Dazu aber mehr in einem kommenden Beitrag zu ActiveSync.

Wie kommen die Nachrichten aufs Handy?

Viele verstehen unter „Push“, dass die Kommunikation vom Exchange-Server ausgeht. Dies besagt ja eigentlich auch der Name. Aber wie weiss dieser, ob das Gerät an und erreichbar ist? Wie können die aktuellen Nachrichten und neuen Termine mit minimalster Verzögerung zugestellt werden, ohne dass der Server ständig versuchen muss das Tablet oder Smartphone zu erreichen? Ein ausschließliche Initiative vom Server aus würde in einer Vielzahl von Fehlversuchen und viel zu hohem und nutzlosem Datenverkehr enden. Die Lösung liegt darin, dass die Initiative vom Client – also dem mobilen Endgerät – ausgeht.

Ein wenig Technik

Die Lösung des Problems liegt in einem Aufbau der Verbindung durch den Empfänger mithilfe einer sogenannten „lang bestehenden Https-Anforderung“. Dies bedeutet, dass das Gerät ein verschlüsseltes Datenpaket an den Server sendet, welches – zum Unterschied von „normalen“ Verbindungsanfragen – eine mehrminütige Verfallfrist hat. Während also ein nicht zu erreichender Webserver binnen Sekunden einen Timeout bringt, wartet in diesem Fall der ActiveSync-Client eine kleine Ewigkeit auf eine Antwort vom Server.

Findet dieses Datenpaket den Weg bis zum Server, so wird dieses nicht beantwortet (die Verbindung bleibt offen). Erst bei einer Änderung im Postfach des Anwenders sendet der Server die Aufforderung an den Client, die neuen Elemente abzuholen bzw. zu synchronisieren.
Ein Beispiel: das Smartphone wird eingeschaltet und sendet nach dem Start der ActiveSync-fähigen Anwendung (meist automatisch ohne Usereingriff) dieses ominöse Https-Paket an den Server. Der Exchange-Server nimmt dies als „Aktivierung“ zur Kenntnis – mehr nicht. Jetzt ist es die Aufgabe des Clients diese Verbindung weiter zu beobachten. Erfolgt innerhalb des Zeitrahmens (z.B. erstmal 15 Minuten) kein neuer Maileingang oder sonstige Änderung im Postfach, so sendet der Server seine „leere“ Antwort in Form einer „Http 200 ok“-Response. Er gibt damit dem Client nur zu verstehen, dass alles in Ordnung ist und keine Neuigkeiten vorliegen.

Das Timeout-Problem

Nun gibt es aber nur allzuhäufig den Fall, dass aufgrund unterschiedlichster Umstände die Verbindung zum Server nicht für die gesamten angenommenen 15 Minuten bestehen bleiben (die Ursachen dafür können vielfältigster Natur sein). Ein technisches Problem kann darin bestehen, dass jenes langlebige Https-Paket entweder auf Provider-Seite oder sogar von der Firewall vor dem Exchange-Server als beendet verworfen wurde. In diesem Fall käme auch das Antwortpaket nicht an und somit kein erwünschtes „Ok“ beim Client.
Dieser versucht nun – nach Ablauf der 15-minütigen Wartefrist – einen neuen Aufbau der Verbindung. Diesmal aber mit einem mit einem kürzeren Timeout-Intervall. Die sogenannte Taktfrequenz wird also verkürzt – zum Beispiel auf 8 Minuten. Erfolgt innerhalb dieser Spanne wieder ein „Ok“ des Servers, so wird diese wieder verlängert (auf beispielsweise 12 Minuten). Das Spiel dürfte nun klar sein: in diesem Trial-and-Error-Verfahren wird die beste funktionierende Verbindung eruiert – mit größtmöglicher Taktfrequez um Datenverkehr und Kosten zu sparen.
Die folgende Grafik (aus einem Whitepaper von Microsofts TechNet) zeigt die Kommunikation und deren Varianten:

Anzumerken bleibt, dass der Server mit der Verständigung an den ActiveSync-Client auch die Angabe des veränderten Ordners übermittelt. Damit weiss das Endgerät welche Informationen zu synchronisieren sind.

Aufgaben des Admins

Direct-Push ist per Default im Exchange-Server 2010 aktiviert. Es gibt also wenig zu tun (abgesehen von der Konfiguration der Richtlinien und Zugriffsrechte für ActiveSync). Einzig der Firewall-Administrator muss Sorge tragen, dass Port 433 (Https) von aussen bis zum Exchange-Server (Client-Access-Server) geöffnet ist. Dabei sollte vor allem der Timeout-Wert für Https-Verbindungen zum CAS-Server beobachtet und wenn möglich höhergesetzt werden (30 Minuten). Dies spart Netzwerk-Traffic und dem Smartphone oder Tablet Akkuverbrauch. Letztlich bleibt aber immer die grosse Unbekannte – der Provider. Spielt dieser beim Timeout nicht mit, so helfen auch individuelle Einstellungen nichts.
Wie auch immer: Direct Push ist ein Meilenstein im Zusammenspiel von Exchange-Server und mobilen Geräten.