Информация
- В рейтинге
- 1 059-й
- Откуда
- Екатеринбург, Свердловская обл., Россия
- Работает в
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Фронтенд разработчик, Фулстек разработчик
Средний
От 1 000 000 ₽
JavaScript
Next.js
React
TypeScript
Node.js
HTML
CSS
Веб-разработка
Redux
Крутой кейс, спасибо, что поделился и за ссылку на проект. С visibilitychange это действительно больше похоже на костыль: вкладка может быть свернута, но пользователь сознательно оставил комнату «включенной», и тогда рвать соединение не всегда корректно.
Я бы попробовал сместить основную логику из «статуса вкладки» в модель «статусов участника» на сервере:
Для каждой вкладки/устройства хранить отдельный participantId и явно помечать соединение как active / background / disconnected.
Лимит «2 участника в комнате» считать не по количеству сокет‑подключений, а по количеству активных участников (например, role=caller/callee). Фоновые/зависшие соединения через таймаут или пинг переводить в inactive, и они перестают блокировать слот.
Если вкладка заморозилась и WebRTC/JS подвисли, но сокет жив, сервер по отсутствию медиапотока/пингов через N секунд сам переводит участника в inactive и освобождает место, не полагаясь на visibilitychange.
Тогда visibilitychange можно использовать более мягко: при уходе в фон отправлять на сервер «я ухожу в background», а уже сервер решает, когда считать такого участника «мертвым» и выкинуть из комнаты. Это уменьшает количество ложных дисконнектов и при этом не даёт «висящим» вкладкам держать слот бесконечно.