Throwing Shapes

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 Table of Contents Index Sample Chapter Read Online--Safari Search this book on Safari:   Only This Book All of Safari Code Fragments only

• 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.