Created a state machine for handling different types of events as a client (events as in receiving SubscriptionStatus resources).
Under the Playground scenario, the panel Manually trigger communication events contains a UI for raising events to the state machine.
Defining State
Subscription clients (subscribers) are primarily concerned with the following:
Assessing the current connection to the server (notifier)
Noticing any missed events (actual numbered server events) that need follow up with $events, $status or another mechanism
Processing any newly received server events
The easiest way to encapsulate this was using 4 properties:
A type that says whether the client's connection to the server is broken or not
lastReceived - The last server event the client received, either from a notification or a $events call
missingEvents -The list of server events the client knows happened, but hasn't received
receivedEvents - The list of server events the client just received. We do not keep an exhaustive list of all received events, since a client can process these as they are received. Note that if an event is re-sent to the client, it will not be re-surfaced here.
Defining Events (Actions upon the Client's State, not specific server events)
There are 4 types of events that can be raised to the client:
notify - A notification sent to the client with included server events
heartbeat - A notification sent to the client without any included events
recover - The outcome of a $events call with included server events
heartbeat-miss - To represent the client's heartbeat-period being exceeded
State Machine Algorithm
This is the rough algorithm I used to take an existing state and a new event (action) and create a new state:
Compare eventsSinceSubscriptionStart to the last received value, if it's less than or equal, proceed to step 3
Use eventsSinceSubscriptionStart to calculate a new list of missing events based on the previous state. Effectively ignore any included events until after this step
If the event included any server events, try to add those to the list of missing events. This list will either be new (calculated from step 2) or existing (if skipped).
Overview
Created a state machine for handling different types of events as a client (events as in receiving SubscriptionStatus resources).
Under the Playground scenario, the panel Manually trigger communication events contains a UI for raising events to the state machine.
Defining State
Subscription clients (subscribers) are primarily concerned with the following:
The easiest way to encapsulate this was using 4 properties:
typethat says whether the client's connection to the server is broken or notlastReceived- The last server event the client received, either from a notification or a $events callmissingEvents-The list of server events the client knows happened, but hasn't receivedreceivedEvents- The list of server events the client just received. We do not keep an exhaustive list of all received events, since a client can process these as they are received. Note that if an event is re-sent to the client, it will not be re-surfaced here.Defining Events (Actions upon the Client's State, not specific server events)
There are 4 types of events that can be raised to the client:
notify- A notification sent to the client with included server eventsheartbeat- A notification sent to the client without any included eventsrecover- The outcome of a$eventscall with included server eventsheartbeat-miss- To represent the client's heartbeat-period being exceededState Machine Algorithm
This is the rough algorithm I used to take an existing state and a new event (action) and create a new state:
eventsSinceSubscriptionStartto the last received value, if it's less than or equal, proceed to step 3eventsSinceSubscriptionStartto calculate a new list of missing events based on the previous state. Effectively ignore any included events until after this step