Message Restransmission: To aid in providing support to buffer outgoing messages if connection is disrupted

Enzo c98602c562 updated with comments 9 ay önce
documents 8822543ce0 some cleaning 9 ay önce
interfaces 41f879a3d6 retransmission without mongo fix 9 ay önce
models b1a81cec87 buffer restructuring 9 ay önce
services c98602c562 updated with comments 9 ay önce
test c98602c562 updated with comments 9 ay önce
.env 9da36b30b3 added attribution class and restructure server client and grpc 10 ay önce
.gitignore 4441404879 First set up 11 ay önce
README.md c98602c562 updated with comments 9 ay önce
attributes.json 980ba7925a statusChain refactoring 9 ay önce
build.bat 61afbae1ee connection attribution 10 ay önce
index.ts 8822543ce0 some cleaning 9 ay önce
package-lock.json 61afbae1ee connection attribution 10 ay önce
package.json 980ba7925a statusChain refactoring 9 ay önce
startgrpc.bat 6fc2d6d868 minor fixs 9 ay önce
startgrpc2.bat 6fc2d6d868 minor fixs 9 ay önce
tsconfig.json 61afbae1ee connection attribution 10 ay önce

README.md

FIs-Retransmission

Description

FIs-Retransmission is a Node.js application that provides a service for buffering and storing messages in case of disruptions in the established connection. This service is designed to ensure message reliability in potentially unreliable network environments.

Installation

To get started with FIs-Retransmission, you can clone the repository and install its dependencies using npm:

Execution Intsructions

Several batch files are prepared for ease of use. After building and the project, please change the path in the startgrpc.bat && startgrpc2.bat to your own path, and just type in start "startgrpc or batchfile of your choosing.bat"

git clone https://github.com/your-username/FIs-Retransmission.git
cd FIs-Retransmission
npm install


NOTE for Server Client Interface

Current way it starst is by declaring the request connection and then calling the server client interface to create the connections based on the details provided Right, the way it works, it that the sender and receiver will first pass in the connection on the designated target to communicate with, and with that info, the server client interface will create the connection attribute correspoding to the requests made. Then, the grpc client methods will send these information concerning t the attributes, which is called connection attributes to the designated servers to request for a channel. Then the server on the other side will then first verify the connection attribute to determine whether the connection exist in the local array. (Note: This is predetermined clients that are expected to be connected.)

The latest intention was that we have established the matter redesign the server client interface, to create the connection dynamically according the channel request that is coming in, and server client service, will assign a unique identifier for the client application to be used to identify themselves when they come back online upon disruption. Of course, how the client choose to store that identifier corresponding to the server tha assigned it has yet to be decided, but it can as simple as a json file, as long as it is something that can assess when the application comes back online. On the note for the server that asign a unique identifier, it will also generate the connection attribute to be stored in it's own memory, so that it too when receiving a client request to establish a channel, can perform the necessary validation to see whether if it's a client that has been connected, based on whether or not that client provide the needed information to identify itself, to which in this case, would be the previously assigned identifier.

Please Note: The retransmission has disabled mongo storage at the moment due to it's faulty nature. It will work fine with local instance buffer array.