warped update


Subject: warped update
From: Jorgen Dahl (dahlj@ECECS.UC.EDU)
Date: Sun Aug 12 2001 - 08:24:43 MDT


Update of /home/paw/CVS/warped/eclmpl/include
In directory viking.ececs.uc.edu:/work/dahlj/warped/eclmpl/include

Modified Files:
        MPIPhysicalCommunicationLayer.h Makefile.am
        TCPSelectPhysicalCommunicationLayer.h
        UDPSelectPhysicalCommunicationLayer.h eclmpl.h
        eclmplCommonInclude.h eclmplSocket.h
Added Files:
        SocketBasedConnectionInterface.h TCPConnectionInterface.h
        UDPConnectionInterface.h eclmplConfigFileTable.h
        eclmplConnectionInterface.h
        eclmplConnectionInterfaceImplementationBase.h
        eclmplContactInfo.h eclmplReliablePhysicalCommunicationLayer.h
        eclmplTimer.h eclmplUnreliableNetworkMessage.h
Removed Files:
        NetworkMessageQueue.h UDPNetworkMessage.h
        UDPNetworkMessagePriorityQueue.h UDPNetworkMessageQueue.h
Log Message:
Adding and removing files for eclmpl after generalising the implementation.
It will now be easier to add new communication layers and share most of
the code between a particular type of communication layer. For example,
the unreliable protocols UDP and VIA will use much of the same code for
implementing a reliable protocol (I'm not adding the VIA comm-layer yet
though).

The MPIPhysicalCommunicationLayer is unchanged from before. All other
communication layers will now use a ConnectionInterface of some kind
that will do the system calls to place/remove messages on the underlying
Transport Layer (e.g. UDP or TCP). For unreliable transport layers, the
communication layer (e.g. UDPSelectPhysicalCommunicationLayer) is respons-
ible for implementing reliability. Most of these reliability features are
inherited from eclmplReliablePhysicalCommunicationLayer.

I am removing all the old queue implementations after changing back to
STL datastructures. I have now run so many tests that I feel comfortable
doing this. The performance is the same with and without STL (within the
error margin), so I now see no reason for not using STL.



This archive was generated by hypermail 2b25 : Mon Mar 18 2002 - 13:00:12 MST