Was passiert wenn man Websockets erzwingt?

[nvd126]

Hallo,

ich habe noch nicht ganz verstanden - trotz recherche - was der Unterschied zwischen dem socket.io Adapter ohne Websockets erzwingen zu mit Websockets erzwingen.
Was ändert sich genau an der Kommunikation wenn man das umstellt?
Was muss man so grob ändern wenn man eine funktionierende Kommunikation ohne erzwungene Websockets hat?
Gibt's vor oder Nachteile?

Danke

[BananaJoe]

@nvd126 da würde ich mich anschließen ... ich bin mir gar nicht sicher wofür ich eigentlich dann zusätzlich den socketio Adapter UND den ws installiert habe ...

[MCU]

ChatGPT

Unterschiede Kommunikationsart

• Ohne "Websockets erzwingen" (Standardverhalten von Socket.IO)
  Transportmethoden: Socket.IO verwendet standardmäßig eine Technik namens Long Polling als Fallback, wenn Websockets nicht verfügbar sind. Es versucht, eine permanente Verbindung aufzubauen, aber falls das nicht möglich ist, wechselt es automatisch zu Long Polling.
  Long Polling: Der Client schickt regelmäßig HTTP-Anfragen an den Server, um zu prüfen, ob es neue Daten gibt. Der Server antwortet, sobald Daten vorliegen.
  Websockets: Sobald die Verbindung aufgebaut ist und der Server erkennt, dass der Client Websockets unterstützt, wird automatisch auf Websockets umgestellt.

• Mit "Websockets erzwingen":
  Nur Websockets: Der Server wird ausschließlich Websockets verwenden, und Long Polling wird deaktiviert.
  Der Verbindungsaufbau scheitert, wenn Websockets nicht unterstützt werden oder nicht erfolgreich initialisiert werden können (z. B. durch Firewall, Proxy oder ältere Browser).

Kommunikation

• Ohne Websockets erzwingen:
  Der Verbindungsaufbau ist robuster, da Fallback-Mechanismen verwendet werden.
  Die Kommunikation ist in der Anfangsphase eventuell etwas langsamer, da der Wechsel von Long Polling zu Websockets erfolgen kann.
  Es entstehen zusätzliche HTTP-Anfragen bei der Verwendung von Long Polling, was die Netzwerkbelastung erhöhen kann.

• Mit Websockets erzwingen:
  Der Verbindungsaufbau ist in der Regel schneller, da direkt Websockets verwendet werden (kein Wechsel von Long Polling).
  Es gibt weniger Overhead, da Websockets eine persistente Verbindung aufbauen und bidirektionale Kommunikation ermöglichen.
  Wenn Websockets nicht funktionieren, schlägt die Verbindung komplett fehl.

Vor- und Nachteile

• Vorteile von "Websockets erzwingen":
  Effizienz: Websockets sind ressourcenschonender als Long Polling, da sie eine permanente Verbindung aufrechterhalten.
  Geringere Latenz: Websockets ermöglichen Echtzeitkommunikation ohne zusätzliche Anfragen.
  Klare Architektur: Du kannst sicher sein, dass die Verbindung ausschließlich über Websockets läuft, was Debugging und Fehlerbehebung erleichtert.
• Nachteile von "Websockets erzwingen":
  Weniger robust: Wenn Websockets nicht unterstützt werden oder fehlschlagen (z. B. durch alte Browser oder Netzwerkeinschränkungen), funktioniert die Anwendung nicht.
  Kompatibilitätsprobleme: Bei älteren Browsern oder Netzwerken mit restriktiven Firewalls/Proxys kann es Probleme geben, da diese Websockets blockieren könnten.
• Vorteile ohne "Websockets erzwingen":
  Fallback: Die Anwendung funktioniert auch in eingeschränkten Umgebungen.
  Höhere Robustheit: Selbst wenn Websockets nicht verfügbar sind, bleibt die Kommunikation durch Long Polling gewährleistet.
• Nachteile ohne "Websockets erzwingen":
  Mehr Overhead: Long Polling erzeugt zusätzliche Anfragen und höhere Latenz.
  Komplexität: Das Handling von mehreren Transports kann Debugging erschweren.

[nvd126]

Danke für die Antworten. Ohne Websocket erzwingen scheint es für mich sinnvoller zu sein bzgl. Visualisierung.
Hab nämlich mein Binding-Monster aka Visualisierung aus der Vis raus geholt und eigenständig aufgesetzt und es funktioniert schnell und fehlerfrei.

Hatte gelesen das empfohlen wird nur noch die Websockets zu nutzen. Ist das nur ein Tipp oder weil alles andere später nicht mehr unterstützt wird?