#grpc

Hi. I'm trying to build a deliverable grpc on Windows using cmake. I think I got the building figured out but the install target gives me trouble. I end up with gRPCTargets-*.cmake files that contain absolute paths instead of ones relative for the grpc as well as the dependency libraries. I obviously can't use these for find_package on any other system. Does anyone have an idea how to fix this? Thanks.

Here is one of the generated files in question: https://pastebin.com/mCfckkeb

For comparison here the corresponding file gflags created: https://pastebin.com/jSVfYPUp . As you can see it doesn't specify any absolute paths.

The grpc CMakeLists.txt has some issues. I think I have solved the problem with the help of #cmake and will try to create a PR to fix them this weekend.

i have short lived processes that need grpc, is there a high startup time besides the tcp 3 way handshake?

like, does connecting send data to the server and wait for a rely or anything?

lungaro: in my experience grpc seems very low latency once the connection is established, but everything is relative, there is a continuous benchmarking page I believe?

One of the actual dashboards, https://performance-dot-grpc-testing.appspot.co...

well i already know connecting each time a process is spawned is not ideal

i guess I have to do my own bench

please post your results back here, I'm interested. My guess is that it'll be high-ish compared to raw udp or something, because it establishes an actual http connection, not just a tcp connection, there might be a few extra rounds of back and forth

but you get lots of benefits from that compared to raw udp, so... /shrug ?

yeah, I will save this for later though. Just showing an strace shows every new connection does this

write(6, "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n", 24) = 24

then reads back some response

then writes again (the actual request)

that's double the RTT for a single RPC

lungaro: sure, but again you get a lot for that... if you need it

no, this is after the tcp handshake

i'm wondering about HTTP2 or GRPC doing crap before calling an RPC (ie, on connect)

maybe I can port it to HTTP and do just a POST request/response

Maybe the grpc-gateway stuff would do that?

i'll check it out. thanks

lungaro: Which implementation are you looking at?

go

I think C doesn't wait for the HTTP/2 handshake before starting. Java does, but that only adds latency when using plaintext.

I guess Go waits as well.

It isn't actually a requirement; we could send RPCs as soon as the TCP connection is established.

lungaro: Oh, and TCP fast open would remove a RTT for a server that's been contected to before.