Hallo Tom

Websockets sind insofern günstiger, da hier eine Serverinstanz die Requests typischerweise einreiht in eine FiFo-Struktur, und daher mehrere Clients bedienen kann. Hier ist als Last an der Schnittstelle im Prinzip nur der reine Bytestream zu spüren.

An den Vorzügen von WebSockets zweifle ich gar nicht. Die gestellte Aufgabe kann damit gelöst werden. Mit Server-Sent Events steht aber eine viel einfachere Methode zur Verfügung, die serverseitig nur ein einfaches PHP-Skript erfordert und keine komplizierte Programmierung oder den Einsatz von Node.js.

Diskussionen über Vor- und Nachteile oder technische Details sind interessant, bringen aber wenig. Aussagekräftig sind letzlich die praktischen Umsetzungen. Die Aufgabe ist klar: Ein Moderator soll von seinem Laptop aus bei ungefähr einem Dutzend Teilnehmer einer Telefonkonferenz deren Bildschirme laufend aktualisieren, ohne dass diese selbst klicken müssen, was erfahrungsgemäss zum Chaos führt.

Selbst Erfahrung habe ich mit sehr ähnlichen Anwendungen mit Ajax, bei einzelnen oder nur wenigen Clients. Das habe ich auch mit Server-Sent Events gelöst, was alles in allem einfacher ist. Das Problem bei Server-Sent Events ist, dass es im IE nicht geht, auch nicht im IE 11, erfordert im Zweifelsfall also einen Ajax-Fallback. WebSockets verwende ich für WebRTC im Rahmen von eLearning.

Noch ein Wort zu Ingrids Vorhaben: Üblicherweise wird das mit bekannter Video-Konferenz-Technik umgesetzt. Sie nannte einen plausiblen Grund, das nicht zu tun. Ich würde trotzdem die Übertragung mit der Webcam machen, der Moderator kann dabei seinen Screen auf die Kamera schalten. Beim Videostream gäbe es die ganze Problematik nicht.

Etwas Lektüre.

Mit besten Grüssen
Richard