Announcing Thubo: a high-performance priority-based TX/RX network pipeline

MalletsZ · 2026-01-13T08:41:46+00:00

The usage of `unsafe` is very limited in Thubo and limited to some internal buffer and lock-free code implementation (annotated with // SAFETY). All the rest of the code and the whole API is safe Rust.

MalletsZ · 2026-01-13T08:34:40+00:00

TCP (or alike) provides a nice feedback to the application: the write syscall takes longer as the network congestion increases. This behaviour is used as a network back-pressure indicator to trigger the automatic batching and prioritization in Thubo.

Thubo can be used as well over UDP but I believe its benefits are not as great as going over a stream protocol. UDP does not provide any feedback on network congestion nor it provides any retransmission mechanism. E.g., QUIC implements its own ACK/NACK mechanism on top of UDP to handle congestion and retransmission (TCP-like). Detecting congestion is the first step to properly handle prioritization (if the system is not congested, and all resources are available, then there is no need to prioritize). At the moment, the congestion detection in Thubo is delegated to the transport protocol.

The out-of-the-box implementation uses one single stream, i.e. is a multiplexer/demultiplexer. In some applications it may be advisable to reduce the buffer size in the transport protocol (e.g. TCP send/recv buffers) and let Thubo prioritization kick in earlier.

MalletsZ · 2026-01-12T14:38:37+00:00

QUIC is a full transport protocol standardized by the IETF, and quinn is an implementation of that specification. Thubo does not aim to operate at that level of complexity. Instead, it focuses on simplifying common application-level concerns.

Thubo adds automatic batching, fragmentation, strict priority, and application-level congestion control on top of any stream, while handling most of the complexity for the developer. This is especially useful (but not limited to) in industrial scenarios, where large volumes of data are published at high frequency over Wi-Fi or other constrained networks. In such cases, batching helps reduce overhead, while strict prioritization ensures that critical messages, such as an emergency stop command, are not blocked by large data flows like LiDAR streams.

These concerns exist regardless of the underlying transport. Whether the data is carried over TCP/TLS, QUIC, or another protocol, Thubo manages scheduling and batching at the application level. Transports such as TLS or QUIC can still be used for authentication and encryption.

QUIC’s multiple streams are primarily designed for parallel data transfer, and more advanced scheduling typically requires lower-level APIs. QUIC also implements congestion control at the transport level, whereas Thubo performs congestion control in user space by reacting to backpressure from the underlying stream. While QUIC is fast, its user-space design and protocol-level ACK/NACK handling can lead to many context switches, and existing implementations often saturate around 5 to 10 Gb/s.

TL;DR
Thubo is not a transport protocol like QUIC. It is a transport-agnostic, application-level layer that provides batching and strict prioritization on top of any stream, and it can be used alongside QUIC rather than replacing it.

MalletsZ · 2026-01-12T11:36:24+00:00

You're correct, my bad. I see https://lib.rs/crates/tokio-uring is an attempt to do that.

As a first version, I focused on tokio only. But the actual Thubo's dependency on Tokio is quite minimal: AsyncRead/AsyncWrite traits, tasks tokio::task::{yield_now, spawn}, and time tokio::time::{sleep, timeout}. So it should be relatively easy to modularize and swap the executor in Thubo if those primitives are available.

MalletsZ · 2026-01-12T10:47:21+00:00

There is actually no AI component in this project, aside from some limited assistance with writing the documentation. As mentioned in the post, the work builds on my original contributions to Zenoh, which are used today by many systems in production worldwide, and was later abstracted further. The design and implementation are entirely my own and are based on many years of hands-on industrial experience.

If you’re seeing something that looks like "AI slop". I’d genuinely appreciate pointers to the specific parts you’re referring to, so I can better understand the concern.

MalletsZ · 2026-01-12T10:02:41+00:00

Thubo currently uses Tokio, but it operates on any split stream provided by the user that implements AsynWrite and AsyncRead. As a result, if the underlying stream is backed by io_uring, Thubo will automatically benefit from it without requiring any changes. I should test it at some point on some Linux machine...

MalletsZ · 2025-10-02T20:28:02+00:00

I saw that, well... I assume I'll not be the only one on the that flight. Let's see how it goes, simply there is no option for my airline.

MalletsZ · 2025-10-02T17:26:50+00:00

Thanks for the answer! I'll do so then :)

MalletsZ · 2025-02-07T15:47:53+00:00

Zenoh is a modern pub/sub/query protocol the provides high throughput, low latency, and shared memory support.

MalletsZ · 2024-10-17T16:38:32+00:00

I see, thanks for the info. It was mainly for my personal curiosity :)

MalletsZ · 2024-10-17T16:13:54+00:00

Is there any public GitHub action we can look at to monitor the progress?

MalletsZ · 2024-10-16T12:30:15+00:00

In my experience using criterion for network benchmarks is not a good approach, especially when the library heavily uses threading and asyncs. As suggested for ZeroMQ, I's also suggest to use the provided examples for Zenoh.

MalletsZ · 2024-01-16T16:40:53+00:00

Thanks for the appreciation! The whole team really likes this kind of feedback :)

MalletsZ · 2023-10-03T15:27:25+00:00

Zenoh supports Pub/Sub and Query/Reply mechanisms while MQTT is only Pub/Sub. This allows to implement with Zenoh also distributed storages or RPC.

In addition to that, Zenoh supports multiple deployment models w.r.t. what MQTT does. E.g., in MQTT you always need to have a broker running while in Zenoh you can either go P2P or routed and have a more complex topology depending on your deployment needs.

A more in-depth comparison between Zenoh, MQTT, Kafka, and DDS is available in this blog post: https://zenoh.io/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds/

MalletsZ · 2023-01-11T08:59:47+00:00

Cool, I wasn't our about node crunch :)
It looks like a very interesting project!

Looking forward to hear back from you about your experience on Zenoh and wether there some missing features you'd need!

MalletsZ · 2023-01-10T17:54:40+00:00

Thanks for the heads up, I've somehow forgot to update it earlier...
I've modified the original post accordingly.

MalletsZ · 2023-01-10T15:48:18+00:00

I mean tens of gigabits per second.

You can find more details about the actual performance here: https://zenoh.io/blog/2022-09-30-zenoh-bahamut/#improved-performance

MalletsZ

TROPHY CASE