Lab 1: Construct a bulletin board system using Ensemble

Purpose

System requirements

• 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 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.
• A client that multicasts a message shall use the Cast function of an object of the ensemble Member class to directly send it ot all other clients.
• 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).
• A client that has got all the old messages of the board after joining the group is an initialized client. An initialized client shall immediately show a received cast message. Ordering guarantees for messages received by an initialized client should be taken care of by ensemble and not by your program.
• For uninitialized clients you need to make sure that received multicasts are not shown until after the client has been initialized and shown the old messages.

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

Submission

Deadline: 6th 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.

1. 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.
2. 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