|
|
@@ -17,24 +17,37 @@ Several batch files are prepared for ease of use. After building and the project
|
|
|
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
|
|
|
+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.
|
|
|
-
|
|
|
-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.
|
|
|
+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.
|
