This looks more like a socket tutorial than rpc. It leaves out most aspects about implementing rpc that are actually interesting.

I'm writing a networked rpc "framework"[0], too! Can you summarize or point me to some resources that outline the aspects you find interesting? I'd like to be aware of them as I'm building and designing!

[0]: https://github.com/lytedev/saurpc

Ignores failure modes. The is_prime example takes an integer to a bool, and is put on the far side of a network call, but there's no change to the interface to indicate network failures and no fallback path to compute it locally if things go wrong.

(strictly it calls exit on anything going wrong, but as the whole problem with rpc is the extra failure modes that's not compelling)

the article is didactic, focusing on overall architecture, furthermore it says it clearly on the subtitle.

     "...so you can appreciate the libraries that do it for you "

Do you know of any rpc libraries that hide the failure modes of the network from the application?

nfs.

nfs as originally designed could not fail. so what happens when something that can not fail has a failure? that's right it hangs.

On the one hand this was kind of fun, network problems, the application hangs waiting on nfs, two days later you get everything sorted out and the application comes back never knew there was a problem.

On the other hand, this is the most infuriating behavior possible, everything you touch on the system starts freezing up. and you wish it would just fail so you could fix the infernal thing.

Later the "soft" option was added so that nfs could actually fail.

The point is to show the big picture.

It's true that error management is critical for a production environment, but from a pedagogic point of view, they can left as an "exercise for the reader".

The article covers all the shortcomings in the final section.

By "covers" you mean "glances over". It means nothing if you just add a footnote mentioning the existence of failure modes.

I notice that the comment refers to sqrt(number), but never does that either. So it tests way more numbers than it needs to.

It does use sqrt(number), just not directly. Instead of taking sqrt(number), it just calculates i*i which is much faster.

D'oh, you're 100% correct!

The whole “network order” of bytes thing is not a given. There’s little endian “network orderings”.

And now it seems most CPUs are little endian anyway, so why do this conversion anymore to “network order” if you are designing a new protocol?

As much as I am a big endian fanboy by nurture, the important thing is that the order is documented.

Also, I don't know if this is apocryphal, but as a wee lad I was told the tale that network routers worked faster because they could do coarse addressing faster thanks to seeing IPv4 addresses in big-endian, when the bytes trickled in one-by-one.

Great intro for more junior devs learning how it all comes together. It's incredibly easy to use these things without understanding what they are doing for you under the hood.