Вопрос по передаче событий и условной синхрон.

[ulquiorra]

Есть цепочка поднятая на основе данной статьи https://habr.com/ru/company/flashphoner/blog/340344/ , есть желание организовать викторину через стрим, вроде квизов что ли. Стример задает вопрос, предлагает варианты ответа на него. Собирает со стороны зрителей ответы. Дальше оглашает правильный ответ в стриме. Вопрос в том как идеалогически правильно в данной цепочке синхронизировать момент когда стример "сказал вопрос и ждет ответы" и "отвечать больше не надо, сейчас скажу правильный ответ" в реалиях возможных отставаний потоков у разных зрителей и тп. Каким образом и кто в цепочке должен посылать событие "вопрос задан" и "ответы не принимаются"? WCS в вебсокете с webrtc контентом или как?

 

[ulquiorra]

По сути каким то образом надо вместе с видео потоком передавать метаданные про то что вопрос оглашен и про то что ответы больше не принимаются и это должно быть синкано с картинкой которую видит зритель на своем девайсе. Вот не понимаю как это сделать в рамках WCS

 

[Max]

Добрый день.
Для обмена сообщениями между пользователями подойдет RoomApi. Посмотрите, пожалуйста, эту статью.
В Вашем случае, стрим вообще может быть опубликован только один, от ведущего, а участники только шлют сообщения в чат. Отметим, что RoomApi работает на одном сервере. Если предполагается, что отвечать на вопросы должны зрители, которые смотрят стрим с Edge сервера, то на каждого зрителя нужно заводить две Websocket сессии: одна для просмотра, на Edge, и одна для обмена сообщениями с ведущим на Origin.

 

[ulquiorra]

Спасибо за ответ! Просто у меня опасения что может появится пользователи с высоким летенси, когда одна вебсокет сессия может начать сильно отставать от другой. И выйдет так что зритель все еще видит вопрос и варианты ответа, а в видео потоке ведущий уже оглашает правильный ответ и вот эти несколько секунд могут позволить юзеру с плохим коннектом - всегда отвечать правильно или что еще хуже - отвечать на старый вопрос, когда как в видео потоке уже может быть разговор про совсем другой. На сколько все это адекватно возможно синхронизировать что бы избежать этих моментов? Или я по не знанию бью пушкой по ворабьям ?

 

[Max]

В нашей реализации Websocket (сообщения) никак не связан с WebRTC (стриминг видео), в плане синхронизации.
Поэтому да, если WebRTC будет работать по протоколу UDP с минимальной задержкой, то Websocket сессии могут отставать друг от друга при передаче сообщений.

Поэтому зрители должны знать, прочитал ли ведущий их ответ.
Например, у ведущего есть 30 секунд для ожидания ответа от зрителей.
Если время вышло, то отсекаются ответы, которые не успели дойти до ведущего.
Например за 30 секунд пришло только 2 ответа из 5 участников.
В этом случае прием ответов завершается и оглашается результат.
Тогда не будет ситуаций, при которых будет получен ответ на старый вопрос или ответ на новый вопрос уже после оглашения правильного ответа.

Для этого требуется:
1) Подтверждение доставки сообщений.
2) Подтверждение прочтения сообщений.

В нашем движке обмена сообщениями sendData() - эти вещи не реализованы. Есть возможность только разослать сообщение либо отправить сообщение конкретному получателю. Поэтому протокол подтверждения доставки потребуется реализовать самостоятельно. Либо найти движок сообщений с функциями подтверждения доставки и прочтения.