Link to the DIT Home Page

DIT Kevin Street, School of Computing
Ciarán O'Leary

  Home -> Teaching -> DT249-4 Distributed Systems -> Assignment
 

News

Date Notice
30th October 2008 This version of the code includes a timestamp on every message, such that all messages sent now that the following syntax:

sender:time:message

The only changes in the code are on lines 222 to 227 and 256 to 266.

 

23rd October 2008 A sample submission document is given here. You don't need to follow this exactly, but it may give you an idea of what is required.

 

22nd September 2008 If you are having difficulty with getting an IP address you may want to try the following:
  • At the command prompt, run the command ipv6 install
  • In your program (at the command prompt), use the IPv6 multicast address FF02::2 instead of the IPv4 address I had given

 

22nd September 2008 I will put news items here if bugs are discovered in the code, or if new versions of the code are made available.

Description

You are required to implement a concurrent versioning system for a distributed whiteboard.

The whiteboard application allows multiple users create a document by concurrently editing the text in multiple locations.

Your task is to manage the interaction between the various instances, so that updates are not lost.

You can implement as many different approaches as you'd like, but all must be correctly documented and analysed. You should use the PMI method for evaluating each of your proposed designs. Only documented approaches will be marked.

I have provided you with code for the Whiteboard, most of which should not be edited. You should only need to edit the following methods:

  • public void aNewMessageHasBeenReceived(String message)
  • public void userHasClickedOnCopy()
  • public void userHasClickedOnSend()
  • public void userHasTypedSomething(String lastCharacterTyped)
  • public void userHasClickedOnTakeTokenButton()
  • public void userHasClickedOnSpareButton()
  • public void timerExpired()

Note that the code has a single timer implemented. You can start the timer by calling the startTimer() method. Whatever code you have in the timerExpired() method will be called when the timer expires. Note that there is only one timer so once you start a new timer, any previously running timers cease to be effective.

In order to use the code, download it first into a folder named DS_ASSIGN.

To compile, go to the folder and type:

:/> javac -classpath . Whiteboard.java

You can then start many more DOS windows by typing

:/> start

In each DOS window, start the Whiteboard by typing:

:/> java -classpath . Whiteboard Ciaran 228.1.2.3 2000

The first argument is the username - put your own name, or any name in here. Use different names for each instance.

The second argument is the class D multicast IP address - you can use any class D address - try to avoid using the one here as you may get a conflict with other users.

The third argument is the port number.

This will give you a screen such as this one for each instance.

You can then type the document contents into the screen, as shown:

Then when you click Send the document will be sent to all members of the group, except the sender - consider the situation below where Ruth and Jack receive the document from Ciaran because they are both also members of the group.

The other members receive it into the inbox, as shown.

 

The other members can then copy the message into the main box by clicking Copy.

The main box on the left is editable, the inbox on the right is not - incoming messages are simply displayed there.

Your task is to change the code so that if both participants are updating the document at the same time, one will not overwrite the other - i.e. how can we get a global state from the distributed state of the message.

Note, this is not an instant messenger system - our goal is to develop one single document. Consider the example of two journalists concurrently writing a story (such as the one above about the World Cup), and sending each other updates.

Note also that as members send instances of the document, their name is broadcast to the group and displayed in the name list on the right hand side of the screen. Also, if a user clicks on the TakeToken button, then all members of the group are informed that that user has a (logical) token. This may form the basis of your approach to the concurrent document update problem.

You must accompany your submission with a document describing your architecture and design. You should explain your approach and compare and contrast your design with possible alternative designs.

Assessment Criteria

If you fail to submit both parts of your assignment you will not be marked. If you submit either part of your assignment late, you will be penalised an absolute mark of 10% for every week (or part thereof) that you are late (constrained by a lower bound of 0%).

Your assessment criteria are given in the table below. You will be awarded marks under each of the headings shown. A grade of A is excellent, B is very good, C is average / poor and D is a fail. Whenever it can be proven that your work is not your own you will be given a mark of 0.

  A B C D
Design 40% Excellent and novel design - consideration of all factors. Good design but some room for improvement - failed to consider some factors. Ignored more than one important factor or use case. Little evidence of effort.
Implemen-tation 30% Fully functional. Satisfies all the requirements. Fails to satisfy some aspects of the requirements, but a very good effort made. A good effort made to implement the program, but clearly does not work correctly. Little evidence of effort.
General Coding 15% Excellent coding style and commenting. Good coding but some small problems with style, or commenting. Poor coding, difficult to follow, absence of comments etc. Very poor code - certain parts fail to compile.
Documentation 15% Clear, concise, well written documentation that explains both the design and the issues encountered. Reasonably good but either lacks clarity of does not deal in sufficient detail with either the design or the issues encountered. Poor documentation that does not explain the design or the issues. Very poor or missing documentation.

Submission

You must supply documentation with your work. Your documentation must describe the following:

  1. The design of your program i.e. how you approached the task.
  2. Analysis of the degree to which your design satisfies the requirements - use the PMI method.
  3. A list of any issues you encountered in completing the assignment.
  4. A description of the implemented functionality, and what you would do if you had more time, and how you would do it.

A sample document is given here. You don't need to follow this exactly, but it may give you an idea of what is required.

All code must be correctly commented as part of the documentation process.

Your documentation MUST contain the following:

  • Your name.
  • My name i.e. Ciarán O'Leary
  • The subject title i.e. Distributed Systems
  • The date e.g. 3rd December 2008
  • The following declaration: "I declare that this work, which is submitted as part of my coursework, is entirely my own, except where clearly and explicitly stated."
  • Your handwritten signature.

If your documentation does not include all these details, it will not be marked, and you will be considered as having failed to submit the assessment.

You must give this to me in hardcopy at the lecture on 3rd December 2008.

Your solution must be e-mailed to me by 17:30 on 3rd December 2008. I will confirm all collections, so if you do not receive a confirmation, you will not be considered to have submitted your assignment.

 

Hit Counter  [Home][School of Computing][Dublin Institute of Technology]