suparngp / aosproject2 Goto Github PK

Create a topology terminal to update/alter system topology in both clients and server

Enhance logging, Comment out the debugging logging.

To simulate the cuts in the graph, a blocking list needs to be implemented. Before sending a message to any node, its presence in the blocking list will be checked.

All the servers must be able to discover each other automatically. Each server must keep polling across the list of possible server addresses/portnumbers until it is connected to the required number of servers. After doing so, it will send a DISCOVERY_COMPLETE message to the other servers to inform that it is ready to server the client requests.

All the message sending should be done via a common method so that the blocking list can be added at that point. This method will act as sort of a gateway. Related to #13

In server, most of the message passing is done inline. All such calls must be replaced by a method, which sends the messages and returns a socket so that, blocking list can be added to this single point of communication. See #13

Clean up unnecessary code from the old version of the protocol.

APIs to create, delete update and read objects are missing.

This covers issue #7 as well.

Complete the missing documentation

A client performs following steps in order to create an object.

1. Generates an object id.
2. Finds out the server ids based on the hashing function.
3. Send a SEEK_CREATE_PERMISSION to each of the servers.
4. If it is not able to send the request to at least two servers, throw error.
5. If the request was successfully sent, wait for the server's reply.

On the server side:

1. If the server can allow the permission to create the object (it is not busy, which is not practically possible), it replies with the GRANT_CREATE_PERMISSION message.
2. Else it replies with FAILED_CREATE_PERMISSION

On the client side, after receiving the replies from all the servers,

1. If there are less than 2 GRANT messages, error is returned.
2. Else for each server :
3. If the reply is GRANT, the client serializes the account object.
4. Next it creates the wrapper object with message type, CREATE_OBJ_REQ and sends to the server.
5. else if the reply is FAILED, client skips this server.

The initial protocol is not perfect. It fails during the concurrent writes.

The new protocol is based on the Google's File System

Add a Data Access API to access the objects.

Initially we planned to use the OpenCSV to store and parse the data. However, OpenCSV doesn't support updates on the files. The only way is to load all the contents into the memory, perform updates, clear the file and write them back to the file.

To achieve this, we can use GSON library since we are already using it to parse the Messages. This implementation is based on the GSON library, a slight change in the plan.

A client performs following steps in order to create an object.

1. Generates an object id.
2. Finds out the server ids based on the hashing function.
3. Send a SEEK_CREATE_PERMISSION to each of the servers.
4. If it is not able to send the request to at least two servers, throw error.
5. If the request was successfully sent, wait for the server's reply.

On the server side:

1. If the server can allow the permission to create the object (it is not busy, which is not practically possible), it replies with the GRANT_CREATE_PERMISSION message.
2. Else it replies with FAILED_CREATE_PERMISSION

On the client side, after receiving the replies from all the servers,

1. If there are less than 2 GRANT messages, error is returned.
2. Else for each server :
3. If the reply is GRANT, the client serializes the account object.
4. Next it creates the wrapper object with message type, CREATE_OBJ_REQ and sends to the server.
5. else if the reply is FAILED, client skips this server.

In this issue, we target the OBJ create API on the client.

Sub-issue of #3

For the inter server communication, following requirements must be met.

1. All the servers should listen to other servers on a port. The port must be open for other servers to accept the connections.
2. The connections should be created on a need to know basis.
3. Each server tries to connect to other servers.
4. All the servers discover each other before the system is operational.
5. Once everyone has established the connections, all of them should send a message to each other that they have discovered others.
6. When each node receives the discovery completed message, it becomes fully functional for the clients.

Messages
SERVER_INTRO: s1 introduces itself to s2.
SERVER_INTRO_REPLY: s2 replies to SERVER_INTRO_REPLY
DISCOVERY_COMPLETE: server broadcasts this message to every one else that it has successfully learnt about all the other servers.

As a last step, verify the design report from #16 and assemble all the test results from #17 to create the final test report.

Periodic heartbeat message need to be exchanged between all the servers to keep a track of which servers are available.

Each Server will have an open socket to listen to client requests. This channel is different from the server-server communication channel. The rest of the flow will remain the same.

Each client will try to connect to the server via this port. Server, on accepting the connection will start a ClientReqHandler thread to handle the request and begin listening for the next connection.

Create fresh design report based on the new protocol. It is simpler than the original protocol. Create diagrams in visio etc.

Create a basic GUI for CRUD operations. The interface doesn't need to be wired up with the remaining code. The sole purpose is to finish the design and create mock APIs.

The connection Handler API is currently Missing. It should handle all the incoming connections on a per handle basis.

System needs to work in various different scenarios. Prepare such testable scenarios, document them with diagrams, test the code and gather results.