Fis-Retransmission

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

Server Client Interface is designed to allow application to create and monitor both the physical and logical connections between the instantiated servers and it's respective clients. It also provide desired communication protocol for the connection to be made between the application.

To be implemented

• Fix the issue for async data storage operation. Eg, in mongo storage, there was issue with event queue which caused some message to be stored at a later time that is conflict with the timing when the buffer is released, storing 1-2 messages inside the buffer storage after all the messages are released back into the stream. Will need more investigation on this.
• Enhance server client interface to generate or assign the connection attribute dynamically based on the client's channel requests. And assign a restransmisison buffer s service respectively. Change the request into connection request rather than passing in connection attributes as request. The server client interface will decide how to deal with the information. 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.

Links to diagram:

https://app.diagrams.net/#G1q8EJBPIHN90x1riOtp2k4nJz7C6O3Rri https://drive.google.com/file/d/1q8EJBPIHN90x1riOtp2k4nJz7C6O3Rri/view?usp=sharing

Details

Currently the way it starts is by declaring the request connection and then calling the server client interface to create the connections based on the details provided from the aforementioned request. The way it works is 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 the attributes assigned to the designated servers to request for a physical 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: We are predetermined the amount of clients' request that are to be connected.)

The latest intention was that we have established the matter of the need to 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. As for the publisher, it needs only to start the desired amount of servers, and the incoming client requests will be ideally handled by the server client interface.