An Acoustic Sensor History Server
for a Submarine Combat Control System
A Thesis Presented
by
Frederick Garvin Burkley
to
The Graduate School of Engineering
In partial fulfillment of the requirements for the degree of
Master of Science
in
Computer Systems Engineering
in the field of
Engineering Software Design
Northeastern University Boston, Massachusetts
August 2002
Abstract
Current submarine computer systems suffer from scaling problems originating from
statically sized database tables. These limitations manifest themselves as constraints with
respect to information processing loads. These legacy systems are only capable of
processing fixed sized data sets; there are hard limits with respect to the number of
contacts (ships) that can be tracked from a submarine combat control system. There are
also fixed limits with respect to the amount of historical data that can be maintained on
each tracked contact.
This situation has improved somewhat over the past few years with the introduction of
the Common Object Request Broker Architecture (CORBA) in the latest combat systems.
However the implementation is still lacking. While the CORBA architecture has lifted
the restrictions concerning the number of contacts that can be tracked, there are still
limits to the amount of historical data that is archived in back end databases for
subsequent information processing. This time limited historical data set impacts the
ability of the submarine to conduct long-term contact localization activities.
This thesis describes a software architecture that places no limits on the number of
contacts that can be tracked or on the amount of historical data that can be held on each
contact. A multi-threaded server is developed whose purpose is to store data from a
submarine sonar suite for subsequent processing by combat control applications.
Concurrent programming techniques are utilized to increase server throughput while
guaranteeing data integrity.
An analysis was conducted to measure the performance of the Java programming
language and to establish relationships between system performance and system load. A
performance comparison was conducted between the Windows 2000 Professional and
SuSE 7.2 GNU/Linux Professional operating system. Results showed that server
processing time is about 20% faster under MS Windows. The fundamental reason is
memory allocation is faster under Windows than GNU/Linux.
ii
Acknowledgements
I would like to acknowledge the following individuals for their assistance and or
guidance:
Professor Ronald R. Mourant, for patience and guidance throughout this process. Shelley
L. McInnis (Naval Undersea Warfare Center), for her technical review. Patrick L.
Clayton, Walter S. Wojciechowski, Susan A. Cadieux, John G. Baylog, and Chidambar
Ganesh (Naval Undersea Warfare Center), for domain knowledge and expert opinion.
Colleen Ciciulla, for proof reading services.
I would like to offer special thanks to Mohsen D. Ghassemi (Northeastern University),
for pointing me in the direction I needed to go.
Finally Maciej Puzio ([email protected]), for timing software that allowed consistent
timing measurements across different operating systems.
iii
Table of Contents 1 Introduction................................................................................................................... 1
1.1 Overview.............................................................................................................. 1 1.2 Objectives ............................................................................................................ 2 1.3 Organization of Thesis......................................................................................... 2 1.4 Typographic Conventions.................................................................................... 3
2 Background................................................................................................................... 4 2.1 Introduction.......................................................................................................... 4 2.2 Domain Description ............................................................................................. 4
2.2.1 Sound Waves ........................................................................................... 4 2.2.2 Sound Detection....................................................................................... 5 2.2.3 Target Motion Analysis ........................................................................... 6 2.2.4 Filtered Input Data Units (Fidus)............................................................. 8
2.3 The Sensor History Server ................................................................................... 8 2.4 Technology .......................................................................................................... 9
2.4.1. Threads and Concurrent Servers.............................................................. 9 2.4.2. Concurrent Programming....................................................................... 10 2.4.3. The Common Object Request Broker Architecture............................... 11 2.4.4. The Java Programming Language ......................................................... 12
2.5 Chapter Summary .............................................................................................. 13 3 Data Flow.................................................................................................................... 14
3.1 Introduction........................................................................................................ 14 3.2 Background........................................................................................................ 14 3.3 List Wraparound ................................................................................................ 17 3.4 Fidu Waterfall .................................................................................................... 17 3.5 Fidu Capacity ..................................................................................................... 17 3.6 Fidu Lifecycle .................................................................................................... 18
3.6.1. Fidu Arrival Prior to Tracker List Wraparound..................................... 19 3.6.2. Fidu Arrival with Tracker List Wraparound and Removal from the Same
Contact List............................................................................................ 19 3.6.3. Fidu Arrival with Tracker List Wraparound and Removal from a
Different Contact List ............................................................................ 20 3.7 Chapter Summary .............................................................................................. 21
4 Design Requirements .................................................................................................. 23 4.1 Introduction........................................................................................................ 23 4.2 Data Dependency ............................................................................................... 23
4.2.1 Use of the Observer Design Pattern....................................................... 25 4.3 Shared Resources ............................................................................................... 27 4.4 Resource Ordering ............................................................................................. 29 4.5 Chapter Summary .............................................................................................. 33
5 Use Cases .................................................................................................................... 34 5.1 Introduction........................................................................................................ 34 5.2 Use Case Diagram for the Sensor History Server.............................................. 35 5.3 Add Fidu ............................................................................................................ 36 5.4 Add Collection of Fidus..................................................................................... 37
iv
5.5 Get Fidus For Tracker........................................................................................ 38 5.6 Get Fidus For Contact........................................................................................ 39 5.7 Delete Tracker.................................................................................................... 40 5.8 Delete Contact.................................................................................................... 41 5.9 Get List of Trackers ........................................................................................... 42 5.10 Get List of Contacts ........................................................................................... 43
6 Requirements .............................................................................................................. 44 6.1 Introduction........................................................................................................ 44 6.2 Overview Statement........................................................................................... 44 6.3 Customers .......................................................................................................... 44 6.4 Goals .................................................................................................................. 44 6.5 System Functions ............................................................................................... 45
6.5.1 Fidu Ingestion ........................................................................................ 45 6.5.2 Fidu Collection Ingestion....................................................................... 45 6.5.3 Tracker List Capacity............................................................................. 46 6.5.4 Tracker List Capacity Exception ........................................................... 46 6.5.5 Contact List Capacity............................................................................. 46 6.5.6 Contact List Capacity Exception ........................................................... 47 6.5.7 Fidus Per Tracker List............................................................................ 47 6.5.8 Fidu Waterfall ........................................................................................ 47 6.5.9 Tracker List Delivery............................................................................. 48 6.5.10 Nonexistent Tracker Lists ...................................................................... 48 6.5.11 Contact List Delivery............................................................................. 48 6.5.12 Nonexistent Contact Lists ...................................................................... 48 6.5.13 Tracker List Deletion ............................................................................. 49 6.5.14 Contact List Deletion ............................................................................. 49 6.5.15 List of Tracker Properties ...................................................................... 49 6.5.16 List of Contact Properties ...................................................................... 49
7 Implementation ........................................................................................................... 50 7.1 Introduction........................................................................................................ 50 7.2 High Level Architecture .................................................................................... 50 7.3 Translation and Delegation Layer...................................................................... 52 7.4 Fidu List Manager.............................................................................................. 55 7.5 System Configuration ........................................................................................ 57
8 Interaction Diagrams................................................................................................... 58 8.1 Introduction........................................................................................................ 58 8.2 Add Fidu ............................................................................................................ 58 8.3 Add Collection of Fidus..................................................................................... 65 8.4 Get Fidus For Tracker........................................................................................ 67 8.5 Get Fidus For Contact........................................................................................ 69 8.6 Delete Tracker.................................................................................................... 71 8.7 Delete Contact.................................................................................................... 75 8.8 Get List of Trackers ........................................................................................... 79 8.9 Get List of Contacts ........................................................................................... 82
9 Results......................................................................................................................... 86 9.1 Introduction........................................................................................................ 86
v
9.2 Background........................................................................................................ 86 9.3 Lab Setup ........................................................................................................... 88 9.4 Get Fidus for Tracker......................................................................................... 89
9.4.1 Test Methodology .................................................................................. 89 9.4.2 Queuing Time ........................................................................................ 91 9.4.3 Wait Time .............................................................................................. 94 9.4.4 Service Time .......................................................................................... 96 9.4.5 Summary ................................................................................................ 98
9.5 Add Collection of Fidus..................................................................................... 99 9.5.1 Test Methodology .................................................................................. 99 9.5.2 Queuing Time ...................................................................................... 100
9.6 Chapter Summary ............................................................................................ 102 10 Discussion................................................................................................................. 104
10.1 Introduction...................................................................................................... 104 10.2 Memory Allocation.......................................................................................... 104 10.3 Towards a Component Based Submarine Combat System.............................. 107
11 Conclusions and Recommendations for Future Work .............................................. 109 11.1 Viability of Java in a Submarine Combat System ........................................... 109 11.2 Generalizing Measurement Types ................................................................... 110 11.3 Extension Via Type Specific Producer and Consumer Servants ..................... 112 11.4 Event Mechanism............................................................................................. 117
References....................................................................................................................... 118 Appendix A: Glossary of Terms ..................................................................................... 120 Appendix B: Uniformity of Time Step ........................................................................... 122 Appendix C: Investigation of System.currentTimeMillis() ............................................ 124
vi
List of Figures Figure 2-1 A spherical array at the fore end of a submarine. ............................................. 5 Figure 2-2 A submarine conducting Target Motion Analysis. ........................................... 7 Figure 3-1 A list of Fidus designated by tracker source. .................................................. 15 Figure 3-2 A list of Fidus designated by contact source................................................... 15 Figure 3-3 A list structure for Fidu storage. ..................................................................... 16 Figure 3-4 A pool of Fidus accessible via tracker list and/or contact list......................... 16 Figure 3-5 A tracker with history on multiple contacts. ................................................... 17 Figure 3-6 A tracker list prior to wraparound................................................................... 19 Figure 3-7 A tracker list at wraparound............................................................................ 20 Figure 3-8 A tracker list in wraparound with removal from the same contact list. .......... 20 Figure 3-9 A tracker list at wraparound with history on multiple contacts. ..................... 21 Figure 3-10 A tracker list in wraparound with removal from a different contact list....... 21 Figure 4-1 Subjects and observers. ................................................................................... 25 Figure 4-2 Removing a waterfalling Fidu (subject) from a tracker list (observer)........... 26 Figure 4-3 Fidu addition to a tracker list in wraparound. ................................................. 27 Figure 4-4 Multiple tracker lists with history on multiple contacts.................................. 31 Figure 5-1 Use case diagram for the Sensor History Server............................................. 35 Figure 7-1 Block structure of the Sensor History Server.................................................. 50 Figure 7-2 Class diagram for the CORBA translation and delegation layer. ................... 54 Figure 7-3 Class diagram for the Fidu List Manager........................................................ 56 Figure 8-1 Sequence diagram for the add Fidu use case. ................................................. 61 Figure 8-2 Sequence diagram for the add collection of Fidus use case............................ 66 Figure 8-3 Sequence diagram for the get Fidus for tracker use case. ............................... 68 Figure 8-4 Sequence diagram for the get Fidus for contact use case................................ 70 Figure 8-5 Sequence diagram for the delete tracker use case. .......................................... 73 Figure 8-6 Sequence diagram for the delete contact use case. ......................................... 77 Figure 8-7 Sequence diagram for the get list of trackers use case.................................... 80 Figure 8-8 Sequence diagram for the get list of contacts use case. .................................. 84 Figure 9-1 A simple queuing model. ................................................................................ 87 Figure 9-2 Fidu List Manager and application service infrastructure boundary. ............. 88 Figure 9-3 Hardware suite for performance benchmarking.............................................. 89 Figure 9-4 Queuing model view of the get Fidus for tracker use case. ............................ 91 Figure 9-5 Queuing time for the get Fidus for tracker use case........................................ 92 Figure 9-6 Wait time for the get Fidus for tracker use case.............................................. 95 Figure 9-7 Service time for the get Fidus for tracker use case. ........................................ 97 Figure 9-8 Queuing time for the add collection of Fidus use case. ................................ 101 Figure 10-1 Fidu instantiation time for Win2k vs. SuSE 7.2. ........................................ 106 Figure 11-1 Block structure of a Sensor History Server with type specific servants. .... 114 Figure 11-2 Class diagram of a Sensor History Server with type specific servants. ...... 116
vii
List of Tables Table 3-1 Relationship Between Fidu Arrivals and List Wraparound ............................. 18 Table 5-1 Use Cases for the Sensor History Server.......................................................... 34 Table 6-1 System Function Categories ............................................................................. 45 Table 9-1 General Queuing Parameters............................................................................ 87 Table 9-2 Successive Phases for One Get Fidus for Tracker Benchmark Run ................ 90 Table 9-3 Queuing Time for the Get Fidus For Tracker Use Case for Win2k ................. 93 Table 9-4 Queuing Time for the Get Fidus For Tracker Use Case for SuSE 7.2 ............. 93 Table 9-5 Wait Time for the Get Fidus For Tracker Use Case for Win2k ....................... 96 Table 9-6 Wait Time for the Get Fidus For Tracker Use Case for SuSE 7.2 ................... 96 Table 9-7 Service Time for the Get Fidus for Tracker Use Case for Win2k................... 98 Table 9-8 Service Time for the Get Fidus for Tracker Use Case for SuSE 7.2................ 98 Table 9-9 Get Fidus For Tracker Queuing Parameter Times ........................................... 99 Table 9-10 Queuing Time for the Add Collection of Fidus Use Case for Win2k .......... 102 Table 9-11 Queuing Time for the Add Collection of Fidus Use Case for SuSE 7.2 ...... 102 Table 10-1 Fidu Instantiation Times for Win2k vs. Linux ............................................. 104
1
1 Introduction
1.1 Overview
Submarine combat systems are evolving from specialized military computers towards
Commercial Off The Shelf (COTS) based hardware. These specialized computers are no
longer feasible due to the diminishing supply of dollars for military systems procurement
[Pow02].
The architecture of the software for these computers was influenced by hardware
constraints that are no longer relevant. Backend database table sizes were fixed at
compile time. These fixed table sizes limit the number of contacts that can be tracked
and the amount of data available for processing per contact.
As combat systems evolve towards COTS based hardware much of the underlying
software architecture remains unchanged. System limits are increased, yet they are still
static in nature. That is, once the system is developed, there are still upper limits on the
number of contacts that can be tracked and the amount of data available for processing
per contact.
The reason for this is financial. It is less expensive to port existing software and increase
limits in table definition files than to redesign the fundamental architecture of the system.
This paper describes the architecture of a data server whose software policies are set via
run-time configuration files rather than hardwired at compile time. This effectively
moves system limits from the software realm to the hardware realm. That is, it is now the
amount of computer RAM or hard disk space that imposes information processing limits.
This is both timely and relevant given the proliferation of highly capable / low cost
hardware.
2
1.2 Objectives
The objectives of this thesis are as follows:
• To design and implement an acoustic Sensor History Server that places no
architectural limits on the following items:
o The number of contacts that are stored in the server.
o The number of trackers1 that are stored in the server.
o The amount of historical data that is stored per tracker.
• Given an implementation in the Java programming language, evaluate the
performance of the server on the Windows 2000 Professional and SuSE 7.2
GNU/Linux Professional operating systems.
Of particular interest is how performance scales under increasing client load.
1.3 Organization of Thesis
Chapter 2, Background – establishes domain specific background, the role of the server
within this context, and surveys relevant software technology as it applies to the
implementation of the server.
Chapter 3, Data Flow – traces the flow of data through the server. The characteristics of
this data flow establish the foundation of the architecture of the server.
Chapter 4, Design Requirements – describes the forces behind the design of the server,
thereby illuminating and justifying the chosen architecture.
Chapter 5, Use Cases – describes the use cases of the server.
Chapter 6, Requirements – establishes the functional requirements of the server.
1 The notion of a tracker is discussed in Chapter 2.
3
Chapter 7, Implementation – describes the high level implementation of the server. It
illustrates the partitioning of core functional software components across architectural
boundaries.
Chapter 8, Interaction Diagrams – describes the interaction diagrams of the server.
Chapter 9, Results – presents the results of performance benchmarking of the most
important use cases for Windows 2000 and SuSE 7.2 GNU/Linux.
Chapter 10, Discussion – gives insight into fundamental reasons for performance
differences for this type of application.
Chapter 11, Recommendations for Future Work– establishes functional areas to
extend the server beyond the prototype stage.
1.4 Typographic Conventions
The following typographic conventions are used in this document:
Courier New Font – Is used to designate a software item, such as a Java class or
package name.
Italics – Are used to place special emphasis on a term, often when it is used for the first
time.
4
2 Background
2.1 Introduction
This Chapter establishes the technical domain in which the Sensor History Server is
relevant. The notion of underwater sound propagation is described, followed by a
description of Target Motion Analysis (TMA). The system solution of the TMA problem
introduces a data storage requirement that the server solves. The term system solution is
used to reflect the design of a computer software system to be used in the process of
Target Motion Analysis.
2.2 Domain Description
Three of the primary operational goals of a submarine are:
• Piloting and navigation.
• Surveillance and intelligence gathering.
• Weapons deployment.
Fundamental to each of these goals is the process of contact localization, also known as
Target Motion Analysis (TMA).
2.2.1 Sound Waves Any surface or subsurface vessel that moves through the ocean makes a certain amount of
noise. Sound originates from the propellers, vibrating machinery, etc., of these platforms
as they transit.
An object that vibrates back and forth in the water creates a pressure differential around
it. As the object moves forward, the particles of water directly in front of it are pressed
closer together. Each particle then passes this pressure along to the particle ahead of it.
5
This state of compression moves away from the object in all directions. When the object
moves backward, this pressure is removed and the particles are thinned out. This state of
rarefaction follows each compressive state [NavPers 16167].
The propagation of this pressure differential through the water describes a sound wave,
that is, a propagating disturbance in a fluid medium, such as air or water.
2.2.2 Sound Detection
A hydrophone is a device that transforms sound waves into electrical signals. A series of
hydrophones can be arranged in such a way as to determine the arrival angle of the
sound. The arrival angle, or bearing, of the sound determines the relative direction to the
contact that originated the disturbance.
Figure 2-1 shows a Spherical Array mounted at the fore end of a submarine. A Spherical
Array is an array of hydrophones physically mounted in a spherical pattern. Again, this
arrangement of hydrophones enables the determination of the bearing to the contact that
originated the sound wave.
SphericalArraySail Periscope
Figure 2-1 A spherical array at the fore end of a submarine.
6
2.2.3 Target Motion Analysis
TMA is a technique used to estimate the range, course, and speed of a contact (target)
from a set of measured bearings and frequencies. Contact range and bearing define the
position of the contact relative to that of the submarine. Contact course and speed define
the velocity of the contact as it transits through the ocean.
Figure 2-2 shows a submarine (ownship) conducting Target Motion Analysis. The line
extending from the aft end of each submarine represents the position history of each
submarine over some period of time. Figure 2-2 is a geographic plot of position history
(latitude, longitude) versus time. In the case of ownship, the position history is a known
item; ownship knows where it has been, and maintains a history of these positions. In the
case of the contact, the position history of the contact is an estimate. The point of TMA
is to accurately estimate the position and trajectory of a contact. If the range, bearing,
course, and speed of a contact are known, the position history of the contact is known.
More importantly, the future position of the contact can be predicted.2
A tracker is an algorithm that processes the electrical signals output from the hydrophone
array and determines the bearing to the contact. Every few seconds, the tracker will
produce a bearing which is valid at that particular instant in time. For example, the
bearing α1, the first bearing collected, might be 1800 seconds (30 minutes) old. The
second bearing, α2, might be 1780 seconds old, up until αn, which might be 20 seconds
old.
A shorthand expression for this process is to “assign a tracker to a contact”. Assigning a
tracker to a contact results in an incoming stream of measurements, each of which is the
bearing to the contact at a particular instant in time.
2 Some simplifying assumptions are made in this discussion.
7
Contact
Ownship
α1 α2 α3αn-1 αn
Figure 2-2 A submarine conducting Target Motion Analysis.
This measurement set, or time-history set of bearings is collected and fed into another
algorithm, the output of which is an estimate of the range, course and speed of the
contact. The bearing to the contact is already known, since it is one of the measurements.
When a submarine conducts TMA, it is said to track the contact. It is possible to track
multiple contacts at the same time. In this case, a separate tracker would be assigned to
each contact being tracked.
Trackers are given alphanumeric designators such as PBB1 (Passive Broadband tracker
1), PBB2 (Passive Broadband tracker 2), etc. The phrase “PBB1 is assigned to contact 1”
8
means Passive Broadband tracker 1 is generating a time-history set of bearings on contact
number 1.
2.2.4 Filtered Input Data Units (Fidus)
A tracker will often produce bearings at a rate of 1 per second. These 1-second bearings
are usually averaged into 20-second data units. This averaging, or filtering, occurs
before the TMA algorithm processes the measurement set. These filtered data units are
referred to as Filtered Input Data Units, or Fidus for short.
From a software development point of view, a Fidu is an object with several fields, a few
of which are:
• Bearing – The bearing to the contact.
• Tracker Designator – The tracker that produced the Fidu. If the Fidu originated from
tracker PBB1, then the Tracker Designator is PBB1.
• Contact Designator – The contact that the tracker is assigned to. If the tracker is
assigned to contact 2, then the Contact Designator is 2.
2.3 The Sensor History Server
As Fidus stream from a tracker (or trackers) they are held in a data store for subsequent
retrieval for TMA processing. This is the purpose of the Sensor History Server.
Within the server, Fidus are organized as lists of data. All Fidus with the same Tracker
Designator are stored on the same list; the PBB1 tracker list holds all Fidus that have a
Tracker Designator of PBB1. All Fidus with the same Contact Designator are stored on
the same list; the “contact 1” contact list holds all Fidus that have a Contact Designator of
1.
9
2.4 Technology
2.4.1. Threads and Concurrent Servers
The most basic type of server is an iterative server. An iterative server can only process
one client request at a time. If two clients make overlapping requests, the second client
will block until the server is finished processing the first client’s request. This technique
is inadequate for all but the simplest servers.
When client requests can take longer to service, multiple clients should be handled at the
same time. The simplest way to write a concurrent server under Unix is to fork a child
process to handle each client [Ste98]. The fork system call is the way to create a new
process under Unix. This new process is referred to as a child process, and the server is
knows as the parent process. The child process then services the client, and the parent
process waits for another connection.
Many operating systems support the notion of a single execution path, or thread, through
the process. Given a model such as this, the only way to write a concurrent server is to
fork a new child process for each incoming connection. The notion, however, of creating
a new process for each client connection is dated. Creating a new process is expensive;
context switching and kernel intervention is required for inter-process communication /
sharing of data.
Modern operating systems overcome the limitations of single-threaded processes by
providing multi-threaded concurrency mechanisms that support the creation of multiple
processes, each of which may contain multiple concurrent threads. Each thread serves as
a unit of execution that runs within a process address space that is shared by other threads
[SSR+00]. Windows 2000 and SuSE 7.2 GNU/Linux both take this approach.
10
In the case of a concurrent server, a new thread3, rather than a new process can service
each incoming client request.
The key benefits of threads are due to performance implications [Sta01]:
1. It takes far less time to create a new thread in an existing process than to create a
brand-new process.
2. It takes less time to terminate a thread than a process.
3. It takes less time to switch between two threads within the same process.
4. Threads enhance efficiency in communication between different executing programs.
In most operating systems, communication between independent processes requires
the intervention of the kernel to provide protection and the mechanisms needed for
communication. However, because threads within the same process share memory
and files, they can communicate with each other without invoking the kernel.
2.4.2. Concurrent Programming
Concurrency is a term that refers to a family of policies and mechanisms that enable one
or more threads or processes to execute their service processing tasks simultaneously
[Ben90]. Many networked applications, particularly servers, must handle requests from
multiple clients concurrently [SSR+00].
Separate threads in multi-threaded programs often communicate via access to shared
resources. A shared resource is any resource that is accessed by more than one thread of
execution. However, multi-threaded programs that access shared resources have certain
constraints placed upon them. In particular, critical sections of code should only be
accesses by one thread at a time.
Synchronization policies must be used to ensure that two threads do not access critical
sections of code simultaneously; this guarantees correctness of program state. There are
two basic kinds of synchronization: mutual exclusion and condition synchronization.
3 Other programming techniques, such as a thread pool, can also be used.
11
Mutual exclusion is a mechanism of ensuring that critical sections of statements do not
execute at the same time. Condition synchronization is a mechanism of delaying a
process until a given condition is true [And00].
Sections 4.3 and 4.4 describe how these policies and mechanisms apply to the design of
the server.
2.4.3. The Common Object Request Broker Architecture
CORBA4 provides platform-independent programming interfaces and modules for
portable distributed object oriented computing applications [HV99]. CORBA is one of
several popular distributed object oriented computing paradigms.
Use of a distributed object oriented paradigm simplifies network communication and
provides an abstraction consistent with the object oriented programming model. In the
most general sense, any object that has one of its methods invoked is providing a service
to the caller. The caller can be thought of as a client to the object whose method is being
invoked. The object whose method is being invoked (target object) is providing a service
to the caller, that is, acting as a server.
The use of CORBA (as well as other distributed object oriented computing paradigms)
extends this idea such that callers and target objects can be located on the same or on
different computers. The entire request invocation mechanism is completely transparent
to the client, to whom a request on a remote object looks like an ordinary method
invocation. This is known as location transparency. The client does not know or care
whether the target object is local to its address space, is implemented in a different
process on the same machine, or is implemented in a process on a different machine
[HV99].
The CORBA Interface Definition Language (IDL) is an interface specification language
whose purpose is to define services that objects will expose to distributed clients. An 4 See www.omg.org for a discussion of the Object Management Group and CORBA.
12
object specifies its interface via IDL, and then the IDL interface specification is compiled
into source code definitions for the target language, in this case Java.
2.4.4. The Java Programming Language
The Java programming language is well suited to a distributed object oriented multi-
threaded server for the following reasons:
• Java is a multi-platform language. Java can run on any computer that supports a Java
Virtual Machine (JVM). This reduces development cost, as developers do not have to
be concerned with subtle Application Programming Interface (API) differences across
distinct operating systems. This is especially evident when making operating system
and networking API calls. Operating system APIs are especially non-portable, even
across releases of the same platform [SSR+00].
• Core threading functionality is built into the language (java.lang). This facilitates
the process of writing operating system independent multi-threaded applications. The
heterogeneity of contemporary hardware and software platforms complicates the
development of concurrent applications and tools that must run on multiple operating
systems [SSR+00].
For example, shutting down multi-threaded applications gracefully and predictably is
hard. The problem stems from inconsistent thread cancellation semantics across
operating systems, such as Posix/Unix and Win32. Additionally, support for
advanced threading features such as thread specific storage and daemon5 threads
varies widely across operating systems [Lew95].
5 Under Unix, a daemon process is a process that does not have a controlling terminal; it is said to run in the background [Ste93]. Under Windows, the same principle is referred to as a Service. An example of a Unix daemon or a Windows Service is a print-queue manager. The concept of a daemon process extends to a thread running in a JVM. There are two types of threads in a JVM: daemon threads and user threads. The programmer explicitly creates user threads. Daemon threads are threads that will not prevent the JVM from exiting [OW99]. An example of a daemon thread is the Garbage Collector. It is started by the JVM on the user’s behalf. The JVM will exit after all of the user-defined threads have exited.
13
Software development for a JVM runtime, which encapsulates low-level operating
system specific semantics, relieves the developer of the complexities and intricacies
of these details.
• Core networking functionality is built into the language (java.net).
• An Object Request Broker (ORB) is built into the language (org.omg.CORBA), as
well as numerous third party ORBs.
2.5 Chapter Summary
The Sensor History Server is a concurrent multi-threaded server, which serves time-
history lists of Fidus; its architecture supports simultaneous requests for Fidu lists from
multiple clients. Within the server, tracker lists and contact lists are shared resources,
accessible by any thread that is handling a client request.
Concurrent programming techniques are used to ensure the integrity of these shared
resources during client access. Mutual exclusion is used to guarantee that a reader and
writer do not access the same list simultaneously. Mutual exclusion is achieved via
condition synchronization. A list that is being written will block reader access until the
writer is finished. Condition synchronization is also used to prevent two writers from
accessing the same list simultaneously.
A CORBA layer wraps the internal logic of the server. All remote requests occur via
CORBA IDL.
The architecture of the server is discussed in greater detail in Chapter 7.
14
3 Data Flow
3.1 Introduction
This Chapter traces the flow of a Fidu through the Sensor History Server. The
characteristics of this data flow lay the foundation for the architecture of the server.
The following cases are considered:
• The arrival of a Fidu for a tracker list / contact list prior to tracker list wraparound
(§3.6.1).
• The arrival of a Fidu for a tracker list / contact list accompanied by waterfall (§3.4) of
the oldest Fidu from the tracker list.
This case is further divided into the following two cases:
o Removal of the oldest Fidu from the same contact list to which the new Fidu is
being added (§3.6.2).
o Removal of the oldest Fidu from a different contact list than the list to which the
new Fidu is being added (§3.6.3).
3.2 Background
The server contains a series of tracker lists and contact lists. A tracker list or a contact
list is simply a ring buffer with a certain finite capacity. Fidus are added to the buffer
until the buffer is full. After this point, the arrival of a new Fidu necessitates the removal
of the oldest Fidu from the list.
Fidus are designated by Tracker Designator and Contact Designator. The receiving
process (server) forwards the Fidu to the appropriate tracker list / contact list based on
these designators.
15
Since each Fidu has two designators, the server holds each Fidu on two different lists: a
tracker list and a contact list.
This allows the server to handle two fundamental types of requests.
• Return all Fidus for a particular tracker, that is, return all Fidus for tracker PBB1.
• Return all Fidus for a particular contact, that is, return all Fidus for contact 1.
If the Fidus only lived on a list organized by tracker, the list might appear as:
N Fidus (bearing estimates) per tracker
Trac
kers PBB1
PBB2
Figure 3-1 A list of Fidus designated by tracker source.
Similarly, if Fidus only lived on lists organized by contact, the list might appear as:
Con
tact
s
N Fidus (bearing estimates) per contact
Contact 1
Contact 2
Figure 3-2 A list of Fidus designated by contact source.
What is required, however, is a list structure that looks like this:
16
Con
tact
1P
BB
2
TimeNewest Oldest
Figure 3-3 A list structure for Fidu storage.
Each box represents a Fidu. Each Fidu is always on two lists. The newest Fidu on each
list is towards the left in the diagram. The oldest Fidu is towards the right.
A contact list can have multiple tracker lists associated with it, that is, a contact list can
reference Fidus that are referenced from multiple tracker lists. Figure 3-4 shows a
contact list (Contact 1) that references Fidus that are referenced from two tracker lists
(PBB1 and PBB2).
Con
tact
1P
BB
1P
BB
2
Figure 3-4 A pool of Fidus accessible via tracker list and/or contact list.
A tracker list can also reference Fidus from multiple contact lists. In Figure 3-5, there is
one tracker list that references Fidus that are referenced by two contact lists.
17
Con
tact
1P
BB
2C
onta
ct 2
Figure 3-5 A tracker with history on multiple contacts.
3.3 List Wraparound
Once the ring buffer is full, the list is said to be in wraparound. The term wraparound
makes sense when applied to an array with first and last pointers denoting the most recent
and oldest elements in the array, respectively. When the array fills up, the pointers will
“wraparound”. Although this is not necessarily the actual implementation of any of the
classes in Sun’s Collection framework, the term is used for historical purposes.
3.4 Fidu Waterfall
The term waterfall refers to the process of removing a Fidu from the end of a tracker list.
Once the list is full, the arrival of a new Fidu forces the removal of the oldest Fidu on the
list. The Fidu is said to waterfall off the end of the list.
3.5 Fidu Capacity
Fidus are received over a period of time, nominally one Fidu per tracker every 20
seconds.
18
The notion of Fidu capacity only applies to tracker lists. In some implementations, a
tracker list is limited to 340 Fidus. This is due to legacy limitations with database size
(there is no reason to have this limitation with a modern architecture). With a default
Fidu capacity of 340, Fidus will begin to waterfall off of a given tracker list at the arrival
of the 341st Fidu.
Consequently, if a contact has two trackers assigned to it, the contact list will hold 680
Fidus, 340 from each tracker. The number of Fidus on a contact list is determined by two
factors:
• The number of trackers on the contact.
• The Fidu capacity of each tracker list.
Fidus waterfall off tracker lists, not contact lists. It is the tracker list that determines
when it is time to waterfall a Fidu. When a Fidu waterfalls off the tracker list, it must
(somehow) be removed from its contact list.
3.6 Fidu Lifecycle
Consider a PBB2 tracker list with some capacity M, where M is the maximum number of
Fidus that can be on the list. For purposes of illustration, let M = 340. At any point in
time, the number of Fidus on the list is N, where 1 <= N <= M. The total number of Fidu
arrivals for a given tracker list is λ, where λ >= 1.
Table 3-1 Relationship Between Fidu Arrivals and List Wraparound
Arrivals Number of Fidus on list Wraparound1 <= λ <= M 1 <= N <= M No
λ > M N = M Yes
19
Table 3-1 shows the relationship between the number of Fidu arrivals for a tracker list,
the number of Fidus on the tracker list and whether the list is in wraparound.
3.6.1. Fidu Arrival Prior to Tracker List Wraparound
Fidu arrival prior to tracker list wraparound implies λ <= M.
Consider the arrival of a Fidu with a Tracker Designator of PBB2 and a Contact
Designator of 1. This means the Fidu will go on the PBB2 tracker list and the “Contact
1” contact list. When the Fidu arrives, it is the newest Fidu on both lists.
Let this Fidu be the 155th Fidu to arrive for the PBB2 tracker list. Since the number of
Fidu arrivals on the tracker list λ is <= M, Fidu waterfall does not occur off the end of the
PBB2 list.
Figure 3-6 shows the state of the PBB2 tracker / Contact 1 list at this instant in time.
17
155 6 4
35
2
Con
tact
1P
BB
2
TimeNewest Oldest
Figure 3-6 A tracker list prior to wraparound.
3.6.2. Fidu Arrival with Tracker List Wraparound and Removal from the Same Contact
List
Figure 3-7 shows the PBB2 tracker / “Contact 1” contact list after 340 Fidu arrivals.
Since λ = M = 340, the arrival of the 341st Fidu will cause the 1st Fidu to waterfall off the
PBB2 tracker list and be removed from the “Contact 1” contact list.
20
17
340 6 4
35
2
Con
tact
1P
BB
2
TimeNewest Oldest
Figure 3-7 A tracker list at wraparound.
Figure 3-8 shows the lists after the arrival of the 341st Fidu. The 2nd Fidu to arrive is now
the oldest Fidu in both lists. The arrival of the 342nd Fidu will cause this Fidu to waterfall
of the tracker list and be removed from the “Contact 1” contact list.
28
341 7 5
46
3
Con
tact
1P
BB
2
TimeNewest Oldest
Figure 3-8 A tracker list in wraparound with removal from the same contact list.
3.6.3. Fidu Arrival with Tracker List Wraparound and Removal from a Different
Contact List
Figure 3-9 shows the PBB2 tracker list and two contact lists, Contact 1 and Contact 2.
Fidus one through five have a Tracker Designator of PBB2 and a Contact Designator of
“Contact 2”. Fidus six and up have a Tracker Designator of PBB2 and a Contact
Designator of “Contact 1”.
21
17
340 6 4
35
2
Con
tact
1P
BB
2C
onta
ct 2
TimeNewest Oldest
Figure 3-9 A tracker list at wraparound with history on multiple contacts.
The arrival of the 341st Fidu causes Fidu number 1 to waterfall from the PBB2 tracker list
and to be removed from the “Contact 2” contact list.
28
341 7 5
46
3
Con
tact
1P
BB
2C
onta
ct 2
TimeNewest Oldest
Figure 3-10 A tracker list in wraparound with removal from a different contact list.
3.7 Chapter Summary
Every Fidu is stored on two different lists, a tracker list and a contact list. This allows a
consumer to request all Fidus for a particular tracker or all Fidus for a particular contact.
Since contact lists can reference Fidus that are referenced from multiple tracker lists, a
22
request for a contact list may result in the delivery of Fidus from multiple tracker lists.
This is by design and facilitates TMA processing.
Fidus waterfall off of tracker lists. When this happens, the waterfalling Fidu must be
removed from its associated contact list. This implies some communication mechanism
is needed between Fidus, tracker lists, and contact lists. This is the topic of §4.2.
23
4 Design Requirements
4.1 Introduction
There are three fundamental forces behind the design of the server.
• There is a data dependency between trackers and contacts. That is, a dependency
exists between tracker lists and contact lists. As described in Chapter 3, every Fidu
on a tracker list is also on a contact list. Conversely, every Fidu on a contact list is
also on a tracker list.
• Tracker lists and contact lists are shared resources. Given this, synchronization
mechanisms must be applied to prevent simultaneous list access by producers and
consumers (writers and readers). At the same time, the choice of synchronization
technique should maximize program liveness.
• Resource ordering must be considered and enforced to preclude the possibility of
deadlock.
This Chapter describes these forces, thereby illuminating and justifying the architecture
of the server.
4.2 Data Dependency
The fact that every Fidu resides on two lists has the following implication:
• When a Fidu waterfalls off a tracker list, it must be removed from its corresponding
contact list.
Therefore contact lists are dependant upon Fidu state. When the Fidu state changes (the
Fidu waterfalls of the tracker list), the contact list must change as well.
24
The tracker list “knows” when it is time to waterfall a Fidu, based on its user defined list
capacity.
Tracker lists are also dependent on Fidu state. The server can receive a request to delete
a contact. The server will iterate through the requested contact list and delete every Fidu.
When this happens, each Fidu must be removed from its tracker list.
The dependency between tracker / contact lists and Fidu state implies coupling between
tracker lists and contact lists. An event occurring on a tracker list (a Fidu waterfall)
implies a change in a contact list. An event occurring on a contact list (a delete contact
request) implies a change in a tracker list.
Loose coupling increases the probability that a class can be reused by itself and that a
system can be learned, ported, modified, and extended more easily [GoF95].
The coupling between tracker lists and contact lists should happen at the Fidu level, not
the tracker list or the contact list level. This simplifies tracker lists and contact lists.
Tracker lists do not directly know about contact lists; contact lists do not directly know
about tracker lists. Fidus can be reused in other implementations.
The Observer design pattern decouples senders (subjects) from receivers (observers) by
defining an interface for signaling changes in subjects [GoF95]. The Fidu is the message
sender (subject). The tracker list and the contact list are message receivers (observers).
When a Fidu is deleted from a tracker list, the Fidu will send a message to its contact list.
When the contact list receives the message, it will delete the Fidu. Conversely, when a
Fidu is deleted from a contact list the Fidu will send a message to its tracker list. When
the tracker list receives the message, it will delete the Fidu.
Section 4.2.1 illustrates the use of the Observer design pattern.
25
4.2.1 Use of the Observer Design Pattern
The following example steps through the sequence of events that occur upon the addition
of a Fidu (subject) to a waterfalling tracker list (observer).
Figure 4-1 shows a tracker list and contact list after the addition of a few Fidus. Each
Fidu plays the role of the subject in the Observer design pattern (all Fidus are not labeled
as such). Each list plays the role of the observer.
17
214 6 4
35
2
Con
tact
1(O
bser
ver)
PB
B2
(Obs
erve
r)
TimeNewest Oldest
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Figure 4-1 Subjects and observers.
As new Fidus are added to the lists, each list must register itself as an observer of each
Fidu. This registration establishes the communication mechanism between subject and
observer.
The next diagram shows a tracker list that has reached its user defined capacity. As
stated in §3.6.2, the addition of the next Fidu will cause the 1st Fidu to waterfall off the
tracker list and be removed from the contact list.
26
17
340
339
6 4
35
2
Con
tact
1(O
bser
ver)
PB
B2
(Obs
erve
r)
TimeNewest Oldest
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Sub
ject
The following sequence of events will occur upon arrival of the 341st Fidu:
1) The capacity of the PBB2 tracker list will be checked. Since the list is full, the
tracker list will be deregistered as an observer of the 1st Fidu.
2) The 1st Fidu will be removed from the PBB2 tracker list.
Figure 4-2 shows that state of the tracker list at this point. The 1st Fidu is no longer on
the PBB2 list.
17
340
339
6 4
35
2
Con
tact
1(O
bser
ver)
PB
B2
(Obs
erve
r)
TimeNewest Oldest
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Figure 4-2 Removing a waterfalling Fidu (subject) from a tracker list (observer).
3) A message will be sent to the 1st Fidu to delete itself. This Fidu will in turn send a
message to any of its observers that it is changing state (being deleted).
4) Since the contact list is still an observer of the 1st Fidu, it will be notified that this
Fidu is being deleted.
27
5) The contact list will be deregistered as an observer of the 1st Fidu. This Fidu will then
be removed from the contact list.
6) The tracker list will be registered as an observer of the 341st Fidu. This Fidu will be
added to the tracker list.
7) The contact list will be registered as an observer of the 341st Fidu. This Fidu will be
added to the contact list.
Figure 4-3 shows each list after the removal of the 1st Fidu and the addition of the 341st
Fidu.
399
28
341
340
7 5
46
3
Con
tact
1(O
bser
ver)
PB
B2
(Obs
erve
r)
TimeNewest Oldest
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Sub
ject
Figure 4-3 Fidu addition to a tracker list in wraparound.
The sequence of events that occurs when Fidu removal is initiated via activity on a
contact list is similar.
4.3 Shared Resources
Tracker lists and contact lists are shared resources. At any time, multiple concurrent
threads may need to read from or write to a tracker list or a contact list.
Data corruption in tracker lists or contact lists can occur under two circumstances:
• Multiple concurrently executing threads try to read from and write to the same list.
• Multiple concurrently executing threads try to write to the same list.
28
To prevent this problem, the following conditions should be enforced:
• A reader and a writer should not be allowed into the same list simultaneously.
• Multiple writers should not be allowed into the same list simultaneously.
Code that should not execute concurrently in objects or functions can be synchronized
within a critical section [SSR+00]. A critical section is a sequence of instructions that
obeys the following invariant: while one thread or process is executing in the critical
section, no other process can execute in the same critical section [Tan95].
Tracker lists and contact lists are critical sections of code and their access must be
controlled with synchronization techniques.
A mutex, which stands for mutual exclusion, is the most basic form of synchronization.
A mutex lock is used to protect a critical region, to make certain that only one thread at a
time executes the code within the region [Ste99]. Note that the terms critical section and
critical region are interchangeable. A survey of relevant literature will reveal both uses.
Use of a mutex lock would meet the two conditions stated above; it would keep
simultaneous readers and writers out of the same list and it would keep simultaneous
writers out of the same list.
However, there is no reason not to allow multiple readers into the same list. Since
readers do not modify the list, there is no harm in allowing multiple readers access.
Doing so allows for the possibility of increased concurrency by allowing multiple threads
to process the same list simultaneously. Stated another way, allowing multiple readers
into the same list will allow the server to serve the same tracker list or contact list to
multiple consumers concurrently.
This type of problem (multiple readers and one writer) is, of course, the classic readers
and writers problem. It is also known as shared-exclusive locking, because obtaining a
29
read-write lock for reading is called a shared lock, and obtaining a read-write lock for
writing is called an exclusive lock [Ste99].
Read-write locks are generally preferable to plain locks when [Lea99]:
• The methods in a class can be cleanly separated into those that only access (read)
internally held data and those that modify (write).
• Reading is not permitted while writing methods are in progress.
• Target applications generally have more readers than writers.
• The methods are relatively time consuming, so it pays to introduce a bit more
overhead associated with read-write locks compared to simpler techniques in order to
allow concurrency among reader threads.
Read-write locks are often used in classes that provide access to large collections of data.
As is evident, read-write locks will be the basic synchronization mechanism to protect the
integrity of critical sections of code (tracker lists and contact lists).
4.4 Resource Ordering
Given the background established in Chapter 3 and §4.2, the process of adding a Fidu to
the server will always result in the acquisition of write locks for at least two resources
and often, a third.
A tracker list can be considered in a transient state when it is not in wraparound. That is,
before it has reached its user defined capacity. A tracker list is in steady state once it has
reached its capacity. As described in Chapter 3, when a tracker list has reached its
capacity the arrival of a (new) Fidu forces the waterfall of the oldest Fidu.
When a tracker list is in a transient state, the addition of a Fidu results in the acquisition
two write locks, a write lock for the designated tracker list and a write lock for the
designated contact list.
30
When a tracker list is in steady state, the addition of a Fidu results in the acquisition of a
third write lock; the write lock for the contact list the oldest Fidu on the tracker list is
being removed from.
Any time multiple threads attempt to acquire multiple resources a deadlock condition can
occur. Deadlock is a concurrency hazard that occurs when multiple threads attempt to
acquire multiple locks and become blocked indefinitely in a circular wait state [SSR+00].
Resource ordering is a simple technique to preclude deadlock when a thread needs to
acquire locks on multiple resources to perform its task. Deadlock cannot occur if the
resources are always acquired in a predictable order.
The following example illustrates the need to establish a predictable pattern around the
acquisition of resources.
Consider a situation with two tracker lists and two contact lists as in Figure 4-4. Each
tracker list is in wraparound and has history on multiple contacts. The specific number of
Fidus on each tracker list is arbitrary, as long as each tracker list is in wraparound.
Thread 1 is adding the 341st Fidu to the PBB2 tracker list / Contact 1 list. Thread 2 is
adding the 350th Fidu to the PBB1 tracker list / Contact 2 list.
31
17
340
339
6 4
35
2
Con
tact
1P
BB
2C
onta
ct 2
TimeNewest Oldest
PB
B1
348
1016349
15 13
1214
11
Thread 1
Thread 2
Figure 4-4 Multiple tracker lists with history on multiple contacts.
It is possible that the simultaneous arrival of Fidus for each set of lists could lead to the
following sequence of events:
Thread 1
1. Request and acquire the write
lock for the PBB2 Tracker list.
2. Since the PBB2 Tracker list is
in wraparound, request and
acquire the write lock for the
Contact 2 list.
3. Thread 1 gets swapped out and
Thread 2 gets swapped in.
Thread 2
4. Request and acquire the write
lock for the PBB1 Tracker list.
5. Since the PBB1 Tracker list is
in wraparound, request and
32
As is evident, deadlock can occur without a predictable scheme to acquire resources. The
following resource acquisition scheme will guarantee that deadlock cannot occur:
• Tracker lists are always locked before contact lists.
• Two contact lists are never locked at the same time.
Given the scenario in Figure 4-4, Thread 1 will acquire and release the write lock for
Contact 2 before it tries to acquire the write lock for Contact 1. Since locks for multiple
contact lists are not held simultaneously, deadlock cannot occur due to interleaving lock
acquisition patterns. The same reasoning applies for Thread 2.
7. Request the write lock for the
Contact 1 list. At this point,
Thread 1 will block on the
request, waiting until Thread 2
releases the Contact 1 lock.
8. Thread 1 gets swapped out and
Thread 2 gets swapped in.
acquire the write lock for the
Contact 1 list.
6. Thread 2 gets swapped out and
Thread 1 gets swapped in.
9. Request the write lock for the
Contact 2 list. At this point,
Thread 2 will block on the
request, waiting until Thread 1
releases the Contact 2 lock.
33
4.5 Chapter Summary
There are three fundamental forces behind the design of the server:
1. A dependency exists between trackers lists and contact lists.
2. Tracker lists and contact lists are shared resources.
3. Resource ordering must be enforced to preclude the possibility of deadlock.
These forces lead to the following design strategies:
1. The Observer design pattern will be used to decouple tracker lists from contact lists,
and to allow Fidus to signal state changes to tracker lists and contact lists.
2. Tracker lists and contact lists are shared resources. Read write locks (shared
exclusive locks) will be used as the basic synchronization mechanism. Read write
locks allow multiple readers into the same list simultaneously, while allowing a writer
exclusive access.
3. Tracker lists will always be locked before contact lists. Two contact lists are never
locked at the same time. This will prevent deadlock due to interleaving contact list
access patterns.
34
5 Use Cases
5.1 Introduction
This Chapter describes the use cases of the server. A use case is a narrative document
that describes the sequences of events of an actor (an external agent) using a system to
complete a process [Lar98]. They are an informal description of what a system does and
who or what is interacting with the system. They are often used to capture the high level
functional requirements of a system.
The following use cases will be described:
Table 5-1 Use Cases for the Sensor History Server
Use Case Purpose Add Fidu Add a Fidu to the server Add Collection of Fidus Add a collection of Fidus to the server Get Fidus for Tracker Stream a tracker list to the client Get Fidus for Contact Stream a contact list to the client Delete Tracker Delete a tracker list from the server Delete Contact Delete a contact list from the server Get List of Trackers Stream a description of all tracker lists to the client Get List of Contacts Stream a description of all contact lists to the client
A use case diagram for the server is presented followed by a description of each use case.
35
5.2 Use Case Diagram for the Sensor History Server
Direction of arrow indicates flow of information.
Add Fidu
Add Sequence Fidus
Producer
Get Fidus For Tracker
Get Fidus For Contact
Delete Tracker
Delete Contact
Get Tracker List
Consumer
Get Contact List
Figure 5-1 Use case diagram for the Sensor History Server.
There are two external agents interacting with the system: a producer of Fidus and a
consumer of Fidus. The producer and consumer are each capable of initiating multiple
use cases. It is possible to have several producers and it is expected to have several
consumers.
36
5.3 Add Fidu
Actors: Producer (initiator), Sensor History Server.
Purpose: Add a Fidu to the server.
Overview: The producer creates a Fidu and streams it to the server. The server
examines the Fidu for pre-condition adherence, and adds the Fidu to its
designated tracker list and contact list.
Typical course of events
Actor Action System Response
Alternative Courses
Line 2: Invalid Tracker Designator. Throw exception to the client (Fidu producer).
Line 2: Invalid Contact Designator. Throw exception to the client.
Line 2: User specified tracker list capacity reached. Throw exception to the client.
Line 2: User specified contact list capacity reached. Throw exception to the client.
1. The Fidu producer creates a Fidu and streams it to the server.
2. The server receives the Fidu
and examines the Tracker Designator and Contact Designator.
3. The server adds the Fidu to the tracker list specified by the Tracker Designator.
4. The server adds the Fidu to the contact list specified by the Contact Designator.
37
5.4 Add Collection of Fidus
Actors: Producer (initiator), Sensor History Server.
Purpose: Add a Collection of Fidus to the server.
Overview: The producer creates a collection of Fidus and streams it to the server.
The server examines each Fidu for pre-condition adherence, and adds
each Fidu to its designated tracker list and contact list.
Typical course of events
Actor Action System Response
Alternative Courses
Line 2: Invalid Tracker Designator. Throw exception to the client.
Line 2: Invalid Contact Designator. Throw exception to the client.
Line 2: User specified tracker list capacity reached. Throw exception to the client.
Line 2: User specified contact list capacity reached. Throw exception to the client.
1. The Fidu producer creates a collection of Fidus and streams it to the server.
2. The server receives the Fidu
collection and examines the Tracker Designator and Contact Designator of each Fidu.
3. The server adds each Fidu to the tracker list specified by the (Fidu’s) Tracker Designator.
4. The server adds each Fidu to the contact list specified by the (Fidu’s) Contact Designator.
38
5.5 Get Fidus For Tracker
Actors: Consumer (initiator), Sensor History Server.
Purpose: Stream a tracker list to the client.
Overview: The consumer requests a collection of Fidus for a tracker. The server
examines the Tracker Designator for pre-condition adherence, and
streams a tracker list to the client.
Typical course of events
Actor Action System Response
Alternative Courses
Line 2: Invalid Tracker Designator. Throw exception to the client.
Line 2: The tracker list specified by the Tracker Designator does not exist. Throw
exception to the client.
1. The consumer requests a collection of Fidus for a Tracker Designator.
2. The server receives the
request and examines the Tracker Designator.
3. The server streams the tracker list specified by the Tracker Designator to the client.
39
5.6 Get Fidus For Contact
Actors: Consumer (initiator), Sensor History Server.
Purpose: Stream a contact list to the client.
Overview: The consumer requests a collection of Fidus for a contact. The server
examines the Contact Designator for pre-condition adherence, and
streams a contact list to the client.
Typical course of events
Actor Action System Response
Alternative Courses
Line 2: Invalid Contact Designator. Throw exception to the client.
Line 2: The contact list specified by the Contact Designator does not exist. Throw
exception to the client.
1. The consumer requests a collection of Fidus for a Contact Designator.
2. The server receives the
request and examines the Contact Designator.
3. The server streams the tracker list specified by the Contact Designator to the client.
40
5.7 Delete Tracker
Actors: Consumer (initiator), Sensor History Server.
Purpose: Delete a tracker list from the server.
Overview: The consumer requests to delete a tracker. The server examines the
Tracker Designator for pre-condition adherence, and deletes the
tracker list.
Typical course of events
Actor Action System Response
Alternative Courses
Line 2: Invalid Tracker Designator. Throw exception to the client.
Line 2: The tracker list specified by the Tracker Designator does not exist. No action.
1. The consumer requests to delete a tracker list specified by a Tracker Designator.
2. The server receives the
request and examines the Tracker Designator.
3. The server deletes the tracker list specified by the Tracker Designator.
4. The server also deletes each Fidu on the tracker list from the Fidu’s associated contact list.
41
5.8 Delete Contact
Actors: Consumer (initiator), Sensor History Server.
Purpose: Delete a contact list from the server.
Overview: The consumer requests to delete a contact. The server examines the
Contact Designator for pre-condition adherence, and deletes the
contact list.
Typical course of events
Actor Action System Response
Alternative Courses
Line 2: Invalid Contact Designator. Throw exception to the client.
Line 2: The contact list specified by the Contact Designator does not exist. No action.
1. The consumer requests to delete a contact list specified by a Contact Designator.
2. The server receives the
request and examines the Contact Designator.
3. The server deletes the contact list specified by the Contact Designator.
4. The server also deletes each Fidu on the contact list from the Fidu’s associated tracker list.
42
5.9 Get List of Trackers
Actors: Consumer (initiator), Sensor History Server.
Purpose: Stream a description of all tracker lists to the client.
Overview: The consumer requests a list of all trackers in the server.
Typical course of events
Actor Action System Response
Alternative Courses
None.
1. The consumer requests a list of all trackers in the server.
2. The server receives the
request. 3. The server creates a list of all
trackers and streams this list to the client.
43
5.10 Get List of Contacts
Actors: Consumer (initiator), Sensor History Server.
Purpose: Stream a description of all contact lists to the client.
Overview: The consumer requests a list of all contacts in the server
Typical course of events
Actor Action System Response
Alternative Courses
None.
1. The consumer requests a list of all contacts in the server.
2. The server receives the
request. 3. The server creates a list of
all contacts and streams this list to the client.
44
6 Requirements
6.1 Introduction
This Chapter describes the requirements of the server. Requirements are a description of
needs or desires for a product. The primary goal of a requirements document is to
identify what is really needed, in a form that clearly communicates to the client and to
development team members [Lar98].
6.2 Overview Statement
The purpose of the Sensor History Server is to provide a data archiving and retrieval
capability for data that is used in Target Motion Analysis as well as other submarine
combat control system applications.
6.3 Customers
The customers for this product are applications typically found in submarine combat
control systems.
6.4 Goals
The goal of this product is to develop an acoustic Sensor History Server that places no
architectural limits on the following items:
o The number of contacts that are stored in the server.
o The number of trackers that are stored in the server.
o The number of Fidus per tracker.
45
6.5 System Functions
System functions are what a system is supposed to do. System functions should be
categorized in order to prioritize them and identify those that might otherwise be taken
for granted [Lar98].
Table 6-1 System Function Categories
Function Category Meaning Evident Should perform, and the user should be cognizant that it is
performed. Hidden Should perform, but not be visible to users. This is true of many
underlying technical services. Frill Optional, adding it does not significantly affect cost or other
functions.
6.5.1 Fidu Ingestion The Sensor History Server shall ingest an individual Fidu. A Tracker Designator
and a Contact Designator shall designate the Fidu. The client application shall
specify the Tracker Designator and the Contact Designator.
Each Fidu shall have a valid time stamp. A valid time stamp is a time stamp that
is greater than zero.
Category: Evident
6.5.2 Fidu Collection Ingestion The Sensor History Server shall ingest a collection of Fidus. A Tracker
Designator and a Contact Designator shall designate each Fidu in the collection of
Fidus. The client application shall specify the Tracker Designator and the Contact
Designator.
46
Each Fidu shall have a valid time stamp. A valid time stamp is a time stamp that
is greater than zero.
Category: Evident
6.5.3 Tracker List Capacity The Sensor History Server shall provide a mechanism to set the tracker list
capacity. A tracker list is a list of Fidus that is identified by the same Tracker
Designator. The tracker list capacity is the number of tracker lists the server will
process. This tracker list capacity shall be user configurable.
Category: Evident
6.5.4 Tracker List Capacity Exception The Sensor History Server shall reject a Fidu that is designated by a Tracker
Designator where the ingestion of that Fidu would cause the creation of a tracker
list that would exceed the tracker list capacity.
The server shall inform the client of the Fidu rejection and specify the reason for
the rejection.
Category: Evident
6.5.5 Contact List Capacity The Sensor History Server shall provide a mechanism to set the contact list
capacity. A contact list is a list of Fidus that is designated by the same Contact
Designator. The contact list capacity is the number of contact lists the server will
process. This contact list capacity shall be user configurable.
Category: Evident
47
6.5.6 Contact List Capacity Exception The Sensor History Server shall reject a Fidu that is designated by a Contact
Designator where the ingestion of that Fidu would cause the creation of a contact
list that would exceed the contact list capacity.
The server shall inform the client of the Fidu rejection and specify the reason for
the rejection.
Category: Evident
6.5.7 Fidus Per Tracker List The Sensor History Server shall provide a mechanism to specify the number of
Fidus per tracker list. The initial default capacity of each Fidu list shall be user
configurable.
Note that placing a limit on the number of Fidus per tracker list effectively places
a limit on the number of Fidus per contact list. For example, if there is a limit on
the number of Fidus per tracker of 340, and there is one tracker assigned to a
given contact, then there is a limit on the number of Fidus for that contact of 340.
If there are two trackers assigned to a given contact, then there is a limit on the
number of Fidus for that contact of 680, etc.
Category: Evident
6.5.8 Fidu Waterfall The Sensor History Server shall waterfall Fidus when a tracker list has reached its
Fidu capacity (and a new Fidu is being added to the list). The Fidu capacity of the
tracker list is the number of Fidus it can hold.
48
Category: Hidden
6.5.9 Tracker List Delivery The Sensor History Server shall serve a tracker list. A Tracker Designator shall
identify the tracker list. The client application shall specify the Tracker
Designator.
Category: Evident
6.5.10 Nonexistent Tracker Lists The Sensor History Server shall reject requests for nonexistent tracker lists. The
server shall inform the client of the rejection and specify the reason for the
rejection.
Category: Evident
6.5.11 Contact List Delivery The Sensor History Server shall serve a contact list. A Contact Designator shall
identify the contact list. The client application shall specify the Contact
Designator.
Category: Evident
6.5.12 Nonexistent Contact Lists The Sensor History Server shall reject requests for nonexistent contact lists. The
server shall inform the client of the rejection and specify the reason for the
rejection.
Category: Evident
49
6.5.13 Tracker List Deletion The Sensor History Server shall delete a tracker list. A Tracker Designator shall
identify the tracker list. The client application shall supply the Tracker
Designator.
Category: Evident
6.5.14 Contact List Deletion The Sensor History Server shall delete a contact list. A Contact Designator shall
identify the contact list. The client application shall supply the Contact
Designator.
Category: Evident
6.5.15 List of Tracker Properties The Sensor History Server shall serve a list of tracker properties. Each property
in the list will provide relevant information about the tracker list it is describing.
Category: Evident
6.5.16 List of Contact Properties The Sensor History Server shall serve a list of contact properties. Each property
in the list will provide relevant information about the contact list it is describing.
Category: Evident
50
7 Implementation
7.1 Introduction
This Chapter describes the high level implementation of the server. Physical Design is
the way functional components of an application are distributed over source files.
Correctly partitioning functionality over source files increases maintainability and
reusability of the code base [HV99].
In designing the server, careful consideration was given to separating the application
business logic from the software components that enable network communication.
7.2 High Level Architecture
Figure 7-1 shows a high level architectural diagram. The server consists of two main
components, a CORBA Translation and Delegation layer and the Fidu List Manager.
CORBAIDL
Interfaces
Sensor History Server
Fidu List Manager
JavaInterfaces
JavaDelegationUsing JavaData Types
CORBATranslation and
Delegation Layer
HistoryProducerServant
HistoryConsumerServant
Figure 7-1 Block structure of the Sensor History Server.
51
The CORBA Translation and Delegation layer is an Object Adapter that is responsible
for the following:
• Translate incoming service requests from a CORBA IDL data type to a neutral data
type understood by the Fidu List Manager (FLM). Use of a neutral data type within
the FLM allows the FLM to plug into any Application Service Infrastructure and
serve lists of objects over that particular protocol. In this case the protocol is CORBA
IIOP (Internet Inter-ORB Protocol).
• Delegate the service request to the Fidu List Manager.
• Process any data returned from the FLM, translating necessary objects from the
neutral data type to the applicable CORBA IDL data type, followed by transmission
back to the client.
All client communication (producer and consumer) occurs through the CORBA IDL
interfaces.
The Fidu List Manager is the application component that contains all the business logic
of the server. The design requirements in Chapter 4 specifically pertain to the design of
the Fidu List Manager. This component is designed so it has no knowledge of the
Application Service Infrastructure6 it resides within.
This design achieves clean separation of concerns. One part of the application – the
delegation layer in a separate set of source files – deals with enabling the application for
remote access via CORBA. The other part of the application – the core logic in its own
set of source files – implements the application semantics [HV99].
This separation allows the Fidu List Manager to be “unplugged” from a CORBA
communication infrastructure and plugged into another distributed object model, such as
Java Remote Method Invocation (RMI).
6 In this document, the Application Service Infrastructure is the CORBA Distributed Object Model that handles the low level client / server networking.
52
7.3 Translation and Delegation Layer
Figure 7-2 shows the class diagram for the CORBA Translation and Delegation layer.
This layer consists of the following items:
• Automatically generated source code. This source code is generated by an IDL
compiler and specified by CORBA IDL interface definition files. This generated
code defines the services that remote objects will expose to distributed clients as well
as the plumbing to carry out network communication. For example, the IDL compiler
automatically generates the HistoryProducerPOA.
• Implementation classes that implement interfaces as specified by CORBA IDL
interface definition files. These classes implement the hooks that allow the
application business logic to plug into the CORBA infrastructure. The two main
implementation classes are the HistoryProducerServant and the
HistoryConsumerServant.
The HistoryProducerServant is a CORBA Object Adapter responsible for the
producer side use cases:
• Add Fidu
• Add Collection of Fidus
The HistoryConsumerServant is a CORBA Object Adapter responsible for the
consumer side use cases:
• Get Fidus for Tracker
• Get Fidus for Contact
• Delete Tracker
• Delete Contact
• Get List of Trackers
• Get List of Contacts
53
An additional class, Main, bootstraps the server. A composition relationship exists
between the HistoryProducerServant, the HistoryConsumerServant and
the Main class. An association relationship exists between the ListManager (§7.4),
the HistoryProducerServant and the HistoryConsumerServant.
T h e M a in c la s s b o o t s t ra p s t h e S e n s o r H is t o ry S e rve r .
H is t o r y P ro d u c e rP O A
_ t h is ( )
(f ro m S H P )
M a ino rb : O R Bc o rb a U t i l i t i e s : C o rb a U t i l i t i e sl i s t M a n a g e r : L i s t M a n a g e rn a m in g C o n t e x t : N a m in g C o n t e x tc a t e g o ry : C a t e g o ry
m a in ( )r u n ( )s e t u p L o g 4 jL o g g in g ( )s h o w U s a g e ( )c le a n U p ( )
H is t o r y C o n s u m e rS e rva n tl i s t M a n a g e r : L is t M a n a g e r
H is t o ry C o n s u m e rS e rva n t ( )g e t F id u s F o rT ra c k e r ( )g e t F id u s F o rC o n t a c t ( )d e le t e T ra c k e r ( )d e le t e C o n t a c t ( )g e t T ra c k e rL i s t ( )g e t C o n t a c t L i s t ( )
1
+ C o n s u m e r O b je c t A d a p t e r
1
H is t o ry P ro d u c e rS e rva n tl i s t M a n a g e r : L is t M a n a g e r
a d d C o l l e c t i o n O fF id u s ( )H is t o ry P ro d u c e rS e rva n t ( )a d d F id u ( )
1+ P r o d u c e r O b j e c t A d a p t e r
1
L is t M a n a g e r
a d d F id u ( )a d d C o l l e c t i o n O fF id u s ( )g e t F id u s F o rT ra c k e r ( )g e t F id u s F o rC o n t a c t ( )d e le t e T ra c k e r ( )d e le t e C o n t a c t ( )g e t T ra c k e rL i s t ( )g e t C o n t a c t L is t ( )c le a n U p ( )
( f ro m l i s t M a n a g e r)
< < In t e rf a c e > >
+ M a n a g e F id u L i s t s
+ M a n a g e F id u L is t s
H is t o r y C o n s u m e rP O A
_ th i s ( )
( f ro m S H C )
T h e F i d u L i s t M a n a g e r(a n im p l e m e n ta t io n o f t h e L is t M a n a g e r i n te r fa c e ) i s in s t a n t ia t e d in th e M a in c la s s .
F id u L is t M a n a g e r
< < fin a l> > t r a c k e rR e p o s i t o ry : H a s h m a p = n u l l< < fin a l> > c o n t a c t R e p o s i t o ry : H a s h m a p = n u l lt ra c k e rM a n a g e r : T ra c k e rM a n a g e r = n u l lc o n t a c t M a n a g e r : C o n t a c t M a n a g e r = n u l l
a d d F id u ( )a d d C o l le c t io n O fF id u s ( )g e t F id u s F o rT ra c k e r ( )g e t F id u s F o rC o n t a c t ( )d e le t e T ra c k e r ( )d e le t e C o n t a c t ( )g e t T ra c k e rL is t ( )g e t C o n t a c t L i s t ( )c le a n U p ( )
( f ro m l i st M a n a g e r )
Figure 7-2 Class diagram for the CORBA translation and delegation layer.
55
7.4 Fidu List Manager
Figure 7-3 shows the class diagram for the Fidu List Manager. The Fidu List Manager
consists of one fundamental interface and two classes. The ListManager interface
specifies the method signatures of all use cases. The FiduListManager is an
implementation of the ListManager interface. Node is a wrapper class that holds
Fidus. The FiduListManager stores Nodes, not Fidus. This allows the
FiduListManager to store any type of object that is wrapped in a Node, allowing
other data types to be easily stored within the FiduListManager.
ContactManager and TrackerManager are inner classes within the FiduListManager. The ContactManager aggregates a read-write lock and a contact list. There is a one-to-one relationship between ContactManagers and contact lists. Each contact list gets managed by its ContactManager. The ContactManager is responsible for protecting the contact list from simultaneous reader and writer access (as discussed in §4.3). ContactManager implements the Observer interface. This allows the ContactManager to register for notifications from the Fidus (Nodes) that are on the contact list that the ContactManager manages (as discussed in §4.2). The TrackerManager aggregates a read-write lock and a tracker list. There is a one-to-one relationship between TrackerManagers and tracker lists. Each tracker list gets managed by its TrackerManager. The TrackerManager is responsible for protecting the tracker list from simultaneous reader and writer access (as discussed in §4.3). TrackerManager implements the Observer interface. This allows the TrackerManager to register for notifications from the Fidus (Nodes) that are on the tracker list that the TrackerManager manages (as discussed in §4.2). Class Node wraps a Fidu by storing the Fidu in its fidu property. Node extends the Observable class, allowing it transmit state changes to the ContactManager and TrackerManager that is observing it. Class ContactRepository is a Hashmap that stores ContactManagers. Class TrackerRepository is a Hashmap that stores TrackerManagers.
56
ListManager
addFidu()addCollec tionOfFidus()getFidusForTracker()getFidusForContact()deleteTracker()deleteContact()getTrackerList()getContactLis t()cleanUp()
<<Interface>>
FiduListManager<<final>> trac kerRepository : Hashmap = null<<final>> contactRepository : Hashmap = nul ltrackerManager : TrackerManager = nullcontactManager : ContactManager = null
addFidu()addCollectionOfFidus()getFidusForTracker()getFidusForContact()deleteTracker()deleteContact()getTrackerList()getContactList()cleanUp()
Implements Observer
Im plements Observer
Extends Observable
ContactRepository
11
TrackerRepository
11
ContactManagercontact : java.util.ArrayListcontactLock : ReentrantWriterPreferenceReadWriteLockwriterCount : int = 0
getWriterCount()incrementWriterCount()decrementWriterCount()
0..*0..*
Contact
add(index : Integer, element : Object)add(element : Object)remove(element : Object)
11
TrackerManagert racker : java.util.ArrayListt rackerLock : Reent rantWrit erPreferenceReadWriteLockwriterCount : int = 0
getWriterCount()incrementWriterCount()decrem entWriterCount()
0..*0..*
Tracker
add(index : Integer, element : Object)add(element : Object)remove(element : Object)
11
Nodefidu : ObjectcontactNumber : shorttrackerDecimalCode : short
Node()delete()
1.. *1.. *1..*1..*
Figure 7-3 Class diagram for the Fidu List Manager.
57
7.5 System Configuration
System limits are set via a configuration file. The server reads this file at initialization
time. This allows the number of contacts, the number of trackers, and the number of
Fidus per tracker to be easily configured. These values are stored internally as integers,
thus can be as great as 231 – 1, or over 2 billion.
<fiduServer>
<maxNumberOfContacts>120</maxNumberOfContacts>
<maxNumberOfTrackers>120</maxNumberOfTrackers>
<maxNumberOfFidusPerTracker>340</maxNumberOfFidusPerTracker>
.
.
.
</fiduServer>
58
8 Interaction Diagrams
8.1 Introduction
This Chapter presents the interaction diagrams of the server. An interaction diagram
illustrates the message interactions between instances (and classes) in the class model
[Lar98]. A sequence diagram is one type of interaction diagram. A sequence diagram
displays object interactions arranged in a time sequence, proceeding from the top to the
bottom of the page (or pages).
8.2 Add Fidu
i. Action – Add a Fidu to the Sensor History Server. The producer initiates this action.
This is described by the following operations:
• Create the Fidu.
• Add the Fidu to the tracker list that is identified by the Tracker Designator.
• Add the Fidu to the contact list that is identified by the Contact Designator.
ii. Precondition – Each Fidu has two designators: 1) a Tracker Designator and 2) a
Contact Designator. The Tracker Designator designates the tracker list. The Contact
Designator designates the contact list. The Tracker Designator must be > 0. The
Contact Designator must be > 0.
The server has a tracker list capacity that is determined at startup time by reading a
configuration file. This tracker list capacity is the number of trackers that the server
can hold.
59
The server has a contact list capacity that is determined at startup time by reading a
configuration file. This contact list capacity is the number of contacts that the server
can hold.
The tracker list has a capacity that is determined at startup time by reading a
configuration file. This capacity is the number of Fidus that the tracker can hold.
iii. Operations
a. Get tracker list reference from the tracker list repository
• Lock the tracker list repository
• Get the designated tracker list reference from the tracker list repository.
• Unlock the tracker list repository.
b. Get contact list reference from the contact list repository
• Lock the contact list repository
• Get the designated contact list reference from the contact list repository.
• Unlock the contact list repository.
c. Lock the tracker list.
d. Waterfall the oldest Fidu on the tracker list.
Check to see if the tracker list has reached its capacity. If so, remove the Fidu from
the tracker list and the associated contact list.
e. Lock the contact list.
f. Add the Fidu to tracker list.
g. Add the Fidu to contact list.
h. Unlock the contact list.
i. Unlock the tracker list.
iv. Alternatives
• At step ii: The pre-condition is not met, the Tracker Designator is not > 0.
Action: Abort operation. Throw exception.
• At step ii: The pre-condition is not met, the Contact Designator is not > 0.
Action: Abort operation. Throw exception.
60
• At step a: The tracker list identified by the given Tracker Designator does not exist in
the tracker list repository.
Action: Create one. Add the tracker list reference to the tracker list repository.
Continue with step a.
• At step a: The tracker list repository has reached the user defined capacity.
Action: Abort operation. Throw exception.
• At step b: The contact list identified by the given Contact Designator does not exist in
the contact list repository.
Action: Create one. Add the contact list reference to the contact list repository.
Continue with step b.
• At step b: The contact list repository has reached the user defined capacity.
Action: Abort operation. Throw exception.
• At step c: Unable to lock the tracker list due to an InterruptedException.
Action: Abort operation.
• At step d: Unable to lock the contact list due to an InterruptedException.
Action: Print a log statement. If this ever occurs, investigate in more detail.
• At step e: Unable to lock the contact list due to an InterruptedException.
Action: Unlock the tracker list. Then abort operation.
61
listManager : FiduListManager
: TrackerManager
: ContactManager
: TrackerRepository
: ContactRepository
: Node : Node c ontac tDeletionQueue : (Queue)
: ContactManager
Node being deleted.
Node being added. This is passed in to the listManager.addFidu() method.
ContactManager being added to.
Contac tManager being de leted from.
The ContactManager being deleted from may be the same ContactManager being added to.
IWC happens while thelistManager has the Monitorfor the TrackerRepository
IWC happens while thelistManager has the Monitorfor the ContactRepository
writeLock.acquire()
[wraparound] deletedNode = t rac ker. remove()
incrementWriterCount( )
incrementW riterCount( )
t rackerManager = get (Object )
contactManager = get(Object)
Continued on next page...
Figure 8-1 Sequence diagram for the add Fidu use case.
62
listManager : FiduListManager
: TrackerManager
: ContactManager
: TrackerRepository
: ContactRepository
: Node : Node contactDeletionQueue : (Queue)
: Cont actManager
If wrapping around, remove the oldest Fidu from the tracker list. Tell the oldest Fidu to delete itself.
Node being deleted.
Node being added.
ContactManager being added to.
ContactManager being deleted from.
[wraparound] delete( )
[wraparound] deleteObserver (trackerManager)
update (node)
writeLock.acquire ()
remove (node)
writeLock.release ()
[contact.size() == 0] put(Object)
Continued on next page...
Figure 8-1a Sequence diagram for the add Fidu use case (page 2 of 4).
63
listManager : FiduListManager
: TrackerManager
: ContactManager
: TrackerRepository
: ContactRepository
: Node : Node contactDeletionQueue : (Queue)
: Cont actManager
Node being deleted.
Node being added.
ContactManager being added to.
ContactManager being deleted from.
add (Node)
add (Node)
writ eLock.acquire ()
decrementWriterCount()
addObserver (contactManager)
addObserver (trackerManager)
Continued on next page...
Figure 8-1b Sequence diagram for the add Fidu use case (page 3 of 4).
64
listManager : FiduListManager
: TrackerManager
: ContactManager
: TrackerRepository
: ContactRepository
: Node : Node contactDeletionQueue : (Queue)
: Cont actManager
Node being deleted.
Node being added.
ContactManager being added to.
ContactManager being deleted from.
writeLock.release()
writeLock.release()
Figure 8-1c Sequence diagram for the add Fidu use case (page 4 of 4).
65
8.3 Add Collection of Fidus
i. Action – Add a collection of Fidus to the Sensor History Server. The producer
initiates this action. This is described by the following operations.
• Create the collection of Fidus.
• Add the Fidu(s) to the tracker list(s) that are identified by the individual Tracker
Designators(s).
• Add the Fidu(s) to the contact list(s) that are identified by the individual Contact
Designator(s).
ii. Precondition – Each Fidu has two designators: 1) a Tracker Designator and 2) a
Contact Designator. The Tracker Designator designates the tracker list. The Contact
Designator designates the contact list. The Tracker Designator must be > 0. The
Contact Designator must be > 0.
The server has a tracker list capacity that is determined at startup time by reading a
configuration file. This tracker list capacity is the number of trackers that the server
can hold.
The server has a contact list capacity that is determined at startup time by reading a
configuration file. This contact list capacity is the number of contacts that the server
can hold.
The tracker list has a capacity that is determined at startup time by reading a
configuration file. This capacity is the number of Fidus that the tracker can hold.
iii. Operations – Invoke the Add Fidu (8.2) operation for each Fidu in the Fidu
collection.
66
iv. Alternatives – The alternatives in 8.2 are applicable here. Preserve all exceptions, and
pass back a collection of exceptions if necessary.
: Producer : FiduListManager
addCollectionOfFidus(Object[])
addFidu(Object)
For each Fidu in Object[], call addFidu(Object)
Gather any exceptions from addFidu(), wrap them in a ListManagerException, and throw it to the Producer
Figure 8-2 Sequence diagram for the add collection of Fidus use case.
67
8.4 Get Fidus For Tracker
i. Action – Stream a tracker list to the client. The client initiates this action.
ii. Precondition – A Tracker Designator identifies the tracker list. The Tracker
Designator must be > 0.
iii. Operations
a. Get the tracker list reference from the tracker list repository
• Lock the tracker list repository
• Get the designated tracker list reference from the tracker list repository
• Unlock the tracker list repository
b. Lock the tracker list
c. Clone the tracker list.
d. Unlock the tracker list
e. Stream the Fidus to the client
iv. Alternatives
• At step ii: The pre-condition is not met, the Tracker Designator is not > 0.
Action: Abort operation. Throw exception.
• At step a: The tracker list reference is not in the tracker list repository.
Action: Abort operation. Throw exception. An alternative would be to check that the
tracker list is in the tracker list repository before the tracker list repository is locked.
Note that the existence of the tracker list would have to be checked again once the
repository is locked.
• At step b: Unable to lock the tracker list due to an InterruptedException.
Action: Print a log statement. If this ever occurs, investigate in more detail.
• At step e: An IOException occurs while streaming the tracker list to the client.
Action: Abort streaming operation.
68
: Cons umer listManager : FiduListManager
: TrackerRepository
: TrackerManager
getFidusForTracker(short)
trackerManager = get(Object)
readLock.acquire()
trackerClone = tracker.toArray()
readLock.release()
trackerClone is a copy of the tracker.
return trackerClone to the Consumer
Figure 8-3 Sequence diagram for the get Fidus for tracker use case.
69
8.5 Get Fidus For Contact
i. Action – Stream a contact list to the client. The client initiates this action.
ii. Precondition – A Contact Designator designates the contact list. The Contact
Designator must be > 0.
iii. Operations
a. Get a contact list reference from the contact list repository
• Lock the contact list repository
• Get the designated contact list reference from the contact list repository
• Unlock the contact list repository
b. Lock the contact list
c. Clone the contact list.
d. Unlock the contact list
e. Stream the Fidus to the client
iv. Alternatives
• At step ii: The pre-condition is not met, the Contact Designator is not > 0.
Action: Abort operation. Throw exception.
• At step a: The contact list reference is not in the contact list repository.
Action: Abort operation. Throw exception. An alternative would be to check that the
contact list is in the contact list repository before the contact list repository is locked.
Note that the existence of the contact list would have to be checked again once the
repository is locked.
• At step b: Unable to lock the contact list due to an InterruptedException.
Action: Print a log statement. If this ever occurs, investigate in more detail.
• At step e: An IOException occurs while streaming the contact list to the client.
Action: Abort streaming operation.
70
: Consumer listManager : FiduListManager
: ContactManager
: Contac tRepository
getFidusForContact(short)
contactM anager = get (Object)
readLock.acquire()
contactClone = contact.toArray()
readLock.release()
contactClone is a copy of the contact.
return contactClone to the Consumer
Figure 8-4 Sequence diagram for the get Fidus for contact use case.
71
8.6 Delete Tracker
i. Action – Delete a tracker list from the Sensor History Server. The client initiates this
action. This implies that all Fidus on the tracker list are removed from their
corresponding contact lists.
ii. Precondition – A Tracker Designator identifies the tracker list. The Tracker
Designator must be > 0.
iii. Operations
a. Get the tracker list reference from the tracker list repository
• Lock the tracker list repository
• Get the designated tracker list reference from the tracker list repository.
• Unlock the tracker list repository.
b. Lock the tracker list.
c. Process the tracker list.
For each Fidu on the tracker list:
• Remove the Fidu from the tracker list.
• Remove the tracker list from the Fidus observer list.
• Call Fidu.delete(). This removes the Fidu from its contact list.
d. Send a request to delete the tracker list from the tracker repository.
Check the writer count for the tracker list. If it is zero, send a delete request to the
tracker deletion helper
e. Unlock the tracker list.
iv. Alternatives
• At step iii.a: The tracker list reference is not in the tracker list repository.
Action: Abort operation. An alternative would be to check that the tracker list is in
the tracker list repository before the tracker list repository is locked. Note that the
72
existence of the tracker list would have to be checked again once the repository is
locked.
• At step iii.b: Unable to lock the tracker list due to an InterruptedException.
Action: Print a log statement. If this ever occurs, investigate in more detail.
73
listManager : FiduListManager
: TrackerManager
: TrackerRepository
: Node : ContactManager
contactDeletionQueue : (Queue)
for each Fidu in the tracker list...
writeLock.acquire ()
deletedNode = t rac ker. remove ()
trackerManager = get (Object)
delete( )
deleteObserver (trackerManager)
update (node)
remove (node)
writeLock.acquire ()
Continued on next page...
Figure 8-5 Sequence diagram for the delete tracker use case.
74
listManager : FiduListManager
: TrackerManager
: TrackerRepository
: Node : ContactManager
contactDeletionQueue : (Queue)
finished looping
writeLock.release ()
writeLock.release ()
[contact.size() == 0] put (Object)
Figure 8-5a Sequence diagram for the delete tracker use case (page 2 of 2).
75
8.7 Delete Contact
i. Action – Delete a contact list from the Sensor History Server. The client initiates this
action. This implies that all Fidus on the contact list are removed from their
corresponding tracker lists.
ii. Precondition – The Contact Designator designates the contact list. The Contact
Designator must be > 0.
iii. Operations
a. Get a contact list reference from the contact list repository
• Lock the contact list repository.
• Get the designated contact list reference from the contact list repository.
• Unlock the contact list repository.
b. Lock the contact list
c. Clone the contact list
The list iteration will occur on the cloned copy. The contact list is cloned to preserve
resource ordering. It is not possible to process the contact list in a manner similar to
8.6 without risking deadlock.
This is due to the fact that each Node.delete() will lock the tracker list that manages
that particular Node. This would violate the resource ordering principle for this
server. When a thread locks multiple resources (a tracker list and a contact list) the
tracker list is always locked before the contact list. Likewise, the contact list is
always unlocked before the tracker list.
d. Unlock the contact list
e. Process the contact list
For each Fidu on the cloned contact list:
• Call Fidu.delete(). This removes the Fidu from its contact list and its tracker list.
76
iv. Alternatives
• At step iii.a: The contact list reference is not in the contact list repository.
Action: Abort operation. An alternative would be to check that the contact list is in
the contact list repository before the contact list repository is locked. Note that the
existence of the contact list would have to be checked again once the repository is
locked.
• At step iii.b: Unable to lock the contact list due to an InterruptedException.
Action: Print a log statement. If this ever occurs, investigate in more detail.
77
listManager : FiduListManager
: Contac tManager
: ContactRepository
: Node : ContactManager
contactDeletionQueue :
: TrackerManager
trackerDeletionQueue :
for each Fidu in the contact list...
readLock.acquire ()
contactClone = contact.toArray ()
readLock.release()
contactM anager = get(Object)
delete( )
update (node)
writeLock.acquire ()
remove (node) Continue on next page...
Figure 8-6 Sequence diagram for the delete contact use case.
78
listManager : FiduListManager
: ContactManager
: ContactRepository
: Node : ContactManager
contactDeletionQueue :
: TrackerManager
trackerDeletionQueue :
finished looping
writeLock.release ()
[contact.size() == 0] put(Object)
update (node)
writeLock.acquire ()
remove (node)
writeLock.release ()
[ tracker.size() == 0] put(Object)
Figure 8-6a Sequence diagram for the delete contact use case (page 2 of 2).
79
8.8 Get List of Trackers
i. Action – Get a collection of tracker property objects. Each tracker property object
describes a tracker list in the server.
ii. Precondition – None.
iii. Operations
a. Get a list of tracker list references from the tracker list repository
• Lock the tracker list repository.
• Get a collection of tracker list references from the tracker list repository.
• Unlock the tracker list repository
b. Process the list of tracker list references
For each tracker list:
• Lock the tracker list.
• Extract the most recent node from the list.
• Create a tracker properties object (describing the tracker).
• Add this tracker properties object to a collection of tracker properties objects.
• Unlock the tracker list.
c. Stream the list of tracker property objects to the client
iv. Alternatives
• At step iii.b: The size of the tracker list is zero. Since each tracker list is not locked
until after the tracker list repository is unlocked, it is possible for a delete tracker
request to occur between the unlocking of the tracker list repository and the locking
of each particular list.
Action: Skip the list.
• At step iii.b: Unable to lock the tracker list due to an InterruptedException.
Action: This will result in an abbreviated list being passed back to the client. Print a
log statement. If this ever occurs, investigate in more detail.
80
listManager : FiduListManager
: TrackerRepository
trackerManagerList : java.util .Collection
listIterator : java.util.Iterator
: TrackerProps : TrackerManager
trackerPropsList : java.ut il.ArrayList
listIterator will iterate throughall trackerManagers in thetrackerManagerList
get last node from the trac ker
iterate through t rackerM anagers
listSize is the size of the trackerM anagerList
trackerManagerList = values( )
listIterator = iterator( )
has Nex t( )
trackerManager = next( )
readLock.acquire ()
node = get ()
new (lis tSize)
Continued on next page...
Figure 8-7 Sequence diagram for the get list of trackers use case.
81
listManager : FiduListManager
: TrackerRepository
trackerManagerList : java.util .Collection
listIterator : java.util.Iterator
: TrackerProps : TrackerManager
trackerPropsList : java.ut il.ArrayList
if a delete request came in,the number of props objectsin the trackerPropsList may not be equal to listSize
end iterationthroughtrackerManagers
props = new ()
readLock.release ()
add (props)
trimToSize ()
Figure 8-7a Sequence diagram for the get list of trackers use case (page 2 of 2).
82
8.9 Get List of Contacts
i. Action – Get a collection of tracker property objects. Each tracker property object
describes a contact list in the server. The tracker property object has enough
information such that it can be used to report on contact lists.
ii. Precondition – None.
iii. Operations
a. Get a list of contact list references from the contact list repository
• Lock the contact list repository.
• Get a collection of contact list references from the contact list repository.
• Unlock the contact list repository
b. Process the list of contact list references
For each contact list:
• Lock the contact list.
• Extract the most recent node from the list.
• Create a tracker properties object (describing the contact).
• Add this tracker properties object to a collection of tracker properties objects.
• Unlock the contact list.
c. Stream the list of tracker property objects to the client
iv. Alternatives
• At step iii.b: The size of the contact list is zero. Since each contact list is not locked
until after the contact list repository is unlocked, it is possible for a delete contact
request to occur between the unlocking of the contact list repository and the locking
of each particular list.
Action: Skip the list.
• At step iii.b: Unable to lock the tracker list due to an InterruptedException.
83
Action: This will result in an abbreviated list being passed back to the client. Print a
log statement. If this ever occurs, investigate in more detail.
84
listManager : FiduListManager
: ContactReposit ory
contac tManagerList : java.util .Collec tion
lis tIterator : java.util.Iterator
: TrackerProps : ContactManager
contactPropsList : java.util.ArrayList
lis tIterator will iterate throughall contactManagers in thecontactManagerList
ge t last node from t he contac t
iterate through contactManagers
li stSize is the s ize o f the contactManagerList
contactManagerList = values( )
listIterator = iterator( )
has Next( )
contactManager = next( )
props = new ()
readLock.acquire ()
node = get ()
new (li stSize)
Contin ued on nex t page ...
Figure 8-8 Sequence diagram for the get list of contacts use case.
85
listManager : FiduListManager
: ContactRepository
contac tManagerList : java.util .Collec tion
listIterator : java.util.Iterator
: TrackerProps : ContactManager
contactPropsList : java.util.ArrayList
if a delete request came in,the number of props objectsin the contactPropsList may not be equal to listSize
end iterationthroughcontactManagers
readLock.release ()
add (props)
trimToSize ()
Figure 8-8a Sequence diagram for the get list of contacts use case (page 2 of 2).
86
9 Results
9.1 Introduction
This Chapter provides detailed performance metrics for the following use cases:
• Get Fidus for Tracker
• Add Collection of Fidus
Each use case is measured from the perspective of the queuing time in the server.
The notion of queuing time is explained below. The primary objective of these tests is to
measure how the server scales under increasing client load.
9.2 Background
A queuing notation is adopted to qualify and quantify server-side request processing.
Each of the above use cases is described as a queuing model.
Figure 9-1 shows a simple queuing model. Requests arrive at the server for processing.
If the server is not busy, the request will be processed immediately; otherwise the request
will join a queue and wait for processing. Each request always moves through the queue,
but as server utilization increases, some requests may be delayed.
87
ServerArrivals
Waiting Line(Queue)
Ts = Service Time
Tq = Queuing Time
Tw = waiting time
Departures
Figure 9-1 A simple queuing model.
In Figure 9-1, the queue is really the software constructs that enforce mutual exclusion,
that is, the software mechanisms that protect critical sections of code. For example, a
read-write lock on a tracker list acts as a queue. As long as there are no writers in the list,
a reader may immediately read the list. But if there is a writer, the reader will block on
the lock (be delayed in the queue) until the writer leaves the critical section of code.
Table 9-1 shows a subset of the items that are generally of interest in a queuing model
[Sta98]:
Table 9-1 General Queuing Parameters
Parameter Meaning Tw Mean time a request spends waiting for service Ts Mean service time for each request Tq Mean time a request spends in the system (queuing time)
All server measurements are taken either at the interface between the Fidu List Manager
and the Application Service Infrastructure (Figure 9-2) or within the list manager itself.
The queuing time Tq is measured at the boundary between the list manager and the
service infrastructure. The wait time Tw and service time Ts are measured within the list
manager. Although the Fidu List Manager is designed to plug into any service
infrastructure, CORBA is used here. It is important to realize that server measurement
times are not measured at the socket level, that is, at the lowest levels of the Server ORB
88
Core. Rather, they are measured at the interface between the list manager and the
CORBA Object Adapter layer. This is the point that the list manager “plugs into” the
Application Service Infrastructure.
Network
ORBInterface
TqClient Application
Client ORB Core
DIIStaticStub
ORBInterface
Fidu List Manager
Server ORB Core
Skeleton DSIObject
Adapter
Figure 9-2 Fidu List Manager and application service infrastructure boundary.
9.3 Lab Setup
Figure 9-3 shows the hardware suite for performance benchmarking. The server runs on
a Dell Precision 620 workstation with dual 1 GHz processors and 768 Mbytes of RAM.
No other user processes are running on the P620.
The producer and all clients (consumers) run on a dual 550 MHz Dell Precision 210
workstation with 512 Mbytes of RAM. No other user processes are running on the P210.
The network is 100 Mbits per second Ethernet.
89
EthernetEthernet
Precision 620 Precision 210
Router
SensorHistoryServer
Consumer
FiduProducer
Figure 9-3 Hardware suite for performance benchmarking.
9.4 Get Fidus for Tracker
The purpose of this test is as follows:
• Measure the queuing time of the Get Fidus for Tracker use case within the server
under increasing client load.
9.4.1 Test Methodology
Producers – The Fidu producer is run on the P210 workstation. Each second, the
producer creates and transmits 120 Fidus to the server. This is considered a high
producer load and will facilitate benchmarking under typical worst-case usage scenarios.
Consumers – Each test run consists of 4 or 5 phases7. For each successive phase, an
additional consumer process is invoked on the P210 workstation. Each consumer tries to
make 40 tracker requests per second from the server. Increasing the number of consumer
processes increases the load placed on the server. Each consumer runs for 60 minutes.
When multiple consumers are run, they are run simultaneously.
7 Under Windows 2000, the P210 workstation becomes CPU bound after the 4th client. Under SuSE 7.2, it is possible to run 5 clients before the system becomes CPU bound.
90
Table 9-2 Successive Phases for One Get Fidus for Tracker Benchmark Run
Phase Number of Consumers Duration (minutes)1 1 60 2 2 60 3 3 60 4 4 60 5 5 60
The processing characteristics of Windows versus Linux impacts the number of
simultaneous consumer processes that can reasonably run under each operating system.
Under Windows 2000, the system becomes CPU bound beyond the 4th consumer; the
maximum number of processes that can be reasonably run is 4. Under Linux, the system
becomes CPU bound beyond the 5th consumer; the maximum number of processes that
can be reasonably run under Linux is 5. Because of this, phase 5 is run under Linux only.
Another run time difference is seen in the number of server requests per second from
each consumer. As mentioned, each consumer tries to make 40 tracker requests per
second. As long as the computer is not CPU bound, this rate is essentially achievable
under Windows (the number turns out to be 39). Under Linux, however, the consumer
actually makes 23 tracker requests per second. As will be seen, two consumers will
generate 79 requests per second under Windows. Under Linux, two consumers will
generate 46 requests per second. No attempt was made to investigate this or tweak the
consumers such that the number of requests per second would be in lock step as
consumer load is increased across operating systems.
Figure 9-4 shows this use case from the perspective of a queuing model. The first queue
is the TrackerRepository that holds the target TrackerManager. The second
queue is the read-write lock of the target TrackerManager.
91
Server 1
Server 2
Server N
Arrivals
Q1(TrackerRepository)
Q2(TrackerManager 1)
Ts = Service Time
Tq = Queuing Time
Q2(TrackerManager N)
Tw = Wait Time Q1 + Q2
Departures
Departures
Departures
Figure 9-4 Queuing model view of the get Fidus for tracker use case.
The wait time (Tw) is the time it takes the request to get the TrackerManager from
the TrackerRepository and then get the read lock from the TrackerManager.
The service time (Ts) is the time it takes to copy the Fidus on the tracker list and prepare
the list for output. The queuing time (Tq) is the sum of Tw and Ts.
Section 9.4.2 presents the queuing time. This is the most important metric from the
server perspective. Section 9.4.3 and 9.4.4 present the wait time and service time,
respectively.
9.4.2 Queuing Time
This Section presents results for the queuing time for the Get Fidus For Tracker use case.
This will be followed by an analysis that shows the speed differential on a percentage
basis over the range of measured client load.
Figure 9-5 shows the queuing time for Windows 2000 versus SuSE 7.2 GNU/Linux.
Tq - Get Fidus for Tracker (Win2k Pro vs. SuSE 7.2)
y = 0.9084x + 169.34y = 1.3686x + 193.59
0.0
50.0
100.0
150.0
200.0
250.0
300.0
350.0
400.0
0 20 40 60 80 100 120 140 160
Requests / Second
Tq (m
icro
Seco
nds)
Linux:Windows:
Figure 9-5 Queuing time for the get Fidus for tracker use case.
93
Table 9-3 Queuing Time for the Get Fidus For Tracker Use Case for Win2k
Requests/Sec Tq (microseconds) Mean High Low
39 208.4 212.7 203.879 231.9 234.5 229.5114 281.1 292.7 276.3135 289.4 293.3 283.6
Table 9-4 Queuing Time for the Get Fidus For Tracker Use Case for SuSE 7.2
Requests/Sec Tq (microseconds) Mean High Low
23 228.8 231.3 225.946 253.5 258.6 248.769 276.7 277.5 275.490 334 350.5 328.5109 336.3 341.3 330.4
The overlap of measured client load falls between 39 requests per second (the low end of
Windows measurements) and 109 requests per second (the high end of Linux
measurements). No attempt at computing percentage difference in speed is made outside
of this interval since there is no data to back it.
At 39 requests per second, the corresponding queuing time for Linux can be computed as:
Tq Mean = 1.3686 * 39 + 193.59 = 247 microseconds.
The difference in speed of Windows Vs. Linux is 247 – 208.4 = 38.6 microseconds; 38.6
is 15.6 percent of 247.
• The speed differential at the low end of measurement overlap is 15.6 percent.
At 109 requests per second, the corresponding queuing time for Windows can be
computed as:
Tq Mean = 0.9084 * 109 + 169.34 = 268.4 microseconds.
The difference in speed of Windows Vs. Linux is 336.3 – 268.4 = 67.9 microseconds;
67.9 is 20.2 percent of 336.3.
• The speed differential at the high end of measurement overlap is 20.2 percent.
Windows is from 15.6 to 20.2 % faster in queuing time Tq.
Tw - Get Fidus for Tracker (Win2k Pro vs. SuSE 7.2)
y = 0.2592x + 64.836y = 0.4462x + 66.861
0.0
20.0
40.0
60.0
80.0
100.0
120.0
140.0
0 20 40 60 80 100 120 140 160
Requests / Second
Tw (m
icro
Seco
nds)
Linux:Windows:
Figure 9-6 Wait time for the get Fidus for tracker use case.
96
Table 9-5 Wait Time for the Get Fidus For Tracker Use Case for Win2k
Requests/Sec Tw (microseconds) Mean High Low
39 76.5 78.5 71.7 79 81.0 83.3 78.6 114 98.7 101.3 95.7 135 98.3 106.6 93.7
Table 9-6 Wait Time for the Get Fidus For Tracker Use Case for SuSE 7.2
Requests/Sec Tw (microseconds) Mean High Low
23 78.2 80.2 77.3 46 84.9 88.2 83.0 69 95.8 97.8 93.7 90 114.2 124.4 109.3109 111.6 115.7 108.8
At 39 requests per second, the corresponding wait time for Linux can be computed as:
Tw Mean = 0.4462 * 39 + 66.861 = 84.3 microseconds.
The difference in speed of Windows Vs. Linux is 84.3 – 76.5 = 7.8 microseconds; 7.8 is
9.3 percent of 84.3.
• The speed differential at the low end of measurement overlap is 9.3 percent.
At 109 requests per second, the corresponding wait time for Windows can be computed
as:
Tw Mean = 0.2592 * 109 + 64.836 = 93.1 microseconds.
The difference in speed of Windows Vs. Linux is 111.6 – 93.1 = 18.5 microseconds; 18.5
is 16.6 percent of 111.6.
• The speed differential at the high end of measurement overlap is 16.6 percent.
9.4.4 Service Time
Figure 9-7 shows the service time for Windows 2000 versus SuSE 7.2 GNU/Linux.
Windows is from 9.3 to 16.6 % faster in wait time Tw.
Ts - Get Fidus for Tracker (Win2k Pro vs. SuSE 7.2)
y = 0.6488x + 104.55y = 0.9229x + 126.69
0.0
50.0
100.0
150.0
200.0
250.0
0 20 40 60 80 100 120 140 160
Requests / Second
Ts (m
icro
Seco
nds)
Linux:Windows:
Figure 9-7 Service time for the get Fidus for tracker use case.
98
Table 9-7 Service Time for the Get Fidus for Tracker Use Case for Win2k
Requests/Sec Ts (microseconds) Mean High Low
39 131.9 134.3 128.379 150.9 153.4 146.9114 182.4 197.1 176.7135 191.1 196.4 183.8
Table 9-8 Service Time for the Get Fidus for Tracker Use Case for SuSE 7.2
Requests/Sec Ts (microseconds) Mean High Low
23 150.6 152.5 147.946 168.5 175.1 160.469 180.9 181.7 179.790 219.9 226.2 215.4109 224.7 229.5 220.4
At 39 requests per second, the corresponding service time for Linux can be computed as:
Ts Mean = 0.9229 * 39 + 126.69 = 162.7 microseconds.
The difference in speed of Windows Vs. Linux is 162.7 – 131.9 = 30.8 microseconds;
30.8 is 18.9 percent of 162.7.
• The speed differential at the low end of measurement overlap is 18.9 percent.
At 109 requests per second, the corresponding service time for Windows can be
computed as:
Ts Mean = 0.6488 * 109 + 104.55 = 175.3 microseconds.
The difference in speed of Windows Vs. Linux is 224.7 – 175.3 = 49.4 microseconds;
49.4 is 22.0 percent of 224.7.
• The speed differential at the high end of measurement overlap is 22.0 percent.
9.4.5 Summary
Table 9-9 summarizes the queuing time Tq, wait time Tw and service time Ts results for
Windows 2000 and SuSE 7.2 GNU/Linux.
Windows is from 18.9 to 22.0 % faster in service time Ts.
99
Table 9-9 Get Fidus For Tracker Queuing Parameter Times
Tq (µSec) Tw (µSec) Ts (µSec) Server Load (Requests/Sec) Win2k SuSE7.2 Win2k SuSE7.2 Win2k SuSE7.2
39 208.4 247 76.5 84.3 131.9 162.7 109 268.4 336.3 93.1 111.6 175.3 224.7
On a percentage basis, the queuing time is 15.6 to 20.2 % faster on Windows.
All server measurements were taken either at the interface between the Fidu List
Manager and the Application Service Infrastructure or within the list manager itself.
Most of the difference in Tq is due to the relatively higher values for Ts. This is
indicative of the fundamental fact that memory allocation is faster under Windows 2000
than SuSE 7.2. See Chapter 10 for further details.
9.5 Add Collection of Fidus
The purpose of this test is as follows:
• Measure the queuing time of the Add Collection of Fidus use case within the server
under increasing client load.
9.5.1 Test Methodology
Producer – The Fidu producer is run on the P210 workstation. Each second, the
producer creates and transmits 120 Fidus to the server. Again, this is considered a high
producer load and will facilitate benchmarking under typical worst-case usage scenarios.
Consumer – The methodology of the consumer is the same as §9.4.1, thus will not be
repeated. Of the queuing parameters listed in Table 9-1, only the queuing time (Tq) is
measured. This is due to the internal construction of the Fidu List Manager.
100
9.5.2 Queuing Time
Figure 9-8 shows the queuing time for Windows 2000 versus SuSE 7.2 GNU/Linux.
Tq - Add Collection of Fidus (Win2k Pro vs. SuSE 7.2)
y = 0.0345x + 3.3557y = 0.0389x + 3.0967
0
1
2
3
4
5
6
7
8
9
0 20 40 60 80 100 120 140 160
Requests / Second
Tq (m
illiS
econ
ds)
Linux:Windows:
Figure 9-8 Queuing time for the add collection of Fidus use case.
102
Table 9-10 Queuing Time for the Add Collection of Fidus Use Case for Win2k
Requests/Sec Ts (microseconds) Mean High Low
39 4.45 4.60 4.40 79 6.53 6.70 6.30 114 7.28 7.40 7.10 135 7.85 8.10 7.60
Table 9-11 Queuing Time for the Add Collection of Fidus Use Case for SuSE 7.2
Requests/Sec Ts (microseconds) Mean High Low
23 3.87 4.00 3.80 46 4.63 4.90 4.40 69 6.30 6.40 6.10 90 6.93 7.10 6.80 109 6.87 7.00 6.70
There is little overall difference in behavior for this use case between Widows and Linux.
9.6 Chapter Summary
Queuing time, wait time and service time are standard parameters that qualify and
quantify the manner in which a server processes client requests. Knowledge of these
parameters allows system architects to understand how a server scales under increasing
client load, and to determine if a given server architecture can meet the demands of its
clients.
Sensor History Server clients are categorized as producers and/or consumers. Producers
instantiate Fidus and feed them to the server. Consumers request lists of Fidus for
various data processing activities.
These parameters were measured and compared under the Windows 2000 Professional
and SuSE 7.2 GNU/Linux Professional operating systems.
The queuing time, wait time and service time for consumer service requests was
measured under increasing consumer load. The queuing time for producer service
requests was measured under increasing consumer load.
103
The most important parameter for understanding server behavior is the queuing time.
This is the time it takes a request to move through various queues within the server and
then receive service. The queuing time is the sum of the wait time and the service time.
The queuing time for consumer service requests is from 15.6 to 20.2 % faster under
Windows 2000 than SuSE 7.2 GNU/Linux, depending on consumer load.
The queuing time for producer service requests is essentially identical for both operating
systems.
104
10 Discussion
10.1 Introduction
This Chapter presents the fundamental reason the performance of this type of Java
application is superior under Windows 2000 Professional than SuSE 7.2 GNU/Linux
Professional. It concludes with a look towards future combat system designs with an
emphasis on self contained software components.
10.2 Memory Allocation
Memory allocation under Windows 2000 is fundamentally faster than Linux. A request
for a tracker list is a memory intensive operation. The size of a typical Fidu is 576 bytes.
A request for a tracker list with a capacity of 340 Fidus results in a memory allocation of
340 * 576 = 196 Kbytes to prepare the Fidus for network transport.
Table 10-1 steps through the instantiation of various sized blocks of Fidus. It starts with
the allocation of 340 Fidus, the historical size of a typical tracker list. It steps up and
ends with the allocation of 34000 Fidus. Win2k Advantage is the relative speed
advantage of Windows 2000. All times are in milliseconds.
These numbers are representative of the speed advantage Windows holds in the service
time analysis of §9.4.4. The steady decline in the Windows advantage as the number of
Fidus increase is left as an item of further research.
Table 10-1 Fidu Instantiation Times for Win2k vs. Linux
Number of Fidus Time (mS) Win2k Advantage (%) Win2k SuSE7.2
340 6.7 9 25.6 3400 126.8 162.1 21.8 8500 321.1 394.2 18.5
105
17000 857.9 1037.9 17.3 34000 1675 1983.4 15.5
Note the instantiation times are an order of magnitude greater than the typical service
time for processing a tracker list request. That is, Table 10-1 shows it takes either 6.7 or
9 milliseconds to instantiate 340 Fidus, depending on operating system. Table 9-7 and
Table 9-8 show service times on the order of 150 to 200 microseconds for Windows and
SuSE respectively. In both cases, memory for 340 Fidus is being allocated.
The difference is the allocation mechanism. For the example above, a test program
looped and called new Fidu() 340 times. When the server prepares a tracker list for
network transport, java.util.ArrayList.toArray() is called to duplicate the
tracker list.
The fundamental point however, is still valid. For the amounts of memory being
allocated, allocation is faster under Windows 2000 than under SuSE GNU/Linux. This is
true regardless of the allocation mechanism.
Fidu Instantiation (Win2k Pro vs SuSE 7.2)
y = 0.0489xy = 0.0582x
0
500
1000
1500
2000
2500
0 5000 10000 15000 20000 25000 30000 35000 40000
Number of Fidus
Tim
e (m
illiS
econ
ds)
Linux:Windows:
Figure 10-1 Fidu instantiation time for Win2k vs. SuSE 7.2.
107
10.3 Towards a Component Based Submarine Combat System
Software that is designed for submarine combat control systems should be adaptable in
order to remain useful during the long lifecycle typical of military systems. In particular,
adaptability is needed to facilitate the (re)configuration of combat systems dynamically to
support varying workloads or missions [SSM+01].
The Sensor History Server is designed with this adaptability in mind, as evidenced by the
following:
• The objective of this thesis, to design an architecture that places no limits on the
number of contacts or the number of trackers that are stored in the server, as well as
no limits on the number of Fidus that are stored per tracker.
This architecture enables the server to dynamically adapt to varying workloads.
System limits (numbers of contact, trackers, Fidus per tracker) are easily adjusted via
modifications to a simple configuration file. The server reads this file upon
initialization and sets its capacity accordingly. It is also possible to run the server
without any system configured (contact, tracker, Fidu) limits. In this case, it is the
amount of RAM configured for the JVM that ultimately determines the capacity of
the server.
• The physical design of the software, which separates application business logic from
the software components that enable network communication. The application
business logic is self-contained in the Fidu List manager. CORBA is the software
component that enables network communication. A Translation and Delegation
Layer decouples the Fidu List Manager from the CORBA communication
infrastructure. As discussed in Chapter 7, this separation of concerns allows the Fidu
List Manager to be unplugged from the CORBA communication infrastructure and
plugged into another distributed object model. Such a decision might be made during
a technology refresh of the combat system.
108
The functionality provided by this server is a fundamental component of every submarine
combat control system. The placement of all business logic in the Fidu List Manager
moves towards COTS based software components that can be pulled “off the shelf” and
plugged into adaptable combat system designs of the future.
109
11 Conclusions and Recommendations for Future Work
This thesis demonstrates the software architecture of a Sensor History Server that is free
of the constraints of legacy combat system implementations. This architecture allows the
server to adapt to the changing workload requirements likely during the long lifecycle
typical of military systems.
11.1 Viability of Java in a Submarine Combat System
The Java Virtual Machine is an example of Host Infrastructure Middleware that
encapsulates and enhances native operating system communication and concurrency
mechanisms to create portable and reusable network programming components
[SSR+00]. The use of a Java Virtual Machine abstracts away accidental incompatibilities
of individual operating systems, and helps eliminate many tedious, error prone, and non-
portable aspects of developing and maintaining networked applications via low level
operating system application programming interfaces, such as Sockets or Posix Threads.
This has the potential of reducing software development and evolution costs significantly
[SSM+01]. In particular, there is reasonable assurance that software developed under one
operating system will exhibit the same run-time characteristics under a different
operating system8.
Server benchmarking demonstrates tracker request processing times from 132 to 175
microseconds under Windows 2000 Professional, depending on system load. Tracker
request processing times vary from 151 to 225 microseconds under SuSE 7.2
GNU/Linux. In either case, these queuing times are acceptable for submarine combat
control Target Motion Analysis and geographic plotting applications. This demonstrates
the viability of the use of Java within the context of a submarine combat control system.
8 However, the world is not perfect. Appendix B: Uniformity of Time Step, details diverging behavior of the System.currentTimeMillis() call under Windows 2000 and SuSE GNU/Linux.
110
11.2 Generalizing Measurement Types
The data management architecture described herein has been applied to measurements
(Fidus) generated from passive sonar sensors only. However, the architecture of the
server is type neutral. More to the point, the architecture of the Fidu List Manager is type
neutral; the Fidu List Manager can serve any type of object, as discussed in Chapter 7.
This is accomplished by wrapping incoming objects in a Node. It is the Node that is
added to and requested from the Fidu List Manager.
Measurements from different types of sensors are collected and analyzed in a submarine
combat system, for example Sonar, Radar and Periscope. Constructing appropriate
interfaces to handle these measurement types will enable the server to serve these
measurements.
Figure 7-1 is repeated below to facilitate subsequent discussion.
CORBAIDL
Interfaces
Sensor History Server
Fidu List Manager
JavaInterfaces
JavaDelegationUsing JavaData Types
CORBATranslation and
Delegation Layer
HistoryProducerServant
HistoryConsumerServant
As discussed in §7.3, the CORBA Translation and Delegation layer is responsible for the
following:
111
• Translate incoming service requests from a CORBA IDL data type to a neutral data
type understood by the Fidu List Manager. Use of a neutral data type within the FLM
allows the FLM to plug into any Application Service Infrastructure and serve lists of
objects over that particular protocol.
• Delegate the service request to the Fidu List Manager.
• Process any data returned from the FLM, translating necessary objects from the
neutral data type to the applicable CORBA IDL data type, followed by transmission
back to the client.
This translation, or wrapping objects in a Node, occurs in the
HistoryProducerServant (for producers) or the HistoryConsumerServant
(for consumers). The following code snippet from the HistoryProducerServant
illustrates this:
/** * A CORBA Servant, implements the producer side interfaces as specified in * SensorHistoryProducer.idl. This class acts as an <i>Object Adapter</i> in * that the methods of this class merely pass incoming requests on to the * <code>ListManager</code>. * @version 1.17 * @author Frederick G. Burkley * @see fiduServer.listManager.ListManager */ public class HistoryProducerServant extends HistoryProducerPOA { /** * The <code>ListManager</code>. The recipient of incoming Filtered Input * Data Units (FIDUs). */ private ListManager listManager = null; // Additional variables and constructor omitted for brevity /** * Create a Filtered Input Data Unit (FIDU) in the <code>ListManager</code>. * This method forwards the FIDU to the <code>ListManager</code>. * @param fiduType The FIDU. * @throws // exceptions omitted for brevity */ public void addFidu (FiduType fiduType) throws // exceptions omitted for brevity { // need to wrap fidu so it can be treated generically by the list services Node node = new Node (fiduType, fiduType.baseFidu.contactNumber, fiduType.baseFidu.trackerDecimalCode);
112
try { listManager.addFidu (node); } catch // exceptions omitted for brevity { } } // Additional methods omitted for brevity }
The parameter to the addFidu() method of the HistoryProducerServant is of
type FiduType. This object type is defined in the CORBA IDL interface definition.
The FiduType object represents a measurement that is generated from a passive sonar
sensor. This object is wrapped in an object of type Node, then passed to the
addFidu() method of the listManager. This is where the Translation and
Delegation occurs. The incoming object of type FiduType is translated to an object of
type Node. The addFidu() method request of the HistoryProducerServant is
then delegated to the addFidu() method of the listManager. The listManager
is an instance of a FiduListManager.
Since it is a Node that is added to the listManager, the Node could wrap any type of
object. This design feature is what makes the server extensible. Adding additional
CORBA IDL interface definitions and relevant servants in the CORBA Translation and
Delegation layer will extend the server to process additional types of objects. Of
particular interest are measurements from Radar, Periscope and ESM sensors.
The following Section presents an architectural extension that allows the server to serve
objects from different types of sensors.
11.3 Extension Via Type Specific Producer and Consumer Servants
As discussed in §7.3, the HistoryProducerServant is a CORBA Object Adapter
responsible for the producer side use cases:
• Add Fidu
113
• Add Collection of Fidus
This is accomplished by implementing an interface as defined by the following CORBA
IDL snippet:
// Sensor History Producer module SHP { interface HistoryProducer { // // The History Server shall provide a CORBA interface that accepts a // collection of Fidus. // void addCollectionOfFidus (in SH::FiduSeq fidus) raises (LMT::ListManagerException) ; // // The History Server shall provide a CORBA interface that accepts a Fidu. // void addFidu (in SH::FiduType fidu) raises (BT::IllegalArgumentException, TrackerCapacityException, ContactCapacityException) ; }; };
Just as the SHP module defines a HistoryProducer interface whose purpose is to
facilitate transmission of objects of type FiduType between a Fidu producer and the
server, additional CORBA IDL modules could be defined whose purpose is to facilitate
transmission of additional object types from other producers.
For example, a CORBA IDL module named RHP (Radar History Producer) might be
defined as follows:
// Radar History Producer module RHP { interface RadarProducer { // // The History Server shall provide a CORBA interface that accepts a // collection of Radar measurements. // void addCollectionOfRadarMeasurements (in RH::RadarSeq radarMeasurements) raises () ; // exceptions omitted for brevity //
114
// The History Server shall provide a CORBA interface that accepts a Radar // measurement. // void addRadarMeasurement (in RH::RadarType radarMeasurement) raises () ; // exceptions omitted for brevity }; };
Given this IDL interface definition, a RadarProducerServant could be written that
performs a Translation and Delegation function for objects of type RadarType in the
same fashion that the HistoryProducerServant performs a Translation and
Delegation function for objects of type FiduType.
CORBAIDL
Interfaces
Sensor History Server
Fidu List Manager
JavaInterfaces
JavaDelegationUsing JavaData Types
CORBATranslation and
Delegation Layer
FiduProducerServant
FiduConsumerServantRadar
ProducerServantRadar
ConsumerServant
Figure 11-1 Block structure of a Sensor History Server with type specific servants.
A block structure of this architecture is presented in Figure 11-1. The corresponding
class diagram appears in Figure 11-2.
115
Processing of additional measurement types simply entails the definition of a
corresponding CORBA IDL module and implementation of a servant to handle the
translation and delegation.
Given this architectural extension, the names of the methods in the listManager
interface could be changed to reflect the general nature of the listManager. For
example, listManager.addFidu() could be changed to listManager.addReport().
The name of the implementing class could be changed from FiduListManager to
SensorListManager. This reflects the generalized nature of the “List Manager”. It
does not just manage Fidu lists, rather it manages lists of sensor reports.
T h e M a i n c l a s s b o o t s t r a p s t h e S e n s o r H i s t o r y S e r v e r .
F i d u P r o d u c e r P O A
_ t h i s ()
( f r o m F H P )
F i d u C o n s u m e r P O A
_ t h i s ()
( f r o m F H C )
T h e S e n s o r L i s t M a n a g e r( a n im p le m e n t a t i o n o f t h e L i s t M a n a g e r in t e r fa c e ) i s i n s t a n t i a t e d i n t h e M a i n c l a s s .
S e n s o r L i s t M a n a g e r
< < f i n a l > > s e n s o r R e p o s i t o r y : H a s h m a p = n u l l< < f i n a l > > c o n t a c t R e p o s i t o r y : H a s h m a p = n u l ls e n s o r M a n a g e r : S e n s o r M a n a g e r = n u l lc o n t a c t M a n a g e r : C o n t a c t M a n a g e r = n u l l
a d d R e p o r t ( )a d d C o l l e c t i o n O f R e p o r t s ( )g e t R e p o r t s F o r S e n s o r ( )g e t R e p o r t s F o r C o n t a c t ( )d e l e t e S e n s o r ( )d e l e t e C o n t a c t ( )g e t S e n s o r L i s t ( )g e t C o n t a c t L i s t ( )c l e a n U p ( )
( f r o m l i s t M a n a g e r )
R a d a r P r o d u c e r P O A
_ t h i s ( )
( f r o m R H P )
R a d a r C o n s u m e r P O A
_ t h i s ( )
( f r o m R H C )
L i s t M a n a g e r
a d d R e p o r t ( )a d d C o l l e c t i o n O f R e p o r t s ( )g e t R e p o r t s F o r S e n s o r ( )g e t R e p o r t s F o r C o n t a c t ( )d e l e t e S e n s o r ( )d e l e t e C o n t a c t ( )g e t S e n s o r L i s t ( )g e t C o n t a c t L i s t ( )c l e a n U p ( )
( f r o m l i s t M a n a g e r )
< < I n t e r f a c e > >
F i d u C o n s u m e r S e r v a n tl i s t M a n a g e r : L i s t M a n a g e r
F i d u C o n s u m e r S e r v a n t ( )g e t F i d u s F o r T r a c k e r ( )g e t F i d u s F o r C o n t a c t ( )d e l e t e T r a c k e r ( )d e l e t e C o n t a c t ( )g e t T r a c k e r L i s t ( )g e t C o n t a c t L i s t ( ) + M a n a g e L i s t s
F i d u P r o d u c e r S e r v a n tl i s t M a n a g e r : L i s t M a n a g e r
a d d C o l l e c t i o n O f F i d u s ( )F i d u P r o d u c e r S e r v a n t ( )a d d F i d u ( )
+ M a n a g e L i s t s
R a d a r P r o d u c e r S e r v a n t
a d d C o l l e c t i o n O f R a d a r R e p o r t s ( )R a d a r P r o d u c e r S e r v a n t ( )a d d R a d a r R e p o r t ( )
M a i no r b : O R Bc o r b a U t i l i t i e s : C o r b a U t i l i t i e sl i s t M a n a g e r : L i s t M a n a g e rn a m i n g C o n t e x t : N a m i n g C o n t e x tc a t e g o r y : C a t e g o r y
m a i n ( )r u n ( )s e t u p L o g 4 j L o g g i n g ( )s h o w U s a g e ( )c l e a n U p ( )
1
+ F i d u C o n s u m e r O b j e c t A d a p t e r
1
1
+ F i d u P r o d u c e r O b j e c t A d a p t e r
1
11+ R a d a r P r o d u c e r O b j e c t A d a p t e r
R a d a r C o n s u m e r S e r v a n t
R a d a r C o n s u m e r S e r v a n t ( )g e t R a d a r R e p o r t s F o r C o n t a c t ( )d e l e t e R a d a r R e p o r t s F o r C o n t a c t ( )
11+ R a d a r C o n s u m e r O b j e c t A d a p t e r
R a d a r P r o d u c e r O b j e c t A d a p t e r
+ M a n a g e L i s t s
+ M a n a g e L i s t s
Figure 11-2 Class diagram of a Sensor History Server with type specific servants.
117
11.4 Event Mechanism
An event mechanism is a well suited to this type of server. TMA applications
periodically update their measurement sets; typically, an application will update it’s Fidu
list (or lists) every 20 seconds. This allows the application to include the most recent
data in it’s processing.
The current implementation of the server has no notion of an event mechanism. When an
application wants a periodic Fidu update, it has to request a full tracker list or contact list.
This is inefficient across the board: in terms of server processing, client processing and
network bandwidth.
Implementing an event mechanism allows a client to receive notification of new Fidus.
This gives the client the mechanism to request periodic list updates from the server.
These list updates would be limited to the newly arrived Fidus at the server, rather than
requests for full tracker lists or contact lists. This approach would yield substantial
increases in efficiency.
118
References
[And00] Gregory R. Andrews: Foundations of Multithreaded, Parallel and Distributed
Programming, Addison-Wesley, 2000.
[Ben90] M. Ben-Ari: Principles of Concurrent and Distributed Programming, Prentice
Hall, 1990.
[GoF95] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns – Elements of
Reusable Object-Oriented Software, Addison-Wesley, 1995.
[HV99] Henning M., S. Vinoski: Advanced CORBA Programming with C++,
Addison-Wesley, 1999.
[Lar98] C. Larman: Applying UML and Patterns, Prentice Hall, 1998.
[Lea99] D. Lea: Concurrent Programming in Java: Design Principles and Patterns,
2nd Edition, Addison-Wesley, 1999.
[Lew95] B. Lewis: Threads Primer: A Guide to Multithreaded Programming, Prentice
Hall, 1995.
[NavPers 16167] Standards and Curriculum Division, Training, Bureau of Naval
Personnel: The Fleet Type Submarine Online Submarine Sonar Operator’s
Manual, http://www.maritime.org/fleetsub/sonar/.
[OW99] S. Oaks, H. Wong: Java Threads, 2nd Edition Java 2, O’Reilly, 1999.
[Pow02] J. Powell Jr.: The Case For COTS, COTS Journal, vol. 4, no. 5, pp. 65-68,
May 2002.
119
[SSM+01] D. Schmidt, R. Schantz, M. Masters, J. Cross, D. Sharp, L. DiPalma: Towards
Adaptive and Reflective Middleware for Network-Centric Combat Systems,
CrossTalk, vol. 14, no. 11, PP. 10-16, November 2001.
[SSR+00] D. Schmidt, M. Stal, H. Rohnert, F. Buschmann: Pattern-Oriented Software
Architecture, Volume 2: Patterns for Concurrent and Networked Objects,
John Wiley & Sons, 2000.
[Sta98] W. Stallings: Operating Systems: Internals and Design Principles, 3rd Edition,
Prentice Hall, 1998.
[Sta01] W. Stallings: Operating Systems: Internals and Design Principles, 4th Edition,
Prentice Hall, 2001.
[Ste93] W. R. Stevens: Advanced Programming in the UNIX Environment, Addison-
Wesley, 1993.
[Ste98] W. R. Stevens: UNIX Network Programming, Volume 1: Networking APIs:
Sockets and XTI, 2nd Edition, Prentice Hall, 1998.
[Ste99] W. R. Stevens: UNIX Network Programming, Volume 2: Interprocess
Communications, 2nd Edition, Prentice Hall, 1999.
[Tan95] A. S. Tanenbaum: Distributed Operating Systems, Prentice Hall, 1995.
120
Appendix A: Glossary of Terms
Spherical An arrangement of hydrophones in a spherical pattern. This pattern
Array facilitates the determination of the arrival angle of a sound wave.
CORBA The Common Object Request Broker Architecture. A specification by the
Object Management Group for distributed object communication.
COTS Commercial Off The Shelf. General purpose hardware or software
components which are assembled into larger systems.
Deadlock A concurrency hazard that occurs when multiple threads attempt to
acquire multiple locks and become blocked indefinitely in a circular wait
state.
Fidu Filtered Input Data Unit. Averaged measurements from an acoustic sensor
aboard a submarine.
Hydrophone A device that transforms sound waves into electrical signals.
IDL The CORBA Interface Definition Language. An interface specification
language whose purpose is to define services that objects will expose to
distributed clients.
TMA Target Motion Analysis. A technique used to estimate the range, course
and speed of a contact (target) from a set of measured bearings and
frequencies.
Tracker An algorithm that processes electrical signals output from a hydrophone
array and estimates the bearing to the noise source.
121
Tracker An identifier indicating the tracker that produced a bearing.
Designator
Contact An identifier indicating the contact that a tracker is tracking.
Designator
122
Appendix B: Uniformity of Time Step
A fundamental requirement of any performance analysis is uniformity of measurement
tools. A meaningful comparison of the delay time across a queue or the round trip time
of a client request necessitates the same fidelity of time step.
The following table shows the fidelity of java.lang.System.currentTimeMillis() for the
Windows 2000 Professional and SuSE Linux 7.2 Professional operating systems. Since
the time step is not the same for both cases, System.currentTimeMillis() is an inadequate
tool for delay time comparisons between Windows 2000 and SuSE Linux.
Method / Operating System Windows 2000 SMP SuSE Linux 7.2 SMP System.currentTimeMillis() 15 or 16 milliseconds 1 millisecond
Additionally, the time step of System.currentTimeMillis() is 10 milliseconds on uni-
processor Windows 2000 Professional system.
A search of the Internet revealed a native package by Maciej Puzio ([email protected])
that solves this problem. The SystemX package calls the Win32
QueryPerformanceCounter function, thus achieving time step fidelity of 1 millisecond.
The following table shows the fidelity of java.lang.SystemX.currentTimeMillis() for
Windows 2000 Professional. Since the time step is 1 millisecond,
SystemX.currentTimeMillis() is an adequate tool for delay time measurements on
Windows.
Method / Operating System Windows 2000 SMP SuSE Linux 7.2 SMP System.currentTimeMillis() 15 or 16 milliseconds 1 millisecond
SystemX.currentTimeMillis() 1 millisecond Not available
123
System.currentTimeMillis() was used for performance metrics on SuSE Linux 7.2.
SystemX.currentTimeMillis() was used for performance metrics on Windows 2000
Professional.
124
Appendix C: Investigation of System.currentTimeMillis()
Prior to the adoption of Maciej Puzio’s SystemX.currentTimeMillis(), data anomalies
were an occasional but predictable occurrence (with Sun’s System.currentTimeMillis()).
This was observed under Windows only.
System.currentTimeMillis() will occasionally return descending times. That is given the
following code snippet:
long lastTime = System.currentTimeMillis (); // some method call long thisTime = System.currentTimeMillis (); long elapsedTime = thisTime – lastTime;
ElapsedTime would occasionally be less than zero. A small test program demonstrates
this. This problem occurs on SMP hardware only. The same test program has run on
uni-processor hardware and the problem does not occur.
The test code appears below.
import java.util.Enumeration; import java.util.Vector; /** * Test to see if System.currentTimeMillis() breaks. */ public class CurrentTimeMillisTest implements Runnable { /** want to allocate heap to get some garbage collection. */ private class TestObj { Vector v; /** */ private TestObj () { v = new Vector (100); for (int j=0; j<v.size (); j++) { v.addElement ("Element " + j); }
125
} } /** */ public CurrentTimeMillisTest () { } /** * check System.currentTimeMillis() */ public void run () { try { long lastTime = System.currentTimeMillis (); long thisTime; while (true) { // allocate many objects TestObj obj[] = new TestObj[1000]; for (int i=0; i<obj.length; i++) { obj[i] = new TestObj (); } thisTime = System.currentTimeMillis (); if (thisTime - lastTime < 0) { System.err.println ("ERROR: thisTime=" + thisTime + " lastTime=" + lastTime + " timeWarp=" + (thisTime-lastTime)); } lastTime = thisTime; Thread.currentThread ().sleep (5); } } catch (InterruptedException ignore) { } } /** bootstrap */ public static void main (String[] args) { final Vector threadList = new Vector (); Thread t = null; Runnable ctmTest = new CurrentTimeMillisTest (); for (int i=0; i<100; i++) { t = new Thread (ctmTest); threadList.add (t); t.start ();
126
} // add shutdown hook Runtime runtime = Runtime.getRuntime (); runtime.addShutdownHook (new Thread () { Thread t; public void run () { System.out.println ("Enter shutdown hook..."); Enumeration enum = threadList.elements (); while (enum.hasMoreElements ()) { t = (Thread)enum.nextElement (); System.out.println ("Interrupting " + t.getName ()); t.interrupt (); try { System.out.println ("Trying to Join " + t.getName ()); t.join (); System.out.println ("Joining " + t.getName ()); } catch (InterruptedException ie) { ie.printStackTrace (); } } } }); } }