5 ms·

My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?

by jayd16 1y ago

efecan0 1y ago
I started with WebSocket over TCP for practical reasons: * Works everywhere today (browsers, LB, PaaS) with zero extra setup. * One upgrade -> binary frames; no gRPC/proto toolchain or HTTP/3 infra needed. * Simple reliability: TCP handles ordering; I add optional QoS2 on top. * Lets me focus on session/room/middleware features first; transport is swappable later. QUIC / gRPC-HTTP/3 is on the roadmap once the higher-level API stabilises.
- seangrogg 1y ago
  Assuming you're locked in on the browser WebSockets are about as good as it gets at present. HTTP/3 requires WebTransport which has been a bit of a shitshow in terms of getting things up and running so far, in my experience.
  - efecan0 1y ago
    Thanks, that matches my experience as well. For browser clients WebSocket is still ‘the path of least pain’, so I’m keeping it as the default. When WebTransport and QUIC become easier to deploy I’ll add an optional transport module. If you’ve tried any recent WebTransport builds and have tips or docs, I’d love to see them—feel free to open an issue or drop a link. Appreciate the confirmation!
inetknght 1y ago
I'm not the author but off the top of my head: - gRPC is not a library I would trust with safety or privacy. It's used a lot but isn't a great product. I have personally found several fuckups in gRPC and protobuf code resulting in application crashes or risks of remote code execution. Their release tagging is dogshit, their implementation makes you think the standard library and boost libraries are easy to read and understand, and neither takes SDLC lifecycles seriously since there aren't sanitizer builds nor fuzzing regime nor static analysis running against new commits last time I checked. - http/3 using UDP sends performance into the crater, generally requiring _every_ packet to reach the CPU in userspace instead of being handled in the kernel or even directly by the network interface hardware - multiplexing isn't needed by most websocket applications
- efecan0 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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. ;)
cherryteastain 1y ago
gRPC's C++ interfaces have horrible design if you want async behaviour. Tons of unsafe and bad practices like the need to call delete this [1] [1] https://grpc.io/docs/languages/cpp/callback/ https://grpc.io/docs/languages/cpp/callback/
jeffbee 1y ago
Ironically this library is much closer to what Google uses internally than grpc is.
- efecan0 1y ago
  Interesting point, thanks!
unit149 1y ago
[dead]
deleted 1y ago
[deleted]

My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?

by jayd16 1y ago

My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?

efecan0 1y ago

I started with WebSocket over TCP for practical reasons: * Works everywhere today (browsers, LB, PaaS) with zero extra setup. * One upgrade -> binary frames; no gRPC/proto toolchain or HTTP/3 infra needed. * Simple reliability: TCP handles ordering; I add optional QoS2 on top. * Lets me focus on session/room/middleware features first; transport is swappable later. QUIC / gRPC-HTTP/3 is on the roadmap once the higher-level API stabilises.

seangrogg 1y ago
Assuming you're locked in on the browser WebSockets are about as good as it gets at present. HTTP/3 requires WebTransport which has been a bit of a shitshow in terms of getting things up and running so far, in my experience.
- efecan0 1y ago
  Thanks, that matches my experience as well. For browser clients WebSocket is still ‘the path of least pain’, so I’m keeping it as the default. When WebTransport and QUIC become easier to deploy I’ll add an optional transport module. If you’ve tried any recent WebTransport builds and have tips or docs, I’d love to see them—feel free to open an issue or drop a link. Appreciate the confirmation!

inetknght 1y ago

I'm not the author but off the top of my head: - gRPC is not a library I would trust with safety or privacy. It's used a lot but isn't a great product. I have personally found several fuckups in gRPC and protobuf code resulting in application crashes or risks of remote code execution. Their release tagging is dogshit, their implementation makes you think the standard library and boost libraries are easy to read and understand, and neither takes SDLC lifecycles seriously since there aren't sanitizer builds nor fuzzing regime nor static analysis running against new commits last time I checked. - http/3 using UDP sends performance into the crater, generally requiring _every_ packet to reach the CPU in userspace instead of being handled in the kernel or even directly by the network interface hardware - multiplexing isn't needed by most websocket applications

efecan0 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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. ;)

cherryteastain 1y ago

gRPC's C++ interfaces have horrible design if you want async behaviour. Tons of unsafe and bad practices like the need to call delete this [1] [1] https://grpc.io/docs/languages/cpp/callback/ https://grpc.io/docs/languages/cpp/callback/

jeffbee 1y ago

Ironically this library is much closer to what Google uses internally than grpc is.

efecan0 1y ago
Interesting point, thanks!

unit149 1y ago

[dead]

deleted 1y ago

[deleted]