41–50 of 116 posts
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-...
A reasonable RPC layer could just layer on IP.
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?
For example, imagine if there are two sockets established between server and client processes (due to multiple ips or roaming, time lags, etc.), then in theory, request received from one socket could be responded through another socket. From application pov it doesn't need to care about the socket. We can do this over TCP, but connection-oriented nature of TCP makes this weird.
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.
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.
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…
Yeah, but the question at hand is why layer it over TCP. SunRPC over UDP is close, but then you push reliability and congestion management into every application.
(Though it can be tunneled through UDP, to get around Internet ossification.)
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…
OMG the Common Object Request Broker Architecture (which coincidentally was created by OMG). I never thought I'd see that acronym again, and all these years later, I still don't understand what it is.
Really interesting article. Wish there was a discussion of performance for various RPCs from the past.
HTTP is a remote procedure call, it's request/response.
Each request/response pair is independent and asynchronous.
The difference between HTTP and a more "specified" RPC is that the body of the request and the body of the response are defined "out of band" and are flexible enough to allow for the client and the server to evolve independently.
I could make HTTP look like ONC-RPC by using XDR to martial the arguments in the request/response body and map the actual procedure name to the URL. The MIME type "application/protobuf" exists to do the same using protobufs. So does "applicaton/vnd.google.protobuf".
HTTP was built using TCP as the reliable connection layer over the IP packet protocol but QUIC replaces that using UDP over IP to remove the problems that a connection based/reliable protcol like TCP causes.
Really not sure what a new protocol would provide other than shuffling the boundaries again.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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...
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.
Interoperability. It's been how many years since SCTP was published? How's that going?