@hackage Holumbus-Distribution0.1.1

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