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

71–80 of 116 posts

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

#71

Post by lozenge »

matjet wrote: post #52
codeflo wrote: post #21

Earlier quoted context omitted.

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.)

To someone only weakly aware in this area, can you explain what is wrong with the statement? From a cursory view, these protocols indeed seem to normally carry the mentioned payloads.

It's not like HTTP stops working if you choose to send something besides HTML. Most of its features still work and make sense for JSON payloads and the usual building blocks still work (eg HTTPS, load balancers, proxies, status codes, redirects...)

There are a few bits that don't make sense eg cookies where the server sends something and the client is expected to remember it but they can just be ignored.

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

#72

Post by mountainboy »

Animats wrote: post #30

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 Trans…

> SOAP, from the XML era.

Don't forget XML-RPC :-)

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

#73

Post by denton-scratch »

cryptonector wrote: post #54
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.

Agreed. MIME came after SMTP, for example, and HTTP is used for all sorts of not-HTML-or-hyper-anything stuff. That statement smacks me of "wow, HTTP is a pretty good RPC, but too bad it's only/mainly for transporting HTML, shucks!". The name of the protocol is not very representative anymore either of how it's used or how anyone should use it. If HTTP fits the bill, then use it and move on.

MIME not only arrived after SMTP (the 'E' in MIME stands for 'extension'); it doesn't infect the SMTP part of the stack. There's nothing in SMTP that would have to change if MIME was abolished. SMTP provides no special support for MIME. They are disjoint.

Since HTTP/1.1, HTTP hasn't been premised on HTML, and vice-versa; again they are disjoint.

I don't know why author makes these claims.

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

#74

Post by dist1ll »

Karrot_Kream wrote: post #49
bob1029 wrote: post #25

Earlier quoted context omitted.

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...

I didn't dive past the links you dropped, but reading the doc comment makes it seem like the call is using `poll` (as an alternative to `select` for FD size reasons.) It's well recognized that the polling model of `select` and `poll` are slow and it was specifically this problem that led to the framing of the C10K problem. The solution is to use an async style of programming which is what libuv and other wrappers off…

Interestingly enough, polling is still preferred in some cases of low-latency networking, because the overhead of NIC interrupts can become significant under high utilization.

Of course in those cases you're running on bare-metal with kernel bypass networking, so there's no userkernel switch like in poll

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

#75

Post by codeflo »

lozenge wrote: post #71
matjet wrote: post #52

Earlier quoted context omitted.

To someone only weakly aware in this area, can you explain what is wrong with the statement? From a cursory view, these protocols indeed seem to normally carry the mentioned payloads.

It's not like HTTP stops working if you choose to send something besides HTML. Most of its features still work and make sense for JSON payloads and the usual building blocks still work (eg HTTPS, load balancers, proxies, status codes, redirects...) There are a few bits that don't make sense eg cookies where the server sends something and the client is expected to remember it but they can just be ignored.

Exactly. The HTTP standard doesn't really mention HTML, except tangentially in examples. And regarding cookies, there are even people who use cookies in RPC contexts, but this is rather rare, and as you said, entirely optional.

Also, as a minor point, even when browsing the web, a minority of the actual requests deliver HTML -- most of them are for various kinds of media referenced by the HTML document.

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

#76

Post by themoonisachees »

cjsplat wrote: post #41
roncesvalles wrote: post #37

You could just use UDP instead of TCP and implement some subset of TCP features that you need in-band, like sequence numbers. This is not a new concept. The Facebook Memcache paper [1] in 2013 described using UDP for intra-datacenter requests. [1] https://research.facebook.com/publications/scaling-memcache-...

Sure, but what is UDP bringing to the party then? The pseudoheader? A reasonable RPC layer could just layer on IP.

UDP gives you port numbers supported by every networking equiment your datacenter already has, instead of having to deal with raw IP frames or somehow extending how your firewalls and servers handle your special boy packets. Especially useful considering you probably want port numbers anyway, and checksums are just a nice bonus. You'll probably reimplement part of TCP on top of it too.

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

#77

Post by bob1029 »

Karrot_Kream wrote: post #49
bob1029 wrote: post #25

Earlier quoted context omitted.

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...

I didn't dive past the links you dropped, but reading the doc comment makes it seem like the call is using `poll` (as an alternative to `select` for FD size reasons.) It's well recognized that the polling model of `select` and `poll` are slow and it was specifically this problem that led to the framing of the C10K problem. The solution is to use an async style of programming which is what libuv and other wrappers off…

Async style brings downsides with regard to real time latency. As noted in other comments here, I am not pushing more than 1k per socket server.

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

#78

Post by drpixie »

cryptonector wrote: post #54
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.

Agreed. MIME came after SMTP, for example, and HTTP is used for all sorts of not-HTML-or-hyper-anything stuff. That statement smacks me of "wow, HTTP is a pretty good RPC, but too bad it's only/mainly for transporting HTML, shucks!". The name of the protocol is not very representative anymore either of how it's used or how anyone should use it. If HTTP fits the bill, then use it and move on.

HTTP might now be used for other things but right from the beginning (check the RFCs) HTTP stood for "Hypertext Transfer Protocol", the RFC was written by Berners-Lee. HTTP and HTML did come together, and from the same person.

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

#79

Post by dfox »

Karrot_Kream wrote: post #49
bob1029 wrote: post #25

Earlier quoted context omitted.

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...

I didn't dive past the links you dropped, but reading the doc comment makes it seem like the call is using `poll` (as an alternative to `select` for FD size reasons.) It's well recognized that the polling model of `select` and `poll` are slow and it was specifically this problem that led to the framing of the C10K problem. The solution is to use an async style of programming which is what libuv and other wrappers off…

The issue with select(2)/poll(2) (and for that matter WaitForMultipleObjects()) is that you are passing huge datastructure across userspace/kernel boundary with each call. There are various alternative platform specific implementations of what in the end is still polling that place the set of interesting FDs on the kernel side and thus make the whole thing significantly faster. That is what libev/libevent/libuv abstracts away in portable manner.

The programming style is essentially same for a program that uses select(2) directly. (If you do not count various anti-patterns that are common in GUI applications which do networking)

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

#80

Post by nubinetwork »

cjsplat wrote: post #38
nubinetwork wrote: post #34

I'd be happy if DNS and NTP would just get off their butts and switch to TCP. No, DoH doesn't count.

Why would NTP be better with retransmisson of stale packets and go-back-N semantics on drops?

UDP can be spoofed for amplification attacks, and since ISPs won't implement reverse path filtering, the only other option is to get rid of UDP.
Post reply on HN