Page History
...
| Tip |
|---|
| In this event, the Customer should contact MF Support Contact in order to confirm the validity of the specified credentials. |
...
| Info | ||
|---|---|---|
| ||
The MF Gateway MF Gateway guarantees persistence of sent outbound messages for possible resend for a minimum period of three heartbeat intervals, allowing for detection of dead connections as per 63805411 Session Monitoring, below. |
| Info | ||
|---|---|---|
| ||
Any unsent messages will be persisted indefinitely until either:
|
The table below specifies what messages are to be persisted and resent when necessary, as opposed to being gap-filled.
...
| Table Filter | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
User Session Synchronisation
...
If the Client msgSeqNum is lower than the Gateway's expected value, or the Client is expecting a sequence number higher than the Gateway's next-to-be-assigned msgSeqNum, then this is an unrecoverable error and the Gateway will abort the session with a Logout message (using it's next sequence number).
Tip The Customer should contact MF Support Contact to agree the correct resolution actions. - Otherwise, the Gateway will issue a LogonResponse message - populating NextExpectedMsgSeqNum which contains the next msgSeqNum value that it expects to receive from the Client.
...
Irrespective of whether repays are required in either direction or not, the Gateway will always issue a further TestRequest to verify overall completion of the session synchronisation. Thus the Client may be expected to respond to one, two or three TestRequest messages in total to successfully Logon.
...
| Gliffy Diagram |
|---|
...
| title | Deprecated Synchronisation Model |
|---|
...
Prior to Release 2020.11.16.WE, the Whisperer Enterprise Client synchronisation model mandated that the Client signal its completion of session synchronisation with a TestRequest. On receipt of this TestRequest, the Whisperer Gateway would respond with the necessary Heartbeat and then signal its own completion of session synchronisation with a TestRequest in the opposite direction.
This is now deprecated and the Gateway issues all required TestRequest messages.
The Client may of course elect to issue TestRequest message at any time, as part of their own session verification logic.
In the sequence diagram below, the deprecated model is in red, whilst the replacement model is in green.
| Gliffy Diagram | ||
|---|---|---|
| ||
|
...
| Warning |
|---|
The Gateway TestRequest messages and Client Heartbeat (response) messages are required as verification that no sequence number gaps remain in either direction. The Client should only proceed with new messages when these have been processed correctly. Any Any new (i.e. not SequenceResetGapFill or SequenceResetGapFill or resent) messages sent by the MFAPI Client prior to the required Heartbeat responses will result in ErrorReport notifications. |
...
Should the Client attempt to establish a second (additional) session using the same credentials as of a currently-active Client session, then it will be rejected. The original session will be unaffected.
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
Session Monitoring
...
| Warning |
|---|
| A heartbeat is deemed to have been missed if it is not received within HeartBtInt + MaxTx seconds and must result in the monitoring party issuing a TestRequest. |
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...
| Warning |
|---|
| If no Heartbeat response is received within HeartBtInt + MaxTx seconds of the issuance of the TestRequest, then the party must abort the session with a Logout message. |
| Gliffy Diagram | ||||
|---|---|---|---|---|
|
...