Для браузерной игры в основном в автономном режиме я изучаю возможность запуска сервера сигнализации WebRTC из браузера.
Я могу себе представить, что с точки зрения безопасности открывать порт и обслуживать соединения из браузера (или сервис-воркера) нельзя, но я не могу* найти никакой информации по этому поводу.
В. Могут ли Chrome, Firefox (или, возможно, любой другой основной браузер) открывать сетевой порт и обслуживать соединения с помощью javascript? Или это принципиально запрещено дизайном браузера?
*) Для полноты картины я нашел один вариант (возможно), но он слишком сложен и поэтому не очень привлекателен. Существует пакет javascript под названием filerjs, который позволяет использовать posix-подобную файловую систему в браузере, я думаю, используя indexedb, что позволит установить nodejs в браузере. Я больше не исследовал это, поэтому понятия не имею, работает ли он на самом деле и можно ли обслуживать соединение таким образом.
Я не думаю, что вы можете запустить сигнальный сервер в браузере. Но вы говорите «в основном в автономном режиме», значит ли это, что пиры подключены к Интернету, но играют из одной и той же локальной сети? Или они полностью офлайн? Вот несколько идей:
Даже если сигнальный сервер работает в Интернете, есть вероятность, что WebRTC будет подключаться напрямую через локальную сеть (требуется проверка, и это может зависеть от того, как браузер выбирает кандидатов ICE).
Теперь сигнальный сервер существует только для обмена сообщениями SDP. Так что теоретически можно было скопировать-вставить предложение и ответить (или скопировать вручную, или отсканировать QR-кодом). Это может быть непрактично, но, например, вы можете попробовать жестко закодировать предложение/ответ SDP. Тем не менее, два игрока должны каким-то образом обмениваться информацией:
Я никогда не пробовал, но, возможно, ваш пользовательский интерфейс может сказать игроку: «Пожалуйста, поделитесь следующими IP-адресами с другим игроком и введите их IP-адреса ниже. Также выберите, являетесь ли вы предлагающим или отвечающим». Но вы видите, что это кажется немного запутанным...
Если одноранговые узлы полностью отключены, а ручная сигнализация слишком запутана, моей следующей идеей будет запуск сигнального сервера в локальной сети и подключение к нему одноранговых узлов. Вы даже можете сделать так, что ваша игра сначала попытается связаться с вашим сигнальным сервером в Интернете, и если это не удастся (потому что он не в сети), она может отступить и попытаться связаться с сервером в локальной сети (возможно, ей нужно будет запросить затем пользователь для IP-адреса сигнального сервера).
Отображение IP-адреса для копирования может быть не так уж плохо, но я думаю, что сглаживание — это ваше последнее предложение. В настоящее время это веб-приложение (PWA), не должно быть слишком сложно создать из него версию приложения для Android и iOS. В приложении у вас есть доступ ко всем видам mDNS и сигнализации, которые должны автоматически подключать всех игроков. В этом сценарии хотя бы один игрок должен использовать версию приложения.
Если это для смартфонов, я, вероятно, воспользуюсь вашим последним предложением, когда один игрок должен запускать сигнальный сервер. Это обеспечит лучший UX IMO.
В основном в автономном режиме: игроки отключены и используют прямой Wi-Fi для настройки локальной сети, однако в какой-то момент в прошлом у них было подключение к Интернету для установки и настройки. Таким образом, во всех смыслах и целях они полностью отключены. --- Я рассматривал возможность использования QR-кодов, но я думаю, что для завершения предложения/принятия рукопожатия требуется отсканировать два QR-кода, что немного громоздко. --- Можно ли жестко запрограммировать предложение/принятие рукопожатия? Кажется, он содержит сетевую информацию, которую нельзя узнать заранее, верно?