This is the Holumbus-Distribution Library
Version 0.1.0
Stefan Schmidt sts@holumbus.org
http://holumbus.fh-wedel.de
About
-----
Holumbus is a set of Haskell libraries. This package contains the
Holumbus-Distribution library for building and running a distributed systems.
One of the core elements of this library is an Erlang-style communication
system for interchanging data between different threads or applications.
This library was completely rewritten between version 0.0.1 and 0.1.0. The old
packages can be found under Holumbus.Network.* while the new ones are
located at Holumbus.Distribution.*. The old packages will be removed in
future versions.
This library itself is independent from other Holumbus libraries although it
contains some modules which are only to be used by the other Holumbus
libraries but this may change in the near future.
Documentation:
------------------------------------------
Haskell offers great libraries and datatypes for the implementation
of intra-process communication, e.g. MVars, Chans, STM. But compared
to other functional languages like Erlang or Mozart/Oz (ok, the later
is a multi paradigm language) offer better support for building distributed
systems. Holumbus-Distribution wants to close this gap by offering multiple
distributed data structures.
The following datastructures are implemented so far:
* distributed Chan (DChan)
like the Chan datatype, but it allows the writing
and reading (!) from other programs
* distributed MVar (DMVar)
like the MVar datatype, but the content of the
MVar can be shared among multiple programs.
* distributed Functions (DFunction)
an easy way to do remote procedure calls, just like
haxr
* distributed Values (DValue)
a variable which could only be written once and
which could easily read by other programs
* distributed Streams and Ports (DStream, DPort)
just like the DChan, but this time, you are only
allowed to read from the channel from one program
To be able to use these data structures, your program needs to become a
distributed node (DNode, comparable to an Erlang-Node). After initializing
the node, you can create instances of the data structures described above.
You only need to register these resources at your node and then other nodes
are able to access them.
Contents
--------
Examples Some example applications
Programs The applications you need to run a distributed system.
(these are not needed any more an belongs to the old
Holumbus.Network.* packages, they will be deleted in 0.2.0)
source Source code of the Holumbus-Distribution library.
Requirements
------------
So far, this library is only tested under Linux, please tell me, if you have
problems under Windows or other OS.
The Holumbus-Distribution library requires at least GHC 6.10 and the
following packages (available via Hackage).
containers
hslogger
network
unix
time
bytestring
binary
hxt
Installation
------------
A Cabal file is provided, therefore Holumbus-Distribution can be installed using
the standard Cabal way:
$ runhaskell Setup.hs configure
$ runhaskell Setup.hs build
$ runhaskell Setup.hs install --global # with root privileges
This will generate the library and the PortRegestry programs.
For those who prefer to build it the old way with make:
$ make build
$ make install # with root privileges
Steps to make a distributed system running
--------------------------------
How to use Streams and Ports:
On the receive side:
-- Step 1:
-- make a Haskell DNode, named "myReceiver" on the Port 7999
-- this only needs to be called once during the runtime of the program
_ <- initDNode $ (defaultDNodeConfig "myReceiver")
{ dnc_MinPort = (fromInteger 7999), dnc_MaxPort = (fromInteger 7999) }
-- Step 2:
-- make a new DStream, named "myStream"
-- this stream can be used until you close it with "closeDStream"
stream <- newDStream "myStream"
-- Step 3:
-- wait for the next message, read it print it out to stdout
msg <- (receive stream)::(IO String)
putStrLn msg
-- Step 4:
-- we are behaving nicely and clean everything up before we leave
closeDStream stream
deinitDNode
On the sender side:
-- Step 1:
-- make a Haskell DNode, we don't care about its name, so we leave it
-- blank. The system will generate a unique random name on its own.
-- this only needs to be called once during the runtime of the program
_ <- initDNode $ defaultDNodeConfig ""
-- Step 2:
-- we need to know how to address the receiver node, so we have to provide
-- its address, this only needs to be done once, or when the address of
-- the receiver changes (which will not happen in most applications)
addForeignDNode $ mkDNodeAddress "myReceiver" "localhost" (fromInteger 7999)
-- Step 3:
-- we make a new port, connected to "myStream" at the node "myReceiver"
port <- newDPort "myStream" "myReceiver"
-- Step 4:
-- send the messages
send port "Hello World"
-- Step 5:
-- we are behaving nicely and clean everything up before we leave
deinitDNode
