github

uWebSockets / uWebSockets

  • вторник, 13 сентября 2016 г. в 03:14:19
https://github.com/uWebSockets/uWebSockets

C++
Highly scalable WebSocket server library



µWS is one of the most lightweight, efficient & scalable WebSocket server implementations available. It features an easy-to-use, fully async object-oriented interface and scales to millions of connections using only a fraction of memory compared to the competition. While performance and scalability are two of our top priorities, we consider security, stability and standards compliance paramount. License is zlib/libpng (very permissive & suits commercial applications).

  • Autobahn tests all pass.
  • Linux, OS X & Windows support.
  • Valgrind clean.
  • Built-in load balancing and multi-core scalability.
  • SSL/TLS support & integrates with foreign HTTPS servers.
  • Permessage-deflate built-in.
  • Node.js binding exposed as the well-known ws interface.
  • 10-300x faster than ws (if they are "fastest", we are "fastester").
  • Default engine in SocketCluster & deepstream.io, optional in Socket.IO & Primus.

npm version

Benchmarks table - validate

Implementation User space memory scaling Connection performance Short message throughput Huge message throughput
libwebsockets 2.0 µWS is 11x as lightweight µWS is equal in performance µWS is 6x as performant µWS is 4x in performance
ws v1.1.0 + binary addons µWS is 47x as lightweight µWS is 18x as performant µWS is 33x as performant µWS is 2x as performant
WebSocket++ v0.7.0 µWS is 63x as lightweight µWS is 4x as performant µWS is 3x as performant µWS is 2x as performant
Kaazing Gateway Community 5.0.0 µWS is 62x as lightweight µWS is 15x as performant µWS is 18x as performant unable to measure

Benchmarks are run with default settings in all libraries, except for ws which is run with the native performance addons. These results were achieved with the native C++ server, not the Node.js addon. Expect worse performance and scalability when using Node.js (don't worry, the Node.js addon will run circles around ws).

Built with µWS

deepstream.io SocketCluster wilds.io Crisp.im droppy

Usage

Node.js

We built µWS with the existing Node.js infrastructure in mind. That's why we target the widespread ws interface, allowing us to seamlessly integrate with projects like SocketCluster, deepstream.io, Socket.IO & Primus.

There are some important incompatibilities with ws though, we aim to be ~90% compatible but will never implement behavior that is deemed too inefficient:

  • Binary data is passed zero-copy as an ArrayBuffer. This means you need to copy it to keep it past the callback. It also means you need to convert it with Buffer.from(message) if you expect a Node.js Buffer.
  • webSocket._socket is not a net.Socket, it is just a getter function with very basic functionalities.
  • webSocket._socket.remote... might fail, you need to cache it at connection.
  • webSocket acts like an EventEmitter with one listener per event maximum.
  • webSocket.upgradeReq is very limited and only holds commonly accessed data.
SocketCluster

µWS is the default engine in SocketCluster as of 5.0.0.

deepstream.io

µWS is the default engine in deepstream.io as of 1.0.0.

Socket.IO

Use the new wsEngine: 'uws' option like so:

var io = require('socket.io')(80, { wsEngine: 'uws' });

This option has not yet been released, one alternative way of enabling uws in current versions of Socket.IO is:

var io = require('socket.io')(80);
io.engine.ws = new (require('uws').Server)({
    noServer: true,
    perMessageDeflate: false
});
Primus

Set 'uws' as transformer:

var primus = new Primus(server, { transformer: 'uws' });
ws

If your code directly relies on ws you can simply swap require('ws') with require('uws'):

var WebSocketServer = require('uws').Server;
var wss = new WebSocketServer({ port: 8080 });

wss.on('connection', function (ws) {
    ws.on('message', function (message) {
        console.log('received: ' + message);
    });

    ws.send('something');
});

C++

For maximum performance and memory scaling the native interface is recommended. Look in the examples folder for threading and load balancing examples. There is no documentation written yet but a bright person like you will have no problem just reading the header file.

int main()
{
    /* this is an echo server that properly passes every supported Autobahn test */
    int connections = 0;
    uWS::EventSystem es(uWS::MASTER);
    uWS::Server server(es, 3000);
    server.onConnection([&](uWS::WebSocket socket) {
        std::cout << "[Connection] clients: " << ++connections << std::endl;
    });

    server.onMessage([](uWS::WebSocket socket, char *message, size_t length, uWS::OpCode opCode) {
        socket.send(message, length, opCode);
    });

    server.onDisconnection([&](uWS::WebSocket socket, int code, char *message, size_t length) {
        std::cout << "[Disconnection] clients: " << --connections << std::endl;
    });

    es.run();
}

Quality control

  • Valgrind clean.
  • Autobahn tests all pass.
  • All Primus transformer integration tests pass.
  • All Engine.IO server tests pass.
  • Small & efficient code base.

Installation

Node.js developers

  • Node.js 4.x, 5.x & 6.x supported
  • Linux, Mac OS X & Windows supported

Windows version requires Node.js 6.4.0+

C++ developers

Dependencies

First of all you need to install the required dependencies. On Unix systems this is typically done via package managers, like homebrew in the case of OS X or dnf in the case of Fedora Linux. On Windows you need to search the web for pre-compiled binaries or simply compile the dependencies yourself.

  • libuv 1.x
  • OpenSSL 1.0.x
  • zlib 1.x
  • CMake 3.x

Compilation

Obviously you will need to clone this repo to get the sources. We use CMake as build system.

  • git clone https://github.com/alexhultman/uWebSockets.git && cd uWebSockets
  • cmake .

Now, on Unix systems it should work by simply running make. Run [sudo] make install as you wish.

Windows, in all its glory

If you are running Windows you should now have a bunch of Visual Studio project files and one solution file. Open the solution file, now you need to make sure the header include paths and library paths are all set according to where you installed the dependencies. You might also need to change the names of the libraries being linked against, all according to the names of the installed library files. You know the drill.