This document describes a simulation of a communication network on UNIX using Remote Procedure Calls (RPCs). The simulation allows testing of network modules and consists of three processes that communicate via RPCs: a network simulator process, a host process, and a remote procedure monitor (RPM) process. The network simulator process pseudocode shows how it simulates message passing between the host and RPM processes and controls message loss based on configurable probability and duration parameters.

1. Communication Network Simulation on the
UNIX System Trough Use of the Remote
Procedure Calls
Damir Pehar,
Faculty of Electrical Engineering and Computing, University of Zagreb
Unska 3, Zagreb, 10000 Croatia
Damir.Pehar@fer.hr
Damir Delija
University Computing Center, University of Zagreb
Marohniceva 11, Zagreb 10000 Croatia
Damir.Delija@srce.hr
Abstract:
In this paper methods for simulating specific communication networks are described. Purpose
of the simulation is testing of the modules which are using network as communication media.
Simulation is done on the UNIX computer with Remote Procedure Calls used as method of
interprocess communication.
Keywords:
Simulation, Remote Procedure Calls, Testing, Interprocess Communication
1. INTRODUCTION
During the complex computer system development it is often necessary to substitute some
parts of the system with the "artificial" counterparts that create the virtual environment or
virtual segments for the given system. This step is very important in the development and
testing of products and their parts. The system simulation combined with the intentional
creation of critical situations contributes to the real system fault and bottleneck detection. It is
possible to detect incompatibilities of the system parts, the inconsistencies in the system
specification and construction, thanks to the artificial system part demands aimed for the
maximal similarity to the real system parts, in order to diminish the dissimilarity detection on
defined interfaces.
Such approach to system development forces particular demands on the computer system,
used for development requiring particular discipline and methodology to be applied in the
development process of the target system. Basically, it implies the creation of detailed system

2. specification at the very beginning of the development process, as well as a test plan making.
The system test parameters are based on the particular considerations and the system analysis.
In some cases, the same principles could be applied to the system simulation.
The system simulation usage could result in the considerable money saving, due to the
diminishing need for field testing. Unfortunately, the real system testing can't be avoided
completely.
In the case of system simulation development there is a need for strict separation into the
functional modules of well-defined interfaces, as well as maximal automatization of the
procedure. The tests must check the functionality of the particular system parts, but it is also
necessary to try out the event scenario set in which the system has to play its role as expected.
2. THE TARGET SYSTEM STRUCTURE AND THE
SIMULATION SYSTEM BUILDING
The simulated system consists of cooperating processes connected by the specific network
(Fig.1). The network is responsible for interprocess message conveying. The communication
protocol takes care about the detection and correction of possible message transfer errors.
At the computer network level, the access points exist - the points where the process and
network interactivities take place in form of the receiving and sending message. The message
consists of two parts:
ADDRESS (envelope) - the part of the message that defines the destination (the recipient of
the message)
INFORMATION (data) - the content of the message that has no direct meaning for the
network and corresponding communication protocol. That has to be transferred in the shape
equal to one received.

3. Figure 1: The schematic presentation of process communication over the network
For the computer network defined in the given way the simulation subsystem purpose is dual:
1. The communication protocol testing. The protocol must be tested regarding the
communication errors, reliability, the interface standardisation and other parameters.
The simulation system enables the testing under the controlled conditions of
intentional error inputting, sample testing and the worst-case analyzing. The testing
could be performed in several steps.
2. The real equipment testing under the controlled conditions. Before the real computer
network interconnection is performed, the remote computers have to be tested as
functional entities. The simulation system usage enables tests to be performed in the
UNIX computer domain.

4. Figure 2: The real subsystem structure including the functional parts
The real system simulation is performed by the simulation subsystem on the UNIX computer.
The simulation subsystem consists of three processes that communicate using remote function
calls. In the theoretical case, it would be enough to use just one process that would unite the
functionality of all three processes, but additional demands and the need for adaptability
dictated the distributed solution. The simulation subsystem defined in described manner could
be distributed on different computers having accessible resources (serial ports, storage space
on disks etc.) and enabling simplified building of the simulation control system. The remote
function call usage guarantees the operation conveying and execution as well as data
uniformity. More detailed description of the remote function calls can be found in the (Delija
1994).

5. Figure 3: The simulation system structure without the computer network usage
The system user interface is system independent and structured in two stages at the process
level and at the level of the common supervising process for the visual interfaces (which may
not be implemented). The common supervising process could be implemented in some
dedicated language, e.g. expect. Expectk languages enable the test automatization and
scenario incorporation. More detailed description of expect and expectk languages is given in
the reference /Lie 95/.

6. Figure 4: Schematic of the simulation subsystem at the RPC calls level

7. 3. THE STRUCTURE OF THE NETWORK
SIMULATOR PROCESS AND COOPERATING
PROCESSES
The behaviour model is build around information gathered about network. The computer
network is reliable and data is transferred atomically - the transfer is completely successful or
it is not. The computer network takes care about the message transferring. The addresses are
interpreted internally which means the message transport need not to be simulated.
Repeat wait for the message reception
if the message comes from:
RPM
then
determine if the message could be forwarded
if the message could be forwarded
then
send a message to the HOST
note the action
HOST
then
determine if the message could be forwarded
if the message could be forwarded
then
send a note to the RPM
note the action
CONTROL
then
modify control parameters
note the action
end.
Figure 5: The network simulator process pseudocode
The partial message destruction scenario is infeasible, but the message could be destroyed
completely. It is possible to loose a sequence of N messages, and for the purpose of the higher
level protocol testing, there must be a possibility of manual interference into the network
behaviour in order to simulate switching off/on of the physical interconnections. The process
that simulates the network has to display messages about its state and must change its
behaviour depending on the external commands. The RPC usage enables simple simulation
control using the control process (Fig.4) and allows the implementation of specified demands.
The network simulator process (net, Fig.4) is called the server if the function call terminology
is used. The behaviour of the net process is defined by the pseudocode in the figure 5.
The function that calculates whether the message should be forwarded or not represents the
base for message transfer simulation. This function simulates the transfer fault and depends
on the specified parameters (that may vary dynamically). There are two variables for fault
occurrence controlling:

8. 1. STATIS defines probability of the message loss
2. FIX defines how many following messages should be lost
The calculation method is shown in the figure 6. The dynamical variable changing is enabled
by means of the control process (control, Fig.5). This process enables STATIS and FIX
variable changing and allows examination to be done atomically. Using the RPC terminology,
such process is called the control service (Delija 1994) or the system control agent.
Begin LOOSE=false
if FIX > 0
then
FIX--
LOOSE=true
else
if RANDOM() < STATIS
then
LOOSE=true
return LOOSE
end.
Figure 6: The method used for message loss calculation
The host and rpm processes are simple-structured and they represent the system entry points.
The most demanding operation parts of these processes are bidirectional message transfer and
the message printout (to standard output and standard error). The processes are implemented
using the custom version of svc_run function for RPC calls as described in (Delija 1994).
For the purpose of initial parameter definition the following manufacturer data are used:
 probability of message loss is 5%
 communication speed is set to 9600 b/s
The system structure enables dynamical parameter tuning, so the initial parameter definition
doesn't pose any limitations on the system. The probability of message loss is dynamically
changed by the means of control service. The communication speed depends on the physical
parameters, so in the simulation case, where the system input comes from the message
generator, it is reasonable to expect any speed manageable by the computer.
4. THE SIMULATOR USAGE IN THE PRODUCT
TESTING PROCESS
The simulation plays multiple role in the product testing and designing. Based on the system
behaviour assumptions it is possible to perform a simulation in order to obtain parameters
needed for the mathematical description of the system and for the definition of initial
parameters and states. In this case, the description of the computer network behaviour (data
given by a manufacturer and data known from the experience) serves as a base for model
defining and controlling.

9. Primarily, the communication protocol is tested, and afterwards, under the controlled
conditions, the work of the real equipment.
Beside the manual protocol testing (start testing) the automated testing is performed. The tests
are based on the black box principle. The sequences of inputs, commands and outputs are
defined as well as the rule for test passing. Specially convenient tool for the test making and
the user interface defining is the expect language (Libes 1995) that enables the centralised
process control and communication. The expect language enables components needed for
testing and tracing to be separated into a special process (or processes), so the structure of the
other system parts is simplified and independent of the test system. This means the simulation
system always works in the same way regardless of the conditions and purposes for which is
used. All simulations and testing could be implemented in the expect language scripts,
including the automated result processing and other tasks. Furthermore, it is easy to use the
standard or graphical user interface, depending on the expect language version used.
5. CONCLUSION
The computer network simulation system could be implemented in the described manner.
Such system enables simplified testing and connection to other real system parts, what is of
great importance (Marks 1992). The system structure is somewhat complicated but we benefit
from the adaptability and easier use. Due to the modular structure and RPC system use, it is
easy to alter the system. The usage of the standard RPC system enables easier implementation
on any UNIX computer supporting RPC paradigm (practically all today UNIX computers).
6. REFERENCES
D.Delija (1994): "Mehanizmi razmjenej poruka ostvareni pozivima udaljenih funkcija",
magistarski rad, Elektrotehnicki fakultet u Zagrebu 1994.
D.Libes (1995): "Exploring Expect, A Tcl-Based Toolkit for Automating Interactive
Programs", O'Reilly & Associates, Inc. 1995.
D.M.Marks (1992): "Testing Very Big Systems", McGraw Hill, Software Enginerring Series,
1992.