ws is a simple to use, blazing fast, and thoroughly tested WebSocket client and server implementation.
Passes the quite extensive Autobahn test suite: server, client.
Note: This module does not work in the browser. The client in the docs is a reference to a back end with the role of a client in the WebSocket communication. Browser clients must use the native WebSocket object. To make the same code work seamlessly on Node.js and the browser, you can use one of the many wrappers available on npm, like isomorphic-ws.
There are 2 optional modules that can be installed along side with the ws module. These modules are binary addons which improve certain operations. Prebuilt binaries are available for the most popular platforms so you don't necessarily need to have a C++ compiler installed on your machine.
npm install --save-optional bufferutil: Allows to efficiently perform operations such as masking and unmasking the data payload of the WebSocket frames.
npm install --save-optional utf-8-validate: Allows to efficiently check if a message contains valid UTF-8 as required by the spec.
API docs
See /doc/ws.md for Node.js-like docs for the ws classes.
WebSocket compression
ws supports the permessage-deflate extension which enables the client and server to negotiate a compression algorithm and its parameters, and then selectively apply it to the data payloads of each WebSocket message.
The extension is disabled by default on the server and enabled by default on the client. It adds a significant overhead in terms of performance and memory consumption so we suggest to enable it only if it is really needed.
Note that Node.js has a variety of issues with high-performance compression, where increased concurrency, especially on Linux, can lead to catastrophic memory fragmentation and slow performance. If you intend to use permessage-deflate in production, it is worthwhile to set up a test representative of your workload and ensure Node.js/zlib will handle it with acceptable performance and memory usage.
Tuning of permessage-deflate can be done via the options defined below. You can also use zlibDeflateOptions and zlibInflateOptions, which is passed directly into the creation of raw deflate/inflate streams.
constWebSocket=require('ws');constwss=newWebSocket.Server({ port:8080, perMessageDeflate: { zlibDeflateOptions: { // See zlib defaults. chunkSize:1024, memLevel:7, level:3, }, zlibInflateOptions: { chunkSize:10*1024 },// Other options settable: clientNoContextTakeover:true,// Defaults to negotiated value. serverNoContextTakeover:true,// Defaults to negotiated value. clientMaxWindowBits:10,// Defaults to negotiated value. serverMaxWindowBits:10,// Defaults to negotiated value.// Below options specified as default values. concurrencyLimit:10,// Limits zlib concurrency for perf. threshold:1024,// Size (in bytes) below which messages// should not be compressed. }});
The client will only use the extension if it is supported and enabled on the server. To always disable the extension on the client set the perMessageDeflate option to false.
constWebSocket=require('ws');constws=newWebSocket('ws://www.host.com/path');ws.on('open',functionopen() {constarray=newFloat32Array(5);for (var i =0; i <array.length; ++i) { array[i] = i /2; }ws.send(array);});
For a full example with a browser client communicating with a ws server, see the examples folder.
Otherwise, see the test cases.
Error handling best practices
// If the WebSocket is closed before the following send is attemptedws.send('something');// Errors (both immediate and async write errors) can be detected in an optional// callback. The callback is also the only way of being notified that data has// actually been sent.ws.send('something',functionack(error) {// If error is not defined, the send has been completed, otherwise the error// object will indicate what failed.});// Immediate errors can also be handled with `try...catch`, but **note** that// since sends are inherently asynchronous, socket write failures will *not* be// captured when this technique is used.try { ws.send('something'); }catch (e) { /* handle error */ }
FAQ
How to get the IP address of the client?
The remote IP address can be obtained from the raw socket.
Sometimes the link between the server and the client can be interrupted in a way that keeps both the server and the client unaware of the broken state of the connection (e.g. when pulling the cord).
In these cases ping messages can be used as a means to verify that the remote endpoint is still responsive.