What is it?

Shadow Network Framework (or SNF in short) is a networking framework that follows it's own protocol over TCP.

Shadow Network Framework -unlike to what the name implies- Has no relation in anyway to Shadow Networks

What's the purpose of SNF?

SNF offers one purpose, and that is to simplify and ease client/server communications.

One might say "making websites with a RESTfull back-end is simple too so why would one should pick SNF over it?"
the answer is that SNF does not intend to replace any already existing protcols, but actually extend them, by example the future releases of SNF will have support to use SNF over HTTP(S) or over WebSockets, and also simplify making servers using C language, and possibly in the future using Zig or Rust, and simplify clients based on .NET (Must Support .NET Standard 2.0 as of publishing), with future plans on supporting ASP.NET, Java, C/C++ clients.

How does SNF work?

for this we'll have to split this into three parts

1. Overall Structure
2. Server Side
3. Client Side

Overall Structure

SNF's protocol basically consists of handling and interchanging Requests after making the Initial Handshake, those Requests consist of 4 important parts (as of publishing) which are:

1. Resuest Sender's Unique ID: Which are a set of bytes Set by the server(Currently a GUID v4) and are UNIQUE to each Client. this is used to identify the Sender's identity.

2. Request's OPCode: which are a set of bytes which define the action to do similar to URL PATH in the HTTP Protocol, but unlike the latter they are defined in a Hierarchical structure and is split into 4 parts:
   I. A Category: which is the head part defining the hierarchy
   II. A Subcategory
   III. A Command
   IV. A Detail ( Default: 0 -as undetailed - )

3. Request's Unique ID: Which are a set of bytes defining a Unique Identifier, which should be UNIQUE on the client side, due to it needing to use that identifier to know if it is a Server Response or which of the client's original request is being responded to.

4. Request's Arguments: Which are data that are provided to obtain the Request's result

Server Side

Both sides have a similar technical structure ( like in OPCodes hierarchy, Request Structure..etc ) and with very striking difference where this side is more optimized to handle multiple clients at once, using whatever technology available to the language used but the server side has a few general rules:

1. Await incoming connections
2. Handle the handshake and verify the clients initial requests:
   • If the client is connecting: a new Unique Identifier is assigned to it by the server.
   • If the client is reconnecting: check the existence of that client (and in the future verify identity )and allow reconnection.
3. Handle the clients requests and respond to them
4. Ability to send requests to clients [ Requires Special Request ]

Client Side

as stated in the past part they do have a similar structure but the client is more optimized on a limited number (or even one) of Connections and this side (as of publishing this post ) submits the following rules:

1. Connect to a server
2. Reconnect in case of disconnection Unimplimented
3. Send Requests to the server
4. Await Requests from the server

Conclusion

Shadow Network Framework is my own personal project that i started for the sake of learning, and to simplify projects that require networking. Feel free to use it and report any issues you encounter while doing so at the Github Repo .