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.>
-Make sure it can work with multiple clients. And yes, more proxy will need to be prepared to simulate that.
ii) Request Response simulation. Make sure the receiver can make request and acquire response (Not referring to request Response adapter. Just use the existing two channel)
-Enable the response generator aspect to simulate such cases. Also, there is a need for a counter so to speak, so that the message
received by the receiver matches. 
-Also, need to consider also seqences once the above is tested. Because retransmission does help in wrapping. Either the retransmission do the wrapping or this message interface 
do the wrapping. <TBD> {Just a thought, the wrapping message format can be implemented across, since transmission and adapter level don't really care?? Need to check again}
iii) Http Transport service
-This one will take some time, because need to emulate it to mimic bidirectional streaming, so there's a need to emulate logical channel 
iv) Think about requestresponse transmission and it's associated adapter's implementation
-Do this when I have too much time to waste

Discussion Points: (Do these first)
i) Explore multiple traffic concept
-To make use of different ports as well as multi ISP to stream data. Eg: External Netword card.
-See how I can talk to underlying OS network configuration to make use of the network stream and delegate ports to it
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.

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