perl.com: Throwing Shapes

Throwing Shapes

by Vladi Belperchinov-Shabanski
February 03, 2005

Sometimes data processing is better when separated into different processes that may run on the same machine or even on different ones. This is the well-known client-server technique. You can do it using a known protocol (such as http) or by developing your own, specific protocol. This approach needs implementation for constructor and parser procedures for each packet type (request and response). It's possible for different packets to have the same structure so the constructor and parser will be always the same. Perhaps the simplest solution is to have key/value pairs packed with newline characters or with other separators inside a text block. Binary form with length encoding is another solution.

In an attempt to simplify this client-server interaction, the Remote Procedure Call (RPC) technique appeared. It tries to map functions inside the client code to their counterparts inside the server. RPC hides all the details between a client function call and the server function's response. This includes argument serialization (to make data appropriate to transfer over the net, also known as marshaling), transport, the server function call, and returning response data back to the client (also serialized). In some implementations, RPC also tries to remove requirements for the client and the server to run on the same operating system or hardware, or to be written in the same programming language.

In the Perl world there are several modules that offer different kinds of RPC, including RPC::Simple, RPC::XML, DCE::RPC, and more.

In this article I'll explain how to use Perl-specific features to develop a compact RPC implementation that I will name Perl-centric Remote Call (PerlRC). As the name suggests, it will run only with Perl clients and servers.

Shape

PerlRC needs to simulate a function call environment that seems familiar to the client. This requires handling the four key properties of a function call:

Function name
Function arguments
Calling context
Return data

The design of the Perl language allows generic argument handling, which means that it is possible to handle arguments without knowing them before the function call. There are also ways to discover the calling context. Finally, the caller can handle results in the same way as the called function's arguments -- generically, without knowing their details until the function call returns.

With this in mind, the PerlRC code must follow these steps:

Creating Transport Containers

Essentially these are the request and response packets. I'll use hashes for both. Each one will be serialized to a scalar which the code will send to the other side with a trailing newline terminator.

A request container resembles:

# request hash
  $req1 = {
            'ARGS' => [          # arguments list
                        2,
                        8
                      ],
            'NAME' => 'power',   # remote function name
            'WANTARRAY' => 0     # calling context
          };

  # result hash for scalar context
  $res1 = {
            'RET_SCALAR' => 256  # result scalar
          };

  # result hash for array context
  $res2 = {
            'RET_ARRAY' => [     # result array
                             12,
                             13,
                             14,
                             15,
                             16,
                             17,
                             18,
                           ]
          };

  # result hash for error
  $res3 = {
            # error description
            'ERROR' => 'No such function: test'
          };

Related Reading

Programming Web Services with XML-RPC
By Simon�St. Laurent, Joe�Johnston, Edd�Dumbill

Arguments

To keep things simple, the first argument will represent the remote function name to call. This server must remove this argument from the list before passing on the rest to the remote function. The request container holds the name for the remote function and a separate reference to the argument list.
Calling Context Discovery

Find the calling context with the built-in wantarray function and put this value (0 for scalar and 1 for array context) in the request hash.
Transfer Both to the Server

Serialize the request to scalar and escape newline chars with \n. Append the newline terminator and send it to the server.
Unpack Request Data

The server takes the request scalar, removes the trailing newline terminator, and unpacks the request data into a local hash that contains the function name, the calling context, and the argument list.
Server-side Function Call

Find and call the required function in appropriate context. Take the result data or the error. Create a result container with separate fields for scalar and array contexts and one field for any error.
Pack Result Data

Serialize the result hash, escape newlines, append a terminating newline, and send the result data to the client.
Client Unpack of the Result Data

When the client receives the result container, remove the trailing newline char. Unescape any newline chars and unpack the data into a local result hash. Depending on the calling context, return to the caller either the scalar or array field from the result hash or die with an error description if such exists.

The implementation uses two modules:

Storable handles the serialization of arbitrary data. Serializing data converts it to a string of characters suitable for saving or sending across the network and unserializable later into the form of the original. The rest of the article will also refer to this process as packing and unpacking the data.
IO::Socket::INET handles the creation of Internet domain sockets.

Both modules are standard in the latest Perl distribution packages.

It is possible to use any serialization module including FreezeThaw, XML::Dumper, or even Data::Dumper + eval() instead of Storable.

Pages: 1, 2, 3