idjaw / edunet

Having fun with networks!

EduNet

This application allows you to simulate different network operations in a simple plug-in manner.

The motivation with this project was to simply learn more about sockets, protocols, and making them all talk to one another.

The end result of this project is to be able to craft together any network entities and have them communicate as intended.

Simple Supported Use Case

There is a built-in simple supported use case called SimpleHTTPNode.

Bringing this up will start a TCP listener on localhost on port 9999 accepting valid HTTP requests. What will be sent back are valid HTTP responses.

Complex Use Cases

As it will be supported soon, the intent is by using the core architecture, we will be able to implement a router with basic features like:

• Routing table
• DHCP assignment
• Packet forwarding
• Network Access Translation (NAT)

Simple Example to put it all together

Installing

pip install edunet

Usage

Going back to the Simple use case, as is you can simply do something like:

Starting service

from edunet.core.applications.simple_http_application import SimpleHTTPApplication
from edunet.core.networking.handlers.simple_http_connection_handler import SimpleHTTPConnectionHandler
from edunet.core.networking.listeners.tcp_listener import TCPListener 

# create an HTTP application 
app = SimpleHTTPApplication()

# create a Connection Handler that takes an application
handler = SimpleHTTPConnectionHandler(app)

# A listener is needed to allow connections to come through
listener = TCPListener("127.0.0.1", 9999, handler)

listener.start()

Calling service

You can now communicate with it over HTTP by any means

curl

curl -X GET http://127.0.0.1:9999

python

import urllib.request
response = urllib.request.urlopen("http://localhost:9999")
print(response.read().decode("utf-8"))

edunet's Issues

Integrate Snyk

Objective

Integrate Snyk to run in the CI

Description

To help with dependency scanning and security, hook snyk in to the pipeline to get notified of any issues.

Acceptance Criteria

Snyk runs in the CI

Provide Skeleton Implementation

This is to help support the architectural layout of the Simple HTTP Server being used as the rudimentary component of the EduNet backbone. The goal of this task is to ensure that we have abstract interfaces to help support the expected structure.

As part of the first phase of delivery, the goal is to have:

• A TCP Listener
• A connection handler
• An application service
• A node representing a machine

From the above list, the idea is to determine a way at the software level to allow those to communicate together to facilitate adding functionality on top. The goal is to allow for a simple way to add functionality of each type. For example:

A TCP Listener should not care what connection handler is implemented, and a connection handler should not care what application is implemented. Wrapping it together, the node/machine should not care what listener it is taking. The glue between them is ultimately the core business logic, and the desired functionality will be "adapted". Ideally we want to follow a ports-and-adapter implementation.

This task is to provide a base set of abstract classes.

class Listener(ABC):
    # methods

class Handler(ABC):
    # methods

class Application(ABC):
    # methods

class Node(ABC):
    # methods

For this task, we simply want to introduce those base classes before providing implementation details around how they will communicate together.

Split out tagging and deploying for specific commit hook

Objective

Have the CI only perform a tag and deploy if pushed to do so through commit keyword

Description

We want to split how we deploy. Deployments should be explicit and in its own commit when bumping a version. The idea is this:

• Run version bumping (ideally locally automated) locally which should:
  • bump versions automatically wherever configured to automatically change
  • reformat/update changelog to specify changes under to-be-released version tag
• CI will never run tag and publish unless the commit only has the following as a message #deploys VERSION. Where VERSION will be the version that should match what has been updated already. You can confirm this value by comparing it to the output of poetry version -s. If they don't match, then reject the pipeline.

So, illustrating:

deploys 0.2.1

CI pipeline will have something in pseudo code like

if 0.2.1 != $(poetry version -s): exit 1

Acceptance Criteria

• CI on merge to master will tag and deploy to PyPi only on #deploys VERSION
• CI will never tag and deploy if #deploys VERSION is not the only message in the commit

Properly package EduNet

Objective

Allow EduNet to be properly built/packaged for PyPi distribution

Description

To wrap up the phase 1 milestone, the project should be able to be built and packaged properly using standard tooling

Acceptance Criteria

• Built using Poetry
• Can be uploaded to PyPi
• Can be installed and executed standalone
• Has a proper README

Implement TCPListener

Objective

Implement a listener that supports TCP.

Description

With #2 complete, the Listener can be implemented to now support a core TCP Listener that will behave as the basis for all TCP listening in EduNet.

The TCPListener should support accepting connections, dispatching them to a handler, starting the listener, and stopping the listener.

With respect to accepting connections, a valid test criteria is to ensure it can handle concurrent calls to ensure that it is managing sockets appropriately.

Acceptance Criteria

• Can respond with a simple OK to indicate successful communication
• Is thread safe by validating that a given request receives its corresponding response
• Can handle a heavier load through concurrency

Fix Windows in CI

Objective

Windows in the CI is currently failing

Description

Fix the Windows CI failing

Reproduce by simply adding windows-latest to the os matrix in the CI action yml file and push

Criteria of Success

Windows now runs successfully in the CI

Separate version bumping and tagging when merging to main

Objective

Separate version bumping and tagging when merging to main

Description

To avoid always having to create a release when merging, the tagging and uploading to pypi should be done outside of a merge to main. This task is to determine an acceptable solution and implement it.

It would be acceptable to simply have a trigger deploy job, but tests should always run prior.

Further down automating will be ideal. For now, manually setting the CHANGELOG and bumping the pyproject.toml is good enough. A separate commit with "bumps " would suffice.

The only hook we have is that the CI will specifically look for a commit message that strictly holds this message"

"bumps "

Acceptance Criteria

• CI no longer bumps and deploys when merging to master
• CI will bump when explicitly executed from CI

Implement Simple HTTP Application

Objective

Implement a SimpleHTTPApplication to handle simple valid HTTP requests

Description

With #2 complete, we can focus on implementing a SimpleHTTPApplication that will handle simple valid HTTP Requests. What this means is:

• The request must be a real valid HTTP request and must be validated as such
• The request coming from the ConnectionHandler ideally should be an object to be managed as such. This implies the validation can be done when crafting the object
• The response should be returned back as bytes since it is to be managed by the TCP Listener out to the client

Acceptance Criteria

• HTTP validator can validate HTTP requests
• SimpleHTTPApplication can craft a valid HTTP response as an object and bytes
• TCPListener can send a valid HTTP Request and receive a valid HTTP Response

Implement Connection Handler

Objective

Implement a Connection Handler that will be used by the TCP Listener to handle all socket connections coming through.

Description

With #2 complete, the ConnectionHandler can be implemented to handle socket data coming through. This handler for now merely acts as a dispatcher intended to the appropriate application to be appropriately handled to send back a response.

Acceptance Criteria

• TCPListener is able to take an implemented ConnectionHandler
• TCPListener dispatches to the ConnectionHandler
• ConnectionHandler "handles" the connection
• Response should now be coming from the Connection Handler as well to the TCPListener and then client

List out the basic design components required for the router

Objective

Have a list of basic components required for the router's functionality to help with the design and implementation

Description

To facilitate the design and implementation of the router for phase 2, document the components to have a list of requirements that have to be designed and implemented in to EduNet to support a router device.

Acceptance Criteria

Some type of documentation (can be rough) that helps illustrate what components will be implemented for the router

Implement a SimpleHTTPNode

Objective

Implement a SimpleHTTPNode that takes and starts a TCPListener

Description

This SimpleHTTPNode will act as a machine that serves as a HTTP Server. This can be seen as the wrapper that binds and starts the entire server core up.

The chain should be looked at like this:

• Listener takes a ConnectionHandler
• ConnectionHandler takes an Application
• Node takes the Listener

So, the Node once it calls start() should spin up the Listener and the Application. The result should be a functional HTTP Server handling HTTP requests

Acceptance Criteria

• Valid end-to-end HTTP request/response functionality for the Simple HTTP Server.

EduNet runs with a passing CI

Objective

The EduNet project has a configured CI to run all automated tests to help with allowing PRs

Description

Configure a CI for EduNet that will allow tox to run

Acceptance Criteria

• Tox runs in the CI
• CI shows test results

Fix issue with building on different Python verions

Objective

Currently there are issues with building on other Python versions outside of 3.11

Description

Ensure that Python can build on Python:

• 3.9 [windows, mac-os, ubuntu-latest]
• 3.10 [windows, mac-os, ubuntu-latest]
• 3.11 [windows, mac-os, ubuntu-latest]
• 3.12 [windows, mac-os, ubuntu-latest]

Acceptance Criteria

• CI passes with updates platform matrix

Add Badges to Project

Objective

Add badges to project

Description

We want to add badges to the project to visualize the latest state and stats.

Acceptance Criteria

• Codecov badge and status
• Test badge and status
• Latest Pypi version

Determine why load test is hanging in the CI

Objective

Determine why load tests are hanging in the CI and resolve

Description

Currently, there are two integration tests that serve as load tests to help validate the concurrency model of the TCPListener. It passes on the macos CI run, and also passes locally. For now, there is a directive being passed as an environment variable to skip these tests in the CI.

Suspicion is that it is not able to properly shutdown the listener, hence stuck in a loop where it can't shutdown.

Determine what it is doing and see what can be done to run it.

Acceptance Criteria

• CI can now run integration load tests