Update P2PImplementation.md

Docs/P2PImplementation.md

@@ -1,10 +1,20 @@
 # P2P Module Implementation 
+
+The P2P module (i.e Peer to Peer Module) is responsible for storing the IP table and interacting
+with the IP table. In the following implementation of the P2P module ,the IP table stores
+information about servers available in the network. The other functionality the P2P module takes
+care of is doing the appropriate speed tests to the servers in the IP table. This is for informing the
+users about nodes which are close by and nodes which have quicker uploads and downloads
+speeds. The module is responsible to ensure that there are no duplicate server IPs in the IP table
+and to remove all server IPs which are not pingable.
+
+![UML diagram of P2P module](images/p2pmoduleArch.png)
+
 The peer to peer implementation was built from scratch. This is because other peer to peer
 libraries were on the implementation of the Distributed hash table. At the current moment all
 those heavy features are not needed because the objective is to search and list all possible servers
 available. The limitation being that to be a part of the network the user has to know at least 1
-server and has to have DMZ enabled from the router if the user wants to act as a server out of the
-users local network. The advantage of building from scratch makes the module super light and
+server. The advantage of building from scratch makes the module super light and
 possibility for custom functions and structs. The sub topics below will mention the
 implementations of each functionality in depth.
 
@@ -32,3 +42,44 @@ path of the IP table json file is received from the configuration module.
 ### Latency
 The latency is measured in milliseconds. The route /server_info is called from the
 server and time it takes to provide a json response is recorded.
+
+## NAT Traversal
+P2PRC currently supports TURN for NAT traversal. 
+
+
+
+## TURN 
+The current TURN implementation used is FRP. The TURN server is also required when 
+a P2PRC node is acting as a Server. The TURN server is determined based on the Node 
+with the least amount of latency based on the Nodes available on the IPTable. 
+Once a TURN server is determined there are 2 actions performed. The first one is 
+```/FRPPort``` to the TURN server to receive a port which is used to generate the external 
+port from the TURN server. The flow below describes the workflow.
+
+### Client mode
+- Call ```/FRPPort```
+```
+http://<turn server ip>:<server port no>/FRPport
+```
+- Call the TURN server in the following manner. The following is a sample code snippet below. 
+```go
+import (
+    "github.com/Akilan1999/p2p-rendering-computation/p2p/frp"
+)
+
+func main() {
+  serverPort, err := frp.GetFRPServerPort("http://" + <lowestLatencyIpAddress.Ipv4> + ":" + lowestLatencyIpAddress.ServerPort)
+   if err != nil {
+    return nil, err
+   }
+   // Create 1 second delay to allow FRP server to start
+   time.Sleep(1 * time.Second)
+   // Starts FRP as a client with
+   proxyPort, err := frp.StartFRPClientForServer(<lowestLatencyIpAddress.Ipv4>, serverPort, <the port you want to expose externally>)
+   if err != nil {
+     return nil, err
+   }
+}
+```
+
+