3 ms·

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

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. ;)
      - inetknght 1y ago
        > 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 https://en.wikipedia.org/wiki/Oracle_attack
        efecan0 1y ago
        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!
      - efecan0 1y ago
        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!
  - gr4vityWall 1y ago
    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 1y ago
      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.
tgma 1y ago
> 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_audit.pdf 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/f5c26aec2904fddffb70471cbc78da0946be4bf8/test/core/end2end/fuzzers https://github.com/grpc/grpc/tree/f5c26aec2904fddffb70471cbc... Android (Internal CI) Kokoro build finished Basic Tests C Windows Kokoro build finished Basic Tests C# Linux Kokoro build finished Basic Tests C# MacOS Kokoro build finished Basic Tests C# Windows Kokoro build finished Basic Tests C++ iOS Kokoro build finished Basic Tests C/C++ Linux [Build Only] Kokoro build finished Basic Tests ObjC Examples Kokoro build finished Basic Tests ObjC iOS Kokoro build finished Basic Tests PHP Linux Kokoro build finished Basic Tests PHP MacOS Kokoro build finished Basic Tests Python Linux Kokoro build finished Basic Tests Python MacOS Kokoro build finished Bazel Basic Tests for Python (Local) Kokoro build finished Bazel Basic build for C/C++ Kokoro build finished Bazel C/C++ Opt MacOS Kokoro build finished Bazel RBE ASAN C/C++ Kokoro build finished Bazel RBE Build Tests Kokoro build finished Bazel RBE Debug C/C++ Kokoro build finished Bazel RBE MSAN C/C++ Kokoro build finished Bazel RBE Opt C/C++ Kokoro build finished Bazel RBE TSAN C/C++ Kokoro build finished Bazel RBE Thready-TSAN C/C++ Kokoro build finished Bazel RBE UBSAN C/C++ Kokoro build finished Bazel RBE Windows Opt C/C++ Kokoro build finished Bloat Diff Kokoro build finished Bloat Difference Bloat Difference Clang Tidy (internal CI) Kokoro build finished Distribution Tests C# Linux Kokoro build finished Distribution Tests C# MacOS Kokoro build finished Distribution Tests C# Windows Kokoro build finished Distribution Tests Linux (standalone subset) Kokoro build finished Distribution Tests PHP Linux Kokoro build finished Distribution Tests PHP MacOS Kokoro build finished Distribution Tests Python Linux Arm64 Kokoro build finished Distribution Tests Ruby MacOS Kokoro build finished Distribution Tests Windows (standalone subset) Kokoro build finished EasyCLA EasyCLA check passed. You are authorized to contribute. Grpc Examples Tests CPP Kokoro build finished Memory Difference Memory Difference Memory Usage Diff Kokoro build finished Mergeable Mergeable Run has been Completed! Migration Test MacOS Sonoma Kokoro build finished ObjC Bazel Test Kokoro build finished Portability Tests Linux [Build Only] (internal CI) Kokoro build finished Portability Tests Windows [Build Only] (internal CI) Kokoro build finished Sanity Checks (internal CI) Kokoro build finished Tooling Tests Python Linux Kokoro build finished Windows clang-cl with strict warnings [Build Only] Kokoro build finished

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. ;)
    - inetknght 1y ago
      > 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 https://en.wikipedia.org/wiki/Oracle_attack
      - efecan0 1y ago
        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!
    - efecan0 1y ago
      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!
- gr4vityWall 1y ago
  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 1y ago
    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.

tgma 1y ago

> 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_audit.pdf 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/f5c26aec2904fddffb70471cbc78da0946be4bf8/test/core/end2end/fuzzers https://github.com/grpc/grpc/tree/f5c26aec2904fddffb70471cbc... Android (Internal CI) Kokoro build finished Basic Tests C Windows Kokoro build finished Basic Tests C# Linux Kokoro build finished Basic Tests C# MacOS Kokoro build finished Basic Tests C# Windows Kokoro build finished Basic Tests C++ iOS Kokoro build finished Basic Tests C/C++ Linux [Build Only] Kokoro build finished Basic Tests ObjC Examples Kokoro build finished Basic Tests ObjC iOS Kokoro build finished Basic Tests PHP Linux Kokoro build finished Basic Tests PHP MacOS Kokoro build finished Basic Tests Python Linux Kokoro build finished Basic Tests Python MacOS Kokoro build finished Bazel Basic Tests for Python (Local) Kokoro build finished Bazel Basic build for C/C++ Kokoro build finished Bazel C/C++ Opt MacOS Kokoro build finished Bazel RBE ASAN C/C++ Kokoro build finished Bazel RBE Build Tests Kokoro build finished Bazel RBE Debug C/C++ Kokoro build finished Bazel RBE MSAN C/C++ Kokoro build finished Bazel RBE Opt C/C++ Kokoro build finished Bazel RBE TSAN C/C++ Kokoro build finished Bazel RBE Thready-TSAN C/C++ Kokoro build finished Bazel RBE UBSAN C/C++ Kokoro build finished Bazel RBE Windows Opt C/C++ Kokoro build finished Bloat Diff Kokoro build finished Bloat Difference Bloat Difference Clang Tidy (internal CI) Kokoro build finished Distribution Tests C# Linux Kokoro build finished Distribution Tests C# MacOS Kokoro build finished Distribution Tests C# Windows Kokoro build finished Distribution Tests Linux (standalone subset) Kokoro build finished Distribution Tests PHP Linux Kokoro build finished Distribution Tests PHP MacOS Kokoro build finished Distribution Tests Python Linux Arm64 Kokoro build finished Distribution Tests Ruby MacOS Kokoro build finished Distribution Tests Windows (standalone subset) Kokoro build finished EasyCLA EasyCLA check passed. You are authorized to contribute. Grpc Examples Tests CPP Kokoro build finished Memory Difference Memory Difference Memory Usage Diff Kokoro build finished Mergeable Mergeable Run has been Completed! Migration Test MacOS Sonoma Kokoro build finished ObjC Bazel Test Kokoro build finished Portability Tests Linux [Build Only] (internal CI) Kokoro build finished Portability Tests Windows [Build Only] (internal CI) Kokoro build finished Sanity Checks (internal CI) Kokoro build finished Tooling Tests Python Linux Kokoro build finished Windows clang-cl with strict warnings [Build Only] Kokoro build finished