Some state fire off a stateTransitionAction and then directly transition to a new state, they have no 'steady wait' condition for handling events like messages and sockets
Some state fire off a stateTransitionAction and then directly transition to a new state, they have no 'steady wait' condition for handling events like messages and sockets
On receipt of an event - a socket connection or a message a series of state transitions can fire off, each may send an action back via the callback, and then transition to anoher state which can again fire an action etc.
On receipt of an event - a socket connection or a message a series of state transitions can fire off, each may send an action back via the callback, and then transition to anoher state which can again fire an action etc. this continues until no new state transitions occur
the eventual new state
During this time handle “new” inbound messages and/or ResendRequest if possible.
During this time handle “new” inbound messages and/or ResendRequest if possible. Note that some logout/termination conditions (e.g. loss of database/message safe-store) may require immediate termination of the network connection following the initial send of the Logout message. Disconnect the network connection and “shutdown” configuration for this session.
Default action on entering a state is to do nothing
Default action on entering a state is to do nothing
The event which entered the previous states handleEvent and which fired off the action
Created by Jonathan on 01/01/2017.
There are some situations especially during logon where we send logout with a reason and then close the socket. Otherwise you send logout and then wait for a reply logout... or a timeout.