Запрос потока с другого источника, если он не найден

[Axel]

Здравствуйте.

Возможно ли реализовать следующую схему, и если да, то каким образом:

- подняты два независимых и ничего не знающих друг о друге (без CDN) инстанса Flashphoner: FP1, FP2
- пользователь A публикует поток S на FP1
- пользователь B пытается потреблять поток S с FP2, на котором такой поток отсутствует
- FP2 вместо "отлупа" пользователя выполняет запрос на API какого-либо сервиса, который знает, на каком из инстансов Flashphoner находится нужный поток, получает от него ссылку на этот поток, ретранслирует пользователю поток с этого инстанса Flashphoner (пользователь через FP2 потребляет поток с FP1), либо "редиректит" его подключение сразу на нужный инстанс Flashphoner без ретрансляции потока

Спасибо.

 

[Max]

Из коробки это работает в конфигурации CDN, когда несколько Origin серверов и несколько Edge серверов.
На один из Origin - серверов подали стрим. На одном из Edge - серверов этот стрим запросили на воспроизведение и получили.
Т.е. удовлетворяет всем требованиям кроме "подняты два независимых и ничего не знающих друг о друге (без CDN) инстанса Flashphoner: FP1, FP2 ".

Без CDN это тоже можно реализовать на REST Hooks.

С ретрансляцией

1. Пользователь B пытается потреблять поток S с FP2, на котором такой поток отсутствует, по сути, делает stream.play()
2. WCS отправляет REST Hook playStream на бэкенд HTTP запросом.
3. Бэкенд ищет этот стрим через /rest-api/stream/find {"status":"PUBLISHING", "name":"S"} на сервере FP1
3.1. Если publish-стрим найден, бэкенд запускает /rest-api/stream/pull - забирает стрим с FP1 на FP2
3.2. Далее бэкенд дожидается перехода стрима в статус PUBLISHING на стороне FP2.
3.3. Далее бэкенд возвращает 200 ОК.

С редиректом

1. Пользователь B пытается потреблять поток S с FP2, на котором такой поток отсутствует, по сути, делает stream.play()
2. WCS отправляет REST Hook playStream на бэкенд HTTP запросом.
3. Бэкенд ищет этот стрим через /rest-api/stream/find {"status":"PUBLISHING", "name":"S"} на сервере FP1
3.1. Если publish-стрим найден, бэкенд запускает возвращает 403 Redirect fp1.mycompany.com
3.2. Веб приложение получает эту информацию в поле info и устанавливает коннект с сервером fp1.mycompany.com чтобы забрать стрим оттуда.

С опросом available

Можно прямо из Web SDK узнать есть ли стрим на сервере и если нет, поискать этот стрим на другом сервере /rest-api/stream/find. Это менее ресурсоемкая операция, чем например stream.play(), т.к. при попытке воспроизведения, аллоцируются порты и память, а при stream.available() этого не происходит, следовательно можно выполнять множество операций в секунду без риска нагрузить сервер play() запросами.

function availableStream(){

    var session = Flashphoner.getSessions()[0];

    var streamName = $('#playStream').val();

    session.createStream({

        name: streamName,

        display: remoteVideo

    }).available().then(function(stream){

        $("#availableStatus").text("AVAILABLE").attr("class", "text-success");

    }, function(stream){

        $("#availableStatus").text("UNAVAILABLE").attr("class", "text-danger");

    });

}

Третий вариант с использованием stream.available() выглядит наиболее простым и пригодным для продакшена.
Первые два варианта будут работать медленнее CDN, т.к. придется дожидаться всех проверок на стороне бэкенда через REST. CDN же работает через вебсокеты и синхронизирует состояние быстро.