Earlier quoted context omitted.
Unless you're using the musl libc - which is in heavy use in conteainerized applications
OK well if it does zone transfers those are over TCP only and always have been.
[deleted]
It's TCP vs. RPC All over Again
81–90 of 116 posts
Re: It's TCP vs. RPC All over Again
#82Re: It's TCP vs. RPC All over Again
#83Earlier quoted context omitted.
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.
So? They aren’t bundled together as the article says they are. Even on the web HTTP is used for all sorts of other content types, from images to CSS, loading javascript, JSON RPC calls, websocket connections, server sent events and so on. Outside of the web? DoH, JSON RPC, git over https, npm, video games, elasticsearch queries, … the list goes on for a long time.
A very small percent of http requests transmit html.
Claiming http “bundles” html is like saying XmlHttpRequest is bundled with xml, or shortening javascript to Java. It’s a strong signal that you don’t know what you’re talking about.
Re: It's TCP vs. RPC All over Again
#84There 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…
> HTTP/JSON - where we are now.
That’s not a protocol either, you can use HTTP as an RPC (with a JSON payload), but you can also define a transport-independent JSON RPC protocol (e.g. JSON-RPC2, which can be used over HTTP but can also be used over simpler sockets, for instance chrome’s dev tools protocol is JSON-RPC2 over websocket or a pipe)
Re: It's TCP vs. RPC All over Again
#85There 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 :-)
Remembered and now intentionally forgotten :-)
Re: It's TCP vs. RPC All over Again
#86If 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 co…
> 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.
No, Ousterhout is not "right", Ousterhout has put forward an hypothesis, backed up by _some_ data that's not really borne out from real world experiences in the datacentre.
Infiniband, despite his claims to the contrary solves a whole bunch of the problems he's describing. Moreover its a proven solution that deploys at scale. not only that, but you can run enthernet/IP over the top.
Having proper flow control inside your switching fabric is bloody amazing if you want real-time with QOS over the top. After all Fibre Channel was designed to be fast, guaranteed deliver and low latency. The problem is, ethernet was cheaper and good enough to cover 80% of usecases.
Re: It's TCP vs. RPC All over Again
#87Earlier quoted context omitted.
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.
And I keep saying that SMTP is a perfectly good message-queue broker message submission protocol (and POP a perfectly good message-queue broker:consumer protocol), but nobody ever listens. :P
I've not just used SMTP the protocol as a submission protocol, but used actual mail servers as the broker, in a production system.
Back in '99 I co-founded a mail provider, and we got so used to abusing qmail (+ rewritten replacement components - any qmail installation becomes a Ship of Theseus thanks to the clear API between small components) that when we needed a message broker we used our internal DNS server for service discovery and our mail infra as the broker (and we had a DNS server where the zones could be updated via SMTP). It worked well, and let us reuse a lot of tooling.
Re: It's TCP vs. RPC All over Again
#88If 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 co…
I think you're right that he's "right", but the writing is shooting itself in the foot here. I agree that there's a mostly-unexplored middle between TCP & UDP, but you need to not utter things like "HTTP is bundled with HTML". I also think RPC is a poor label for "request/response" protocol (HTTP is request/response, and many of the problems here apply to HTTP too … but it isn't RPC). I'd like more discussion of the…
On the topic of WAN vs DC it's about reliability. A lot of the engineering behind TCP assumes an unreliable transport, but in a data center context a lot of the unreliability doesn't exist, or can be engineered out of the network infrastructure you use. A good example of this in my space is video over IP (ST 2110), which is over RTP/UDP, but RTCP (for retransmission and rate control) is much more of a vestigial component, and if I remember correctly is entirely optional in the specs. A lot of the SDN solutions even default to not carrying the RTCP back channel.
Now, in the video over IP space, there is essentially zero time available for retransmission, so such packet loss would be better handled as a dropped frame or audio packet, but it's not like this is an expected outcome of using UDP in such a controlled environment as a dedicated video transport network
Re: It's TCP vs. RPC All over Again
#89Earlier quoted context omitted.
You're likely interacting with SCTP every time you use a mobile phone, as it's in heavy use in the control plane of telecom networks. Outside that, not so much though.
Also every Zoom/Google Meet call. WebRTC is on top of SCTP.
Sort of. SCTP is used for data channels, the audio/video is RTP. Still an important piece though.
Re: It's TCP vs. RPC All over Again
#90Earlier quoted context omitted.
Sure, but what is UDP bringing to the party then? The pseudoheader? A reasonable RPC layer could just layer on IP.
IIRC, UDP just adds port numbers and a checksum to IP. It's about as bare bones as it can get, unless you want to get rid of the checksum too.
Some implementations do skip checksum (leaving it as zero), for instance you can configure a Linux UDP socket to skip it if you can't afford the time it would take to calculate them.