diff --git a/Docs/ClientImplementation.md b/Docs/ClientImplementation.md
new file mode 100644
index 0000000..af15b53
--- /dev/null
+++ b/Docs/ClientImplementation.md
@@ -0,0 +1,34 @@
+# Client Module Implementation
+
+This section focuses in depth on how the client module works. To understand the architecture of
+the client module refer to section 4.2. The client module is incharge of communicating with
+different servers based on the IP addresses provided to the user. The IP addresses are derived
+from peer to peer modules. Section 5.6 talks more in depth regarding the peer to peer module.
+The objective here is how the client module interacts with peer to peer module and server module.
+
+### Updating the IP table
+The client module calls the peer to peer module to get the local IP table initially, Based on the
+servers IP addresses available it calls the speedtest function from the peer to peer module to
+update IP addresses with information such as latencies, download and upload speeds. Once this is
+done the client module does a Rest Api call to the server to download its IP Table. Once the hops are 
+done it writes the appropriate results to the Local IP table. Once this is done it prints out the results. 
+To derive parameters such as current the public IP address the url “http://ip-api.com/json/” was called. 
+This url returns json response of the current public IP address. This feature will be used in the future 
+to ensure that the user's current IP address will not be used for a speed test. 
+Clients IP table is updated to the server using a form of type multipart.
+
+### Reading server specifications
+The client module calls the route /server_specs and reads the json response. If the json response
+was successful then it just calls the pretty print function which just prints the json output in the
+terminal.
+
+### Client creating and removing container
+The client module uses the servers Rest apis to create and delete containers. To create a container
+the client requires 3 parameters being the server ip address, the number of the ports the user
+wants to open and if the user wants it connected to the GPU or not. The 3 parameters are sent as a
+GET request to the server and the server responds with a json file which has information such as
+the container ID, ports open , SSH username, SSH password, VNC username and VNC password.
+At the moment the username and password are hard coded from the server side for both SSH and
+VNC.
+To remove a container the client module only requires the server IP address and the container ID.
+The client prints the response from the server Rest api.
\ No newline at end of file
diff --git a/Docs/Implementation.md b/Docs/Implementation.md
new file mode 100644
index 0000000..44d822d
--- /dev/null
+++ b/Docs/Implementation.md
@@ -0,0 +1,18 @@
+# Implementation 
+This chapter describes how the project was built. It talks in depth of the implementation
+performed to give a better understanding of the project.
+
+## Programming langauge used
+The programming language used for this project was Golang. The reason Go lang was chosen was
+because it is a compiled language.
+The entire codebase is just a single binary file. When
+distributing to other linux distributing the only requirement would be the binary file to run the
+code. It is easy to write independant modules and be monolithic at the sametime using Go. Using
+Go.mod makes it very easy to handle external libraries and modularise code. The go.mod name for
+the project is git.sr.ht/~akilan1999/p2p-rendering-computation.
+
+## [Cli Module](ClientImplementation.md)
+## [Config Module](ConfigImplementation.md)
+## [Server Module](ServerImplementation.md)
+## [Client Module](ClientImplementation.md)
+## [P2P Module](P2PImplementation.md)
\ No newline at end of file