XMLRPC

In this article, I'll talk about a pretty old RPC Protocol, XMLRPC. It is over 20 years old now and, it is mostly associated in legacy systems. I'd have never come across it if it wasn't for ROS. ROS 1.x still uses XMLRPC for all of its communication. So, I decided to read out the protocol specification.

I was surprised that the protocol is quite simple. It leverages the already existing Request-Response foundation of HTTP and defines the Message Types for Request and Response. That's pretty much it.

What is RPC?

RPC stands for Remote Procedure Call. Think of procedure call as a function invocation. So a remote procedure call is the function invocation done remotely where remotely can mean anything from a separate process on the same machine to a machine across the world.

In RPC's context, the caller is the RPC Client and, the callee is the RPC Server. An RPC client needs to figure out how to send the procedure name and its parameters to the RPC Server. The Server will then invoke the function and return the response. An RPC Protocol defines the way of encoding and sending the data across.

XMLRPC Transport

For transporting the data, XMLRPC relies on the HTTP Standard, thus eliminating most of the complexity. XMLRPC uses the POST Method of HTTP for the Request, but it does not care about the URI. HTTP Server can use the URI for routing.

It does require the following HTTP Headers to be present.

• Content-Length
• Content-Type (text/xml)
• User-Agent
• Host

XMLRPC Encoding

This one is a little more obvious. XMLRPC uses XML for encoding the data. It recognizes most of the primitive data types:

• Bool
• Int
• Double
• String
• DateTime
• Binary Bytes (Base64 Encoded)

Additionally, XMLRPC supports compound datatypes like Arrays and Custom Structs (that can also be recursive).

Request

The Request must have a single methodCall XML structure. There should be a single methodName item under it. Method Name is the name of the remote procedure. All the parameters are defined under the params array as param items. The following snippet is a sample Request body.

<?xml version="1.0"?>
<methodCall>
  <methodName>sum</methodName>
    <params>
      <param>
        <value><i4>41</i4></value>
      </param>
      <param>
        <value><i4>59</i4></value>
      </param>
  </params>
</methodCall>

Response

The Response must have a single methodResponse XML structure. The structure can have either a params item or a fault item.

The params item is used for a successful procedure invocation. XMLRPC supports only a single return parameter. But it can be any supported datatype. The successful invocation would return a response similar to this.

<?xml version="1.0"?>
<methodResponse>
  <params>
    <param>
      <value><i4>100</i4></value>
    </param>
  </params>
</methodResponse>

On the other hand, the fault item is used for a failed procedure invocation. The Fault response is defined as a struct with two fields, failureCore and failureString. A failed RPC call would look like this.

<?xml version="1.0"?>
<methodResponse>
  <fault>
    <value>
      <struct>
        <member>
          <name>faultCode</name>
          <value><i4>-1</i4></value>
        </member>
        <member>
          <name>faultString</name>
          <value><string>Some error occurred</string></value>
        </member>
      </struct>
    </value>
  </fault>
</methodResponse>

Criticism

XMLRPC is a simple plain-text protocol that humans and machines can parse. However, it has its flaws. XML as a data encoding format is rapidly being replaced with JSON. The most commonly cited reason for that seems to be the complexity of XML. Moreover, XMLRPC's Request/Response structures are also criticized to be verbose and redundant.

Additionally, XMLRPC is a plain-text protocol. This is good because humans can easily understand communication, but it's not performant because computers do not understand it. Computers need to first parse the text to understand the data. More and more modern protocols are choosing binary format over plain-text including HTTP/2 and HTTP/3.

Modern Replacements

Some modern-day replacements are generally known to be better in some ways than XMLRPC. I plan to read the specifications of these Protocols and possibly cover them in future posts.

• JSONRPC
• gRPC
• Apache Thrift