>> А теперь представим, что клиентов подключено хотя бы 1000.
>> Решение хорошо знакомое, классическое, даже рабочее, но по многим причинам дикое.
> Согласен. Для большей нагрузки решения нужны более элегантные, чем простой, топорный EventSource.Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который сам по себе имеет весьма малые накладные расходы). Мне это показалось очевидным, ну да ладно.
> Вебсокеты - технология какая-то странная с привязкой к http, если даже не вообще к https вроде - точнее не помню: успел не применить их у себя нигде
Да, с привязкой к HTTP(S) (HTTP поверх SSL/TLS всё-таки не стоит считать отдельным протоколом), но в контексте браузера это не очень-то большая проблема. На самом деле эта привязка очень мало мешает (в т.ч. потому что клиентскую сторону на JS всё равно писать придётся, а серверную можно обернуть в вебсокеты, готовых решений полно). ИМХО, существенно она мешает только там, где не то что HTTP(S) не очень-то подходит, а и вообще TCP (так что начинаются всякие SCTP или, напротив, Enet).
> а теперь благодаря сабжу их время/эпоха подходит к концу.
Хе-хе, сабж если когда-нибудь и внедрят, то очень нескоро, особенно с учётом армии пользователей с мобильных устройств, которые никогда уже не обновятся. Некоторые и на десктопе предпочитают сидеть либо на неподдерживаемых версиях браузера (опасные люди, практически вредители, ибо ловят эксплоиты, а потом другим жизнь портят), либо на особо порезанных (не от хорошей жизни), где вся подобная функциональность зарезана. Тут и про вебсокеты-то до сих пор лишний раз приходится подумать, внедрять или опять извернуться и обойтись без него, а уж это — дожить бы.
> А если мне надо отправить запрос на 110-й порт моего_почтового_сервера?
Оффтоп, но как же у меня припекает от пользователей POP3: вот вообще ничем он не лучше IMAP4, но всё равно находятся упёртые странные пользователи, которые будут страдать, но продолжать заставлять меня держать лишний сервис на сервере, да загаживать логи своим опросом, не говоря уж про прочие неудобства («пошли мне это письмо ещё раз, а то оно на домашнем компе забралось»). Понимаю, что просто пример, но аргх.
> Или на любой другой порт, если меня на другом конце ждёт моя программа-сервер, работающая хоть по телнету и обрабатывающая мои команды на моём спец-языке?
ИМХО, лучше всё-таки с такой программой-сервером общаться не через браузер. И так у браузера слишком много функций и это трагично.
> Ну это я всё клоню к тому, что нужна просто простая штука для просто подключений на указанный хост по указанному порту без всяких странных наворотов.
Такая штука упростит жизнь нескольких разработчиков (хочется сказать каких, ну ладно), но сильно испортит жизнь остальным, т.к. открывает большой просто для злоупотреблений. Тут и так умудряются всякие XSS проворачивать, а с такой штукой (надо быть честным с собой и не верить в то что пользователи будут умные и будут раздавать права только на нужное) открываются невообразимые возможности делать ботнеты на ровном месте. А если вводить аналоги same origin policy и CORS, штука будет довольно бесполезная (и всё равно будут возможности злоупотребления).
> Ну типа как просто берёшь, например, tcpcat и "горя не знаешь"
Да-да, netcat, socat и т.д. Это всё прекрасно в локальной сети (сам часто пользуюсь), но в дикой природе кроме горя ничего так и не познать.
> Конечно-конечно! 30 - это сильно приблизительно! С небольшой погрешностью лет в 7.
> :-) (для браузеров в современном понимании, когда во 2-й половине 90-х
> уже пошли Нетскейпы после Мозаик да Арахн :-) )
Да, я именно про конец 90-х (а то и начало 2000-х), а это всё-таки совсем не 30 лет.
> Оказывается, что интернетом юзер называет браузер.
> Поэтому требуется такие задачки решать в среде, в которой люди, уж извините,
> ни бум-бум в том, что такое компьютер и программы, которые им
> нынче теперь называют: "устройство" вместо "компьютер", "приложения" вместо "программы".
> И так далее.
Вот именно из-за необходимости ориентироваться на таких пользователей, браузерные (да и вообще сетевые) технологии и стали такими, какие есть. Они (технологии) могут выглядеть жутко, дико, непонятно для разбирающегося на низком уровне, но это результат тяжёлого труда по поиску компромиссов.
> Вот так и WebRTC. Хочу открыть исходящее соединение по адресу хост:порт. Ну
> сделайте простую функцию с этой парой аргументов (хост, порт) ну и
> возможно с назначением callback и т.п., если что, да и всё.
В современном мире прежде чем хотеть чтобы что-то появилось, нужно сначала хорошенько подумать: а кто и как этим может злоупотребить? Потому что если что-то может пойти не так, оно обязательно пойдёт худшим из возможных сценариев. Нужно ли разворачивать эту мысль применительно к этому конкретному желанию?
> Так нет же. Там нужны ещё сервера сигнальные и TURN. [...]
> И объясняют всю эту сложность в WebRTC - необходимостью гарантированного пробивания NAT.
И абсолютно правильно объясняют. В современном мире (опять, хех) даже если какой-то провайдер вдруг даёт белый IP, по умолчанию часто на него нельзя подключиться даже с хоста из той же подсети (!). А всё почему? Потому что «требуется такие задачки решать в среде, в которой люди, уж извините, ни бум-бум», отсюда и умолчания соответствующие.
> А если мне не надо пробивать NAT и оба браузера находятся в одной локальной сети, даже не подключенной к интернету?
То это настолько специфичное исключение, что админ этой корпоративной/институтской сети может обойти (не обязательно ногами) оба этих ПК и установить и настроить там не только браузер, но и другой нужный софт.
---
На самом деле, всё ещё намного хуже: в современном мире приходится учитывать не только то что проблемных пользователей и порезанных окружений большинство, так ещё и что программисты по большей части криворуки и не думают о последствиях (а некоторые ещё и при этом очень великого о себе мнения, ведь они не орган собачий, а что-то там писали на чистом WinAPI, ууу), поэтому массовые технологии приходится, гм, делать очень ограниченными и дуракоустойчивыми (как следствие, довольно усложнёнными). Это печально, но приходится смириться с тем что усидеть на всех стульях (чтобы решение было в 5 строчек, и работало устойчиво, и нужды 99% пользователей покрывало) не выйдет и искать компромиссы, выжимая 80% пользы с помощью 20% усилий, а не наоборот.
