Simple, secure & standards compliant web server for the most demanding of applications

Overview

Simple, secure[1] & standards compliant[2] web server for the most demanding[3] of applications. Read more...

Language grade: C/C++



🔐 Optimized security

Being meticulously optimized for speed and memory footprint, ”WebSockets is fast enough to do encrypted TLS 1.3 messaging quicker than most alternative servers can do even unencrypted, cleartext messaging[3].

Furthermore, we partake in Google's OSS-Fuzz with a ~95% daily fuzzing coverage with no sanitizer issues. LGTM scores us flawless A+ from having zero CodeQL alerts and we compile with pedantic warning levels.

▶ Rapid scripting

”WebSockets is written entirely in C & C++ but has a seamless integration for Node.js backends. This allows for rapid scripting of powerful apps, using widespread competence. See ”WebSockets.js.

⚔ Battle proven

We've been fully standards compliant with a perfect Autobahn|Testsuite score since 2016[2]. Companies with everything to lose rely on ”WebSockets on a daily basis - we power the trading APIs of Bitfinex.com & Kraken.com, handling volumes of multiple billions of USD every day. Other companies include Trello, where ”WebSockets is serving their 50 million users with real-time board updates.

🔋 Batteries included

Designed around a convenient URL router with wildcard & parameter support - paired with efficient pub/sub features inspired by MQTT. ”WebSockets should be the obvious, complete starting point for any real-time web project with high demands.

Start building your Http & WebSocket apps in a swift; read the user manual and see examples. You can browse our TypeDoc for a quick overview.

uWS::SSLApp({

    /* There are tons of SSL options, see uSockets */
    .cert_file_name = "cert.pem",
    .key_file_name = "key.pem"
    
}).get("/hello", [](auto *res, auto *req) {

    /* You can efficiently stream huge files too */
    res->writeHeader("Content-Type", "text/html; charset=utf-8")->end("Hello HTTP!");
    
}).ws<UserData>("/*", {

    /* Just a few of the available handlers */
    .open = [](auto *ws) {
        /* MQTT syntax */
        ws->subscribe("sensors/+/house");
    },
    .message = [](auto *ws, std::string_view message, uWS::OpCode opCode) {
        ws->send(message, opCode);
    }
    
}).listen(9001, [](auto *listenSocket) {

    if (listenSocket) {
        std::cout << "Listening on port " << 9001 << std::endl;
    }
    
}).run();

đŸ’Œ Commercially supported

uNetworking AB is a Swedish consulting & contracting company dealing with anything related to ”WebSockets; development, support and customer success.

Don't hesitate sending a mail if you're building something large, in need of advice or having other business inquiries in mind. We'll figure out what's best for both parties and make sure you're not stepping into one of the many common pitfalls.

Special thanks to BitMEX, Bitfinex, Google, Coinbase, Bitwyre and deepstreamHub for allowing the project itself to thrive on GitHub since 2016 - this project would not be possible without these beautiful companies.

🔧 Customizable architecture

”WebSockets builds on ”Sockets, a foundation library implementing eventing, networking and cryptography in three different layers. Every layer has multiple implementations and you control the compiled composition with flags.

In a nutshell:

  • WITH_WOLFSSL=1 WITH_LIBUV=1 make examples builds examples utilizing WolfSSL and libuv
  • WITH_OPENSSL=1 make examples builds examples utilizing OpenSSL and the native kernel

See ”Sockets for an up-to-date list of flags and a more detailed explanation.

đŸ€ Permissively licensed

Intellectual property, all rights reserved.

Where such explicit notice is given, source code is licensed Apache License 2.0 which is a permissive OSI-approved license with very few limitations. Modified "forks" should be of nothing but licensed source code, and be made available under another product name. If you're uncertain about any of this, please ask before assuming.

Issues
  • Segfault when connections are closing during publish()

    Segfault when connections are closing during publish()

    I am running into a situation where the library has a seg fault while trying to publish on the websockets. During the call to publish(), the library calls into drain(), which calls the cb() function of TopicTree. While executing that function, the segfault occurs because the Subscriber pointer is reset to UINTPTR_MAX.

    I could not cause this problem with a single client. The corner case is occurring when I have thousands of clients connected while publishing a large number of updates. As I end up overwhelming the clients, I see TCP retransmits and TCP windows reach 0. As the congestion occurs, some clients begin closing sockets. When this happens, TopicTree.h line 374 cb(min, intersectionCache[intersection] = std::move(res)); is eventually called with min set to UINTPTR_MAX. This then causes the seg fault in WebSocketContextData.h on line 61 auto *asyncSocket = (AsyncSocket<SSL> *) s->user; when trying to access the user.

    I've made two changes to workaround this, but am not sure if this is the best or proper solution.

    In WebSocketContextData.h, I added the if check on the subscriber pointer:

        WebSocketContextData() : topicTree([this](Subscriber *s, std::string_view data) -> int {
            /* We rely on writing to regular asyncSockets */
            if (s != (Subscriber *)UINTPTR_MAX) {
                auto *asyncSocket = (AsyncSocket<SSL> *) s->user;
    

    And in TopicTree.h in the drain() method around line 350, I added the additional code to decrement nonEmpty.

                        else {
                            /* We need to lower nextMin to us, in the case of min being the last in a set */
                            if ((it[i] != end[i]) && (nextMin > *it[i])) {
                                nextMin = *it[i];
                            } else if (min == (Subscriber *)UINTPTR_MAX) {
                                if (nonEmpty > 0) {
                                    nonEmpty--;
                                }
                            }
                        }
    
    

    Also the backtrace from gdb.

    (gdb) bt
    #0  0x00007f847a010837 in ioctl () from /lib64/libc.so.6
    #1  0x00007f847cb854bf in oo_resource_op (cmd=1074027035, io=0x7f84745ce65c, fp=<optimized out>) at ../../../../../src/include/onload/unix_intf.h:80
    #2  citp_signal_terminate (signum=<optimized out>, info=<optimized out>, context=<optimized out>) at ../../../../../src/lib/transport/ip/signal.c:280
    #3  0x00007f847cb85412 in citp_signal_run_app_handler ([email protected]=11, [email protected]=0x7f84745ce8f0, [email protected]=0x7f84745ce7c0) at ../../../../../src/lib/transport/ip/signal.c:106
    #4  0x00007f847cb8565a in citp_signal_run_now (our_info=<optimized out>, context=0x7f84745ce7c0, info=0x7f84745ce8f0, signum=11) at ../../../../../src/lib/transport/ip/signal.c:226
    #5  citp_signal_intercept (signum=11, info=0x7f84745ce8f0, context=0x7f84745ce7c0) at ../../../../../src/lib/transport/ip/signal.c:263
    #6  <signal handler called>
    #7  0x0000000000446f66 in std::_Function_handler<int (uWS::Subscriber*, std::basic_string_view<char, std::char_traits<char> >), uWS::WebSocketContextData<false>::WebSocketContextData()::{lambda(uWS::Subscriber*, std::basic_string_view<char, std::char_traits<char> >)#1}>::_M_invoke(std::_Any_data const&, uWS::Subscriber*&&, std::basic_string_view<char, std::char_traits<char> >&&) (__functor=...,
        __args#0=<optimized out>, __args#1=...) at /opt/x3p/xrt_b/base/lib/gcc/x86_64-unknown-linux/7/../../../../include/c++/7/bits/std_function.h:299
    #8  0x00000000004277e8 in std::function<int (uWS::Subscriber*, std::basic_string_view<char, std::char_traits<char> >)>::operator()(uWS::Subscriber*, std::basic_string_view<char, std::char_traits<char> >) const (__args#1="", __args#0=<optimized out>, this=0x1f4cd48) at /opt/x3p/xrt_b/base/lib/gcc/x86_64-unknown-linux/7/../../../../include/c++/7/bits/std_function.h:706
    #9  uWS::TopicTree::drain (this=0x1f4cd48) at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/TopicTree.h:374
    #10 0x0000000000411bd7 in fu2::abi_400::detail::type_erasure::tables::vtable<fu2::abi_400::detail::property<true, false, void (uWS::Loop*)> >::invoke<0ul, fu2::abi_400::detail::type_erasure::data_accessor*, unsigned long const&, uWS::Loop*>(fu2::abi_400::detail::type_erasure::data_accessor*&&, unsigned long const&, uWS::Loop*&&) const (this=0x1ec7df0)
        at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/f2/function2.hpp:995
    #11 fu2::abi_400::detail::type_erasure::erasure<true, fu2::abi_400::detail::config<true, false, fu2::capacity_default>, fu2::abi_400::detail::property<true, false, void (uWS::Loop*)> >::invoke<0ul, fu2::abi_400::detail::type_erasure::erasure<true, fu2::abi_400::detail::config<true, false, fu2::capacity_default>, fu2::abi_400::detail::property<true, false, void (uWS::Loop*)> >&, uWS::Loop*>(fu2::abi_400::detail::type_erasure::erasure<true, fu2::abi_400::detail::config<true, false, fu2::capacity_default>, fu2::abi_400::detail::property<true, false, void (uWS::Loop*)> >&, uWS::Loop*&&) (erasure=...)
        at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/f2/function2.hpp:1215
    #12 fu2::abi_400::detail::type_erasure::invocation_table::operator_impl<0ul, fu2::abi_400::detail::function<fu2::abi_400::detail::config<true, false, fu2::capacity_default>, fu2::abi_400::detail::property<true, false, void (uWS::Loop*)> >, void (uWS::Loop*)>::operator()(uWS::Loop*) (args#0=0x384e000, this=0x1ec7de0)
        at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/f2/function2.hpp:775
    #13 uWS::Loop::postCb (loop=0x384e000) at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/Loop.h:57
    #14 0x0000000000706a88 in us_loop_run (loop=0x384e000) at external/uSockets/src/eventing/epoll_kqueue.c:149
    #15 0x00000000004557e4 in uWS::Loop::run (this=<optimized out>) at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/Loop.h:152
    #16 uWS::run () at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/Loop.h:164
    #17 uWS::TemplatedApp<false>::run (this=<optimized out>) at bazel-out/k8-opt/bin/external/uWebSockets/_virtual_includes/uWebSockets/uWebSockets/App.h:334
    
    
    high priority bug v0.17 
    opened by tomwickert 36
  • Safari (macOS 12, iOS 15) and compression is broken

    Safari (macOS 12, iOS 15) and compression is broken

    All versions of uWS are totally incompatible with iOS 15 when using compression and will not keep a connection. This is because of an Apple bug where client_no_context_takeover is not properly implemented in newest Safari for iOS 15.

    Because of this, if you use compression and expect iOS 15 connections, you will have to enable uWS::DEDICATED_DECOMPRESSOR as well.

    See EchoServer.cpp example. uWS::DEDICATED_DECOMPRESSOR is available in v20.3.0 and forward. This adds about 44kb of memory usage per connection.

    an-apple-a-day 
    opened by alexhultman 34
  • Websockets Authorization

    Websockets Authorization

    Is there any best practice for implementing websockets authorization with uWS? In previous versions of the library it was possible to check a bearer token in the req.headers of the initial HTTP request before upgrading to websockets, then respond with status 401 oer whatever. Is this still possible somehow? currently I am doing the authorization in the ws callback like this:

    app
      .ws("/*", {
        /* Options */
        compression: CompressOptions.SHARED_COMPRESSOR,
        maxPayloadLength: 16 * 1024 * 1024,
        idleTimeout: 10,
        open: (ws, req) => {
          console.log("A WebSocket connected via URL: " + req.getUrl() + "!");
    
          console.log(ws, req.getHeader("authorization"));
    
          const authorization = req.getHeader("authorization");
    
          if (authorization) {
            const token = authorization.split(" ")[1];
            if (token) {
              ws.userId = getUserIdFromToken;
              if(ws.userId) {
                 return;
            }
          }
          // 404 is not a valid websocket error code
          ws.end(404, "Unauthorized");
        },
    

    Problem is that there are not suitable standard websocket error codes that express missing authorization or similar. Also it is not as clean as just doing the authorization before even starting the ws connection.

    high priority v18 API-breaking 
    opened by manast 29
  • GetQuery with optional parameters

    GetQuery with optional parameters

    Right now the getQuery function will ignore any parameter, woudln't it be nice to have the option to get the exact Query you are looking for? Making it optional so it doesn't affect performance at all if no params is sent

    opened by FerLuisxd 27
  • Reconsider pub/sub interfaces for v19

    Reconsider pub/sub interfaces for v19

    Hello

    socket.id = 1234;
    socket.subscribe("TOPIC1");
    socket.subscribe("TOPIC2");
    
    //Any way to do this?
    socket.getAllSubscribedTopics();  //returns ["TOPIC1", "TOPIC2"]
    

    How can i get the subscribed topics for a given socket. At the moment i keep a state myself in memory with the socket id and the subscribed topics, but i think the underlying library already keeps this state but i don't see a way to access that state.

    Thanks!

    API-breaking v19 
    opened by zappys 24
  • Missing way to read HttpRequest body/data for POST/PUT...

    Missing way to read HttpRequest body/data for POST/PUT...

    Apologies if I missed it, but I can't find a way to read the request body (the data after the headers) in HttpRequest.

    This would be needed in handling POST/PUT/... requests.

    Thanks in advance

    opened by christoth 22
  • Streaming to pipelining client

    Streaming to pipelining client

    Hi. Thanks for library.

    I got issue in my library issues, which describes this:

    • When testing with stream file, under high-load headers duplicated (up to Infinity)
    • When under high-load, even not stream file, headers duplicated (1-5x times)
    • When testing with wrk this issue happens too
    • If as client using Safari, issue happening less than Chrome

    More info here and here

    bug v0.17 
    opened by dalisoft 18
  • Http3Transport draft implementation

    Http3Transport draft implementation

    uWS is going to implement the QUIC-based QuicTransport protocol as a complement to WebSocket.

    The idea is that since QuicTransport has the concept of URL, it can fit nicely into the app/routes concept that is so central to uWS:

    app.qt("/route", { // whatever behavior here })

    This can be applicable to web messaging that is not in need of reliable & ordered messaging, such as IO-games.

    uSockets v20 
    opened by alexhultman 17
  • Support of Cmake.

    Support of Cmake.

    Adding support of CMake, adds possibility to easily integrate uWebSockets to other C++ projects.

    For my project I wrote small CMakeLists.txt for uWebSockets and it works very well. So If maintainer of project agrees to add Cmake support I could prepare PR.

    opened by patriotyk 17
  • Memory allocation error - incorrect checksum for freed object

    Memory allocation error - incorrect checksum for freed object

    Description

    Memory allocation errors occur when launching 100 servers that do not appear when launching 10 servers in the same configuration.

    • OS: Mac OS 10.14
    • Node: Homebrew v10.15.2

    Code to reproduce

    https://github.com/bunchtogether/braid-server/blob/master/tests/peers-ring.test.js

    (Apologies, I have been unable to reproduce in a simpler example.)

    Output

    node(65675,0x1091595c0) malloc: Incorrect checksum for freed object 0x104819200: probably modified after being freed.
    Corrupt value: 0x1baffed00baffedf
    node(65675,0x1091595c0) malloc: *** set a breakpoint in malloc_error_break to debug
    

    Extended Description

    The Braid application syncs key-value pairs between a small network of peers and a larger network of read-only subscribers. All communication between the peer and subscriber processes occurs over WebSockets.

    In this test 100 uWebSocket servers are created and linked in a ring using ws, i.e. peer A opens a connection to peer B, peer B opens a connection to peer C, peer C opens a connection to peer A.

    When the test is reduced to 10 uWebSocket servers the error does not occur.

    Thanks

    Thanks for the great work and let me know if there is any additional information I can provide.

    bug not reproducible 
    opened by wehriam 17
  • Empty close reasons

    Empty close reasons

    When websocket gets closed because of maxPayloadLength exceeded, it closes with 1006 and empty reason data.

    Would it be possible to have option to turn on details for close reasons?

    I would like to monitor socket closes also log if someone gets disconnected for exceeded payload length to know that there is something wrong client side and its sending unexpected sized messages or in case of attempted DoS attack etc.

    I could also do this on message handler but would that be good idea?

    Thanks

    high priority v18 uSockets 
    opened by ghost 15
  • Remove all Safari hacks

    Remove all Safari hacks

    Since Safari is the only browser which continuously takes a dump on the spec, we have several Safari hacks:

    • User agent hack for permessage-deflate being completely broken before 15.4
    • Hack for dealing with Safari-specific x-webkit-deflate-frame and its deviating behavior

    All of this garbage should be removed (at some point in the future) and we should only implement the standard behavior.

    opened by alexhultman 0
  • use with sendfile?

    use with sendfile?

    Hi, Reading the code, I wonder how I could use the sendfile syscall in the app.

    My usecase is the distribution of static files and I would like to avoid copies in user space.

    Linux. From those in the know, any issues to predict with using sendfile in uws?

    Thanks

    opened by LeHibou2 9
  • added more c apis and capi ssl version with capi examples

    added more c apis and capi ssl version with capi examples

    This adds a complete useful capi with ssl suport and most examples added.

    It's a step to solve this issue: https://github.com/uNetworking/uWebSockets/issues/1192 Opaque C interface for Swift, Rust, etc

    For now its just a wrapper and can be optimized a lot, but its a start.

    make capi, and make capi_examples for build added

    opened by cirospaciari 84
  • Dynamic url demo

    Dynamic url demo

    This will improve the demo for the server by showcasing a few more features like wildcard paths and serving directories.

    Now URLs can be localhost:3000/app/content/filename depending on the directory index that is specified in the main portion of the app.

    opened by Vaporeaux 0
  • closeOnBackpressure should block all further sending

    closeOnBackpressure should block all further sending

    When we reach maxBackpressure we start closing the connection (which doesn't even work on Windows!). But there is no guarantee that backpressure won't drain a bit and we then send another message still. This can cause a gap in the stream. This needs to be guaranteed that when we reach maxBackpressure and we are closing, never send anything more. To guarantee stream integrity.

    low priority bug 
    opened by alexhultman 0
Releases(v20.14.0)
  • v20.14.0(May 2, 2022)

    Streaming large HTTP response fix

    • Fixes a potential heap-use-after-free when finishing (tryEnd, end) an Http response within onWritable callback (captured variables are destroyed).
    • Affects only users who stream large Http responses with the use of onWritable callback. If your application never sets an onWritable callback, then you're not affected.
    • See uWebSockets.js/examples/VideoStreamer.js for an example of affected use.

    Thanks to @o5k @zdm

    Source code(tar.gz)
    Source code(zip)
  • v20.13.0(Apr 20, 2022)

    This release fixes a minor issue where the HTTP parser did not allow header values with bytes above 7-bit ASCII. Now it is possible to receive any byte sequence except for terminating CRLF. A unit test for this was added.

    Source code(tar.gz)
    Source code(zip)
  • v20.12.0(Mar 17, 2022)

    Safari 15.4 finally fixed?

    It is believed that Apple finally fixed their permessage-deflate ("WebSocket compression") in Safari 15.4. This release will disable permessage-deflate for broken versions of Safari (15.0 - 15.3), but not for 15.4 and forwards. If you experience issues with Safari 15.4 and compression, report it and we can mark 15.4 as broken as well. Apple is not a transparent company and we cannot know what black magic they are up to and their releases do not explain anything.

    Think different, think Apple. And now punch yourself in the face. Mmm, nosebleed.

    Source code(tar.gz)
    Source code(zip)
  • v20.11.0(Jan 27, 2022)

    • All versions of Safari 15 for iOS and macOS are entirely broken when it comes to WebSocket. This release adds exceptions to the standard, applied only to Safari user agents in order to play along with Apple's thorough and unmatched incompetence.
    Source code(tar.gz)
    Source code(zip)
  • v20.10.0(Jan 25, 2022)

  • v20.9.0(Jan 4, 2022)

    • Adds HttpResponse::pause, HttpResponse::resume for throttling of data I/O.
    • Adds new fast path for zero masked WebSocket messages and optimizes large message unmasking.
    • Fixes HttpRouter ordering issues in certain undiscovered edge cases & adds tests.
    • Adds endWithoutBody for responding without a body or content-length.
    • Clear subscriptions before calling close handler, not after.
    Source code(tar.gz)
    Source code(zip)
  • v20.8.0(Oct 31, 2021)

  • v20.7.0(Oct 30, 2021)

    More decompressors

    • Fixes DEDICATED_DECOMPRESSOR introduced in v20.3.0
    • Adds a range of DEDICATED_DECOMPRESSOR_32KB .. DEDICATED_DECOMPRESSOR_512B
    Source code(tar.gz)
    Source code(zip)
  • v20.6.0(Oct 18, 2021)

  • v20.5.0(Sep 30, 2021)

    Reordering & flags fix

    • In v19.8.0 while optimizing large message sending, a reordering bug was introduced that may reorder outgoing messages.
    • uSockets 0.8.1 fixes a bug passing invalid flags down to send syscall.
    Source code(tar.gz)
    Source code(zip)
  • v20.4.0(Sep 28, 2021)

    Optimizes large publishes

    • Large message publishing is now just as fast as regular WebSocket::send and bypasses any effort to coalesce with small messages.
    • Fixes a potential memory leak in TopicTree::publish.
    Source code(tar.gz)
    Source code(zip)
  • v20.3.0(Sep 28, 2021)

    Dedicated decompressors

    Adds uWS::CompressOptions::DEDICATED_DECOMPRESSOR. This (decompressor) flag can be OR:ed with one (compressor) flag to easily create a complete compression preference such as:

    .compression = uWS::CompressOptions(uWS::DEDICATED_COMPRESSOR_4KB | uWS::DEDICATED_DECOMPRESSOR),
    

    See https://github.com/uNetworking/uWebSockets/issues/1347. This change is backwards compatible. More specific decompressors will be added with time.

    Source code(tar.gz)
    Source code(zip)
  • v20.2.0(Sep 27, 2021)

    • Moves TopicTree from individual WebSocketContextData's up to the one shared App.
    • Fixes undefined behavior in the destructor of App (passes fuzzing build sanity checks).
    • Fixes two fuzzing issues introduced in v20 (fuzzing should now be clean; but let's wait a week and find out).
    Source code(tar.gz)
    Source code(zip)
  • v20.1.0(Sep 25, 2021)

  • v20.0.0(Sep 25, 2021)

    Massively simplified & improved pub/sub

    Pub/sub is now a lot more predictable and always guarantees strict ordering inside topics, across topics and between WebSocket::send and WebSocket::publish / App::publish. Subscription and unsubscription is always guaranteed to be strictly ordered with respect to publish. Support for MQTT wildcards has been removed.

    Backwards compatible

    Unless you're relying on MQTT wildcards ('#', '+'), v20.0.0 is entirely backwards compatible with v19.9.0.

    Motivation

    When pub/sub was introduced in 2018, it was designed based on a few assumptions:

    • SHARED_COMPRESSOR being preferred by customers and customers being okay with supporting many application-level messages wrapped in and delivered as one bigger WebSocket message.
      • Expectation: Customers being willing to optimize the application protocol to minimize compression overhead.
      • Reality: This is way too complicated for customers and not even backwards compatible with their existing protocols. Customers simply want things to work, and they heavily prefer DEDICATED_COMPRESSOR.
    • Subscription and unsubscription to/from topics being "malleable" and not strictly ordered.
      • Expectation: Customers being fine with subscriptions and unsubscriptions being executed in as big of a batch as possible, with minor re-ordering of messages not being a problem.
      • Reality: Many apps depend on a strict ordering guarantee and break down if order is not guaranteed. This is why the nonStrict hack was added, which performs really bad in worst-case and is badly understood.
    • WebSocket::send and WebSocket::publish being two different streams out of order with each other.
      • Expectation: There being a separate use for pub/sub, not related to send.
      • Reality: Customers expect WebSocket::publish followed by WebSocket::send to be delivered in order, and the opposite likewise.
    • MQTT syntax being useful
      • Expectation: Efficient use of a logarithmic tree of topics and wildcards
      • Reality: Customers don't care
    Source code(tar.gz)
    Source code(zip)
  • v19.9.0(Sep 22, 2021)

  • v19.8.0(Sep 20, 2021)

    Large messages & slow receivers

    WebSockets are typically used for small message sending. In some cases you might end up with larger-than-ideal messages being sent, and these cases need to be handled efficiently. Especially if receivers are slow and backpressure is building up.

    • Only reduce backpressure in steps of 1/32th of the backpressure itself. This hinders excessive reallocation/shifting of especially large backpressure and improves drainage performance.

    • Use std::string::erase instead of std::string::substr. This alone is a 3x performance improvement for worst cases.

    • Write directly to backpressure if sending a large message, or if already draining. This improves sending performance of large messages as we avoid extra copying/allocations.

    • Adds ability to benchmark large message echoing with load_test. Use extra argument size_mb. This release is at least 1.5x the peformance when echoing 100mb messages.

    Source code(tar.gz)
    Source code(zip)
  • v18.24.0(Sep 15, 2021)

  • v19.6.0(Sep 13, 2021)

  • v19.5.0(Sep 4, 2021)

    Boost Asio

    Adding support for seamless integration with Boost Asio.

    Compile with WITH_ASIO=1 and integrate with existing boost::asio::io_context on the same thread.

    Caveat: Loop must be run by uWS (Loop::run() or us_loop_run) even if the io_context is third party.

    Source code(tar.gz)
    Source code(zip)
  • v19.4.0(Aug 29, 2021)

    Stampede tweaks

    • Tweaks the TLS handshake queue to better cope with mass connections and mass disconnections.
    • Adjusts the WebSocket shutdown timeout from a default of 120 seconds to roughly 4 seconds, making mass disconnections finish quicker.

    Please report any issues or undesired side effects introduced in this release.

    Source code(tar.gz)
    Source code(zip)
  • v19.3.0(Jun 26, 2021)

    Do not publish to self

    • Fixes a bug where publishing to all but self, still would publish to self (WebSocket::publish).
    • Adds test case for this issue.
    • Improves scale_test.
    • Fixes header install.
    • Fixes 4 GB HTTP stream limit on 32-bit platforms.
    Source code(tar.gz)
    Source code(zip)
  • v19.2.0(Apr 13, 2021)

  • v19.1.0(Apr 10, 2021)

    First fixes

    • Fixes compilation of WebSocket::isSubscribed, App::numSubscribers
    • WebSocket::iterateTopics returns topic names without initial slash ("/broadcast" is now returned as "broadcast").
    Source code(tar.gz)
    Source code(zip)
  • v19.0.0(Apr 10, 2021)

    All versions below v19 are now deprecated. This is as usual - we only manage one branch and therefore it is important to upgrade. No fixes will be backported to deprecated versions. Don't worry - v19 is mostly backwards compatible with v18 except for a few key areas:

    1. Ping and pong events now take std::string_view message [definitely breaking]

    Any WebSocket ping or pong frame can carry a small message as payload. We never exposed that message to the library user until now. This means we break APIs a tiny bit. Look at the (updated) examples to see what I mean.

    2. WebSocket::getUserData is now type safe [most probably backwards compatible]

    The type of WebSocket<SSL, isServer> has changed to WebSocket<SSL, isServer, USERDATA> where USERDATA is what you specified in App::ws<USERDATA>, often times called PerSocketData. This was done to make WebSocket::getUserData() type safe instead of returning a void pointer. This change should be entirely backwards compatible for everyone using type inference (all examples do).

    3. WebSocket::publish now sends to every subscriber except for itself [differing behavior]

    Publishing using WebSocket::publish will now send to all subscribers in the whole App, except for to itself. If you want to send to all subscribers in the App, unconditionally, use App::publish. This change is potentially breaking, so check your usage - however - most users were expecting this behavior so this change will most likely fix things rather than break things.

    4. Pings are now sent automatically if necessary to meet idleTimeout constraints [differing behavior]

    Defaults regarding ping/pong have changed. Now the server will automatically send pings as needed, unless the client has sent us something recently. This is a change from v18 where all clients had the sole responsibility of sending the server something every once in a while to not time out. Yes, you can revert back to the old behavior via settings, but the new default is for the server to manage pings automatically - meaning that the entire heartbeat problematic is now entirely automatic by default - you don't need to consider it, it just works.

    5. WebSocket::unsubscribeAll was removed [definitely breaking]

    v19 adds new functions regarding pub/sub - such as WebSocket::iterateTopics. This means the rather specialized WebSocket::unsubscribeAll makes less sense now. Especially since the library automatically unsubscribes from all topics on socket close (more efficiently). So this function was removed in favor of more general functions.

    Source code(tar.gz)
    Source code(zip)
  • v19.0.0a5(Mar 5, 2021)

    Fuzzing fixes and API changes

    Fuzzing is now without issues at roughly 97% coverage - higher than ever reported before. Some API changes - still some to be done.

    Source code(tar.gz)
    Source code(zip)
  • v19.0.0a4(Feb 14, 2021)

  • v19.0.0a3(Feb 2, 2021)

    Non-strict subscribe/unsubscribe

    • WebSocket::subscribe and unsubscribe now takes bool nonStrict as a very significant optimization in certain use cases.
    • idleTimeout must be specified as 0 or greater than 8 and is now unsigned short, limiting maximum timeout as 18 hours (2^16 seconds).
    • Timeouts are now truncated to nearest 4 second and a warning is displayed for timeouts not being a multiple of 4.
    • Timeouts have been micro optimized and will require up to 40% less CPU-time overall (although 40% of nothing is nothing!).
    Source code(tar.gz)
    Source code(zip)
  • v19.0.0a2(Jan 31, 2021)

    Automatic ping/pong management

    Adds new option "sendPingsAutomatically" and changes a few defaults to more sane values in respect to simplicity. With these defaults you no longer have to bother with timeouts or pings but can put all focus on business logic.

    Source code(tar.gz)
    Source code(zip)
  • v19.0.0a1(Jan 29, 2021)

    Publish to all subscribers except sender

    One of the most requested features since pub/sub was added. WebSocket::publish will no longer publish to itself, even if subscribed to the topic being published to. App::publish remains like before and will publish to any matching subscriber.

    Source code(tar.gz)
    Source code(zip)
Owner
uNetworking AB
uNetworking AB
LAppS - Lua Application Server for micro-services with default communication over WebSockets. The fastest and most vertically scalable WebSockets server implementation ever. Low latency C++ <-> Lua stack roundtrip.

LAppS - Lua Application Server This is an attempt to provide very easy to use Lua Application Server working over WebSockets protocol (RFC 6455). LApp

null 47 Apr 25, 2022
Ole Christian Eidheim 735 Jun 24, 2022
server secure chat

nem server api Register Login GetList Handshake Message Feed StatusOnline HandshakeKey HandshakeNotice FileAdd StorageFile GetFile Register { "type":

Dmitrii 6 Apr 3, 2022
A protocol for secure client/server connections over UDP

netcode netcode is a simple connection based client/server protocol built on top of UDP. It has the following features: Encrypted and signed packets S

The Network Protocol Company 2.2k Jun 26, 2022
A protocol for secure client/server connections over UDP

netcode netcode is a simple connection based client/server protocol built on top of UDP. It has the following features: Encrypted and signed packets S

The Network Protocol Company 2.2k Jun 26, 2022
C library to create simple HTTP servers and Web Applications.

Onion http server library Travis status Coverity status Onion is a C library to create simple HTTP servers and Web Applications. master the developmen

David Moreno Montero 1.9k Jun 30, 2022
:hocho: Strictly RFC 3986 compliant URI parsing and handling library written in C89; moved from SourceForge to GitHub

uriparser uriparser is a strictly RFC 3986 compliant URI parsing and handling library written in C89 ("ANSI C"). uriparser is cross-platform, fast, su

uriparser 243 Jun 26, 2022
đŸŒ±Light and powerful C++ web framework for highly scalable and resource-efficient web application. It's zero-dependency and easy-portable.

Oat++ News Hey, meet the new oatpp version 1.2.5! See the changelog for details. Check out the new oatpp ORM - read more here. Oat++ is a modern Web F

Oat++ 5.5k Jun 27, 2022
C Hypertext Library - A library for writing web applications in C

CHL C Hypertext Library - A library for writing web applications in C #include <chl/chl.h> int main() { chl_set_default_headers(); chl_print_header

null 272 Jun 20, 2022
A WiFi-enabled microcontroller capable of communicating with web-based service APIs for fast prototyping applications.

A WiFi-enabled microcontroller capable of communicating with web-based service APIs for fast prototyping applications.

Mark Hofmeister 2 Mar 9, 2022
Lightway Core is a modern VPN protocol by ExpressVPN, to deliver a VPN experience that’s faster, more secure, and more reliable.

Lightway Core NOTE: This is a preview snapshot of the Lightway repository used for both our client and server. We will be publishing a live, actively

ExpressVPN 22 Feb 17, 2022
Lightway Core is a modern VPN protocol by ExpressVPN, to deliver a VPN experience that’s faster, more secure, and more reliable.

Lightway Core is a modern VPN protocol by ExpressVPN, to deliver a VPN experience that’s faster, more secure, and more reliable.

ExpressVPN 302 Jun 15, 2022
GnuTLS implements the TLS/SSL (Transport Layer Security aka Secure Sockets Layer) protocol

GnuTLS implements the TLS/SSL (Transport Layer Security aka Secure Sockets Layer) protocol

Jonathan Bastien-Filiatrault 3 Jun 3, 2021
BabyCoin: secure, fast and anonymous currency // Dev-Pool:

BabyCoin BabyCoin (BABY) is a state-of-the-art cryptocurrency based on Arqma and Evolution projects. BabyCoin is well suited for CPU mining based on t

null 2 May 15, 2022
Mongoose Embedded Web Server Library - a multi-protocol embedded networking library with TCP/UDP, HTTP, WebSocket, MQTT built-in protocols, async DNS resolver, and non-blocking API.

Mongoose - Embedded Web Server / Embedded Networking Library Mongoose is a networking library for C/C++. It implements event-driven non-blocking APIs

Cesanta Software 8.5k Jun 29, 2022
When you need a web server in a hurry.

darkhttpd https://unix4lyfe.org/darkhttpd/ When you need a web server in a hurry. Features: Simple to set up: Single binary, no other files, no instal

Emil Mikulic 800 Jun 24, 2022
web server that will print hello world on the screen only for linux users

a simple http server side lib only for linux users Note: This lib is currently under development you can check the source code and even use it but dn'

notaweeb 11 Mar 14, 2021
cServe : mean and lean web server written in c

cServe =========== cServe is a web server written in c for POXIS compliant operating systems cServe is planned to be [ ] Supporting HTTP/1.x and HTTP/

Ayush Kumar 1 Dec 21, 2021
reverse proxy with web server and preview page

Reverse Proxy Dependencies Go Make Suport Termux (android/afsd kernel) linux (kernel) Install: Termux: 1 step: Install Go-lang, Git and Make pkg insta

AlbĂąniaSecurity-RT 7 Feb 19, 2022