Home
Up
Overview
Download
Build/Install
Documentation
Presentations
Links

SCT DAQ/DCS/Test Software

 

Demonstration and Overview of IPC:

12 November 2002  

Since in the last meeting I claimed that it should be fairly straightforward to use IPC, I thought I had better prove it!  Here is a brief overview of the test application, followed by a brief explanation of IPC, some pointers on how to design a class structure that can easily have IPC retro-fitted and finally some threading issues.

Helloworld application:

This is a simple HelloWorld set of applications that use IPC to do some simple communication.  We have got them working at Cambridge with each application running on a different machine (note all have access to the same file system).  The application consists of 

  1. Interface Definition Language (IDL) file: helloworld.idl
    This defines the external interface (helloworld) which clients access.
    Servers create objects that are instances of this interface (i.e. they sub-class it) and these instances are then available to clients
  2. Server application file: helloworld.cpp
    This file contains an implementation of the helloworld interface (the class Hello) and a small server application that publishes it.
  3. Client application file: helloworld_client.cpp
    This is a simple client application that retrieves a handle to the object that the server has published and calls its method.
  4. Java client application: test_client.java 
    This is a Java version of the above client.  It proves that IPC works across language boundaries as well as machine boundaries.
  5. A Makefile
    This is quite instructive for people starting writing IPC code.  It shows how to call the stubbers and what files need to be compiled for which executables

It should be noted that the application requires a working installation of the Online Software, a general partition server and partition server for the partition be_test.  This can be achieved by running:

machine> ipc_server &
machine> ipc_server -p be_test &

 

Overview of IPC

IPC is a thin layer on top of ILU - a CORBA implementation from Xerox (Links).  CORBA provides a language and platform independent mechanism for local and distributed inter-process communication.  

It achieves this by defining the communications protocols and also by using a language independent specification of the interface that objects (servers) present to clients.  This interface is written in Interface Definition Language (IDL).  IDL has many similarities with Object-Oriented (OO) syntax found in Java and C++.  The principle components of IDL are:

  • interfaces containing only methods, which map onto Java interfaces and C++ pure abstract base classes
  • simple data-types
  • C-style structs
  • exceptions
  • enumerations

It is also possible to define valuetypes which would correspond to a Java class of a C++ class with data members.  It is probably a good idea to avoid these though in simple applications as it restricts the implementation.

In IPC applications, your interfaces should derive from ipc::freeable.  The implementation of this interface is provided by the IPCObject class.

The IDL file is converted into code by a stubber.  For instance, the C++ stubber creates a number of classes based on the IDL file.  These provide the necessary code for making and receiving remote calls.  Normally, you write a class that derives from the IPC base object, IPCObject and implements your interface.

For a more clear and lucid explanation, see the Online Software website.

Pointers for writing C++/Java classes for later retro-fitting IPC

  • Don't uses ints - use longs instead
  • Define an interface (i.e. a pure abstract base class) that contains only methods.  Then sub-class it to provide an implementation
  • Use simple data-types/arrays where possible or references to classes that are also part of the external interface
  • Do not use STL types.  There is a sequence type in IDL, but it maps to a stubber-created class.  To use this, it is probably best to install the Online Software, or use vectors for now realising that all code that accesses them will have to be changed later.
  • C-style structs can be used for more complex data structures.    
  • Methods that return void can (your decision) be called asynchronously.  This would be useful for methods that invoke long operations, but note the threading issues.
  • Make sure your classes can derive from a base object that will be supplied by IPC

Um, that's all I can think of.  IPC is designed to make it easy to give external programs access to your class structure.

 

Threading issues

When writing a server (i.e. a program that provides an interface for clients to use), the IPC core can be initialized in single-threaded or multi-threaded modes.  In multi-threaded mode, ILU (the underlying CORBA implementation) will spawn a new thread to deal with each incoming request.  Thread safety in the external interface is therefore crucial.  

In single-threaded mode, each request is handled in order.  However, there is still a threading issue if the server is also a client.  If a server receives a request and whilst dealing with it, calls another server using IPC, then, whilst waiting for that call to return, requests will be dealt with.  This behaviour is intended to prevent deadlocks.

I think it is probably a good idea if code is made thread-safe so that a server can always be contacted and can provide status information.

 

 

Last modified 15 February 2003 .  Maintained by Matthew Palmer