|
|
@@ -1,31 +1,45 @@
|
|
|
-Currently the way it works is, tranport service, which is the websocket or http or whatever transport protocol that is selected will have a universal emit and subscribe public method
|
|
|
-so, the concept of having bi directional will be somewhat weaved into every class object of said transport service. What it will do is that, when a client is connected, i mean it
|
|
|
-doesn't have to be literally like in the case of http, we will assume a logical channel so to speak. So when a client is connected, the connected client will be assinged an ID,
|
|
|
-one that will be used by the connection manager to instantiate a set of adapter with the assigned id, to identify the client as well as the type of transport it used.
|
|
|
-Essentially, a set of adapter is tied to one client and it's associated transport type.
|
|
|
+Latest change as of 12/11/2024
|
|
|
+Currently following the diagram from Chin.
|
|
|
|
|
|
-There the core of this transport interface, or at least that what I will choose to call it, will communicate with transmission manager, which in turns will be communicating with
|
|
|
-connection manager to handle how the message is received and transmitted. The need for this is to allow the integration for re-transmission service, so that messagecan be
|
|
|
-re-transmitted over, should there be an interuption of sorts.
|
|
|
+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.
|
|
|
|
|
|
-Now, in this context, we are talking about a server that can have multiple client connected to it, so that means there is a need to manage multiple 'traffic' with these connectedc
|
|
|
-clietns. To remember their credentials so as to be able to handle retransmission should they lost connection for whatever reasons, while dealing with various type of transport.
|
|
|
-FOr now, the example provided is only using websocket at the moment, another transport sample, which is http will be prepared at a later stage when i get this websocket working,
|
|
|
-with multiple clients as well as the server acting as a receiver itself.
|
|
|
+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.
|
|
|
|
|
|
-So, when an application starts, which assume to be the provider, will instantiate a transmission manager. The transmission manager will in turn instantiate a connection mnager ,
|
|
|
-and the connection manager will also instantiate a transport service specified at .env file. Once that is done, the connection manager will then subscribe to the transportevent
|
|
|
-also instantiated within it's component, and be exposed to transmission manager as well, so that all the concerned parties that are subscribed to transport event, will know what's
|
|
|
-happening. So, in this websocket's context: A client is connected, a transport event is reported and announced. Connection manager will listen to this type of event and
|
|
|
-instantiate a set of adapters to cater for this specific client. It will keep a copy with it's class, and can be retrieved by transmission transmitter and receiver and request response
|
|
|
-class. They too will also be listening to new adapter set event so to speak, and store the reference pointer in it's own local memory array.
|
|
|
-So here's how it is, the app which is
|
|
|
-the producer, once calls for transmission manager to instantiate a set of transmission methods, which is the message transmitter, receiver and request response class, which doesn't
|
|
|
-care what the underlying transport that is being used, will use the instantiated objects to perfrom all the available methods to transmit and receive message, even as far as
|
|
|
-emulating request response behaviour. So, when the producer wants to send a message, it will send through the message transmitter instantiated earlier. By the way, forgot to mention,
|
|
|
-when a client is connected, an ID will be assinged to the client, the same id that was assigned is also assigned to the adapter, which makes it easier to be managed later as I continue
|
|
|
-to develop this point. I probably mentioned this a few paragraphs, but anyway, as I was sating the message transmitter will read the message and see what adapter it's using,
|
|
|
-and search through it's array adapter ref, to find the matching adapterID, and then using that adapter to pass along the message. The adapter tha was chosen would have already been
|
|
|
-mapped with it's associated transport service to send the message out to the respective clients. At least that whole gist of it.
|
|
|
-With that in mind, the retransmission service will sit at the adapter side, since each adapter is tied to one client and it's respective transport type, so it's easier to manage.
|
|
|
-All events or activities will go through one, well "global" subject, which is the transport event instantiated at connection manager.
|
|
|
+
|
|
|
+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
|
