Reference no: EM13100300
Project code in visual Studio Console application and class library
The PADI project aims at implementing a simpli ed distributed software transactional system.
1 Introduction
The goal of this project is to design and implement PADI-DSTM, a distributed system to manage data objects that reside in memory and can be shared by transactional programs that execute in di erent machines. This will be a simpli ed version of a Distributed Software Transactional Memory System[5, 2, 3].
To simplify the work, and make the project doable in the timeframe available for the project, the applications will only share a particular type of object, of type PadInt, that stores an integer that can only be accessed b y well de ned read and write methods.
The work will start b y writing a paper describing the solution . and only then should the system be developed sequentially in phases .
2 Architecture
The architecture of the PADI-DSTM includes a centralised master, a variable number of servers (that store data objects), and a variable number of clients that concurrently access one or more data objects transactionally. The clients run applications that are linked to the PADI-DSTM library and that access shared objects stored at the servers. Each server stores a set of shared objects. The servers' interfaces are identi ed b y a URL in the format "tcp : == < ip address >:< port > =Server". The students are free to implement the library as they wish; in particular, the implementation of the library methods may communicate with the centralised master if needed. Still, for scalability, the implementation should strive to use decentralised solutions as much as possible, such that the centralised master does not become a bottleneck.
The students may assume that the centralised master is always running and that it does not crash. Students may also assume that clients do not crash in the middle of the execution although they will terminate when the application reaches its end. Also, when testing and debugging the system they may assume that the master is launched before the servers. If a server does not nd the master active it is not required to provide service.
3 The PADI-DSTM Library
The library to be created b y the students is linked to each application that uses PADI-DSTM.
The library exports a set of methods that provide access to PADI-DSTM:
bool Init(): this method is called only once by the application and initializes the PADI-DSTM library.
bool TxBegin(): this method starts a new transaction and returns a boolean value in-dicating whether the operation succeeded. This method may throw a TxException. A TxException should include a string indicating what caused the exception.
bool TxCommit(): this method attempts to commit the current transaction and returns a boolean value indicating whether the operation succeded. This method may throw a TxException.
bool TxAbort(): this method aborts the current transaction and returns a boolean value indicating whether the operation succeeded. This method may throw a TxException.
bool Status(): this method makes all nodes in the system dump to their output their current state.
bool Fail(string URL): this method makes the server at the URL stop responding to external calls except for a Recover call (see below).
bool Freeze(string URL): this method makes the server at URL stop responding to external calls but it maintains all calls for later reply, as if the communication to that server were only delayed. A server in freeze mode responds immediately only to a Recover call (see below), which triggers the execution of the backlog of operations accumulated since the Freeze call.
bool Recover(string URL): this method makes the server at URL recover from a previous Fail or Freeze call.
The library also mediates the interaction with the shared distributed objects. Basically, it o ers primitives to create a shared object and to obtain a reference to a shared object that was previously created. Each object is uniquely identi ed by an integer id. For simplicity, we assume that all shared objects are of type PadInt. The methods exported by the library regarding the local object manager are the following:
PadInt CreatePadInt (int uid): this method creates a new shared object with the given uid. Returns null if the object already exists.
PadInt AccessPadInt (int uid): this method returns a reference to a shared object with the given uid. Returns null if the object does not exist already.
Each shared object can only be accessed in the context of a valid transaction. For this purpose, an object of type PadInt exports two di erent methods:
int Read(): reads the object in the context of the current transaction. Returns the value of the object. This method may throw a TxException.
void Write(int value): writes the object in the context of the current transaction. This method may throw a TxException.
A transaction may abort as a result of a read or write operation. In this case a TxException exception is triggered, whose internal contents (e.g. a string) should help in describing the cause of the transaction abort. Additionally, TxException exception should be triggered with informative string if somehow the input is considered invalid.
4 Consistency
The system should provide sequential consistency. The students should refer to the classes and to the bibliography of the course for the details of this consistency model[1, 4].
5 Fault Tolerance (optional)
The students must rst implement a version of the system that is not required to tolerate faults. If, and only if, this version is operating correctly should the students consider implementing a fault-tolerant version of the system. The fault-tolerant version is only required to tolerate the failure of a single server node. Clients are assumed never to fail.
In the fault-tolerant version of the system each data object must be stored in at least two di erent server nodes. Also a server node should be able to crash without blocking or compromising the consistency of the data, i.e., if a server node crashes during the execution of a transaction the atomicity must be preserved: either the transaction commits before the crash and the updates will be visible to the other servers, or the server node fails before the transaction commits and none of the updates of the interrupted transaction become visible.
Furthermore, whenever a server node commits a transaction, the updates must have been replicated (and ready to commit) at least in another server node, such that the results of the transaction survive a potential failure.
Attachment:- Project Visual Studio.zip