> Ja, der ClientRequest stollte in 'socket.request' stehen, so ich das denn richtig verstehe. > Aber 'socket.response' ist anscheinend nicht definiert, an dieser Stelle antwortet der Server auch noch garnicht. Ich bin da etwas verwirrt. [Und die Doku hilft mir auch gerade nicht weiter.] Also du hantierst mit zwei verschiedenen Protokollen: HTTP und WebSocket. HTTP ist zustandslos, das heißt jeder Request/Response-Zyklus ist unabhängig von den vorherigen und nachfolgenden Zykeln. Wenn man sich zwischen diesen Zykeln etwas über den Kommunikations-Verlauf zwischen Browser und Server merken will, dann speichert man die nötigen Informationen auf dem Server und sendet dem Browser eine eindeutige Kennung, mit der er sich wieder ausweisen kann. Diese eindeutige Kennung nennt man SessionId und benutzt einen Coookie, um sie über mehrere Request/Response-Zykel zu transportieren. WebSocket dagegen ist ein zustandsbehaftetes Protokoll, da ist dieser Umweg über den Cookie nicht nötig: Die Gesprächspartner wissen für die gesamte Lebensdauer der Kommunikation, wer ihr Gesprächspartner ist. Die Kommunikation wird nicht automatisch nach einem Request/Reponse-Zyklus beendet, sondern läuft weiter bis einer der Gesprächspartner sie ausdrücklich für beendet erklärt. Mit anderen Worten ausgedrückt, managt WebSocket die Session automatisch, bei HTTP muss der Anwendungsentwickler sie selber managen. Ein klares Verständnis für den Unterschied von zustandslosen und zustandsbehafteten Kommunikations-Protokollen ist unabdingbar, wenn du mit beiden Protokollen arbeitest, weil du sonst versuchst Konzepte vom einen in das andere Protokoll zu übertragen, die es dort nicht gibt oder braucht.

> Ja, der ClientRequest stollte in 'socket.request' stehen, so ich das denn richtig verstehe. > Aber 'socket.response' ist anscheinend nicht definiert, an dieser Stelle antwortet der Server auch noch garnicht. Ich bin da etwas verwirrt. [Und die Doku hilft mir auch gerade nicht weiter.] Also du hantierst mit zwei verschiedenen Protokollen: HTTP und WebSocket. HTTP ist zustandslos, das heißt jeder Request/Response-Zyklus ist unabhängig von den vorherigen und nachfolgenden Zykeln. Wenn man sich zwischen diesen Zykeln etwas über den Kommunikations-Verlauf zwischen Browser und Server merken will, dann speichert man die nötigen Informationen auf dem Server und sendet dem Browser eine eindeutige Kennung, mit der er sich wieder ausweisen kann. Diese eindeutige Kennung nennt man SessionId und benutzt einen Coookie, um sie über mehrere Request/Response-Zykel zu transportieren. WebSocket dagegen ist ein zustandsbehaftetes Protokoll, da ist dieser Umweg über den Cookie nicht nötig: Die Gesprächspartner wissen für die gesamte Lebensdauer der Kommunikation, wer ihr gesprächspartner ist. Die Kommunikation wird nicht automatisch nach einem Request/Reponse-Zyklus beendet, sondern läuft weiter bis einer der Gesprächspartner sie ausdrücklich für beendet erklärt. Mit anderen Worten ausgedrückt, managt WebSocket die Session automatisch, bei HTTP muss der Anwendungsentwickler sie selber managen. Ein klares Verständnis für den Unterschied von zustandslosen und zustandsbehafteten Kommunikations-Protokollen ist unabdingbar, wenn du mit beiden Protokollen arbeitest, weil du sonst versuchst Konzepte vom einen in das andere Protokoll zu übertragen, die es dort nicht gibt oder braucht.