Browse Prior Art Database

Testing a Distributed System

IP.com Disclosure Number: IPCOM000123251D
Original Publication Date: 1998-Aug-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 1 page(s) / 57K

Publishing Venue

IBM

Related People

Dixit, A: AUTHOR [+6]

Abstract

In a distributed system design, it is often difficult to bring a system to various desired states so that the system can be thoroughly tested. In order to test how a network of servers would behave when one of the servers reports a certain error or fails to respond, it is necessary to start all the desired servers and then force a targeted server to report an error, fail to respond or behave accordingly. The other servers individually have to be configured to handle the failure being reported by the faulty server.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Testing a Distributed System

   In a distributed system design, it is often difficult to
bring a system to various desired states so that the system can be
thoroughly tested.  In order to test how a network of servers would
behave when one of the servers reports a certain error or fails to
respond, it is necessary to start all the desired servers and then
force a targeted server to report an error, fail to respond or behave
accordingly.  The other servers individually have to be configured to
handle the failure being reported by the faulty server.  In order to
test the numerous conditions envisaged by a designer for such a
system, each test requires its own set up time, a mechanism to
produce the error state in a targeted server and a mechanism to
record the handling of the error condition by other servers in the
network, so that such a test can be self verifying.  All this
requires a lot of time and resources.

   The mechanism described here is such that a network of
servers can be made to co-exist within a process.  Two basic server
types can be created, a real server and a simulated server.  The code
for the actual servers being tested is clearly divided into modules
that represent the distributor which is the heart of the server logic
and a transport module which controls the communication between the
servers.  In the testing infrastructure the transport module is
replaced with a module known as the process local transport.  This
essentially makes communication work within a process and keeps the
rest of the code transparent to the fact that the transport has bee...