Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/uNetworking/uWebSockets/releases below:

Releases · uNetworking/uWebSockets · GitHub

Releases · uNetworking/uWebSockets

• libdeflate is now compatible with uWS::DEDICATED_DECOMPRESSOR and will be used if (and only if) the WebSocket's negotiation downgraded to equivalent of uWS::SHARED_DECOMPRESSOR (client_no_context_takeover). This will boost performance when possible. Of course, uWS::SHARED_DECOMPRESSOR as decompressor will always use libdeflate.
• In other cases, zlib will be used regardless.

Resurrecting support of libdeflate, now specifically only for inflation and only as a fast path to zlib.

WITH_LIBDEFLATE=1 make

builds examples using this fast path (you need to build the submodule first). Improved load_test.c benchmark can now highlight inflation cost:

For me and my particular test system:

• With dynamically linked zlib - 110k msg/sec inflated and echoed 300 byte JSON messages
• With statically linked zlib-cloudflare - 130k
• With libdeflate as fast path - 180k
• Without any inflation - 320k

Note: WITH_DEFLATE is only compatible with uWS::SHARED_DECOMPRESSOR!

A feature from v0.14, previously removed due to lack of interest, has now been revived! Check out the demo in examples/Precompress.cpp to see it in action.

A PreparedMessage is a message that is compressed once but can be sent multiple times. This requires the SHARED_COMPRESSOR option but works with any decompressor option. The core idea is to decouple the compression process from the act of sending the message, reducing the per-socket computational overhead of compression to near zero.

This feature is ideal for scenarios where you need to send snapshots of a data stream to multiple recipients. Here’s how it could work:

• A timer periodically creates a new PreparedMessage containing the latest snapshot of the data (e.g., every 500ms).
• When a WebSocket connects, it receives the most recent prepared snapshot, followed by incremental updates (deltas) from that point onward.
• If the snapshot is large, pre-compressing it as a PreparedMessage eliminates the need for repeated compression, significantly reducing overhead for each socket.

• This feature only works with SHARED_COMPRESSOR. Using a sliding window compression method is incompatible with this optimization.
• New methods have been added to support this feature:
  • WebSocket::sendPrepared
  • App::publishPrepared
  • Loop::prepareMessage
• You can create PreparedMessage objects on any thread, as long as that thread has its own Loop (which is automatically created for you via Loop::get()). However, in such cases, you must handle synchronization manually. Refer to examples/Precompress.cpp for guidance.

This release introduces the interface and its initial implementation. While memory-saving optimizations are not included in this release, they may be addressed in future updates.

• Examples are built in parallel
• Supports building with all _LIBCPP_HARDENING_MODE
• (Experimental) cached HTTP support is reverted for now, restoring fuzz builds
• h1spec and test subject is added to CI
• Disallow duplicate Host headers as per RFC9112

This release adds more HTTP tests and makes some minor corrections for passing those tests:

A basic HTTP RFC9112 spec. compliance test has been added and minor changes have been made to pass all tests immediately:

This basic test catches no issues in Node.js, but it catches 2 issues in Deno (reported). The test can be found here:

https://github.com/uNetworkingAB/h1spec

In contrast, running the test on completely broken servers like mrhttp you get an obvious indication of so:

For some users, recent introduction of CachedApp broke seamless backwards compatibility. If you rely on uWS::App being uWS::TemplatedApp<false> and not something else (like uWS::CachedApp<false> 😉), this release fixes your build:

    typedef uWS::TemplatedApp<false> App;
    typedef uWS::TemplatedApp<true> SSLApp;

• Emit 431 on too many headers (not just too long headers)
• Don't emit 505 on fragmented request line (regression since 505 was introduced)

• Always put a reason message on 1006 close events
• Template refactors needed for coming HTTP cache; it should be entirely backwards compatible for your app

You can’t perform that action at this time.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4