converted entire docs to org mode

Docs/DocsDeprecated/P2PImplementation.org

@@ -0,0 +1,111 @@
+* P2P Module Implementation
+:PROPERTIES:
+:CUSTOM_ID: p2p-module-implementation
+:END:
+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.
+
+#+caption: UML diagram of P2P module
+[[file: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. 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.
+
+** IP Table
+:PROPERTIES:
+:CUSTOM_ID: ip-table
+:END:
+The ip table file is a json as the format with a list of servers ip
+addresses, latencies, downloads and uploads speeds. The functions
+implemented include read file, write file and remove duplicate IP
+addresses. The remove duplicate IP address function exists because
+sometimes servers IP tables can have the same ip addresses as what the
+client has. The path of the IP table json file is received from the
+configuration module.
+
+#+begin_src json
+{
+  "ip_address": [
+    {
+      "ipv4": "<ipv4 address>",
+      "latency": "<latency>",
+      "download": "<download>",
+      "upload": "<upload>"
+      "port no": "<server port no>",
+    }
+  ]
+}
+#+end_src
+
+*** Latency
+:PROPERTIES:
+:CUSTOM_ID: latency
+:END:
+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
+:PROPERTIES:
+:CUSTOM_ID: nat-traversal
+:END:
+P2PRC currently supports TURN for NAT traversal.
+
+** TURN
+:PROPERTIES:
+:CUSTOM_ID: turn
+:END:
+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
+:PROPERTIES:
+:CUSTOM_ID: client-mode
+:END:
+- Call =/FRPPort=
+
+#+begin_example
+http://<turn server ip>:<server port no>/FRPport
+#+end_example
+
+- Call the TURN server in the following manner. The following is a
+  sample code snippet below.
+
+#+begin_src 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
+   }
+}
+#+end_src