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

It's TCP vs. RPC All over Again

systemsapproach.substack.com

Post reply on HN
Print view View original

1–10 of 116 posts

Re: It's TCP vs. RPC All over Again

#3

Post by tonymillion »

ktpsns wrote: post #2

What are the best recommendations for modern day low latency RPC? Google protocol buffers? Or some message queue such as ZeroMQ?

You’re thinking too high level, this is talking about replacing TCP or UDP with a new transport protocol designed specifically with RPC in mind.

Instead of opening a TCP (or UDP) socket and writing data (or data grams) to it you’d open a (for want of a better term) RPCP socket and write data that represents the procedure call and parameters to it.

I assume the protocol would have assurances of some kind of reliability (unlike UDP) and procedure call data boundaries (unlike TCP) built in at the lowest levels along with request/response sequences to allow out of order completions.

Re: It's TCP vs. RPC All over Again

#4

Post by iambvk »

Good to learn a bit of history about TCP.

It always felt weird developing RPC layers on top of TCP cause requests and responses end up tied to the underlying socket -- which doesn't need to be the case ever.

Re: It's TCP vs. RPC All over Again

#8

Post by jiggawatts »

dist1ll wrote: post #7
ktpsns wrote: post #2

What are the best recommendations for modern day low latency RPC? Google protocol buffers? Or some message queue such as ZeroMQ?

Check out eRPC.io It leverages DPDK and is perfect for low-latency RPC in lossless DCs

It would be nice to have something like that, but have libraries for most common languages.

Re: It's TCP vs. RPC All over Again

#9

Post by AceJohnny2 »

iambvk wrote: post #4

Good to learn a bit of history about TCP. It always felt weird developing RPC layers on top of TCP cause requests and responses end up tied to the underlying socket -- which doesn't need to be the case ever.

How else would the kernel know to which application it should route a response?

Re: It's TCP vs. RPC All over Again

#10

Post by drbruced »

ktpsns wrote: post #2

What are the best recommendations for modern day low latency RPC? Google protocol buffers? Or some message queue such as ZeroMQ?

Part of what we're arguing in this article is that there is no good answer today because of the assumption that TCP was good enough. Homa is challenging that assumption (as many others have tried before). My view is that if you want something better than TCP for RPC today, QUIC is the best thing available, as discussed here: https://systemsapproach.substack.com/p/quic-is-not-a-tcp-rep...

What you run over that for your RPC is a matter of taste - gRPC is certainly popular, and can be run over QUIC.

Post reply on HN