3 min read

Seddar Network Protocol

About

The Seddar Network Protocol ( or SNP in short ) is an general-purpose RPC protocol, using Operation codes as instruction, a more detailed description will be released later on and this blog will be updated.

I) History

I initially created this "Protocol" for a messaging platform called Spectrom Chat.

GitHub Card

however, this was initially called Spectrom Network Protocol that has a specific instruction set, and seeing how it was acting as some form of RPC I thought of making it more than just a built-in communication protocol. Hence the code for the networking was moved to:

GitHub Card

Which was initially a Template Project which contains methods and ways to dynamically add your own instruction set. Initially called SRBNP ( or Spectrom Requests Based Network Protocol), which later became a Library. and after research and talk with a university professor, it was better to split the developpement of the Protocol itself apart from it's impelentation that's now called The SNF ( or Shadow Network Framework )

  • Shadow Network Framework ( More on it later )

II) Core Concepts

As it's previous name suggests SRBNP ( or Spectrom Requests Based Network Protocol), the whole communication consists of specefically constructed requests. Each Request is generally made of two parts

  1. Metadata
  2. Arguments

1. Metadata

This generally contains contains information about the request itself, it depends on the connection step, and in some cases, the server itself like for example:

  • OPeration Codes ( or OPCodes )
  • Arguments Amount/Size
  • Server Versions
  • ... etc

- Operation Codes

Which represents a set of 4 bytes(currently) ranked from left to right. where each byte represent the following rank in order:

  1. Category
  2. Sub-Category
  3. Command
  4. Detail(Default is 0x00)

- The rest

The other data change from a request to another, and they will be mentioned in the full documenation.

2. Arguments

They are set of data that follow the OPCode, Currently due to current implementation limits ( as this is the first version ) the arguments are only strings split by a UNIT_SCEPARATOR byte.

III) Inner Workings

let's assume the current version is 0.0.1 .
The protocol passes through 4 Stages

  1. Client's Initial Connection
  2. Client's Initial Request
  3. Server's Initial Response
  4. Regular Communication.

1. Client's Initial Connection

(Or better known as Initial Server Request)

Happens when a client connects. The server sends an Initial Server Request containing information about the server, like protocol version, implementation version, and the server's version. which the client verifies and either accepts and continues to the next step if it sees itself compatible.

2. Client's Initial Request

Which decribes the connection's nature. Either Sateful or Stateless, limited or not.

3. Server's Initial Response

which either accepts the incoming client or not. If the latter's connection is stateless, respond to the request as if it is a regular request

4. Regular Communication

assuming the connection is stateful, the server and client shall exchange back and forth requests and responses.

IV) Why I made it?

As previously said, it was initially going to be a built-in TCP protocol. but seeing how the initial project was just a learning project, I made use of it as a learning tool, like TCP handling, multithreading, pools, queues,... etc. But Eventually i thoyugh of it more than just a learning project and could be something much bigger and potentially be of help for other developpers too.

V) Why not http(s)?

This protocol is never meant to replace any existing structure, however it is meant as translation layer of some sorts. like a server could understand HTTP-Based SNP Requests, and/or native-TCP Based SNP, which could allow it by example for server to act as a gateway, for low-power IoT or other purposes, without sacrificing much processing power. and keeping the useful ness of HTTP-Based communications, without much of a hurdle during developpement periods.

VI) Where can i read the full spec?

The full spec is not released as of late. This page will be updated later on.

Conclusion

I appreciate you taking time to read this blog of mine, I hope this projects becomes helpful to you, and if you want to assist in it. please check my Github .