libdatachannel VS µWebSockets

Node.js node JavaScript runtime itself provides a means to interface with native applications. Plenty of people write their own WebSocket or WebRTC data channel libraries https://github.com/paullouisageneau/libdatachannel.

Fourtunately some technologies and API's are extensible enough to do whatever you want in spite of and to overcome limitations; e.g., WebRTC (particularly data channels https://github.com/paullouisageneau/libdatachannel), Native Messaging, WebTransport, fetch(), Trasnferable Streams, Media Capture Transform, File API, File System Access API, Web extensions.

To be fair, C++ has libdatachannel which I like using too.

https://github.com/paullouisageneau/libdatachannel ?

Or use something specific like libdatachannel https://libdatachannel.org/

If you’re using WebRTC data channels in a client server config then infra is no more complex than a regular setup because the server will almost certainly have an external facing IP address.

People should really try using WebRTC as well because you can get the full pipeline setup for a toy demo in a couple of slow days. I did whilst also writing my own signalling server in Go without having used Go before!

It’s certainly not any more complex than rolling all the stuff the article is talking about on top of raw UDP.

This does use a real WebRTC stack (specifically libdatachannel - https://libdatachannel.org). Under the hood this is making real WebRTC connections.

But I guess you mean why it doesn't mock using real peers in the browser where the tests are happening, using the browser's existing stack there?

There's a few reasons I've avoided that:

* Primarily: I want to do things that the browser APIs won't let you do. E.g. sending invalid data, or intentionally causing various types of errors. The browser APIs are designed to stop you doing the wrong thing, by keeping the raw data at arm's length. Very sensible for normal WebRTC usage, but bad for testing edge cases and breaking things.

Building WebRTC tends to be hell. If your use case is simple enough, it might be interesting to switch to an alternative C++ library like libdatachannel (I'm the author).

You can, in theory, get UDP-like characteristics out of a different web API - with a WebRTC datachannel configured to be unreliable and unordered. I haven't seen anybody use that API just because it's a pretty big pain to use. The developer of Agar IO called it too hard to use in a HackerNews comment, but nowadays there's simpler libraries than the ones he had in 2016 like webrtc-unreliable and libdatachannel. You still need to run a STUN/TURN server and the integration is easier than it was back then, but still much harder than raw UDP sockets though.

exit(EXIT_SUCCESS); } char message[message_length]; fread(message, message_length, sizeof(char), stdin); string m(message, message + sizeof message / sizeof message[0]); return json::parse(m); } // Encode a message for transmission, given its content. message_t encode_message(json content) { string encoded_content = content.dump(); message_t m; m.content = encoded_content; m.length = (uint32_t)encoded_content.length(); return m; } // Send an encoded message to stdout. void send_message(message_t encoded_message) { char *raw_length = reinterpret_cast(&encoded_message.length); fwrite(raw_length, 4, sizeof(char), stdout); fwrite(encoded_message.content.c_str(), encoded_message.length, sizeof(char), stdout); fflush(stdout); } int main(int argc, char *argv[]) { while (true) { json message = get_message(); auto command = message.get(); // https://github.com/paullouisageneau/libdatachannel/issues/544#issuecomment-1024739214 // https://www.reddit.com/r/cpp\_questions/comments/swr1tk/comment/hxral9f/ FILE *pipe = popen(command.c_str(), "r"); while (true) { size_t bufferSize = 1024; byte buffer[bufferSize]; size_t count; while ((count = fread(buffer, 1, bufferSize, pipe)) > 0) { stringstream data; // S16NE PCM from parec to integers in JSON array data << "["; for (size_t i = 0; i < count; i++) { data << (int)buffer[i]; if (i < count - 1) { data << ","; } } data << "]"; // send JSON array to Native Messaging local client send_message(encode_message(data.str())); } } } }

Not exaclty -- it looks like it's pretty overkill for my needs

I'm looking for something more like websocketpp[0], or even just grpc without a requisite proxy. uWebsockets looks really promising, being header only, but in the fine print requires a runtime library. unfortunately, none of that ecosystem seems to use cmake, making integrating it that much more of a pain.

why use cpp for this, I'm sure some HNer will ask. the ray tracer itself is using cuda, that's why. I've also debated

- running it as a grpc server and having some proxy in a more web-accessible language

- creating python bindings and using python to make a websocket/http server for it

neither of those are out of the question, but they're not my first choices, because I'd like to keep the build & execution simple. introducing dependencies, especially other executables, is in conflict with that.

i don't need anything particularly scalable -- a threaded implementation, or one using select() would be fine, if not preferable.

[0] https://docs.websocketpp.org/

[1] https://github.com/uNetworking/uWebSockets

We discover a really fast, small, and well maintained C++ Library called uNetworking/uWebSockets, but no C API available, so we create and adapt the full C API from uNetworking/uWebSockets and will integrate libuv powered fetch and file IO, this same C API is used by Bun

Cool little library, I'm using it, but author has an ego the size of Wolfram's. This is just one snippet, there are many if you rummage through the docs and issues:

> In the 1970s, programming was an elite's task. Today programming is done by uneducated "farmers" and as a result, the care for smart algorithms, memory usage, CPU-time usage and the like has dwindled in comparison. Just look at, how many web developers represent time - it is not uncommon for web developers to send an entire textual representation of time as 30-something actual letters inside a JSON document with an actual textual key.

https://github.com/uNetworking/uWebSockets/blob/master/misc/...

For those who didn’t know, uWebSockets is one of the reasons for Bun’s high performance in server benchmarks [1], not just JavaScriptCore.

[1] https://github.com/uNetworking/uWebSockets/discussions/1466#...

Seeing the example[1], I suddenly realised how nodejs and C++ are slowly merging into one language...

[1]: https://github.com/uNetworking/uWebSockets#battery-batteries...

https://github.com/uNetworking/uWebSockets (has both for HTTP/S and WebSockets)

Lots of reasons:

- Code cleanliness: their code almost looks like code golfing. Hard to debug.

- Dependencies: everyone has different ways of implementing everything. some are even outdated. some even have stale bots that close legitimate but unattended issues.

- Performance: fastify and uWebSockets.js beats express.js on benchmarks. see https://www.fastify.io/benchmarks/ and https://github.com/uNetworking/uWebSockets/tree/master/bench...

- Multi-part parsing: this is built-in with uWebSockets.js. on express your options are multer or busboy.

- WebSocket Server support: this is built-in with uWebSockets.js. on express your options are using ws and socket.io.

- WebSocket pub/sub: built-in with uWebSockets.js

There are better alternatives like the following:

- https://www.fastify.io/

- https://github.com/uNetworking/uWebSockets.js

- https://github.com/kartikk221/hyper-express

Some of Bun's server speed can be attributed to uWebSockets which has node bindings btw. Source here [1]

[1] https://github.com/uNetworking/uWebSockets/discussions/1466#...

About the project - I was trying to find the perfect reliable and performant rust's web framework to use for one of my personal project, and since I've been using Drogon/uWebSockets previously, I wanted to choose the best one to replace it. So I decided to create a benchmark system that is fully automated.