Исходное сообщение
"Для Chrome развивается API для прямых TCP и UDP коммуникаций" Отправлено n80, 25-Авг-20 18:05
> А серверный cgi-скрипт каждые N секунд шлёт в этот канал данные А теперь представим, что клиентов подключено хотя бы 1000. Решение хорошо знакомое, классическое, даже рабочее, но по многим причинам дикое. А ещё EventSource — довольно бестолковая штука, ИМХО: в дикой природе я его не встречал и сам так нигде и не применил (хотя и были порывы). С одной стороны, требует довольно нового браузера (к счастью, теперь-то IE уже закапывают официально, но сколько лет к этому шли), с другой — всё равно мало что даёт (одно направление, прибитый гвоздями формат сообщений и т.д.). Так что если важны клиенты, используют long polling с GET/POST-запросами, а если можно надеяться на свежий браузер у клиента, давно есть WebSocket'ы, в которых возможностей куда больше при той же нагрузке на сервер и клиент. Только не надо рассказывать про то что это плохо совместимо со столь родными CGI-скриптами, с которыми прожил много лет и не поднимается рука выкинуть, это несерьёзно. Затраченные в прошлом ресурсы не должны быть определяющим аргументом в пользу оставлять/не оставлять. Да, себя иногда тоже на подобном ловлю, но стараюсь пресекать. > Мне нужно отправить юзеру пакет. > Обычно это в браузерах 30 лет делают так: Браузерам в современном понимании «немножко» меньше 30 лет, на минуточку. Не могу не позанудствовать в данном вопросе, пардон. > Браузер шлёт пакет на сервер, а получатель пакета в другом браузере получает этот пакет с сервера. Эту задачу WebSocket прекрасно решает. В смысле, уже лет пять (если не восемь, а до этого аналогичное делалось на Flash и тому подобных отвратительных, но работающих технологиях), как для решения такой задачи браузер не шлёт пакет на сервер. Устанавливает соединение один раз при заходе на сайт и дальше через него может получать пакеты от сервера в любой момент (пока соединение не отвалится или сервер, но это уж с каждым может случиться). > И когда не останется ни одного доступного сервера-посредника, тогда надо иметь возможность отправить пакет из браузера в браузер напрямую без посредников в виде веб-серверов. А если такая возможность будет, то веб-серверы для межбраузерного обмена информацией Так ведь такая возможность давно есть. Локальные браузер-совместимые peer-to-peer программы (типа IPFS или Mastodon) уже давно существуют, в сами браузеры WebRTC тоже завезли уже довольно давно. Т.е. разные возможности есть, организовать транспорт — не проблема. Проблемы возникают куда более интересные, особенно с активным содержимым (скриптами и тому подобным), ну и банально с тем что контент нужно где-то хранить, а его очень много.