added docs for architecture
This commit is contained in:
12
Docs/ClientArchitecture.md
Normal file
12
Docs/ClientArchitecture.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# Client Module Architecture
|
||||
|
||||
The Client Module interacts with the P2P module and Server Module. It is responsible for
|
||||
interacting with the server module and appropriately updating the IP table on the client side. It
|
||||
connects to the server using the server's REST Apis. It is also the primary decision maker on how
|
||||
the IP table is updated is on the client side. This is because each user can have requirements like
|
||||
how many number of hops they would want to do to update their IP table. Hops is the number of
|
||||
times the client is going to download the IP table from different servers ,once it gets the IP tables
|
||||
from the previous servers.
|
||||
|
||||

|
||||

|
||||
14
Docs/DesignArchtectureIntro.md
Normal file
14
Docs/DesignArchtectureIntro.md
Normal file
@@ -0,0 +1,14 @@
|
||||
# Design Architecture
|
||||
|
||||
This chapter focuses on architecture of the dissertation. The objective would be to have a good
|
||||
understanding on the purpose of each module and how they interact with each other. The design
|
||||
architecture was inspired and based on the linux kernel design. The project is segmented into
|
||||
various modules. Each module is responsible for certain tasks in the project. The modules are
|
||||
highly dependent on each other hence the entire codebase can be considered as a huge monolithic
|
||||
chuck which acts as its own library. The following sub topics below talk about the main modules
|
||||
and how they function with appropriate diagrams.
|
||||
|
||||
### 1. [Client Module](ClientArchitecture.md)
|
||||
### 2. [P2P Module](P2PArchitecture.md)
|
||||
### 3. [Server Module](ServerArchitecture.md)
|
||||
|
||||
@@ -6,6 +6,7 @@ Over here we will cover the basic steps to get the server and client side runnin
|
||||
The entire the implementation of this project is done using Go lang.
|
||||
Thus, we need go lang to compile to code to a binary file.
|
||||
[Instructions to install Go lang](https://golang.org/doc/install)
|
||||
|
||||
### Install Docker
|
||||
In this project the choice of virtualization is Docker due to it's wide usage
|
||||
in the developer community. In the server module we use the Docker Go API to create and
|
||||
@@ -17,11 +18,11 @@ interact with the containers.
|
||||
Do ensure that the docker command does not need sudo to run
|
||||
````
|
||||
|
||||
### Build Project
|
||||
### Build Project and install project
|
||||
To set up the internal dependencies and build the entire go code
|
||||
into a single binary
|
||||
```
|
||||
make build
|
||||
make install
|
||||
```
|
||||
|
||||
### Test if binary works
|
||||
@@ -43,12 +44,19 @@ COMMANDS:
|
||||
help, h Shows a list of commands or help for one command
|
||||
|
||||
GLOBAL OPTIONS:
|
||||
--Mode value Specifies mode of running (default: "client") [$P2P_MODE]
|
||||
--ListServers List servers which can render tasks (default: false) [$LIST_SERVERS]
|
||||
--CreateVM value Creates Docker container on the selected server [$CREATE_VM]
|
||||
--FilePath Testing for absolute path (default: false)
|
||||
--help, -h show help (default: false)
|
||||
--version, -v print the version (default: false)
|
||||
--Mode value Specifies mode of running (default: "client") [$P2P_MODE]
|
||||
--UpdateServerList Update List of Server available based on servers iptables (default: false) [$UPDATE_SERVER_LIST]
|
||||
--ListServers List servers which can render tasks (default: false) [$LIST_SERVERS]
|
||||
--CreateVM value Creates Docker container on the selected server [$CREATE_VM]
|
||||
--RemoveVM value Stop and Remove Docker container [$REMOVE_VM]
|
||||
--ID value Docker Container ID [$ID]
|
||||
--Ports value Number of ports to open for the Docker Container [$NUM_PORTS]
|
||||
--GPU Create Docker Containers to access GPU (default: false) [$USE_GPU]
|
||||
--Specs value Specs of the server node [$SPECS]
|
||||
--SetDefaultConfig Sets a default configuration file (default: false) [$SET_DEFAULT_CONFIG]
|
||||
--help, -h show help (default: false)
|
||||
--version, -v print the version (default: false)
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
36
Docs/Introduction.md
Normal file
36
Docs/Introduction.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Chapter 1: Introduction
|
||||
|
||||
## Abstract
|
||||
This project focuses on creating a framework on running heavy tasks that a regular computer
|
||||
cannot run easily such as graphically demanding video games, rendering 3D animations , protein
|
||||
folding simulations. In this project the major focus will not be on the financial incentive part. A peer
|
||||
to peer network will be created to help run tasks decentrally, increasing bandwidth for running
|
||||
tasks. To ensure the tasks in the peer to peer network do not corrupt the server 0S (Operating
|
||||
System), they will be executed in a virtual environment in the server.
|
||||
|
||||
The main aim of this project was to create a custom peer to peer network. The user acting as the
|
||||
client has total flexibility on how to batch the tasks and the user acting as the server has complete
|
||||
flexibility on tracking the container's usages and killing the containers at any point of time.
|
||||
|
||||
## Motivation
|
||||
Many of the users rely on our PC / Laptop or servers that belong to a server farm to run heavy
|
||||
tasks and with the demand of high creativity requires higher computing power. Buying a powerful
|
||||
computer every few years to run a bunch of heavy tasks which are not executed as frequently to
|
||||
reap the benefits can be inefficient utilization of hardware. On the other end, renting servers to
|
||||
run these heavy tasks can be really useful. Ethically speaking this is leading to monopolisation of
|
||||
computing power similar to what is happening in the web server area. By using peer to peer
|
||||
principles it is possible to remove the monopolisation factor and increase the bandwidth between
|
||||
the client and server.
|
||||
|
||||
## Aim
|
||||
This project aims to create a peer to peer (p2p) network, where a user can use the p2p network to
|
||||
act as a client (i.e sending tasks) or the server (i.e executing the tasks). A prototype application will
|
||||
be developed, which comes bundled with a p2p module and possible to execute docker containers
|
||||
or virtual environments across selected nodes.
|
||||
|
||||
## Objectives
|
||||
- Background review on peer to peer network, virtual environments, decentralized
|
||||
rendering tools and tools to batch any sort of tasks.
|
||||
- Creating p2p network
|
||||
- Server to create a containerised environment
|
||||
- The client node to run tasks on Server containerised node
|
||||
11
Docs/P2PArchitecture.md
Normal file
11
Docs/P2PArchitecture.md
Normal file
@@ -0,0 +1,11 @@
|
||||
# P2P Module Architecture
|
||||
|
||||
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.
|
||||
|
||||

|
||||
@@ -1,8 +1,16 @@
|
||||
# Table of contents
|
||||
1. [Installation](Installation.md)
|
||||
2. [Problems](Problems.md)
|
||||
3. [Design Architecture](DesignArchtectureIntro.md)
|
||||
1. [Client Module](Client.md)
|
||||
2. [P2P Module](P2P.md)
|
||||
3. [Server Module](#NotImplemented)
|
||||
|
||||
# Table of contents
|
||||
1. [Introduction](Introduction.md)
|
||||
2. [Installation](Installation.md)
|
||||
3. [Design Architecture](DesignArchtectureIntro.md)
|
||||
1. [Client Module](ClientArchitecture.md)
|
||||
2. [P2P Module](P2PArchitecture.md)
|
||||
3. [Server Module](ServerArchitecture.md)
|
||||
4. [Implementation](Implementation.md)
|
||||
1. [Client Module](ClientImplementation.md)
|
||||
2. [P2P Module](P2PImplementation.md)
|
||||
3. [Server Module](ServerImplementation.md)
|
||||
4. [Config Module](ConfigImplementation.md)
|
||||
5. [Cli Module](CliImplementation.md)
|
||||
5. [Problems](Problems.md)
|
||||
|
||||
|
||||
8
Docs/ServerArchitecture.md
Normal file
8
Docs/ServerArchitecture.md
Normal file
@@ -0,0 +1,8 @@
|
||||
# Server Module Architecture
|
||||
The server module takes care of setting and removing the virtualization environment (i.e
|
||||
containers) for accessing and doing the appropriate computation. It also interacts with the peer to
|
||||
peer module to update the IP table on the server side. The server module
|
||||
accesses information regarding CPU and GPU specifications of the machine running the server
|
||||
module. To do Speed tests the server has routes which allows it to upload and download a 50mb.
|
||||
|
||||

|
||||
BIN
Docs/images/NumOfHops.png
Normal file
BIN
Docs/images/NumOfHops.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
BIN
Docs/images/clientmoduleArch.png
Normal file
BIN
Docs/images/clientmoduleArch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 28 KiB |
BIN
Docs/images/p2pmoduleArch.png
Normal file
BIN
Docs/images/p2pmoduleArch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 27 KiB |
BIN
Docs/images/servermoduleArch.png
Normal file
BIN
Docs/images/servermoduleArch.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 32 KiB |
Reference in New Issue
Block a user