| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748 |
- 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.
|
