Ich habe gimite / web-socket-js verwendet, um ein WebSocket einfach in Chrome und Entwicklung zu implementieren Builds von Safari. Ich möchte vom Ruby-Server weg und auf Node.js gehen. Plötzlich funktioniert es in nichts außer Chrome.
Ich vermute, dass dies mit der Flash Socket Policy -Datei zu tun hat, die ich implementieren muss. Ich möchte das als externen Node.js-Prozess implementieren, um nicht mit der ursprünglichen Anwendung zu verschmutzen. Ich benutze den node-websocket-server , um das WebSocket-Protokoll mit Node.js zu implementieren, und wieder würde ich es bevorzugen nicht auch nicht damit.
Es schien so, als wäre es am einfachsten, flashsocket.js , aber das Ausführen gibt mir den folgenden Fehler:
%Vor%Hier stoßen wir auf die schönen kryptischen Fehler, für die Node.js geliebt wird.
Meine Frage ist, gibt es einen eigenständigen globalen Flash-Socket-Policy-Server, den ich entweder von Node.js oder einer anderen Anwendung ausführen kann? Mein Verständnis ist, dass ich es nur auf Port 843 haben muss. Oder gibt es eine andere WebSocket-Bibliothek für Node.js, die mit der Flash-Policy wie der Ruby-Server umgehen wird?
Mit ein wenig Hilfe von der Node.js Mailingliste habe ich folgendes gefunden:
%Vor%Ich habe auch ein (kurzes) Tutorial für WebSockets-Anwendungen mit Flash Sockets .
Flash-Richtlinienanforderungen können auch inline am selben Port wie der von Ihnen bereitgestellte WebSockets-Service beantwortet werden. Siehe diese Änderung zum Socket.IO-Modul node.js. Es fügt eine Verbindung zu dem Server hinzu, der Anforderungen des Richtlinienservers auf demselben Port beantwortet. Auf diese Weise müssen Sie auf Port 843 (der normalerweise root-Rechte erfordert) nichts ausführen.
Alternativ können Sie auch einen sehr einfachen (zweizeiligen) Richtlinienanforderungsserver mit socat ausführen (vorausgesetzt, Sie befinden sich in einem * nix-System): Ссылка
Aktualisieren (Antwort auf @Josh K):
Es ist ein häufiges Missverständnis, dass der Port 843 der primäre Speicherort für Flash-Policy-Anforderungen ist und dass Requests für denselben Port ein Fallback sind und dass sie aufgrund von Timeouts langsamer sind. Dies beruht wahrscheinlich auf dem allgemein genannten Ссылка und auch weil die Dokumentation von Adobe schwer zu finden ist (und gelesen wird). Hier ist die Adobe-Dokumentation zu ihrer Sicherheitsrichtlinie: Ссылка
In Wirklichkeit hat Port 843 einen etwas
Der Timeout von 3 Sekunden gilt nur für den Fall, dass Verbindungen zu Port 843 stillgelegt werden. Sie gilt nicht für den Fall, dass ein anderer Dienst auf Port 843 läuft oder die Verbindung zurückgewiesen wird (d. H. TCP-Reset). Ich benutze den gleichen Port die ganze Zeit und es gibt keine wahrnehmbare Verzögerung nur mit dem gleichen Port Policy Server.
Bei einem WebSocket-Server besteht ein weiterer Vorteil der Richtlinienantwort für denselben Port darin, dass Sie die Konfiguration der Ursprungsrichtlinie leichter zwischen der Flash-Richtlinie und dem WebSockets-Handshake koordinieren können.
Es ist besser, die Listener von Stream zu überschreiben (Listener des Sockets). Andernfalls stürzt Ihr Server ab, wenn Sie einen Fehler haben wie:
ECONNRESET, Verbindung durch Peer zurückgesetzt
Beispiel einer Implementierung, um es zu verhindern:
%Vor%Siehe Dokumentation unter: Ссылка (at "net.Stream")