RPC vs. TCP (Redux)
I have a hard time wrapping my mind around this whole line of discussion because it seems to treat as a binary something that is a continuum. It is not the case that we have &quot;TCP&quot; and &quot;RPC&quot; as some sort of cleanly separable discussion, or at least, if they do mean it as some very cleanly definable term it doesn&#x27;t seem to have ever gotten a discussion.<p>RPC, to my mind, isn&#x27;t really a thing of its own. It&#x27;s a particular popular pattern for using messages. You can use that pattern poorly or well on TCP. You may need to use another underlying protocol for any of a variety of reasons to get another performance profile out of it. You may be in a situation where you need all the guarantees of TCP anyhow, in which case the room for improvement is somewhat marginal (although non-zero, especially if you want to be on the cell network).<p>I&#x27;m not particularly convinced there&#x27;s a need or even &quot;room&quot; for a pure RPC protocol, on the grounds that it&#x27;d probably end up much like SOAP in that it can only serve a particular set of needs and the benefit of a custom protocol for those needs could well be outweighed by the costs of the stampede of developers jamming everything into the new protocol regardless of their needs, most of which would mismatch. The field of &quot;RPC&quot; is already very diverse and to my eyes, people generally have satisfactory solutions available to them.<p>It&#x27;s not like it&#x27;s even possible to build something that would both replace generalized RPC on the internet <i>and</i> service supercomputer mesh networks.<p>If TCP was the only option, yes, many needs would be going unmet, but it already isn&#x27;t. If I do an analysis and determine that TCP is my core problem, it seems to me I already have an abundance of choices serving many points on the continuum. I don&#x27;t see what trying to lift up one of those points as some sort of standard would particularly accomplish that isn&#x27;t already being accomplished in the real world. And it isn&#x27;t even RPC <i>qua</i> RPC driving that per se; you can have all sorts of niche needs that drive you off of TCP, of which RPC doesn&#x27;t even strike me as a particularly distinguished case.<p>RPC when you get down to it just isn&#x27;t that complicated or really even that interesting; you send a message, you expect a 1-to-1 message back in reply. Of all the message patterns, it&#x27;s just about the simplest other than unilateral broadcast without any reply at all.