Lab 1: Construct a bulletin board system using Ensemble

Purpose

Through working on this project, students would be familiar with the fundamental ideas and protocols that are discussed in the course. The task is to create a bulletin board system on the top of an existing distributed system infrastructure called Ensemble. The bulletin board supports posting and reading.

System requirements

Try to make ensemble provide you with as much as possible before implementing things on your own.

The application will act as both a bulletin board server and a client. Each client is a peer in the peer-to-peer board system.

The service is be able to stand the loss of any peer (regardless of if it leaves or crashes).
If the state in which only one peer holds the data is reached, this state is reported to the user of that peer.
Even a single peer can use the BBS normally (you can assume that a new client gets a new view immediately if there are others in the group).
You don't need to care about partitioning of the network
Include your group number (that you get in Fire) in the group name your client uses to avoid conflicts with other groups.

The messages of the bulletin board:

Messages sent by a client are showed by the sender client as well.
The system keeps the bulletin board items in memory as long as there is a peer in the system.
The client supports lising of all messages in the system.
Messages have message identifiers, sender names, dates and subjects.
You don't need to implement the actual text part of the messages, but you are encouraged to do so to.
For a node that has fully joined the BBS, all newly arriving messages delivered by ensemble to the client are immediately displayed.
For a node that is joining, the older messages of the BBS that you need to transfer during join needs to be displayed before any newly arriving messages.
There is a mechanism in the application for replying to messages.

The subject of a reply should have the subject of the message replied to prepended by "Re: " unless the referent (the message that is replied to) is already a reply .
A reply should always appears after its referent:
- Not necessarily directly after, but guaranteed to not be before the referent.
- Think about this one. There is a really easy solution to this one.
- Different clients does not necessarily need to show all messages in the same order as long as the above requirements are met.

Joining of new peers:

A joining client should show all the messages of the system just like any other client (first showing the old ones gotten at the joining procedure, after that messages arriving).
Make sure that the referent-reply guarantees holds even for the order presented by joining clients (even if messages and/or replies are being sent while the client joins).

Documentation and examples

The Ensemble tutorial and reference manual are good sources of information together with the lecture slides on Ensemble and the first lab: ppt, pdf.

Students are recommended to look at this Talk application written in java for an example of a client.

How to run and compile

To run an ensemble client, the ensembled server needs to be running on the current computer. The client are usually running on the remoteX.student.chalmers.se machines (X in {1,2,3,4,5}). If you are running on another machine that does not have the ensembled server running start it by executing /chalmers/groups/cse-ds2/ensemble/ensembled

You need to set the environmental variable CLASSPATH to /chalmers/groups/cse-ds2/javapackages:. to compile and run java programs that use ensemble. You also need to set the environmental variable ENS_CONFIG_FILE to /chalmers/groups/cse-ds2/ensemble/ensembled.conf

In bash you can do these two by executing:
export CLASSPATH="/chalmers/groups/cse-ds2/javapackages:."
export ENS_CONFIG_FILE="/chalmers/groups/cse-ds2/ensemble/ensembled.conf"

Lab groups

You are supposed to do this in groups of two.

Submission

Deadline: 7th of February 2011

The labs will be reported using the Fire system. It can be found at: https://fire.cs.chalmers.se:8039/cgi/Fire-ds2. Make sure that both members of the group are added before submitting.

You are supposed to submit one tar.gz archive (usage: tar cvfz somename.tar.gz file1 file2 ...) that contains the following:

A working program that satisfies the aforementioned requirements, with source code.

The source code must be clear and well structured.
The source code must compilable from a terminal (see below)
Do not change parts of ensemble.
Do not submit parts of ensemble, caches from editors or anything like that.
Do not submit things in an archive within the tar.gz archive. This includes jar files.

A report that shows:

How to compile the program from a terminal
How to run the program
How the program keeps data consistent among peers
How the program makes sure that arriving messages are not shown before old ones at the joining procedure
What kind or order the program guarantees and why this makes replies come after their parents