This is an example of utilizing the failover mechanism of the Red5 Pro HTML SDK to select a subscriber based on browser support and to reconnect on close of broadcast or loss of connection.
Please refer to the Basic Subscriber Documentation to learn more about the basic setup.
Use the events API to determine when to kick off a reconnection request.
A call to connect
is set on a timeout and upon failure in being able to connect to a broadcast, the timeout is started over:
function retryConnect() {
clearTimeout(retryTimeout)
if (!connected) {
retryTimeout = setTimeout(connect, 1000)
}
}
When a connection is established, an event handler is assigned to the subscriber instance to handle situations in which the broadcast will be stopped.
In the occurance of a lost stream from the publisher - either from a network issue or stop of broadcast - you can stopstart the request cycle again.
There are 2 important events that relate to the loss of a publisher:
CONNECTION_CLOSED
NET_STATUS
with message ofNetStream.Play.UnpublishNotify
In this example, we rely on the CONNECTION_CLOSED
event to start that reconnect cycle again, waiting for the publisher to come back:
function onSubscriberEvent(event) {
if (event.type !== 'Subscribe.Time.Update') {
console.log('[Red5ProSubscriber] ' + event.type + '.')
updateStatusFromEvent(event)
}
// If connection lost, let's start trying to connect again...
if (
event.type === red5prosdk.SubscriberEventTypes.CONNECTION_CLOSED ||
event.type === red5prosdk.SubscriberEventTypes.CONNECT_FAILURE
) {
setConnected(false)
}
}
Listening on CONNECTION_CLOSED
is best as it will handle both the scenario that the broadcast has stopped from the publisher side (either explicitly or from a poor network condition) and the connection for the subscriber having been closed (either explcitly from the server after a broadcast stop or from a poor network condition).