th0mcumm1ngs / ARWIN

https://thomcummings.dev
1 stars 0 forks source link

Inter-server Communication #38

Open th0mcumm1ngs opened 10 months ago

th0mcumm1ngs commented 10 months ago

Feature Purpose: There needs to be a system devised for communication between the servers.

The Original Idea

The original idea for this, with early versions, was that each server would have two separate sender.py and receiver.py files that would contain HTTP request sending actions and a flask server respectively. Each server would then send JSON packages, which would each contain a standardized data structure containing an action, its data, etc.

This was an okay approach as a first draft. However, there are much more efficient, already-existing protocols and methods that specialise in this field, rather than 'reinventing the wheel' using web requests.

Newer Ideas

The most up-to-date idea – more research will be conducted before development of this feature – is similar to the first in that data will be in JSON packages, using a standardised format. However, instead of HTTP requests using verbose files and messy programming, the server will use Sockets and a request queue of some sort that the main.py file will fetch from based on an instruction scheduling system (FCFS to start with, probably more optimised / prioritised ones in the future).

Each server will hopefully then be able to send to another's queue and work through its own queue simultaneously, requiring no more than one python file when working asynchronously.

th0mcumm1ngs commented 10 months ago

I did some research today, here's how it's going to work:

th0mcumm1ngs commented 10 months ago

I think that a local SQLite queue might be better

th0mcumm1ngs commented 10 months ago

Plan of Action

Note: I'm taking a trial and error approach to this as I think it will be better than trying to plan, which always takes too long and isn't helpful enough. This is like a rough sketch model.

[^1]: Data should only be decrypted when it needs to be read, so any data stored in SQL databases or anywhere else will be encrypted. The code can then decrypt (and re-encrypt) when required. [^2]: The code could have the server running in a separate thread to catch incoming communications, while each client's action could be asynchronous in the main thread to avoid slowing down the program.