Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does gRPC insist on trailers?

carlmastrangelo.com

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Why does gRPC insist on trailers?

#101

Post by sneak »

twiss wrote: post #28

> Whether it’s because I was wrong, or failed to make the argument [for HTTP trailers support], I strongly suspect organizational boundaries had a substantial effect. The Area Tech Leads of Cloud also failed to convince their peers in Chrome, and as a result, trailers were ripped out [from the WHATWG fetch specification]. FWIW, I personally think it's a good thing that other teams within Google don't have too much of…

Why should the decisionmaking process for Chromium be “democratic” simply because it is open source?

Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time].

If Google is paying for the implementors’ time, Google should have 100% say in what code they write. You and everyone else are free (thanks to Google’s generosity) to fork it at any point in the commit history and individually veto any specific change.

Re: Why does gRPC insist on trailers?

#102

Post by crest »

jiggawatts wrote: post #97

Something that’s always bugged me about streaming protocols of this type is that they prevent processing pipelining. If trailers are used for things such as checksums, then the client must wait patiently for potentially gigabytes of data to stream to it before it can verify the data integrity and start processing it safely. If the data is sent chunked, then this is not an issue. The client can start decoding chunks a…

I would argue that RPC systems shouldn't be burdened down with features like this. If you want to exchange more date than either endpoint can buffer comfortably in memory split it up into several RPC messages e.g. create large object, define byte range, seal object. If the producer can precompute the length and hash you can simplify things by using content addressing to reference such objects and replicate them. If you can afford the overhead breaking them up into Merkle DAGs reasonably sized leaves is a good idea to allow validating and resuming partial transfers. It matters if your devices are connected via PCIe in a single chassis or mobile networks spread over half the world and datacenter optimised protocol won't be optimal for expensive, slow, unreliable links.

Re: Why does gRPC insist on trailers?

#103

Post by jmillikin »

jiggawatts wrote: post #97

Something that’s always bugged me about streaming protocols of this type is that they prevent processing pipelining. If trailers are used for things such as checksums, then the client must wait patiently for potentially gigabytes of data to stream to it before it can verify the data integrity and start processing it safely. If the data is sent chunked, then this is not an issue. The client can start decoding chunks a…

This comment is mixing up a few concerns.

1. When transferring large amounts of data, the checksum for the full transfer can't be verified until all the data is received. If you want to (for example) download an Ubuntu ISO and verify its checksum before installing it, you'll have to buffer the data somewhere until the download finishes.

2. When transferring small amounts of data, such as individual chunks, the data integrity is (/ should be) automatically verified by the encryption layer[0] of the underlying transport. There's no point in putting a shasum into each chunk because if a bit gets flipped in transit then that chunk will never even arrive in your message handler.

3. In gRPC, chunking large data transfers is mandatory because the library will reject Protobuf messages larger than a few megabytes[1]. As the chunks of data arrive, they can be passed into a hash function at the same time as you're buffering them to disk.

[0] gRPC supports running without encryption for local development, but obviously for real workloads you'd do end-to-end TLS.

[1] IIRC the default for C++ and Go implementations of gRPC is 4 MiB, which can be overridden when the client/server is being initialized. For bulk data transfer there's also the Protobuf hard limit of 2GB[2] for variable-length data.

[2] https://developers.google.com/protocol-buffers/docs/encoding

Re: Why does gRPC insist on trailers?

#104

Post by IshKebab »

chucky_z wrote: post #30

From my perspective, I think the biggest issue with gRPC is it using HTTP/2. I understand that there’s a lot of reasons to say “No, HTTP/2 is far superior to HTTP/1.1.” However, in terms of proxying _outside Google_ HTTP/2 has lagged, and continues to lags at the L7 proxy layer. I recently performed a lot of high-throughput proxying comparing HAProxy, Traefik, and Envoy. HTTP/1.1 outperformed HTTP/2 (even H2C) by a p…

I agree. HTTP/2 is a huge requirement to push everywhere you want to use RPC. Want to do RPC to a microcontroller? Tough luck. Want to make RPC calls from a web page? Yeah have fun figuring out the two incompatible gRPC-web systems, setting up complicated proxies and actually finding a gRPC library that actually supports them fully.

Thrift has a much more sane design where everything is pluggable including the transport layer.

Bit of a shame that Thrift never became more popular.

Re: Why does gRPC insist on trailers?

#105

Post by __alexs »

rswail wrote: post #82
akshayshah wrote: post #81

Earlier quoted context omitted.

That's true of CORBA, for sure. I'm not familiar with ONC-RPC or Java RMI. It's not true of gRPC. It's not "RPC" in any traditional sense - it's just a particular HTTP convention, and the clients reflect that. They're asynchronous, make deadlines and transport errors first-class concepts, and make it easy to work with HTTP headers (and trailers, as the article explains). Calling a gRPC API with a generated client oft…

The verb-oriented style is part of the problem. Too many verbs is the problem. Java/OOP problems are not the same as the REST style, which is entirely about Nouns. There's none of the Java ManagerFactoryManager problems. The generated client from an IDL that wraps the network protocol with a function call is also part of the problem. REST APIs that have function calls that aren't "Send Request and wait for Response"…

gRPC has no opinion on what you name things.

Re: Why does gRPC insist on trailers?

#106

Post by Brian_K_White »

sneak wrote: post #101
twiss wrote: post #28

> Whether it’s because I was wrong, or failed to make the argument [for HTTP trailers support], I strongly suspect organizational boundaries had a substantial effect. The Area Tech Leads of Cloud also failed to convince their peers in Chrome, and as a result, trailers were ripped out [from the WHATWG fetch specification]. FWIW, I personally think it's a good thing that other teams within Google don't have too much of…

Why should the decisionmaking process for Chromium be “democratic” simply because it is open source? Anyone who wants to pay can implement whatever they want in the codebase. That’s in a way as democratic as it gets: equality of opportunity [to invest money and time]. If Google is paying for the implementors’ time, Google should have 100% say in what code they write. You and everyone else are free (thanks to Google’s…

The democratic process is that anyone who wants to pay for the ad campaign can try to convince everyone else that it's a good spec everyone should adopt, not merely pay a developer to code it.

If everyone else is not convinced then it should not become a thing no matter how much one party with money wants it.

Re: Why does gRPC insist on trailers?

#107

Post by vidarh »

thamer wrote: post #27

A few years ago I worked on a service that had to stream data out using protobuf messages, in a single request that could potentially transfer several gigabytes of data. At the HTTP level it was chunked, but above that I used a protobuf message that contained data plus a checksum of that data, with the last message of the stream containing no data but a checksum of the entire dataset (a flag was included to different…

Inserting metadata in the protobuf itself seems like the obvious, simple solution to avoid having to depend on what the transport layer supports. Just defining a message to provide the metadata they wanted to insert in trailers would have avoided a whole lot of pain.

Re: Why does gRPC insist on trailers?

#108

Post by vidarh »

candiodari wrote: post #98
akshayshah wrote: post #77

Earlier quoted context omitted.

I've spent a fair bit of time working with gRPC, and you're correct - gRPC's length-prefixing makes it easy to detect when individual messages are terminated early. You do still need some way to detect streams that terminate unexpectedly on message boundaries - perhaps you could rely on HTTP/2 EOS bits as evidence of an application-level success, but you need some equivalent of trailers to communicate the details of…

First, we need to clarify. The problem is that you cannot use GRPC from javascript (yes, there's unofficial, and sketchily supported, hacks, but read on for why they're required) He explains the problem that caused this, in his opinion, in the article, but not very obviously. The problem is protobuf encoding. It's key-length-value (key identifies the field that follows, length is the length of the value, value is the…

Another option is simply to reserve a key (or multiple) for providing stream/transport specific metadata which should be stripped out before handoff to the client, such as allowing you to send an "end" marker. Now you're not depending on the transport layer cooperating. It's not a particularly hard problem.

Re: Why does gRPC insist on trailers?

#109

Post by bpicolo »

mort96 wrote: post #79
thayne wrote: post #52

Earlier quoted context omitted.

Also, http/2 over cleartext is not very well supported by a lot of things. Which is probably a good thing when going over the open internet. But it means you have to deal with setting up certificates even if just developing locally, and makes it more difficult to use for IPC on a single host.

My preferred setup is to have an unencrypted service running on 127.0.0.1 (so not publicly available), and then have nginx in front to handle certificates. Lets me do all certificate stuff across all virtual hosts in one place. HTTP/2 makes this impossible due to its ridiculous TLS requirement, so I, and everyone who does it the way I do, must keep using HTTP/1.1 forever. It's my belief that requiring TLS for HTTP/2…

A few years back it seemed the ecosystem had the tools needed for h2c (HTTP/2 minus TLS) to work out. Was able to get the proto service set up in Golang, and work with a couple different proxy options

Re: Why does gRPC insist on trailers?

#110

Post by ackfoobar »

withinboredom wrote: post #88
alexcpn wrote: post #53

I use GRPC between micro services instead of REST and for that it is really great; All the deficiencies of REST - Non versioned, no typed goes away with GRPC and the protobuf is the official interface for all micro-services. No problems with this approach for over two years now; and also multi language support - We have Go and Java and Python and TypeScript micro-services now happily talking and getting new features…

With GRPC, you lose the ability to introspect the data on-the-wire. You lose the ability to create optimized data formats for YOUR application (who said you have to use JSON?) Most people can’t implement REST correctly, so it has been a shitshow for the last 20 or so years, GRPC isn’t a magic bullet, it just forces you to solve problems (or helps you to solve them) that you should have been doing in the first place.…

I suppose you mean "inspect" the data on-the-wire

https://grpc.io/blog/wireshark/

Wireshark can load proto files and decode the data for you.

BTW, "The Internet is running in debug mode".

Post reply on HN