program design, a brief description of how your system works
and your message design. Also discuss any design tradeoffs considered and made. Describe
possible improvements and extensions to your program and indicate how you could realise them.
If your program does not work under any particular circumstances please report this here. Also
indicate any segments of code that you have borrowed from the Web or other books.



Design/Trade-offs.

For the first steps of the program, i used UDP as required for the delivery and receiving of ping messages between peers. I chose to perform this whole task within a single thread. I acheived this by implementing a 'delay' after each sending and receiving of messages. While this allowed it to function within a single thread, there was a clear trade off in effeciency and response times for response messages. Nonetheless, it is still able to constantly monitor whether the peers were alive periodically.

Step 3 required TCP to transport the messages and because it requires a set up connection, i chose to implement it using multithreads to allow each peer to simulatenously send and listen for both responses and standard input commands. I chose to implement an "ExecutorService" which essensially ran a private class in another thread to handle the messages and response separate from the server listening for connections to accept. I got this idea from stackOverflow, referenced below.


========================================================================================================
//Aug 24 '13 at 11:59 - Shaggy
//on stackoverflow "http://stackoverflow.com/questions/18418326/get-data-from-client-in-server-socket-java"
public class ServerListener {

    public static void main(String[] args) {
        new ServerListener().startServer();
    }

    public void startServer() {
        final ExecutorService clientProcessingPool = Executors
                .newFixedThreadPool(10);

        Runnable serverTask = new Runnable() {
            @Override
            public void run() {
                try {
                    ServerSocket serverSocket = new ServerSocket(8000);
                    System.out.println("Waiting for clients to connect...");
                    while (true) {
                        Socket clientSocket = serverSocket.accept();
                        clientProcessingPool
                                .submit(new ClientTask(clientSocket));
                    }
                } catch (IOException e) {
                    System.err.println("Unable to process client request");
                    e.printStackTrace();
                }
            }
        };
        Thread serverThread = new Thread(serverTask);
        serverThread.start();
    }

    private class ClientTask implements Runnable {
        private final Socket clientSocket;

        private ClientTask(Socket clientSocket) {
            this.clientSocket = clientSocket;
        }

========================================================================================================



For step 4, i found the predecessor peers by looking at the messages in the ping messages, since they contained the ID of the peer is came from. I ordered the peer predecessors using several if cases to deal with corner cases such as peer 15(first predecessor) and peer 1 (second predecessor) for peer 3.


Improvements/extension
My program could be improved particualrly in step 2 where the UDP ping messages and response messages could be more responsive. While at the moment, one request and one response are sent at the same period of time followed by a delay to separate the next round of request/response. This could be acheived by implementing a second thread in which the program will listen for UDP packets to receive. This will mean the response messages will be send directly after receiving a request without delay. This will also allow a more controlled/delayed timing for when to send request, without implying other peers are dead.


Notes on running
The program initializes in about 1 minute, it will start pinging straight away and begin determining it's predecessors.
It will find initial predecessors although they may be incorrect at first, but it will self correct itself to finally determine it's correct 'first predecessor' and 'second predecessor'. after which it is ready to accept 'request commands'.

The ping messages come in pairs of 1 request and 1 response. The delayed response is due to the delay function as part of the implementation so sometimes after a request has been sent, the corresponding response may not arrive until approximately 30 seconds later.

When testing step 3, while inputing the commands into standard input, a ping message may interrupt the standard input line. However, you may continue to finish the initial command as if it were not interrupted and the command should still work.

The program still has not yet fully implemented 'quit' yet although initial messages for quit have been implemented, the actual reallocation of predecessors and sucessors have not been implemneted.