ReadMe
Systems Programming, Designing and Developing Distributed Applications
Richard John Anthony
README file to accompany resources
This book is accompanied by a substantial resource-base to support the various activities and programming exercises.
The resources comprise tools for carrying out experiments (the workbenches), as well as significant numbers of sample applications (with full source code, project files and executable files) in three languages: C++, C Sharp (C#), and Java.
1. Resource Archives
The sample applications are archived into compressed zip files, categorised by chapter and language, i.e. there are three compressed archives for each chapter (one for C++, one for C# and one for Java).
The naming convention for archives
For chapter-specific resources the file name has the following format:
SP, followed by Cn (where n is the chapter number 2-7), followed by one of {Cp, Cs, Jv} indicating the language (C++, C# and Java respectively), followed by the date of the archive.
For example an archive named SP_C2_Cp_26Feb15.zip contains the chapter 2 C++ applications, dated 26th February 2015.
For general resources the file name has the following format:
SP, followed by resource type name, followed by the date of the archive.
For example an archive named SP_Workbenches_26Feb15.zip contains the Workbenches, dated 26th February 2015.
2. Tools and environment used in the development of the sample applications
Development tools used
The C++ and C# applications have been developed using Microsoft Visual Studio 2012 (VS2012). The project files can be upgraded to work with VS2013 (using the VS2013 in-built facility), or otherwise new empty projects can be created and the source files copied in (although this approach is more complex and not recommended.).
Netbeans v8.0.1 has been used to develop the Java applications.
Development and testing environments
The applications have been developed and tested on the Windows 7 and Windows 8 operating systems.
The constant upgrading of tools such as compilers, IDE's and the operating system poses a potential porting challenge when using future versions of these tools and environments, which users need to bear in mind. However at the time of finalising and testing there are no specific portability problems known.
3. Usage notes
This section contains some specific notes for installing and using the applications:
Installation Directories
The recommended way to use the supporting resources is to create a separate folder on your computer to hold the resources that relate to each chapter; i.e. to extract each archive into a separate directory. This will make it easier to keep track of which resources relate to each chapter.
The recommended pathname naming convention is:
"
For example, for the chapter two Cpp resources you might use:
C:\SystemsProgramming\ProcessView\Cpp\"
Extract files from the archives so as to retain the original directory structure for each application (containing the source code, project files and other resources, and the executable files). Some applications also use additional library files which have been included in the archives in the same directory as the relevant executable files. If these libraries are moved the executables will possibly not run correctly (depending on the actual pathname of where you place the libraries).
Some of the applications require the presence of the Directory Service running on one of the computers in the local network. The Directory Service itself is provided as part of the Distributed Systems Workbench. You can start the Directory Service and leave it running in the background; the various applications that use it will send name-registration requests and name-resolve requests to it via broadcast.
For any particular application, the recommended way to use the resources is to first experiment with the executable version to gain an overall understanding of what the application does (i.e. its behaviour and functionality), and then to study the source code to understand how the functionality is achieved.
The end-of-chapter programming challenges are mostly based on extending specified sample applications; so that you have a working starting point to explore and can work incrementally to reinforce understanding. Solutions to the programming challenges are also provided for you to consult, and to compare your solutions against.
IP addresses (IPv4)
IPv4 addresses are used in all the sample applications, and in the workbenches.
Ports (router and firewall aspects)
Various ports are used by the sample applications and also the workbenches. In many of the applications these have been made user-configurable. Users should be aware that firewall and router settings can block transmission of messages based on port numbers. If applications fail to communicate correctly, or 'bind' errors occur, a possible problem is router and/or firewall configuration issues.
Note that firewalls sometimes prevent certain applications (identified e.g. by the name of the executable file) from running; if this is an issue then you may have to edit your firewall settings.
Note also that once a process has bound to a particular port at a specific computer, further attempts to bind to the same port at the same computer will be refused. This means that for those applications where multiple components bind to the same port number, they must be run on separate computers. Many of the applications however have been designed purposely to allow co-existence, and thus experimentation, with only a single computer, so that a significant amount of work can be achieved even if you only have one computer available.
The Inter-Process Communication (IPC) applications used in chapter 2 and chapter 4 assume that both processes are located at the same computer.
The timing characteristics of some of the activities reported in chapter 2 are based on the C++ versions of the applications. The C# versions will yield similar response times but note that the Java versions run significantly slower, for like-for-like operations, due to the overhead of running in the JVM. I found the Java versions to run approximately one-quarter of the rate of the C++ versions, but the actual ratio is system dependent.
If using Microsoft Visual Studio 2013 with some of the C++ applications (those that use MFC) you may encounter various warnings stating that some features have been depreciated. If this happens add the following at the beginning of each .Cpp file affected: #pragma warning(disable: 4996)
4. Resource categories
There are several different categories of resource, these comprise:
- Three complete case studies with full source code and detailed documentation (the case study resources are included with the chapter 3 and chapter 7 resource archives).
- Extensive sample code and executable code to support practical activities in chapters and to support the programming challenges (including starting points for development and example solutions).
- Special editions of the established Workbenches suite of teaching and learning tools.
5. Additional uses of the Workbenches
In addition to laboratory / experimental use, all three Workbenches are very useful for demonstrating concepts in lectures, especially dynamic aspects which are very difficult to explain with static diagrams.
The Workbench activities are ideal as the basis for setting practical homework tasks for students to explore specific characteristics of systems. These allow practical experiments with communications and operating systems concepts without students having to actually write any code.
The Networking Workbench is particularly useful as a debugging tool when testing the communication aspects of components you are developing. The UDP and TCP tools within the Workbench can be used to determine if a component is actually sending a message, or can generate a message to examine the behaviour of a component when it receives a message. This is particularly useful when both sending and receiving components have been developed, but fail to communicate – the workbench can be used to track down the communication error to one of the components.
The Distributed Systems Workbench provides a Directory Service which can be used by other applications (as done by some of the activities in the book, see text for details). This can be used to illustrate modular systems and can be integrated with for example a coursework task (such as to integrate the use of the Directory Service into an application so that the client can automatically locate the server).