Evaluation ========== o Spread 3.15.2, http://www.spread.org/ Spread is a sophisticated message passing framework. The software itself is written in C and uses a design very similar to SRPC's: It is split into a permanently running daemon and a link library containing interface routines to that daemon for the programmer. The daemon will maintain so called "groups", which computers can join and leave. Furthermore the daemon provides group communication services based on TCP, UDP or Multicast-UPD. There is no actual RPC functionality available, but implementing such a system on top of Spread would be relatively trivial. The software seems to be actively maintained, well-written and documented, but unfortunately the following drawbacks kept us from using it: - Spread's license currently prohibits any commercial use, but according to the authors (as of April 2001) they are providing special license exceptions for Open Source projects and working on moving Spread to a commercial split of from their University and then releasing Spread under a real Open Source license. - It is not possible for peers to communicate without the daemon. - The API for the programmer is somewhat messy. - No GNU autoconf, no install target. - The I/O system is hardcoded into the library and cannot be customized for our own needs. o XML-RPC, http://www.xmlrpc.org/ XML-RPC is a standardized remote procedure call framework for which several complying implementations exist. These implementations provide support for the programming languages Perl, Python, Java, C/C++, Lisp, PHP, Microsoft .NET, Tcl, Delphi, WebObjects and many more. Remote procedure calls are encoded in a portable XML representation and transferred via HTTP. The software seems to be popular and many resources dealing with XML-RPC exist, but for us the massive XML encoding overhead was too much. o RPC2, http://www.coda.cs.cmu.edu/ This RPC mechanism is part of the CODA network file system, but it can be used without the file system part. RPC2 consists of a link library for the programmer and a stub generator, that will create function descriptions, which the library can then use to call the described function remotely. The whole approach is very clean and minimalistic, but unfortunately, the code depends on liblwp -- a user space threading library. While threading is certainly useful on many occasions, we did not want to use a system that enforces threading. In C++, for instance, the behavior of exceptions within a thread are totally unspecified. Furthermore, user space threads do not achieve the performance of kernel threads, nor are they portable (RSE: Hmmmm... I'm not sure this really holds, because evaluation showed that 1. user-space dispatching is usually faster than dispatching in kernel-space and 2. GNU Pth proofed that user-space threading can be done in a very portable way). o MRPC 0.9.1, http://www.tildeslash.org/mrpc.html "Modular RPC" is a minimalistic remote procedure call mechanism using a similar design as the original RPC: It consists of a code generator that will encapsulate function definitions in such a way that they can be called remotely with the functions provided in a link library. The whole system is very lean and efficient, marshaling is done automatically for most data types, and the provided documentation is sufficient. Unfortunately, the whole system is written in C++ and can thus not trivially be used in plain C or any other language. o LinuxDoors 0.9, http://www.rampant.org/doors/ The author discontinued development of the package in May 2001. The current version 0.9 is considered to be alpha quality software. o ORBit 0.5.8, http://orbit-resource.sourceforge.net/ ORBit implements the CORBA 2.2 protocol in order to provide RPC services. The source code is written in C and has been licensed under the GNU GPL for the general public. Considering the fact that ORBit uses CORBA, it is very fast and efficient. ORBit allows peer-to-peer communication without the use of a request broker and comes with an "interface definition language" (IDL) that is used for marshaling the parameters of remote function calls. - Requires glib 1.2.1 or newer. o TIRPC, ftp://ftp.uu.net/networking/rpc/ The "Transport Independent RPC" package is derived from the original SUN RPC and uses the TLI interface to access the network. Unfortunately, TLI is not widely supported; sockets rule the communication market. Thus, the package is not very useful for us. o SunRPC The "original". While the RPC mechanism itself is fine, proven and widely available, the API for the programmer is insufficient: SunRPC does not support any asynchronous message passing in a sensible way. Furthermore, the standard dictates the use of XDR. o DCE RPC, ftp://gatekeeper.dec.com/pub/DEC/DCE/ This package was developed by the Open Software Foundation (OSF) in 1993. It appears not to have changed since then: there is no support for GNU autoconf and consequently the build system fails miserably. Furthermore, the package inherently depends on pthreads but seems to call functions that are not part of the standard pthread implementation. Our impression is that a lot of clean-up work would be necessary before the package can even be compiled -- let alone be tested. o PVM, http://www.epm.ornl.gov/pvm/ o Foreign Function Call Library http://clisp.cons.org/~haible/packages-ffcall.html Evaluation for XDS ================== o libbinio http://members.home.net/mikpos/libbinio/ o HiM http://www.sama.ru/~despair/him/ o pbio ftp://ftp.cc.gatech.edu/pub/groups/systems/chaos/pbio/ o SunRPC XDR RFC1832 o XTL http://gsd.di.uminho.pt/jop/xtl/ o CORBA GIOP CDR ???