unetworking / uwebsockets.js Goto Github PK

SSL, non-SSL, compression, non-compression, dedicated compression, etc

VideoStreamer example should make use of res.onAborted when that is wrapped, to properly abort streaming.

In hammer test, content of the message sent should be checked against the origin.

There are three versions of interest:

• Node.js major version support (10, 11)
• Version of µWS (0.15)
• Version of the wrapper itself

It has move semantics and no memory allocs

Just like the video streamer example we need POST receiving example.

It could make things easier to build and commit binaries automatically.

Testing can then be done on any platform, and if it pass, just bump the version and tag head and be done.

No testing will be done in CI, that takes too long and is hard to debug.

It should only rely on µWS features

Node.js calls beginExit, and we free our app.

Problem is, Node.js can still trigger a timer event after this point and crash at tear-down due to our timer using freed memory:

Exiting now
=================================================================
==22228==ERROR: AddressSanitizer: heap-use-after-free on address 0x6110000174c8 at pc 0x7f2442bf82fc bp 0x7ffdbf7f65b0 sp 0x7ffdbf7f65a0
READ of size 8 at 0x6110000174c8 thread T0
    #0 0x7f2442bf82fb in sweep_timer_cb (/home/alexhultman/uWebSockets.js/dist/uws_linux_64.node+0x1022fb)
    #1 0xa438b4 in uv__run_timers ../deps/uv/src/timer.c:174
    #2 0xa47bab in uv_run ../deps/uv/src/unix/core.c:361
    #3 0x8bea0d in node::Environment::CleanupHandles() (/usr/bin/node+0x8bea0d)
    #4 0x8beda8 in node::Environment::RunCleanup() (/usr/bin/node+0x8beda8)
    #5 0x8e533b in node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::string, std::allocator<std::string> > const&, std::vector<std::string, std::allocator<std::string> > const&) (/usr/bin/node+0x8e533b)
    #6 0x8e34a1 in node::Start(int, char**) (/usr/bin/node+0x8e34a1)
    #7 0x7f245030ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #8 0x89dd44  (/usr/bin/node+0x89dd44)

0x6110000174c8 is located 8 bytes inside of 208-byte region [0x6110000174c0,0x611000017590)
freed by thread T0 here:
    #0 0x7f24517227b8 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xde7b8)
    #1 0x7f2442bd9d7d in void uWS_App_forcefully_free<uWS::TemplatedApp<false> >(v8::FunctionCallbackInfo<v8::Value> const&) (/home/alexhultman/uWebSockets.js/dist/uws_linux_64.node+0xe3d7d)

previously allocated by thread T0 here:
    #0 0x7f2451722b50 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb50)
    #1 0x7f2442bf6ac2 in us_create_child_socket_context (/home/alexhultman/uWebSockets.js/dist/uws_linux_64.node+0x100ac2)
    #2 0x7f2442bd8d41 in void uWS_App_ws<uWS::TemplatedApp<false> >(v8::FunctionCallbackInfo<v8::Value> const&) (/home/alexhultman/uWebSockets.js/dist/uws_linux_64.node+0xe2d41)
    #3 0xb5faee in v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) (/usr/bin/node+0xb5faee)
    #4 0xb60658 in v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) (/usr/bin/node+0xb60658)
    #5 0x7f244305be1c  (<unknown module>)
    #6 0x7f24430118d4  (<unknown module>)
    #7 0x7f24430118d4  (<unknown module>)
    #8 0x7f24430118d4  (<unknown module>)
    #9 0x7f24430118d4  (<unknown module>)
    #10 0x7f24430118d4  (<unknown module>)
    #11 0x7f24430118d4  (<unknown module>)
    #12 0x7f24430118d4  (<unknown module>)
    #13 0x7f24430118d4  (<unknown module>)
    #14 0x7f24430118d4  (<unknown module>)
    #15 0x7f244300ee74  (<unknown module>)
    #16 0x7f24430092c0  (<unknown module>)
    #17 0xe6f612 in v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) (/usr/bin/node+0xe6f612)
    #18 0xafce98 in v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) (/usr/bin/node+0xafce98)
    #19 0x8de029 in node::LoadEnvironment(node::Environment*) (/usr/bin/node+0x8de029)
    #20 0x8e515f in node::Start(v8::Isolate*, node::IsolateData*, std::vector<std::string, std::allocator<std::string> > const&, std::vector<std::string, std::allocator<std::string> > const&) (/usr/bin/node+0x8e515f)
    #21 0x8e34a1 in node::Start(int, char**) (/usr/bin/node+0x8e34a1)
    #22 0x7f245030ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: heap-use-after-free (/home/alexhultman/uWebSockets.js/dist/uws_linux_64.node+0x1022fb) in sweep_timer_cb
Shadow bytes around the buggy address:
  0x0c227fffae40: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fffae50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fffae60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fffae70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c227fffae80: 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa fa
=>0x0c227fffae90: fa fa fa fa fa fa fa fa fd[fd]fd fd fd fd fd fd
  0x0c227fffaea0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c227fffaeb0: fd fd fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c227fffaec0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x0c227fffaed0: fd fd fd fd fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c227fffaee0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==22228==ABORTING

I can still get it to crash at times, over SSL at least. Will need to check into this

If you fail to load the module, it crashes or throws, or behaves strange or breaks down for the simple examples provided, do not report this as a bug to me.

Failing to load is most probably caused by an unofficial Node.js build, not honoring the official ABI versioning of Node.js.

Official builds, running on official platforms (Tier 1), do follow strict ABI rules and will refuse to load mismatching ABIs.

Platforms like Alpine Linux and Node.js builds that are provided by your package manager of your Linux distribution are very likely to disregard official ABI rules of Node.js.

ABI rules are extremely important, it's what makes it possible to run a native program on other machines. Node.js, being a scripting environment, has largely failed to properly enforce an ABI everywhere.

Report start-up crashes to your Linux distribution, do not report them here. It is impossible to ship native code when people do not follow set rules.

If you wish to run on strange platforms and Node.js builds, you'll have to rebuild this project from source, as described in the readme.

Make sure to update to new versions of µWS.js when new major releases of Node.js ship.

Official builds of Node.js can be downloaded here: https://nodejs.org/

If the files from SSLApp setting do not exist in file system

{
    "key_file_name": "misc/key.pem",
    "cert_file_name": "misc/cert.pem",
    "dh_params_file_name": "misc/params.dh"
}

segmentation fault happens

uWebSockets.SSLApp(this.settings);
                          ^
App construction failed
Segmentation fault (core dumped)

app.mjs:

import uWS from 'uWebSockets.js';
import getAuthorization from './getAuthorization';

const { PORT = '8080' } = process.env;

const app = uWS.App();

app.post('/get-authorization', getAuthorization);

app.listen(PORT, (token) => {
  if (token) console.log(`server started on port ${PORT}`);
  else console.log(`server failed to start on port ${PORT}`);
});

getAuthorization.mjs:

import setupCORS from '../setupCORS';

export default (res, req) => {
  // res.writeHeader = res.writeHeader.bind(res); <-- binding solves problem
  setupCORS(res, req);

  res.end('Welcome!');
};

setupCORS.mjs:

export default (res, req) => {
  const origin = req.getHeader('origin');

  res.writeHeader('Access-Control-Allow-Origin', origin); // TypeError: res.writeHeader is not a function
  res.writeHeader('Access-Control-Allow-Credentials', 'true');
};

Windows is far more unstable than Linux version, be aware.

Hey there,

I saw this on Reddit last night and it looks/sounds neat. I'd like to replace socket.io with this in my fastify app but I'm not sure how to do so...the provided example uses this module itself as a server but (obviously), I already have one.

Any pointers?

Server currently shuts down when there is an error, which is not preferable for a robust application.

Also there is no stack trace in error shown, so it is hard to debug.

Enhancement request.

Need a function to get all headers added to the API. Something like the following function.

getHeaders():Dictionary(String: String)

Apollo transforms the request from a standard http req, to a more generic request (with fields such as { method: string, headers: Headers ... }

export declare class Headers implements Iterable<[string, string]> {
  constructor(init?: HeadersInit);

  append(name: string, value: string): void;
  delete(name: string): void;
  get(name: string): string | null;
  has(name: string): boolean;
  set(name: string, value: string): void;

  entries(): Iterator<[string, string]>;
  keys(): Iterator<string>;
  values(): Iterator<[string]>;
  [Symbol.iterator](): Iterator<[string, string]>;
}

more here : https://github.com/apollographql/apollo-server/blob/master/packages/apollo-server-env/src/fetch.d.ts

and that's the transformation function for node standard pkg:
https://github.com/apollographql/apollo-server/blob/master/packages/apollo-server-core/src/nodeHttpToRequest.ts

Tks

It should pass autobahn and have /exit route to gracefully exit once done

I have noticed in the benchmarks in readme that the test ran on single thread.

Rust's actix, Go's fast http and C++ can do multi-thread. Would this implementation for Node allow clustering? or is it something on the roadmap?

Thank you!

Http methods, simple fix now with template

Attaches a socket filter, used to track when a socket opens/closes to help with tracking validity of res internally, and potentially to filter certain IP addresses.

Also needed to track when an App can be destroyed and when it has properly closed every socket.

Three use cases in one function, very much needed feature.

With ASAN enabled, very good indication of memory leaks

Currently we always exit with a libuv assertion. This because loop destruction happens after Node.js wants us to -> fix this by adding some kind of explicit Loop::free wrapper.

It's broken according to reports

It is possible to attach any file as an asset to any github release. That should be good enough - there's a test image

It's the same old problem, not knowing when the server is really done.

In C++ is is easy - it happens automatically. But in JS, with garbage collection, there's no reliable and correct destructor.

There needs to be something like app.shutdown(callback) or similar. Either forcefully or passively.

I want someone with a Mac computer to benchmark with wrk the HelloWorld example on macOS and Linux on the same very hardware.

Also, I want the same for Node.js with a simple HelloWorld server counterpart.

It seems we get way different numbers on the two platforms. I want to know on what platform Node.js runs the best.

Testing the entire stack in Node.js is a good way to really stress every layer, and since we can use JavaScript clients to do so, we can automate things very well.

Are you planning on implementing app.use functionality in the router?

app.use((req, res, next)=>{ next() })  

app.use('/path', handler)

This would make it possible for developers to easily replace their current framework such as polka with µWS.

Something you can require from examples, useful helpers regarding streams, arraybuffers, buffering, etc.

Or not, but i had to ask...

If you are on macOS or Linux, you can try out the kick-starting section and report if that succeeds or not.

I see here that listen function takes host parameter too, but I get segmentation fault. Is it not supported yet?

const uWS = require('uWebSockets.js')
const port = 3000

uWS
  .App()
  .get('/*', (res, req) => {
    res.writeHeader('content-type', 'application/json; charset= utf-8')
    res.end(JSON.stringify({ hello: 'world' }))
  })
  .listen('127.0.0.1', port, token => {
    if (token) {
      console.log('Listening to port ' + port)
    } else {
      console.log('Failed to listen to port ' + port)
    }
  })

Last feature to wrap is the new idleTimeout feature

Everything should be tested many times over

The lib shall throw exceptions when used in the wrong way,

• Using req past return shall throw,
• Using ws past close shall throw,
• Using res past onAbortion or ending shall throw (I've made this mistake myself),
• Passing wrong data types as string shall throw (does not accept Node.js buffers, only ArrayBuffer)

This will massively prune away crashes caused by ill use, from those crashes which are actually bugs. Overall, this will improve experienced stability massively, since ill-use can stick around and cause long term undefined behavior.

It's a new route

Because of native nature of your library it's impossible for IDEs to list methods of req and res objects. Also it's impossible to get methods and properties of this objects via Object.enties or Object.keys.

So the question is where to find an uWS's HTTP API reference?

req.getRoute() should return the pattern this handler is attached to.

run node/examples/HelloWorld.js，that can't to work, the console out the: Segmentation fault: 11

How can I shorten this;

		process.nextTick = (f, ...args) => {
			if (args.length == 1) {
				uWS.nextTick(() => {f(args[0]);});
			}

			if (args.length == 2) {
				uWS.nextTick(() => {f(args[0], args[1]);});
			}

			if (args.length == 3) {
				uWS.nextTick(() => {f(args[0], args[1], args[2]);});
			}

			if (args.length == 4) {
				uWS.nextTick(() => {f(args[0], args[1], args[2], args[3]);});
			}
		}

So that it works, presumably with apply, bind or any such thing. I can't get it working with apply.

Hello, this library is awesome and I'm getting great performance (even from my macbook 70k/s HTTP GET).

I've been trying out the new ws.publish ws.subscribe functions but I haven't been able to get them to work. Even using the PubSub.js example I don't get any errors but nothing is sent on the websocket.

I'm assuming it's because I'm running on a mac, any ideas to narrow down? (I've tried running in a docker container as well but I get the same results, nothing published on the socket).

There are more than the current 3

Again, same thing with macOS. Incredibly frustrating working on macOS. Can't even type. Wtf is wrong with Apple keyboard layout.

Loop::init() fails for some reason.

hi, i was try your code without https and with https, and on 80000 simultanues connections there are results:

1. no https - used memory: 600Mb
2. with https - used memory: 3.5Gb

i am use SHARED_COMPRESSOR
How i can reduse memory usage? (Nodejs 11.10)