|
@@ -1,35 +1,3 @@
|
|
|
-Latest change as of 12/11/2024
|
|
|
-Currently following the diagram from Chin.
|
|
|
-
|
|
|
-So, right now, transmitter file, even though it can act as a receiver, will act as a server application. So it will instantiate a transmission manager first thing first, separating
|
|
|
-from application logic. So when the transmission manager is instantiated, it will also instantiate the necessary transport service. Please DO NOTE that at the moment, the code is
|
|
|
-hardcoded to only work with 1 type of transport and a singular transport, which is Websocket. I have not design a system where it can cycle through multiple transport. But can be
|
|
|
-enhanced later on. Going back to transmission manager, once the transprot service, aka socket service in this case is instantiated, it will start listening to events. Events like
|
|
|
-whether or not is there a new or old client connected, and whether or not is there any new requests or messages or notifications. There are many events going on, but for the
|
|
|
-transmission manager, it's only concern is whether or not if it's a new client or old client. So, it's only subscribing to these two types of events, and based on these events,
|
|
|
-let's say it's a new client has been established, it will instantiate the necessary transmission instances needed to transmit and receive message.
|
|
|
-Here's how it works. A new client is connected, transmission manager will talk to connection/adapter manager to instantiate the necessary adapters according to the transport services
|
|
|
-that are available. A set of transmission instance, which is transmitter, receiver and request response instances will be returned so that the applciation can start sending and
|
|
|
-receiving messages through the aforementioned instances. And the adapters acquired from adapter manager will be attached alongside with the transmission instances.
|
|
|
-Retransmission will be implemented at the transmission level.
|
|
|
-
|
|
|
-Please note that the current code is only tested with one on one, which means only 1 server and 1 client, and it's a one way communication at the moment. I have yet to test it with
|
|
|
-multiple clients, but the current test is working so far with the retransmission. To emulate internet disruption without manually shutting down both the server and the client, I
|
|
|
-came up with an idea of writing another middle-man. or a proxy if you would, to simluate internet disruption by just shutting off the proxy, so that the socket on each side of the
|
|
|
-party can pick up the event, and notify/broadcast the information to the parties concerned. That's where the retransmission can shine.
|
|
|
-
|
|
|
-
|
|
|
-Things to do:
|
|
|
-i) Still need to test it out with multiple clients
|
|
|
-ii) Try it out with http as well, need to allocate time to code http services to emulate bi-directional streaming
|
|
|
-iii) Haven't try to use request-response. To be enhanced.
|
|
|
-iv) Implement dual roles: Eg => A server can be both transmitter and receiver. <Current Level only transmitter>
|
|
|
-v) Mutliple adapters implmentation. <TBD> (Need to discuss the logic to cycle through the transport and metrics measurement)
|
|
|
-
|
|
|
-
|
|
|
-Final i) General Documentation and it's associated components.
|
|
|
-Final ii) Clean Code (Usually this is done after prototype is functionally acceptable and stress tested.)
|
|
|
-
|
|
|
As of 14/11/2024 <Since there's no slot for meeting for the rest of the week>
|
|
|
Things to consider:
|
|
|
i) Multi Client test. <Based on chin, this is out of my scope, but will do anyways.>
|
|
@@ -51,8 +19,32 @@ i) Explore multiple traffic concept
|
|
|
ii) Move transport service instantiation to adapterManager
|
|
|
ExtraNotes: In some cases, servers can only be transmitting. Although this program allows for dual roles if there's a need for me.
|
|
|
|
|
|
-Note for 19/11/2024:
|
|
|
-i) Move the instantiation of transport service to adapterManager
|
|
|
-ii) Test multi client. Make sure they can be recognized. Will have to have multi proxies to be set up.
|
|
|
-iii) Also test if the server can also receives instead of just transmitting, and responds accordingly.
|
|
|
-iv) Modify the code to start using wrapped messages to allow message ordering
|
|
|
+As of 20/11/2024
|
|
|
+Here's what I did yesterday. Succeeded in wrapping all the messages to implement the retransmisison as well as message ordering mechanism. I also focused on getting the receiver to implement retransmission on their side as well. Didn't get to test the message ordering, even though I enabled it.
|
|
|
+I assumed it worked for now. Although I didn't really observe the test to see if it really works, but it was tested previously, so, I would assume it works for now. But the thing
|
|
|
+about the message ordering is that, if the previous message never arrives, the current message that arrives will always be held hostage. Just to take note. So, with that being said,
|
|
|
+today I will be focus in on the following:
|
|
|
+i) Move the instantiation of transport serivce to adapterManager Side. <DONE>
|
|
|
+ii) Code and test for server to respond this time round. Make sure the receiver have all the required responses. (Can also observe for the message ordering.)
|
|
|
+-The message ordering may need to be fixed for the request response. It is not ideal to hold the last message, because that would mean that the receiver has to
|
|
|
+make another action just for the message that has been held hostage to be released. Special clause should be enforced to allow the completion of a request
|
|
|
+iii) Test multi client.
|
|
|
+
|
|
|
+Things to do:
|
|
|
+- Connection Manager to manage different transport options. Default using websocket, but will also consider fail detection on each transport and decide on adapters swap
|
|
|
+- Also need to cater for browser environment. Right the now, the default behaviour is that one would assume to instantiate a socket server, instead of client.
|
|
|
+Need to cater for those cases too.
|
|
|
+
|
|
|
+Target for week:
|
|
|
+i) R&D for multi channel data traversal.
|
|
|
+-That means utilizing multiple TCP ports or network cards or transport services.
|
|
|
+-To be Prep via documents for discussion
|
|
|
+ii) Functional Http Service options to be made available.
|
|
|
+-Default transport will be geared towards socket at the moment.
|
|
|
+iii) Code Adjustments and Cleaning
|
|
|
+-Make sure the file structure and folders are in orderi
|
|
|
+-Necessary comments
|
|
|
+iv) Documentation
|
|
|
+-A special Readme file to help understand the usage and what it does.
|
|
|
+-Also guide for future enhancements
|
|
|
+
|