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.

For 2/12/2024 Monday (Updated!!!!)
URGENT: Fix the default socket transmission first. SOmething wrong with retransmission for both side when either side reconnected. Play with proxy for now.
i) Do include in the list of discussion for the message ordering mechanism
- Currently the way it is working is not favorable. In the mean time, do think up suggestion to improve the ordering.
- Just to acquire boss's input. Doesn't have to challenge him or anything
ii) Http Service Prep
-Need to emulate logical channel somehow.
iii) TCP Service Prep
-Try this out, so that I can proceed with multi port and metric performance
-Adapter Manager need to be intelligent enough to instantiate necessary components. So there will be a need to also check if a port is busy or in used.


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: (Same for Week4)
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
 
DONT  FORGET TO UPDATE SPICEWORK!!!!!!

Optiomal but cool things to do:
i) A global logging service that can be configured and toggled <DONE>
- instead a console.log, create a logging features in utility. It's like nestjs version but but my own. It will just read from logSetting.json configurations


Things to be discuss later: (as of 2/12/2024)
i) If a service crashes and comes back up, does client(UI sender) still send requests?
-Since the service loses all it's memory and have no clue who were connected and what it was doing unless there's a state machine.
-Current paradigm only solves for internet disruption, it doesn't assume either of the sender and receiver crashes.