Alive
What are alive Messages?
Alive messages are like a heartbeat. These messages indicate that the given producer is operating normally and you are able to receive messages from it. You can also see from the message if you are subscribed to that producer or not.
Alive messages are sent by each producer every 10 seconds.
If you stop receiving alive messages at the expected intervals, it is indicating something might be wrong with the connection between our service and yours.
XML example
<alive timestamp="1234579" product="2" subscribed="1"/>Alive attributes
Name
Description
timestamp
Timestamp in milliseconds since epoch when this message was generated according to generating system's clock.
product
The producer that sent this alive message.
subscribed
If set to 0, this means the producer is up again after downtime (but you are not receiving anything else other than alive messages), you should issue recovery messages against the API to resubscribe to the producer and start receiving any additional messages.
If set to 1, that not only the producer is up but that you should be receiving other messages as well.
Please note that after you'll recieve subscribed set to 0 untill the first recovery request is sent and when recovery is completed, you'll start recieving the alive messages with attribute subscribed = 1
Producer Down
The alive message is automatically handled by the SDK, so it’s not exposed to the client, and what it does is tracking of alive messages. By default, if there’s no alive message for 20 seconds, it will trigger a producer down message, which means that you should take immediate action on your side and suspend all the betting markets for the producer that is down.
Producers are decoupled, meaning one producer's downtime won't affect others. All betting markets for the specific producer that is down should be suspended, while the rest of the producers and their associated markets remain unaffected as long as they are active.
Once the connection is established again, recovery should be requested from the last stored timestamp from the affected producer, the requests should be done per connection/Node ID & Producer ID individually". Once the recovery is completed, snapshot_complete message will be sent, which indicates that all of the messages from the recovery were sent, and if you process them all, you should be able to go back into betting again (re-open only active markets per producer).
Troubleshooting
What is important to look at is the timestamp inside the alive messages, and the time interval you are receiving them.
Trigger recovery on given producer through UOF API if
alive messages are missing
alive messages are delayed (consider timestamp attribute)
when subscribed=0 in the alive messages
Special cases
If the timestamp inside the messages is consistent at 10 seconds, but you receive the messages at a slower pace or irregular interval, this might indicate a bad network connection between your servers and our service, or slow processing on your side.
If the timestamp inside the alive messages is not at an approximate 10 seconds interval, this indicates something is wrong on our side.
Both these situations are denoted as not receiving an alive message in the below.
Recovery Process
The recommended action is described below, and you can only treat the connection as up again only after recovery has been completed (confirmed with a snapshot_complete message)
If you do not receive an alive message for more than 15 seconds, you must wait until you start receiving alive messages again and then issue a recovery from UOF API from the time you last received a message. Be aware that if you start issuing recovery requests before you start receiving alive messages, the requests will not be successful, and you might hit our rate limiting on the recovery endpoint.
Recovery Handling (or Post Recovery Instructions)
If you have not received an alive message, and successfully completed a recovery from a given producer for a certain amount of time, you should act according to the match state. Here are some recommendations, but you are free to use other thresholds for the actions:
If the match is pre-match, and kicking off in more than 5 minutes, and you have not received an alive message in 5 minutes, then we recommend to suspend all markets on that match. However, to avoid losing business, it might be good to keep accepting bets in a restricted way (e.g. increased odds key, reduced limits, limited market offers, etc.).
Matches which are scheduled to start in the next 5 minutes have to be suspended until the system is fully recovered.
If the match is in play or kicking off in the less than 5 minutes, and you have not received an alive message in 15 seconds, you should suspend all markets.
Matches from the Virtual producers should be treated as if the match is in play.
Matches from the Numbers Betting producer should be treated as if it is pre match.
You can only treat the connection as up again once recovery has been completed and confirmed with a snapshot_complete message. You should only reopen markets and bets (applicable to all producers) after you have successfully completed a recovery.
Example instance of interruption and recovery handling
Example showing how to act for an in play event
Time (minutes:seconds)
0:10
0:24
0:30
0:40
0:45
0:50
0:56
0:60
0:70
Alive message from live producer
OK
OK
OK
OK
OK
OK
In play event status
Active
Active
Active
Active
Suspended
Suspended
Suspended
Active
Active
Connection handling
-
-
-
-
-
-
Issue recovery
Snapshot complete
-
Example showing how to act for a pre-match event
Time (minutes:seconds)
1:00
1:10
1:20…
2:00
2:10…
7:00
10:00…
11:00…
12:00…
Alive message from pre match producer
OK
OK
OK
OK
OK
Pre-match event status
Active
Active
Active
Active
Active
Suspended
Suspended
Active
Active
Connection handling
-
-
-
-
-
-
Issue recovery
Snapshot complete
-
Producers that send alive messages
Here are some producers that are available for the product attribute found in the above table:
Last updated
Was this helpful?