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

21–30 of 116 posts

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

#21

Post by codeflo »

manv1 wrote: post #19

This paragraph is just wrong: "Another explanation is that the Internet has unnecessarily coupled the transport protocol with the rest of the RPC framework. Conflating the two naturally follows from the purpose-built examples I just gave: SMTP is bundled with MIME; SNMP is bundled with MIB; and HTTP is bundled with HTML. " I think at this point he's suffering from what old-timers used to call recto-cranial inversion.

I think I feel dumber for reading this. (The referenced paper by Ousterhout is quite good though, and doesn’t confuse the terminology. Maybe that one’s what HN should link and discuss.)

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

#23

Post by User23 »

bob1029 wrote: post #17

There are some things that current RPC frameworks simply cannot touch. I've been up to my elbows in TCP lately. Working on a low-latency, select-based socket server for streaming gaming applications. Each instance runs on 1 thread so there is absolutely no context switching delay when servicing player requests. The TCP streams are responsible for moving player inputs and game state as quickly as possible between syst…

A well written C mux is absurdly performant. I was handling thousands of requests per second with efficient hand rolled binary protocols in the early oughts when I could make UDP work, which I could since it was an intra datacenter app and a super lightweight exponential backoff retry scheme on the client side was entirely adequate. “Modern” network programming is hilariously inefficient. I think games are the only mass market exception since that’s the one area where optimal network performance affects pleasantness. Gamers used to speak of netcode almost reverently.

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

#24

Post by User23 »

Karrot_Kream wrote: post #18
bob1029 wrote: post #17

There are some things that current RPC frameworks simply cannot touch. I've been up to my elbows in TCP lately. Working on a low-latency, select-based socket server for streaming gaming applications. Each instance runs on 1 thread so there is absolutely no context switching delay when servicing player requests. The TCP streams are responsible for moving player inputs and game state as quickly as possible between syst…

Do you mean the `select` call? libuv and friends can offer higher throughput than `select`.

It’s been many many years since I’ve done low level multiplexing but I think epoll() is the no longer quite so new hotness?

Ah I see libuv is a cross platform lib. I’d probably use that for production code, but it’s still really valuable to work with the low level API enough to understand it.

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

#25

Post by bob1029 »

Karrot_Kream wrote: post #18
bob1029 wrote: post #17

There are some things that current RPC frameworks simply cannot touch. I've been up to my elbows in TCP lately. Working on a low-latency, select-based socket server for streaming gaming applications. Each instance runs on 1 thread so there is absolutely no context switching delay when servicing player requests. The TCP streams are responsible for moving player inputs and game state as quickly as possible between syst…

Do you mean the `select` call? libuv and friends can offer higher throughput than `select`.

Whatever OS primitive this API effectively calls is what I use:

https://learn.microsoft.com/en-us/dotnet/api/system.net.sock...

Edit: This is the source: https://source.dot.net/#System.Net.Sockets/System/Net/Socket...

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

#26

Post by bob1029 »

User23 wrote: post #23
bob1029 wrote: post #17

There are some things that current RPC frameworks simply cannot touch. I've been up to my elbows in TCP lately. Working on a low-latency, select-based socket server for streaming gaming applications. Each instance runs on 1 thread so there is absolutely no context switching delay when servicing player requests. The TCP streams are responsible for moving player inputs and game state as quickly as possible between syst…

A well written C mux is absurdly performant. I was handling thousands of requests per second with efficient hand rolled binary protocols in the early oughts when I could make UDP work, which I could since it was an intra datacenter app and a super lightweight exponential backoff retry scheme on the client side was entirely adequate. “Modern” network programming is hilariously inefficient. I think games are the only m…

I am not even planning to push any sort of limits here. There are architectural elements which coalesce requests towards the edges into fewer, larger pipes. At most, any one of my socket servers will be responsible for 1k connections.

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

#28

Post by chasil »

bob1029 wrote: post #17

There are some things that current RPC frameworks simply cannot touch. I've been up to my elbows in TCP lately. Working on a low-latency, select-based socket server for streaming gaming applications. Each instance runs on 1 thread so there is absolutely no context switching delay when servicing player requests. The TCP streams are responsible for moving player inputs and game state as quickly as possible between syst…

I've used NFS over stunnel and I don't see any performance problems, but I do have the perception that it is not a panacea.

I've read that kerberos NFS encryption has performance problems that stunnel solves.

I've never sunk down to ONC RPC, but it does feel like it's a hack compared to QUIC.

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

#29

Post by hardwaresofton »

If you'd like to watch Ousterhoust explain Homa and his vision of replacing TCP:

https://www.youtube.com/watch?v=o2HBHckrdQc

Spoiler: Ousterhout is right, and the data shows he is right. Maybe not everyone knows it yet, or it's the kind of "right" that not everyone will ever get to (and we'll settle for "good enough" for much longer), but he is almost certainly right.

Not to disparage the poster of this article of course -- I always love a good hot take or contrarian piece, but if you can't come with the same amount of data to support your thesis...

Homa is probably dismissable on UX grounds (are people really going to switch to it?), but it's clear that long hard thinking has gone into the case for Homa (and it's implementation).

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

#30

Post by Animats »

There have been lots of RPC protocols. Here are some still in use.

Transport level:

* Sun RPC [1]. QNX still uses this. It can run over UDP or over raw Ethernet. It just transfers an array of bytes and gets an array of bytes back - marshalling is a higher level problem. It handles messages bigger than one packet, and retransmission. It's simple and performance is good, but there is no security.

* Stream Control Transmission Protocol. Telcos still use this. It's how Signalling System 7 is sent over IP.

Although many implementations exist for both, they've never been popular outside their niches.

Marshalling level:

* CORBA - you define interfaces in a special language and compile them. Data is not self-describing.

* SOAP, from the XML era.

* Google Protocol Buffers - another system where you compile definitions.

* HTTP/JSON - where we are now.

Plus a lot of Microsoft-specific stuff.

Either you have a system where both ends have to exactly agree on format, you have a verbose format with unneeded description data in every message, or you have a very complicated negotiation at connection time. This leads to much disagreement.

[1] https://en.wikipedia.org/wiki/Sun_RPC

Post reply on HN