Fis-TransportInterface/doc/explanation.txt

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 retranismission 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.
-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:
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