pgriess/node-websocket-client

A Web Socket client for NodeJS

node-websocket-client's Issues

If close() isn't passed a timeout, finishClose is never called and the socket isn't cleaned up

In close():

        if (timeout) {
            setTimeout(finishClose, timeout * 1000);
        }

Currently if you don't pass a timeout to close, finishClose is never called, and the socket is never cleaned up.

Maybe something like this would be appropriate:

        if (timeout) {
            setTimeout(finishClose, timeout * 1000);
        } else {
            finishClose();
        }

... or maybe a have a default value for timeout?

typo in usage

Hey,
I think you have a typo in your USAGE section of the readme.

var WebSocket = require('websocket').WebSocket;

Should probably be

var WebSocket = require('websocket-client').WebSocket;

Right?

targetStart out of bounds [websocket.js:246]

I get errors with websocket-client (as used in node-webworker) using node v0.1.100 on darwin. Using this test code http://gist.github.com/473964 and sending a request like

curl http://localhost:8000 --data '{"params": [1,2], "id": 1}'

I often (but not always) get

$ node master.js 
debugger listening on port 1025
targetStart out of bounds [/usr/local/node/lib/node/websocket-client/websocket.js:246]

Also connecting with d8 to the debug port, seems to more reliably cause this problem to appear. But this is only a correlation.

npm install websocket-client fails

$ npm install websocket-client

npm info it worked if it ends with ok
npm info using [email protected]
npm info using [email protected]
npm info fetch http://registry.npmjs.org/websocket-client/-/websocket-client-1.0.0.tgz
npm info calculating sha1 /tmp/npm-1299525208549/1299525208549-0.2477872739546001/tmp.tgz
npm info shasum f8727a2756b2324d1fd1b71e4db4c98a77007cda
npm ERR! Failed unpacking the tarball.
npm ERR! This is very rare. Perhaps the 'gzip' or 'tar' configs
npm ERR! are set improperly?
npm ERR!
npm ERR! couldn't unpack /tmp/npm-1299525208549/1299525208549-0.2477872739546001/tmp.tgz to /tmp/npm-1299525208549/1299525208549-0.2477872739546001/contents
npm ERR! Error installing [email protected]
npm ERR! Error: Failed tar "-vxpf" "-" "-C" "/tmp/npm-1299525208549/1299525208549-0.2477872739546001/contents"
npm ERR! exited with 2
npm ERR! at ChildProcess. (/usr/local/lib/node/.npm/npm/0.2.19/package/lib/utils/exec.js:48:8)
npm ERR! at ChildProcess.emit (events.js:45:17)
npm ERR! at ChildProcess.onexit (child_process.js:171:12)
npm ERR! Report this entire log at http://github.com/isaacs/npm/issues
npm ERR! or email it to [email protected]
npm ERR! Just tweeting a tiny part of the error will not be helpful.
npm not ok

`websocket` not found

The code in readme throws

websocket not found for the require call.

Doesn't work with Node 0.6

This library seems broken with Node 0.6. The issue, I think, is that http.createClient is deprecated (it no longer is in the docs at least.) Switching the code over to use http.request seems to fix this issue. I've fixed this in socket.io-client here:

https://github.com/tristanz/socket.io-client

[HTTP Parser] Parse error on https://myopenid.com

var openSite = http.createClient(443, 'www.myopenid.com', true);
var req = openSite.request('GET', '/signin_password', {'host': 'www.myopenid.com'});
req.end();

Parse Error
Error: Parse Error
at Client.onData as ondata
at Client._onReadable (net.js:573:27)
at IOWatcher.onReadable (net.js:156:10)

As far as I know the http.createClient() API is deprecated and only exists for legacy support and backwards compatibility. Can you try the following code using the new http.request() API and see if you can reproduce the issue?

nodejs/node-v0.x-archive#504

npm repository tarball does not work with gnu-tar

npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keyword LIBARCHIVE.creationtime' npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keywordSCHILY.dev'
npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keyword SCHILY.ino' npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keywordSCHILY.nlink'
npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keyword SCHILY.dev' npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keywordSCHILY.ino'
npm ERR! tar "-mvxpf" "-" "-o" "-C" "/tmp/npm-1320713133858/1320713133967-0.6399423768743873/contents/___package.npm" tar: Ignoring unknown extended header keyword `SCHILY.nlink'

Typically, this happens when the tarball has been built on MacOS, which runs bsdtar by default. Installing gnu-tar on mac and preferentially using that addresses the issue, as does building on a linux box. eg, "brew install gnu-tar; rm /usr/bin/tar; ln -s which gtar /usr/bin/tar"

Latest release of nodejs (0.5.8) - Does not work at all

Hey,

This lib does not work at all on the latest version of nodejs (0.5.8).

I know it work well on the 0.4.8 version of nodejs.

Do anybody have an idea of what can be the problem ?

Alain

Expose underlying net.Stream

I think this would be really useful for certain testing scenarios.

Proper implementation of an auto-reconnect?

When a web socket is closed, what's the proper implementation (from a client perspective, not a server) for auto-reconnecting? My thought is something like this, but I wondered if it's too naive, and whether there are any pitfalls I should be aware of.

        connection.on('close', function() {
            reconnect = setInterval(function() {
                // Standard stuff for opening a new WebSocketClient connection
                clearInterval(reconnect);
            }, 1000);
        }); 

Any insights for me? Thanks.

hi^^ wss support?

    switch (getUrlScheme(url)) {
    case 'ws':
        var u = urllib.parse(url);

case 'wss' => where??.

thanks

Origin header required

Wasn't specified, so I added it. Was breaking http://socket.io when trying to connect.

Spec reference: http://en.wikipedia.org/wiki/WebSockets

Patch: http://github.com/qrush/node-websocket-client/commit/5c770af101e324b9acf41896354c404e408c5ac3

can't decode onmessage

When I get called back with the onmessage event, and I do JSON.parse(msg), I get this:

SyntaxError: Unexpected token ILLEGAL
    at Object.parse (native)

But I can JSON.parse what you return in the data callback just fine. odd.

http.createClient is not a function

Error within lib/websocket.js itself.

Node.js: v7.6.0
NPM: 4.1.2

httpClient = http.createClient(u.port || 80, u.hostname);
TypeError: http.createClient is not a function

Optimize debug() calls for performance boost

There are a few debug() calls in websocket.js that really slowed down our application. We have a high throughput of packets, and it turns out that sys.inspect() consumed almost 90% of the CPU time, which could be pinpointed down to these debug() calls.

Example:

debug('dataListener(' + sys.inspect(buf) + ')');

When we commented out these (for us) unnecessary calls, performance was substantially increased. I suppose you could create something like debugBuffer() and send buf as the argument. Inside the function you would then check the debug level before calling sys.inspect().

Client should detect closing frame and close the connection (not crash)

As per http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76, the client should detect the closing frame sequence of bytes, 0xFF followed by 0x00, and close the connection.

Currently however, the client crashes when receiving the closing frame with the error "High-byte frames not yet supported". Tested with https://github.com/miksago/node-websocket-server.

Optional graceful close specified by WebSocket constructor

It seems that nobody implements graceful close on the server.

We should default to non-graceful close (i.e. sever the TCP connection), but allow clients to specify that they wish for graceful close using an option in the WebSocket constructor.