Comment by jayd16
2 days ago
My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?
2 days ago
My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?
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.
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.
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!
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/
Ironically this library is much closer to what Google uses internally than grpc is.
Interesting point, thanks!
[dead]
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
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.
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.
7 replies →
> I have personally found several fuckups in gRPC and protobuf code resulting in application crashes or risks of remote code execution.
Would be great if you report such remote code executions to the authors/Google. I am sure they handle CVEs etc. There has been a security audit like https://github.com/grpc/grpc/tree/master/doc/grpc_security_a...
> there aren't sanitizer builds nor fuzzing regime nor static analysis running against new commits last time I checked.
Are you making shit up as you go? I randomly picked a recently merged commit and this is the list of test suites ran on the pull request. As far as I recall, this has been the practice for at least 8 years+ (note the MSAN, ASAN, TSAN etc.)
I can see various fuzzers in the code base so that claim is also unsubstantiated https://github.com/grpc/grpc/tree/f5c26aec2904fddffb70471cbc...
Interesting discussion. My current goal isn’t to replace gRPC but to offer a lighter option for simple real-time apps. I’ll keep following the thread; the security links are useful, thanks.
> Would be great if you report such remote code executions to the authors/Google. I am sure they handle CVEs etc.
I wasn't getting paid to fix their code, I have no interest in helping Google for free, and don't want to help Google.
> There has been a security audit like
A checkbox report from six years ago. That's ancient times at the pace that things are added to gRPC.
> Are you making shit up as you go?
No. This [0] repo I used to reproduce a stack smash issue before `main()`. I reported the issue here [1]. I don't get paid to fix Google's things and found a workaround for the purposes I needed.
[0]: https://github.com/keith-bennett-airmap/grpc-stacksmash
[1]: https://github.com/protocolbuffers/protobuf/issues/12732
> I can see various fuzzers in the code base so that claim is also unsubstantiated
Fuzzers are cool, but they don't cover the whole codebase.
2 replies →