# Review of distributed computing concepts

The Natural Access internal architecture is based on the client/server model of distributed computing. This topic briefly reviews distributed processing concepts and implementation strategies.

In this topic:

- Basic distributed computing concepts

- Remote procedure call (RPC)

- Summary

## Basic distributed computing concepts

Distributed computing refers to two or more processes (which can be located on different computers) that interact with each other over a communications channel in order to accomplish some computing task. The client/server model is a popular model for implementing distributed computing. In this model, two different sets of code, known as the client and the server, are produced. These parts are typically located on different computers within a network, although they may exist within different processes on the same computer, or even within different libraries or threads within the same process.

The client makes a request over a communications channel and waits for a reply. The server waits for incoming requests, processes the request, and returns a response. In this model of computing (shown in the following illustration), the server is responsible for coordinating and providing access to a resource on behalf of one or more clients. The resources controlled by a server can be any computing resource such as a database, a physical device, or even another server process.

Client server model

Writing an application that works in the raw client/server environment requires detailed knowledge of inter-process and network communications mechanisms. Implementing applications in this environment deals with communications details rather than with server implementation details.

## Remote procedure call

A remote procedure call (RPC) is a way of implementing the communications between the client and server in the client/server model. The main strength of RPC is that the details of using inter-process and network communications mechanisms are hidden.

Using RPC, the client makes a procedure call that looks like a local call from the client's perspective. The procedure call is translated into a message and sent to the server using the RPC specific communications protocol. Once the server receives the request, it is translated back to a procedure call and the appropriate server procedure is executed. Responses are returned in a similar fashion.

RPCs are implemented using stubs and an RPC runtime library as shown in the following illustration. Stubs contain functions which map simple local procedure calls into a series of RPC function calls. RPC function calls are the communication interface implementing the RPC protocol. They also specify how the messages are constructed and exchanged.

Remote procedure call (RPC)

The client and server both communicate using stubs, one for the client and one for the server. The client stub calls RPC library procedures to:

1. Package (marshal) the arguments and ID of the call into a message.

2. Find the server.

3. Transmit the message to the server using the RPC runtime library.

4. Wait for the response from the server.

5. Return the response to the caller.

The server stub calls RPC library procedures to:

1. Receive the incoming message from the RPC runtime library.

2. Unpack (unmarshal) the arguments and procedure id.

3. Invoke (perform an upcall to) the appropriate server procedure.

4. Marshal the results.

5. Send a response back to the client.

In the client/server and RPC environments, the term service describes the remote procedure call (service interface) and remote procedure implementation (service implementation) components of the server. The service interface component is typically packaged as a library to be linked into a client application. Similarly, the service implementation component is packaged as a separate library to be linked into a server process (a daemon). Both components (both libraries) can be linked into the same application, effectively making one process operate as both client and server.

As described earlier, the internal architecture of Natural Access is based on the client/server model. The internal implementation strategy of Natural Access is loosely based on RPC. The outcome is a highly efficient, distributable infrastructure for telephony services.

## Summary

The Natural Access architectural model is based on the RPC implementation strategy of the client/server model. Rather than using RPC directly, Natural Access was developed to address the following additional requirements beyond what is specified by RPC:

- Event handling

RPC is a request/reply paradigm. The service can only respond to requests from a client. Natural Access also requires the ability for a service to generate unsolicited events and send them to clients.

- Built-in services

RPC does not provide an infrastructure of system-level services such as parameter management. Natural Access requires a rich infrastructure of built-in services.

- Efficiency

Access to Natural Access services must be very efficient with very little overhead in processing a message from the service interface to the service implementation.