Comments 23
> Браузерный мультиплеер без сервера
Не врите,
> Сначала клиент пытается соединиться (используем peer.js) с другим пользователем…
Что-то не очень понял смысла всех действий… Чтобы соединиться со случайным клиентом?
Вы обернули обычный алгоритм работы WebRTC логикой, чтобы получить функционал соединения со случайным клиентом… Зачем?
UPD: Вернее, зачем вы это назвали без сервера и делаете на этом акцент.
Не врите,
> Сначала клиент пытается соединиться (используем peer.js) с другим пользователем…
Что-то не очень понял смысла всех действий… Чтобы соединиться со случайным клиентом?
Вы обернули обычный алгоритм работы WebRTC логикой, чтобы получить функционал соединения со случайным клиентом… Зачем?
UPD: Вернее, зачем вы это назвали без сервера и делаете на этом акцент.
Не вритеЖелтый заголовок — не ложь :) А тексте все написано, как есть.
чтобы получить функционал соединения со случайным клиентом… Зачем?Затем, чтобы получить функционал соединения со случайным клиентом. :)
UPD: Вернее, зачем вы это назвали без сервера и делаете на этом акцент.
Обычно для того, чтобы организовать выбор случайного соперника приходится писать некий серверный код, который отслеживает статус имеющихся пользователей. И соединяет пару свободных друг с другом. В данном случае тот же функционал работает без такого серверного кода. Клиенты случайным образом сами выбирают друг друга.
Открыл хром и фаерфокс рядом, открыл страницу. Вот уже 5 минут крутится круг, что я делаю не так?
Вот уже 5 минут крутится круг, что я делаю не так?А это как раз результат нагрузочного тестирования. Собственно первый положительный результат статьи — теперь можно попытаться понять причины ошибки.
Т.е. такое у вас называют «нагрузочным тестированием»? Надеюсь это пятничная шутка.
Ну от хабраэффекта и не такие поделки падали.
В целом пост, конечно же пятничный. Это скорее эксперимент, но добиться того поведения, которое я наблюдаю сейчас, мне, имея один ноут, не удавалось. Поэтому я и говорю, что тестирование очень удачным получилось.
В целом пост, конечно же пятничный. Это скорее эксперимент, но добиться того поведения, которое я наблюдаю сейчас, мне, имея один ноут, не удавалось. Поэтому я и говорю, что тестирование очень удачным получилось.
Так поясните, что произошло? Упал сервер, обеспечивавший безсерверный мультиплеер?
О состоянии серверов мне ничего неизвестно.
Но вижу ситуацию, когда к одному пиру ломится сразу несколько попыток соединения, и при этом он и отлупов не дает, но и соединение не устанавливает. В результате все «ждут». Что именно в данном случае является критичным я не знаю — не похоже, что проблема в количестве, а вот разные версии браузеров вполне могут быть причиной. А может быть надо озаботиться использованием STUN. Средств диагностики не хватает. Да и отсутствие сервера с его логами тоже мешает :)
Но вижу ситуацию, когда к одному пиру ломится сразу несколько попыток соединения, и при этом он и отлупов не дает, но и соединение не устанавливает. В результате все «ждут». Что именно в данном случае является критичным я не знаю — не похоже, что проблема в количестве, а вот разные версии браузеров вполне могут быть причиной. А может быть надо озаботиться использованием STUN. Средств диагностики не хватает. Да и отсутствие сервера с его логами тоже мешает :)
Так вы может быть разобрались бы как такие сервера работают, как технология работает, прежде чем на них строить «без серверные» игры.
> Работаю: Mail.Ru Group
:) это круто xD
> Работаю: Mail.Ru Group
:) это круто xD
> Работаю: Mail.Ru GroupИ какое отношение это имеет к указанному топику? Может быть тут написано, что это блог компании? Или сказано, что это компания mail.ru проводила эксперимент?
Да ладно вам, комментарий не в этом был заключен. Это только мое субъективное удивление.
Остальная часть комментария содержательностью тоже не отличалась.
Эксперименты для того и проводятся, чтобы разобраться в технологии.
Эксперименты для того и проводятся, чтобы разобраться в технологии.
Угу :) на статью какую-то похоже.
Ну а если по теме, то сервер для связи двух клиентов WebRTC имеет совсем не сложную структуру. Его одной и основной задачей является передача сообщений от одного к другому клиенту ну и плюс он должен для этого устроить обработку и хранение онлайн клиентов. Исходя из этого
> приходится писать некий серверный код, который отслеживает статус имеющихся пользователей
при вашей реализации вы просто берете уже готовый сервер. Да, вам не нужно писать такой код, но он должен быть написан кем-то…
Выгода от заимствования кода может быть минимальна, так как реализация своего сервера (крайне простая реализация) может даль ощутимо больше пользы.
Даже если писать код самому — функции сервера очень просты и занимают крайне мало времени, поэтому даже маленький сервер при такой архитектуре способен вытянуть очень много пользователей.
Ну а если по теме, то сервер для связи двух клиентов WebRTC имеет совсем не сложную структуру. Его одной и основной задачей является передача сообщений от одного к другому клиенту ну и плюс он должен для этого устроить обработку и хранение онлайн клиентов. Исходя из этого
> приходится писать некий серверный код, который отслеживает статус имеющихся пользователей
при вашей реализации вы просто берете уже готовый сервер. Да, вам не нужно писать такой код, но он должен быть написан кем-то…
Выгода от заимствования кода может быть минимальна, так как реализация своего сервера (крайне простая реализация) может даль ощутимо больше пользы.
Даже если писать код самому — функции сервера очень просты и занимают крайне мало времени, поэтому даже маленький сервер при такой архитектуре способен вытянуть очень много пользователей.
Ну а если по теме, то сервер для связи двух клиентов WebRTC имеет совсем не сложную структуру.Так вопрос совсем не в сложности кода (он у меня есть и даже работает). А в том, что хочется от лишнего звена избавиться. Логически построение взаимодействия при наличии центрального синхронизирующего элемента намного проще, но привязка к такому центральному элементу делает все решение крайне негибким.
Идеальный вариант это простой html файл, который можно засунуть куда угодно и который будет работать без всякой настройки, конфигов и прочей фигни. И в общем случае ничто не мешает созданию такой сети взаимодействующих друг с другом клиентов, без наличия центрального синхронизирующего элемента. В случае webrtc без сигнального сервера не обойтись, но есть возможность не завязываться на специальный сервер для проекта, а использовать общедоступные ресурсы.
> И в общем случае ничто не мешает созданию такой сети
Нет, мешает, архитектура интернета мешает. Не возможно. Хотя бы потому, что есть клиенты, которые сидят за натом и это одно из исключений, которыми обрастет ваша идея. С ними придется бороться если вы хотите это:
> html файл, который можно засунуть куда угодно и который будет работать
Поймите правильно, сам хочу такую вкусняшку, но сейчас это не возможно.
Кстати, зависимость будет в любом случае, будет это ваш сервер или свефический в вакууме и тут не понятно еще зависимость от какого будет лучше :)
Нет, мешает, архитектура интернета мешает. Не возможно. Хотя бы потому, что есть клиенты, которые сидят за натом и это одно из исключений, которыми обрастет ваша идея. С ними придется бороться если вы хотите это:
> html файл, который можно засунуть куда угодно и который будет работать
Поймите правильно, сам хочу такую вкусняшку, но сейчас это не возможно.
Кстати, зависимость будет в любом случае, будет это ваш сервер или свефический в вакууме и тут не понятно еще зависимость от какого будет лучше :)
Хотя бы потому, что есть клиенты, которые сидят за натом и это одно из исключений, которыми обрастет ваша идея.
Ну на абсолютную универсальность я не претендую. Это всего лишь эксперимент.
И я его оцениваю, как удачный. Хабраэффект создал некоторую нагрузку (самое главное — разнообразие браузеров и сетевых конфигураций), которую вручную создать было затруднительно. Некоторые ошибки найдены и устранены, проблемы осознаны.
В то же время идею можно считать рабочей — мне и самому удалось сыграть множество партий с разными соперниками, да и другие люди, привлеченные к тестированию, поиграли. Всем понравилось :)
А по старинке по IP нельзя соединиться?
Далеко не у всех порты проброшены
И не только поэтому. Даже если оба клиента имеют белый ip, то хотя бы один из них должен знать адрес другого, а это требует наличия связующего звена от которого автор ооочень хотел избавиться. Да и статья о web приложении. Вы вот знаете способ соединения браузер-браузер по ip?.. Я только один знаю — WebRTC, который, кстати и без проброса портов работать может) Для него непроходим только симметричный нат :)
Я про него и спрашиваю. Можно ли в нем напрямую задать IP и Порт к которому соединиться, или порт на который принимать соединения?
Если это возможно то можно создать сеть DHT для которой сервер нужен будет только при первом подключении.
Если это возможно то можно создать сеть DHT для которой сервер нужен будет только при первом подключении.
Сейчас, если ничего не делать дополнительно то сервер и нужен только для установки «первого» и единственного соединения.
> Можно ли в нем напрямую задать IP
В любом случае вам нужно его знать. По мне так лучше оставить это на WebRTC, предоставив ей только сигнальный сервер, так как сама технология может выполнить не только прямое подключение но и подключение через нат, чего вы никогда не сделаете из JavaScript кода.
Это примерно так работает:
1. есть браузер А и Б
2. и они знают про адрес (IP/домен) сигнального сервера
3. А и Б коннектятся к сигнальному серверу, он позволяет обмениваться сообщениями между А и Б
4. например, А приглашает Б установить контакт, пересылая ему спец пакет через сигнальный сервер
5. А и Б обмениваются IP адресами (через сигнальный сервер), по которым к ним можно присоединиться. это ip компа и все вплоть до белого ip
6. Браузеры пытаются соединиться между собой по одному из этих ip с учетом обхода нат и т.п. и работают уже меду собой им больши никто не нужен.
Собственно на шаге 4 бразеры должны знать ID друг друга, чтобы указать какому именно браузру предназначено сообщение. Т.к. к сигнальному серверу может присоединиться более двух драузеров. Получение именно этих ID «случайным образом» и решает автор статьи испоьзуя для этого сам сигнальный сервер. Не лишего смысла, кстати.
> Можно ли в нем напрямую задать IP
В любом случае вам нужно его знать. По мне так лучше оставить это на WebRTC, предоставив ей только сигнальный сервер, так как сама технология может выполнить не только прямое подключение но и подключение через нат, чего вы никогда не сделаете из JavaScript кода.
Это примерно так работает:
1. есть браузер А и Б
2. и они знают про адрес (IP/домен) сигнального сервера
3. А и Б коннектятся к сигнальному серверу, он позволяет обмениваться сообщениями между А и Б
4. например, А приглашает Б установить контакт, пересылая ему спец пакет через сигнальный сервер
5. А и Б обмениваются IP адресами (через сигнальный сервер), по которым к ним можно присоединиться. это ip компа и все вплоть до белого ip
6. Браузеры пытаются соединиться между собой по одному из этих ip с учетом обхода нат и т.п. и работают уже меду собой им больши никто не нужен.
Собственно на шаге 4 бразеры должны знать ID друг друга, чтобы указать какому именно браузру предназначено сообщение. Т.к. к сигнальному серверу может присоединиться более двух драузеров. Получение именно этих ID «случайным образом» и решает автор статьи испоьзуя для этого сам сигнальный сервер. Не лишего смысла, кстати.
Sign up to leave a comment.
Браузерный мультиплеер без сервера