News for hackers. Stuff that matters.

A comment on Show HN: BinaryRPC – Lightweight WebSocket-based RPC framework in modern C++. Parent comment

Re:Show HN: BinaryRPC – Lightweight WebSocket-based RPC fram... by reactordev on Saturday July 12, 2025 @08:00PM (#44546294)
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. ;)

[ Parent | on HN ]
Re:Show HN: BinaryRPC – Lightweight WebSocket-based RPC fram... by inetknght on Saturday July 12, 2025 @11:20PM (#44547220)
> 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

[ Parent | on HN ]
Re:Show HN: BinaryRPC – Lightweight WebSocket-based RPC fram... by efecan0 on Sunday July 13, 2025 @03:40AM (#44548321)
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!

[ Parent | on HN ]
Re:Show HN: BinaryRPC – Lightweight WebSocket-based RPC fram... by efecan0 on Sunday July 13, 2025 @03:40AM (#44548314)
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!
[ Parent | on HN ]