AirPlay stinkt
Aus einem Forum us-amerkanischer Universitätsadministratoren zu Bonjour (Grundlage von AirPlay) und Multicastprotokollen im Allgemeinen. In den Vereinigten Staaten gibt es schon mehrere Jahre Erfahrungen mit Appleprodukten in großen Netzen, Deutschland steht da noch am Anfang:
- Broadcast traffic and performance are mortal enemies. Supporting a few users who want to do iPad mirroring, for example could end up penalizing productivity for a large number of users who do not participate.
- Will need to support a single subnet spanning your entire infrastructure, for both wired and wireless devices.
- No troubleshooting mechanism or tools to help determine connectivity issues.
- No centralized monitoring, management of such devices like number of devices online, number of devices connected, quality of service provided, etc.
- No centralized admission control for those devices – If you wanted to only allow certain people to be able to connect/disconnect, you could not do that
- Little Security – Any device on the same subnet can enumerate all devices. Anyone with physical access to a device can easily pair and control the device fairly quickly.
- As the number of Airplay-compatible devices increases on the network, it will be more and more difficult for users to find and connect to their own devices, as the list gets longer. It will be only a matter of time where a naming convention for iDevices will have to be managed for those users, and it probably would be assigned to an fte in IT to do so.
- If a user decides to consume an inordinate amount of bandwidth using an application such as video, there is no easy way to immediately identify that user and constrict it on the fly.
http://www.networkcomputing.com/wireless/academia-to-apple-fix-your-airplay-wirel/240003500
https://discussions.apple.com/thread/3538172?start=0&tstart=0
Etwas ausholen
Zunächst einmal der Versuch zu erklären, was das Problem an Multicastprotokollen wie AirPlay (und übrigens auch DLNA) ist. Man kann sich ein Netzwerk vereinfacht als Postkartenverteilungssystem vorstellen (Netzwerktechniker verzeihen das etwas kranke Bild).
Bei Unicast tauschen Sender und Empfänger miteinander Postkarten aus. Der Switch erkennt an Aufklebern auf den Postkarten, wo er sie hinschicken muss. Jede Postkarte kommt genau dahin, wo sie einen Sinn hat.
Bei Multicast klebt ein Sender folgenden Aufkleber auf die Postkarten: „An alle Haushalte mit Tagespost“. Für Tagespost muss sich jeder Empfänger explizit anmelden und bekommt dann alle Postkarten mit diesem Aufkleber – ob sie etwas nützen oder nicht. Zudem schicken alle Multicastempfänger phrophylaktisch immer wieder die generelle Nachricht ind Netzwerk, dass sie gerne Tagespost hätten. Diese Tagesportstruktur baut sich in großen Netzen erst nach und nach auf. Der Switch kopiert die Tagespostpostkarten für jeden Empfänger, der signalisiert, dass er sie gerne hätte und schickt sie auch dahin.
Was bei zwei Empfängern noch prima klappt, kann bei vielen Empfängern zum Problem werden, da ein Großteil der Kapazität des Netzes hinter einem Switch dann irgendwann durch Tagespost verstopft ist – wie der heimische Briefkasten zu Hause. Außerdem klagt der Briefträger zwischen dem Sender und dem Switch bald über Rückenschmerzen und macht seine Arbeit nur noch, so gut es eben geht – zudem haben hat für ihn Tagespost nicht unbedingt Vorrang vor „richtiger“ Post und er fängt an, Tagespost in die Botanik zu werfen.
Typische Probleme mit AirPlay
Daher gibt es mit AirPlay in großen Netzen sehr typische Probleme (mit DLNA eher weniger, aber das ist eine andere Geschichte):
- Die Geräte finden sich anfangs nicht (die Multicaststruktur ist von den Switchen noch nicht aufgebaut)
- Die Wiedergabe stockt (das gesamte von Multicast betroffene Netzsegment ist überlastet von Tagespost)
- Die Geräte finden sich nach einer Weile nicht mehr (der Briefträger wirft aus Verzweiflung Tagespost in die Botanik)
Nichts davon ist durch den Nutzer oder dem Administrator in irgendeiner Form beeinflussbar! Damit erkauft man sich die Bequemlichkeit von AirPlay.
Und jetzt die Übersetzung der obigen Forenauszuges:
-
Tagespost und Performance sind tödliche Feinde. Wenn man wenigen iPad-Usern die Möglichkeit gibt, ihre Anzeigen zu spiegeln, sind davon viele Unbeteiligte im gleichen Netzsegment betroffen.
-
Man muss die Netzsegmente, die für Multicast genutzt werden sollen, möglichst klein halten, sowohl für WLAN- als auch für LAN-betriebene Geräte
-
Es gibt keine Tools, um Verbindungsprobleme zwischen Geräten einzugrenzen
-
Man kann Tagespost nicht zentral überwachen, um hinsichtlich von z.B. Performanceproblemen zu optimieren
-
Man kann den Zugriff auf Tagespost nicht nutzer- oder rechtebezogen steuern
-
Es gibt keine Sicherheitsmechanismen. Das letzte Gerät gewinnt immer.
-
Je mehr Geräte sich im gleichen Netzwerk befinden, desto länger wird die Liste für die möglichen Anzeigegeräte. Orientierende Namenskonventionen sind für Privatgeräte nicht sinnvoll durchsetzbar.
-
Wenn ein Benutzer viel Bandbreite für sich beansprucht, gibt es keinen Weg, das Problem näher zu lokalisieren.
Also bei mir in der Klasse klappt das doch wunderbar!
Ja! Es klappt auch im Wohnzimmer zu Hause. Die meisten Lehrkräfte spannen für die Arbeit mit AirPlay ein eigenes Netz im Klassenraum auf, z.B. durch einen AirPort-Extreme (jeder andere Dualbandrouter würde es übrigens auch tun). Router transportieren im Gegensatz zu Switchen keine Tagespost in ein anderes Netz.
Ziel sollte aber doch sein, dass das nicht die Lehrkraft, sondern ein Technologiepartner tut. Viele Subnetze sind wiederum wartungsaufwändig und stehen dem Anspruch einer kostengünstigen, zentralen Wartung diametral entgegen.
Wenn ich die Aufgabe bekäme, für eine ganze Schule oder auch nur einen Gebäudeteil, AirPlay zerverlässig zu garantieren, müsste ich sehr teure Geräte und viel Wartungsaufwand projektieren. Denn es wird auch in kleinen Netzen immer mal wieder spontan „nicht gehen“ – das ist bandbreitenabhängig. Da es keine Fehlerdiagnosemöglichkeit gibt, ist Fehlerbehebung nur wie zu guten, alten Windowszeiten nur per Pass&Fail möglich.
Besser wäre aus Administratorensicht eine Weiterentwicklung des AirPlayprotokolls, sodass es auch für Enterpriseumgebungen taugt. Ich als Adminsistrator bekomme nämlich jetzt im Fehlerfall die Anforderung „Geht nicht (ist ja dein blödes Netz, vorher/zu Hause ging’s ja immer!), mach’s heil, Maik!“ Ich habe bei Multicast jedoch kein Analyseinstrument zur Verfügung, kann also höchstens Stecker rein- und rausziehen und würde am liebsten antworten: „Kann ich nicht, selbst wenn ich es wollte, weil du ein dämliches, verschwenderisches Wohnzimmerprotokoll verwendest, AirPlay stinkt eben!“
Hallo,
ist nicht ein Tril der Probleme mit dem letzten Update behoben?
So kann man Passwörter setzen, die den Geräten auf dem aktuellen Display angezeigt werden, die Paarung kann jetzt auch über Bluetooth erfolgen und über den Gerätemanager kann man doch auch zugelassene MacAdressen eingeben…
Die Problematik mit dem Traffic bleibt da natürlich.…
> Die Problematik mit dem Traffic bleibt da natürlich….
Yupp. Mir gent es auch nicht um das Szenario „ambitionierte Lehrkraft stellt in ihrem Klassenraum AirPlay mit dem eigenen Gerät zur Verfügung“, sondern mehr um die Vision „alle Klassenräume einer Schule nutzen AirPlay“ – da wollen wir ja hin. Und die Lösung ist ja eindeutig die etwas aufwendigere netzwerktechnische Kapselung durch Routing.
Ich fürchte aber, dass die von dir beschriebenen Features von einem Großteil der Lehrkräfte nicht genutzt werden werden. Für Bluetooth musst du ja z.B. die Verbindungsart explizit auswählen. MAC-Adresse, was ist eine MAC-Adresse :o)…? Du musst dabei dem Gerät vertrauen, nicht dem Benutzer. Wie managed man die AppleTVs zentral (ich würde da momentan eher die minix-Variante wählen)? Alles, wofür ich mich vor ein Gerät setzen muss, ist in großen Netzen kaum beherrschbar – man läuft ja nicht von Raum zu Raum, um Passwörter oder MAC-Adressen nachzupflegen … Und Standardpasswörter sind keine Passwörter.