License Agreement

MPF is available via the open source license described at the end of this document

Contents

Introduction

MPF is the successor to HIDEOS which was written with the following goals:

• Support Industry Pack modules on an MV162 VME processor with limited memory. This required the development of a small standalone operating system.
• Communicate with an EPICS processor residing in the same VME crate via the VME backplane.
• Support a variety of IP modules.

When other IP carriers became available, it was decided that that it was too time consuming to support processors besides the MV162. Thus MPF was developed. It supports the same type of client server relationship as Hideos but support two types of communication: 1) If the client and server reside on the same processor, messages are passed in memory, and 2) If the client and server reside on different processors, message are passed via TCP. The original MPF was only supported on vxWorks. When EPICS base evolved to be Operating System Independent (OSI), the OSI version of MPF was devloped. When this document refers to MPF it means the OSI version. When it refers to EPICS base it means the OSI version of base.

MPF uses the OSI features of EPICS base for threads, mutexes, etc. It should run on any platform supported by EPICS base.

This document describes two main components:

Message Passing Facility

MPF provides client server message passing.  The messages are handled by message routers. Both local and remote message routers are provided.

A base class DevMpf is provided for writing epics device support that communicates with MPF.

All IP support has been unbundled from MPF. Thus it is described elsewhere

All code is written in C++. It is written to minimize dependencies between various components. For example the IP support can be used without MPF, MPF without the IP support, etc. The current implementation uses the standard C library but not the standard C++ library.

Acknowledgments

Jim Kowalkowski

Jim developed HIDEOS, the precursor of MPF. Many of the basic ideas for MPF come from Hideos. In addition the IP support for the ip330, GpibGsTi9914, OctalUart, and dac128 started with the Hideos support for these modules

Joe Sullivan

Joe developed the vxWorks board support packages that allow VME back plane communication.

Tom Coleman

Tom developed the original 162 Industry Pack Support and GpibGsTi9914 for MPF.

Mohan Ramanathan

Mohan was an early user of MPF and suffered patiently through the initial problems.

Andrew Johnson

Andrew made the changes so that his ipic support could be used with MPF.

Mark Rivers

Mark contributed many ideas that make the serial support general purpose, ,which is described eleswhere. He also developed support for digital and analog support which is also described elsewhere.

Requires

• Epics base release 3.14.4 or later
• IPAC release 2-6 or later

Hardware Configurations

• Epics and message servers on a single processor.
• Epics on one processor and message servers on another processor.

When MPF is used between processors, communication is via a tcp connection. Thus the two processors can reside anywhere as long as it is possible for them to communicate via tcp.

Install and Build MPF

Installation and Building

1. Create an installation directory for the module, usually this will end with

.../support/mpfosi/

2. Place the distribution file in this directory. Then issue the commands (Unix style)

gunzip <file>.tar.gz
tar xvf <file>.tar

3. This creates a <top> application with EPICS base 3.14 style rules.

.../support/mpfosi/mpfosiX-Y

where X-Y is the release. For example.

.../support/mpfosi/mpf2-1

4. Edit the configure/RELEASE file and set the paths to EPICS base and ipac (optional).
5. Run make in the top level directory and check for any compilation errors.
.

iocepicsclient/st.cmd
iocepicsserver/st.cmd
iocmpfclient/st.cmd
iocmpfserver/startServers
  

Now issue the commands:

cd X-Y
make

Now proceed to the next two sections.

Getting Started

The iocBoot directory has a number of sub directories for running mpf tests and/or examples. The best example is a test which connects an epics database to a mpf server. The test can be run in either local (client and server on the same processor) or remote (client and server on different processors)To start the test:

• Start the clients and servers
  • For local test

    cd iocBoot/iocepicslocal
    ../../bin/<arch>/test st.cmd
            

  • For Remote Test
    • Start the server

      cd iocBoot/iocepicsserver
      Check the inet address given to tcpMessageRouterServerStart in st.cmd
      ../../bin/<arch>test st.cmd

    • Start the client

      cd iocBoot/iocepicsclient
      check the inet addresses given to tcpMessageRouterClientStart in st.cmd
      ../../bin/<arch>test st.cmd

• Run medm from <top>/testApp/adl and ask for file epicsTest.adl

• On the server serverInt32 is started. It just echoes any Int32 message sent to it.
• The client has four ai records which use DevMpfInt32Test. This device support keeps a private counter which counts from egul to eguf. After incrementing the counter an Int32 message is sent to serverInt32. The reply is put in the val field.
• The medm display allows you to set the scan rate for all client records.

Studying the above will show how to write servers, device support, build servers and client, and boot servers and clients.

Using MPF in Applications

It is a good idea to keep mpf separate from applications which use it. An application can access mpf components by making the following changes:

• In <top>/configure/RELEASE add the line:

  MPF=<full path name>

• In the Makefile where the application is built add the following:

  <prod>_LIBS += mpfSerial mpfEpics mpf
  <prod>_LIBS += $(EPICS_BASE_IOC_LIBS)

MPF does not include support for specific ip modules. Such support must be obtained elsewhere.

Yiur xxxInclude.dbd file must include:

include "mpf.dbd"

Your xxxInclude.dbd file can include the following:

include "devStringMpf.dbd"
include "mpfSerial.dbd"
include "mpfSerialVx.dbd"

NOTE:

• devStringMpf.dbd is needed only if you use devStringMpf
• mpfSerial.dbd is required for serial support on non-vxWorks systems
• mpfSerialVx.dbd is required for serial support on vxWorks systems.

The st.cmd file must contain commands to start MPF routers and MPF servers. Look at the iocBoot/iocxxx/st.cmd files provided with MPF for examples.

Message Passing Overview

Messages are sent through a router. Two routers are provided: localRouter and RMR (Remote Message Router). The localRouter passes messages between a client and server residing on the same processor. RMR sends messages between a client and server on different processors via a tcp connection.

Message Client

typedef void (*clientCallback)(Message *message,void *clientPvt);
class MessageClient
{
public:
    MessageClient(clientCallback,void *clientPvt);
    int bind(char *server, int location);
    int send(Message *message);
    void *getClientPvt();
private:
    ...
}

1. Create an instance of MessageClient for each server with which it wants to communicate.
2. Issue a bind call to establish communication.
3. Call send to send messages.
4. Provide a callback which is called whenever a connection is made or broken and is also called whenever the server sends a message to the client.

Message Server

class MessageServer
{
public:
    MessageServer(const char* name);
    void waitForMessage();
    Message *receive();
    Message *allocReplyMessage(Message *clientMessage,messageType type);
    int reply(Message *);
    void setQueueSize(int size);
    const char *getName() const;
    void report() const;
private:
     ...
}

1. Create an instance of MessageServer.
2. Call waitForMessage if it wants to block until it receives messages.
3. Call receive to accept messages.
4. Call reply to send messages to a client.
5. Call allocReplyMessage if it wants to send additional additional messages to a client

Messages

• Message - The base class. It provides the following methods for message users:  getType, getClientType, setClientType, getClientExtra, setClientExtra.
• Connect - A message that is passed when a client connects or disconnects from a server.
• StandardFields - This is not an actual message type but a class that provides fields, which can be used with other message types.  The fields are timeout, cmd, status, address, and extra. The meaning of these fields are determined by particular client/servers.
• Char8Array - A message for passing character strings. It supports the standard fields.
• Int32 - A message for passing integer values. It supports the standard fields.
• Int32Array - A message for passing arrays of integer values. It supports the standard fields.
• Float64 - A message for passing float values. It supports the standard fields.
• Float64Array - A message for passing arrays of float values. It supports the standard fields.
• SerialConfig - A message for configuring serial ports, e.g. baudrate.
• OutOfBand - A message not requested by the other side.

Message instances are kept on a free list. Thus malloc is called only if the free list is empty. Free is never called. Each message type has it's own free list.

Example

Epics Record to MPF server - Flow of Control

INP("C1 S0 @Int32")

• C1 identifies the location of the server. Location is described below in the section on Router Configuration.
• S0 is not used
• Int32 is the name of the MPF supplied server

• The ai record support module calls DevMpf::read_write.
• DevMpf calls DevMpfInt32Test::startIO.
• startIO calls DevMpf::sendReply.
• If a local router connects to serverInt32
  • LocalRouter puts the message on the  serverInt32 queue.
• Else if a remote router connects to serverInt32
  • The message is put on the RMRclient queue.
• DevMpfInt32Test , DevMpf and record support finish the beginning phase of asynchronous record processing.
• If a remote router connects to serverInt32
  • RMRclientTask sends a TCP message to RMRserver.
  • tcpTask receives the message and calls RMRserver::receiveCallback.
  • RMRserver puts the message on the serverInt32 queue.
• The serverInt32 task wakes up from MessageServer::waitForMessage.
•  serverInt32 calls MessageServer::receive.
• For more complicated servers some other code, i.e. ip support would then be called. The simple example just echos the received message.
• serverInt32 calls MessageServer::reply.
• If a local router accepts the message.
  • DevMpf::messageClientCallback is called.
  • DevMpf make an epics callbackRequest.
  •  serverInt32 again calls MessageServer::waitForMessage.
• Else if a remote router connects to serialServer
  • The reply message is put on the RMRserver queue.
  • serverInt32 again calls MessageServer::waitForMessage.
  • RMRserverTask sends a TCP message to the RMRclient.
  • The client tcpTask receives the message and calls RMRclient::receiveCallback.
  • RMRclient calls DevMpf::messageClientCallback.
  • DevMpf make an epics callbackRequest.
• The epics callback task calls DevMpf::callDeviceSupport which calls the RSET::process.
• The ai record support module calls DevMpf::read_write which calls DevMpfInt32Test::completeIO.
• DevMpfInt32Test, DevMpf, and record support finish the asynchronous completion phase of record processing.

Diagnostic Aids

WARNING: A queue overflow usually means that the queue size was made too small.

mrr

For servers it provides a report like the following:

iocrstserver> mrr
clientRouterList
serverRouterList
 1 RMRServer stateConnected queueSize 100 inQueue 0 replyQueueFull 0
   sendPerSec 240 receivePerSec 240  tcpSendPerSec 10 tcpReceivePerSec 10

• queueSize - The maximum number reply messages which can be queued.
• inQueue - The number of unsent reply messages.
• replyQueueFull - The number of times a reply request was rejected because the reply queue was full.

For clients it produces the following type of report

iocrstclient> mrr
clientRouterList
 1 RMRClient stateConnected queueSize 100 inQueue 0 sendQueueFull 0
   Server Int32 has 4 clients. bindState connected
   sendPerSec 40 receivePerSec 40  tcpSendPerSec 10 tcpReceivePerSec 10
serverRouterList

msr ("serverName")
msr

iocrstserver> msr "Int32"
Int32
          queueSize 10
            inQueue 0
      queueRequests 132171
 queueFullResponses 0
      replyRequests 132171

• queueSize - The maximum number of unprocessed requests that can be placed in the servers queue.
• inQueue - The number of unprocessed requests currently in the servers queue.
• queueRequests - The number of queue requests that have been made since the server was started.
• queueFullResponses - The number of times a queue request was made and the receive queue was already full. When this happens a ConnectMessage is sent to the client.
• replyRequests - The number of reply requests that have been made since the server was started.

Message Routers

Local Message Router

Remote Message Router

Router Configuration

Each processor that is a member of a set of MPF clients/servers is assigned a unique location, which is just an integer value. For example if the set is an mv167/mv162 the mv167 could be assigned location 0 and the mv162 location 1. All that matters is that each cpu is assigned a unique location and all cpus agree on the assignments. If local communication is desired then the following command must appear:

localMessageRouterStart(location)

If tcp communication is desired then for each remote system the client must have the following command:

tcpMessageRouterClientStart(location,port,"address",bufSize,queueSize)

• location is the location of the server.
• port is the port the server will use to listen for a connection.
• address is the inet address of the server.
• bufSize determines that maximum size message accepted by the client.
• queueSize is the maximum number of send messages that will be queued.

Each system supporting remote servers must have the following command for each client machine.

tcpMessageRouterServerStart(location,port,"address",bufSize,queueSize)

• location is the location of the server.
• port is the port the server will use to listen for a connection.
• address is the inet address of the server. This argument can be null, in which case the server will accept connections via all internet interfaces attached to it's cpu.
• bufSize determines that maximum size message accepted by the server.
• queueSize is the maximum number of reply messages that will be queued.

NOTE CAREFULLY:Each server router can only handle a single client router. A particular client/server pair is established by the client and server having EXACTLY the same (location,port,addresss) tuple. Also each server/client pair must use a unique port number.

Message

Overview

• Clients must allocate a message via a call

  <message class> *pmessage = new <message class>;

  for example an Int32 message can be allocated as follows:

  Int32Message *pmessage = new Int32Message;

• Servers allocate a message via a call to the allocReplyMessage of class MessageServer. For example an Int32 reply message can be allocated via a call:

  Int32Message *pmessage =(Int32Message*)pMessageServer->
      allocReplyMessage(preceive,messageTypeInt32);

  where preceive must be a message received from the client. The reason is that the receive message contains information describing where the client is located.
  
• The final destination of a message must call delete to free the message via the statement:

  delete pmessage;

  Thus the server must delete any message received from a client and a client must delete reply messages from the server.

The definition of class Message is:

class Message
{
public:
    messageType  getType();
    int32 getClientType();
    void setClientType(int32 type);
    int32 getClientExtra();
    void setClientExtra(int32 extra);
    virtual ~Message();
    virtual int  toBuffer(char **buffer);
    virtual int  fromBuffer(const char **buffer);
    virtual int  fromBufferSwitch(const char **buffer);
    virtual void print() const;
    static Message *allocate(messageType type);
protected:
    Message(messageType type);
    ....
}

Client and server code normally only call new, delete, the methods described in the following table, and message specific methods. The other methods are called by MPF itself. A message is allocated via a call to new and released via a call to delete. When delete is called the message is placed on a free list. Only one of the message types derived from Message can be created, i.e. it is not possible to create an object of type Message.

The virtual methods must be implement by any class that derives from Message. The toBuffer and fromBuffer methods are called to put and take messages from a buffer that passes over a communication link.

Architecture Independent Message Passing

• signed and unsigned 16 and 32 bit integers
• IEEE float and double.
• strings, i.e. C char 8 arrays. MPF itself uses some strings as ascii strings. Other strings are uninterpreted 8-bit values whose contents are guaranteed not to undergo any conversions during transmission.

MPF provides a header file "mpfType.h" which defines typedefs for int16, uint16, int32, uint32, float32, and float64. MPF provides static methods to transfer the following to/from network buffers:

• signed and unsigned 16 and 32 bit integers
• IEEE float and double
• char8 arrays which are uninterpeted bytes.

Adding New Message Types

• messageType.h and messageType.cpp must be modified.

These files contain instructions about what to add. This is a simple change.
• A header and source file for the new message must be created.

ConnectMessage

• connectNo - Sent when client router detects a disconnect from server.
• connectYes - Sent when a successful connection is made to server.
• connectNoRouter - No router exists.
• connectNoServer - Sent when a bind request is made but server router can not find server.
• connectQueueFull - Sent when a message is sent to server but the servers queue is full.

StandardFieldsMessage

Free Lists for Array Messages

Char8ArrayMessage

Char8ArrayMessage provides the following methods for allocating and freeing the string value.
 

Int32Message

Int32ArrayMessage

Float64Message

Float64ArrayMessage

SerialConfigMessage

OutOfBandMessage

MPF Device support

DevMpf is an abstract base class for implementing EPICS device support.

// return codes for startIO and completeIO.

#define MPF_OK                  0
#define MPF_NoConvert           2

enum replyType {replyTypeNone, replyTypeCompleteIO, replyTypeReceiveReply};

class DevMpf
{
public:
    DevMpf(dbCommon*,link*,bool iointValid);

    // Following must be implemented by device support modules
    virtual long startIO(dbCommon*)=0;  // start async IO
    virtual long completeIO(dbCommon*,Message *)=0; // end async IO
    // the following can be implemented by device support modules
    virtual void receiveReply(dbCommon*,Message *);
    virtual void connectIO(dbCommon*,Message *);     // connection message
    virtual void outOfBandIO(dbCommon*,OutOfBandMessage *);// outOfBand
    virtual long convert(dbCommon*,int pass);   // do linear conversion
    // The following must be called after object is constructed
    void bind();
    // The following are usefull during record initilization 
    bool connectWait() {return(connectWait(5.0));}
    bool connectWait(double timeout);
    // send a message to MPF server with no reply expected
    int send(Message*);
    // send a message to MPF server and wait for reply via completeIO
    int sendReply(Message*);
    // send a message stating the type of reply
    int send(Message*,replyType);
    int sendWait(Message *pmessage,replyType type)
        {return(sendWait(pmessage,type,5.0));}
    int sendWait(Message*,replyType,double timeout);
    // This routine gets a pointer to the user portion of the parm field
  
    long getStatus() const { return(status);}
    // Following are DSET routines
    static long read_write(void*);      // generic DSET read/write routine
    static long ioint(int cmd,dbCommon*,IOSCANPVT* iopvt); // DSET i/o intr
    static long linconv(void*,int); // calls convert
    IOSCANPVT ioscanpvt;
    bool iointValid;
    bool isConnected() { return((connectState==connectYes) ? true : false);}
private:
    ...

}

If the support is for a simple device, i.e. a device that can be supported via the following:

• When the associated record starts the first phase of record processing, the device support issues a sendReply message to the server.
• When the reply is received the record completes processing.
• Device support doesn't have to do anything special when it first connects to it's server

For devices that are not simple, e.g. devices that must take special action when connecting to the server, additional methods are available: In particular:

• connectWait can be called to wait for connection to the server. This should NOT be called as part of record processing. It is OK in the constructor or in a private thread.
• sendWait can be called to wait until the server processes the message and sends a response. This should NOT be called as part of record processing. It is OK in the constructor or in a private thread.
• receiveReply and send(message,replyTypeReceiveReply) are available. receiveReply does not interact with record processing. Thus the device support can interact with the server without processing the record. This can be used to send a series of messages to the server. DevMpf uses the message field clientType to distinguish the reply type.
• connectIO can be implemented so that the device client is called everytime the support is connected or disconnected with the server.
• The  Message methods getClientExtra and  putClientExtra can be used by the device support to match response with request messages. NOTE: DevMpf uses getClientType and  putClientType so device support MUST NOT use these methods.
• After connection processing is complete device support can revert to the simple processing described above.

ioscanpvt is for provided for convenience.  If a derived class wishes to support io interrupt processing it can request that the base class perform the necessary initialization. The derived class must, however, call scanIoRequest.
 

The INP or OUT field MUST have the format:

field(INP or OUT, "#C<location> S<signal> @<server>,<deviceSpecific>")

Device Support Entry Tables

MAKE_LINCONV_DSET(<dset name>,<dev init>)
MAKE_DSET(<dset name>,<dev init>)

MPF Directory Structure

<top>/
    configure/
           RELEASE
    mpfApp/
           coreSrc/
           messageSrc/
           registerSrc/
           testSrc/
           utilSrc/
    epicsApp/
           devMpf.h
           devMpf.cpp
    testApp/
           adl/
           Db/
           src/
    iocBoot/
           iocepicsclient/
           iocepicslocal/
           iocepicsserver/
           iocmpfclient/
           iocmpflocal
           iocmpfserver/
           iocmpflocal/
           ioctcp

Multiple Processor vxWorks VME systems

• An mv167 resides in the first slot. It has an ethernet connection. It also provides a back plane gateway for other processors in the same crate. It is processor number 0.
• An mv162 resides in the second slot. It has no ethernet interface. It has network access via the back plane and appears on the same local area network as the mv167. It is processor number 1.
• Additional mv162s could appear in other slots. They are similar to the first mv162.

• IPmv167 - The address of the mv167
• IPgateway - The address of the MVE gateway, which is managed by the mv167 vxWorks support
• IPmv162 - Each mv162 needs its own address
• IPhost - The address of the vxWorks boot host.

MV167

boot device          : ei
processor number     : 0
host name            : <host>
file name            : <full path>/vxWorks
inet on ethernet (e) : <IPmv167>:<subnet mask>
inet on back plane (b): <IPgateway>
host inet (h)        : <IPhost>
gateway inet (g)     :
user (u)             : <user>
ftp password (pw) (blank = use rsh): <password>
flags (f)            : 0x0
target name (tn)     : ioc167
startup script (s)   : <full path name>/st.cmd
other (o)            :

boot device          : sm=0x80000600
processor number     : 1
host name            : <host>
file name            : <full path>/vxWorks
inet on ethernet (e) :
inet on back plane (b): <IPmv162>
host inet (h)        : <IPhost>
gateway inet (g)     : <IPgateway>
user (u)             : <user>
ftp password (pw) (blank = use rsh): <password>
flags (f)            : 0x0
target name (tn)     : ioc162
startup script (s)   : <full path name>/st.cmd

Utility Classes

• FreeList - A class that keeps objects of a particular class on a free list.
• DLList - A double linked list class.
• WatchDog - A class that is a C++ interface to the vxWorks wdLib.
• DataFreeList - A free list class for date.
• Reboot - A class providing support for the vxWorks rebootHookAdd facility.

FreeList provides the same functionality as the freeList facility provided with epics base, in fact it is just freeList redone in C++.

DLList is a double linked list class that does not require nodes to be embedded in objects placed in a list. This is different than the ellList facility provided by epics base.

WatchDog is a class that provides functionality similar to the vxWorks wdLib. The major exception is that the user supplied callback is called by a WatchDog supplied task rather than being called at interrupt level.

DataFreeList is a class for data free lists. It provides free lists of sizes ranging from 16 bytes to 4096 bytes. It is used by the array message types.

Reboot can be used to turn off interrupts when a soft reboot is being performed.

These classes are not described in this document. If you want to use them in new code look at examples in existing code.

License Agreement

Copyright (c) 2002 University of Chicago. All rights reserved.

MPF - Message Passing Facility
MPF is distributed subject to the following license conditions:

 SOFTWARE LICENSE AGREEMENT
 Software: MPF

 1. The "Software", below, refers to MPF (in either source code, or
    binary form and accompanying documentation). Each licensee is
    addressed as "you" or "Licensee."

 2. The copyright holders shown above and their third-party licensors
    hereby grant Licensee a royalty-free nonexclusive license, subject to
    the limitations stated herein and U.S. Government license rights.

 3. You may modify and make a copy or copies of the Software for use
    within your organization, if you meet the following conditions:
      a. Copies in source code must include the copyright notice and this
         Software License Agreement.
      b. Copies in binary form must include the copyright notice and this
         Software License Agreement in the documentation and/or other
         materials provided with the copy.

 4. You may modify a copy or copies of the Software or any portion of it,
    thus forming a work based on the Software, and distribute copies of
    such work outside your organization, if you meet all of the following
    conditions:
      a. Copies in source code must include the copyright notice and this
         Software License Agreement;
      b. Copies in binary form must include the copyright notice and this
         Software License Agreement in the documentation and/or other
         materials provided with the copy;
      c. Modified copies and works based on the Software must carry
         prominent notices stating that you changed specified portions of
         the Software.

 5. Portions of the Software resulted from work developed under a U.S.
    Government contract and are subject to the following license: the
    Government is granted for itself and others acting on its behalf a
    paid-up, nonexclusive, irrevocable worldwide license in this computer
    software to reproduce, prepare derivative works, and perform publicly
    and display publicly.

 6. WARRANTY DISCLAIMER. THE SOFTWARE IS SUPPLIED "AS IS" WITHOUT WARRANTY
    OF ANY KIND. THE COPYRIGHT HOLDERS, THEIR THIRD PARTY LICENSORS, THE
    UNITED STATES, THE UNITED STATES DEPARTMENT OF ENERGY, AND THEIR
    EMPLOYEES: (1) DISCLAIM ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
    BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
    FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT, (2) DO NOT ASSUME
    ANY LEGAL LIABILITY OR RESPONSIBILITY FOR THE ACCURACY, COMPLETENESS,
    OR USEFULNESS OF THE SOFTWARE, (3) DO NOT REPRESENT THAT USE OF THE
    SOFTWARE WOULD NOT INFRINGE PRIVATELY OWNED RIGHTS, (4) DO NOT WARRANT
    THAT THE SOFTWARE WILL FUNCTION UNINTERRUPTED, THAT IT IS ERROR-FREE
    OR THAT ANY ERRORS WILL BE CORRECTED.

 7. LIMITATION OF LIABILITY. IN NO EVENT WILL THE COPYRIGHT HOLDERS, THEIR
    THIRD PARTY LICENSORS, THE UNITED STATES, THE UNITED STATES DEPARTMENT
    OF ENERGY, OR THEIR EMPLOYEES: BE LIABLE FOR ANY INDIRECT, INCIDENTAL,
    CONSEQUENTIAL, SPECIAL OR PUNITIVE DAMAGES OF ANY KIND OR NATURE,
    INCLUDING BUT NOT LIMITED TO LOSS OF PROFITS OR LOSS OF DATA, FOR ANY
    REASON WHATSOEVER, WHETHER SUCH LIABILITY IS ASSERTED ON THE BASIS OF
    CONTRACT, TORT (INCLUDING NEGLIGENCE OR STRICT LIABILITY), OR
    OTHERWISE, EVEN IF ANY OF SAID PARTIES HAS BEEN WARNED OF THE
    POSSIBILITY OF SUCH LOSS OR DAMAGES.