sitegui / nodejs-websocket

A node.js module for websocket server and client

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

The client doesn't recognise server response when the text from the server is immediate

nnseva opened this issue · comments

I've tried to implement some simple scenario when the server sends some text to the client immediately after the connection.

The (simplified) server looks like:

var ws = require("nodejs-websocket");
var wserver = ws.createServer(function (conn) {
    console.log("New connection");
    setTimeout(function(){
        conn.sendText(JSON.stringify({
            type:'hello'
        }));
    },0);
    conn.on("close", function (code, reason) {
        console.log("Connection closed");
    })
})

wserver.listen(8001);

The (simplified) client looks like:

var ws = require("nodejs-websocket");

var conn = ws.connect("ws:127.0.0.1:8001",function() {
    console.log("New connection");

    conn.on("close", function (code, reason) {
        console.log("Connection closed")
    })
    conn.on("error", function (err) {
        console.log("Connection ERROR!",err)
    })
});

When the first client connects to the server it looks fine, the client prints "New connection"

But when the second (and all following) client connects to the server, the client doesn't recognise a connection readyness (i.e. doesn't print "New connection" message).

The server recognises and reports the both connections.
The network traffic grabbed by the wireshark looks the same (except security cookies).

The only difference is a time between last server handshake packet and the text packet sent from the server after the handshake.

To check the problem, I've tried two cases:

  1. I've removed immediate text send from the server code. The bug disappeared.
  2. I've changed timeout from 0 to 100 to delay a text send. The bug disappeared.

From my point of view it might be caused by some inconsistency in the client code, when the client doesn't separate a server handshake packet from the next packet if it follows immediately to the last websockets handshake packet and concatenated by the TCP layer to one piece of data sent to the user layer.

I've changed the timeout in a sample server to 0 - this value causes a bug, while value of 100 makes a bug disappear.

Hi @nnseva ,
thank you for pointing this out.

After a while I managed to reproduce this in my environment.
The problem seems to be caused by a websocket frame right after the handshake answer.
This part of the code reads the handshake response and, the way it was implemented, it assumes that the handshake data will end in \r\n\r\n.

This is not true when the handshake response is concatenated with more data:

HTTP/1.1 101 Switching Protocols[\r\n]
Upgrade: websocket[\r\n]
Connection: Upgrade[\r\n]
Sec-WebSocket-Accept: x9BBXCEEJkN4qlGLjNp/w+d8Sew=[\r\n]
[\r\n]
\x81\x10{"type":"hello"}

I'll publish more info on this soon,
Regards

@nnseva , could you please check if the bug is fixed in master and ping back here?

Thank you for your time,
Gui

Yes, the new version of the code works fine on my environment in these circumstances. Thank you.