[efecan0]

Thank you for the extra information!

I am a recent CS graduate and I work on this project alone. I chose WebSocket over TCP because it is small, easy to read, and works everywhere without extra tools. gRPC + HTTP/3 is powerful but adds many libraries and more code to learn.

When real users need QUIC or multiplexing, I can change the transport later. Your feedback helps me a lot.

[reactordev]

The point people are beating around the bush at here is that a binary RPC framework has no such need for HTTP handling, even for handshaking, when a more terse protocol of your own design would/could/might? be better.

I totally understand your reasoning behind leaning on websockets. You can test with a data channel in a browser app. But if we are talking low-latency, Superman fast, modern C++, RPC and forgeddaboutit. Look into handling an initial payload with credential negotiation outside of HTTP 1.1.

[efecan0]

You’re right: HTTP adds an extra RTT and headers we don’t strictly need.

My current roadmap is:

1. Keep WebSocket as the “zero-config / browser-friendly” default. 2. Add a raw-TCP transport with a single-frame handshake: [auth-token | caps] → ACK → binary stream starts. 3. Later, test a QUIC version for mobile / lossy networks.

So users can choose: * plug-and-play (WebSocket) * ultra-low-latency (raw TCP)

Thanks for the nudge this will go on the transport roadmap.

[reactordev]

The actual handshake part of WebSockets is good. Send a NONCE/KEY and get back a known hash encoded however you like. This can be as little as 24 bytes or as much as 1024. Just sending the HTTP preamble eats through 151 bytes at least. Imagine that for every connection, per every machine... That's a lot of wasted bandwidth if one can skip it.

Compression helps but I think if you want to win over the embedded crowd, having a pure TCP alternative is going to be a huge win. That said, do NOT abandon the HTTP support, WebSockets are still extremely useful. WebRTC is too. ;)

[efecan0]

Agree: for small devices every byte counts. Plan is to keep WebSocket for zero-config use, but add a raw-TCP handshake (~24-40 bytes) so embedded clients can skip the HTTP preamble. I’ll note that on the transport roadmap. Appreciate the insights!

[inetknght]

> Compression helps

It's generally unwise to use compression for encrypted transport such as TLS or HTTP/S.

https://en.wikipedia.org/wiki/Oracle_attack

[efecan0]

Good point, thank you.

You’re right—no compression over TLS by default. If I add deflate support later it will be opt-in and disabled when the connection is encrypted.

Appreciate the insights!

[gr4vityWall]

Shouldn't WebSockets be comparable to raw TCP + a simple message protocol on top of it once you're done with the initial handshaking and protocol upgrade?

I wouldn't expect latency to be an issue for long lived connections, compared to TCP.

[reactordev]

no but reliability is. And if you need to re-establish the connection, you'll have to preamble your way through another handshake.

gRPC uses HTTP/2, which has a Client/Server Stream API, to forgo the preamble. In the end though, ANY HTTP based protocol could be throttled by infrastructure in-between. TCP on the other hand, can be encrypted and sent without any preamble - just a protocol, and only L2/L3 can throttle.