Message Restransmission: To aid in providing support to buffer outgoing messages if connection is disrupted
Enzo c98602c562 updated with comments | 10 mēneši atpakaļ | |
---|---|---|
documents | 11 mēneši atpakaļ | |
interfaces | 10 mēneši atpakaļ | |
models | 11 mēneši atpakaļ | |
services | 10 mēneši atpakaļ | |
test | 10 mēneši atpakaļ | |
.env | 1 gadu atpakaļ | |
.gitignore | 1 gadu atpakaļ | |
README.md | 10 mēneši atpakaļ | |
attributes.json | 11 mēneši atpakaļ | |
build.bat | 1 gadu atpakaļ | |
index.ts | 11 mēneši atpakaļ | |
package-lock.json | 1 gadu atpakaļ | |
package.json | 11 mēneši atpakaļ | |
startgrpc.bat | 11 mēneši atpakaļ | |
startgrpc2.bat | 11 mēneši atpakaļ | |
tsconfig.json | 1 gadu atpakaļ |
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.
To get started with FIs-Retransmission, you can clone the repository and install its dependencies using npm:
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
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.