> > Гм, аргумент с нагрузкой относился к CGI, а не к EventSource (который
> > сам по себе имеет весьма малые накладные расходы). Мне это показалось
> > очевидным, ну да ладно.
> Ну правильно ж. EventSource пусть себе расходы накладные в браузере несёт весьма малые. Но если этих EventSource начнёт одновременно набираться тысячами для долбёжки cgi-скрипта, то у машины с веб-сервером, на котором этот скрипт трудится, может появиться напрряг - ну смотря как систему настраивать, конечно.Всё сильнее ощущение, что меня (сравнительно тонко) троллят. Ведь очевидно же, что накладные расходы клиента здесь вообще не являются тем, о чём имеет смысл беспокоиться, да и вообще: клиентов тысячи, а сервер на них один. Равно как и очевидно, что CGI не годится для долгоживущих соединений чуть более, чем совсем. Да и вообще ни для чего (кроме махрового legacy и некачественных сайтов, особенно внутренних) не годится, как ни настраивай систему. Можно сколько угодно оптимизировать fork+exec (vfork+exec, spawn, не важно), подгонять размер стека потоков ядра, подстраивать планировщик и всё равно это будет много хуже (в плане отношений полезной работы к потребляемым ресурсам как сервера, так и разработчика/поддержки), чем сразу делать по уму.
Но да, CGI — одна из «святых коров» закостенелых админов (не старых, не опытных, а именно закостенелых, это не от возраста зависит), не желающих даже смотреть на что-либо новое, ведь позволяет писать серверную часть абы как и долго не замечать (читай, игнорировать) проблемы разной степени серьёзности (вплоть до чего-нибудь типа повреждения кучи).
А если под «cgi-скриптом» подразумевалось вообще любое серверное ПО для генерации динамики (а не конкретно используемые через CGI программы) — лучше так всё-таки не вводить в заблуждение, у термина есть вполне конкретное значение.
> Есть такая идея, что мобильные, как раз быстрее обновляют свои железки, чем десктопные, т.к. мобилы нынче делают так, что не успел повернуться, а уже "устройство исчерпало память, будет работать плохо, медленно, прегадко и т.д." - после этого простые смертные (которые ни разу не программисты) просто выбрасывают свои мобилы и идут покупать новые.
>
> Конечно, какая-то часть населения железяки свои не обновляет. Но это во многом - не платёжеспособная часть населения, которая многим сайтам, увы, всё-равно бесполезна.
Идея интересная, но дело-то не в железках, а в софте. И если на десктопе вроде как программы так или иначе обновляются регулярно (хотя ещё не так давно на это рассчитывать не приходилось), то лепить новые мобильные устройства со старым вшитым софтом (и не выпускать обновления) производители ох как любят. Это не говоря уж про изначально урезанные версии софта по сравнению с исходными версиями. Отдельного гнева, кстати, заслуживает то что в новых версиях мобильных ОС из-за засилья низкосортных кодеров (ну и по коммерческим причинам, конечно) всё сильнее продавливают использование push-уведомлений (в т.ч. в браузере, с необходимостью использовать соответствующий API) вместо поддержания долгих соединений самим приложением. Доходит до того, что очень многие разработчики свято верят, что если программа (какой-нибудь XMPP или IMAP клиент, например) для получения данных с сервера без задержки не использует push-уведомления, то обязательно должна выжирать батарею на глазах (в итоге в свежих версиях ОС уже и нет возможности без этого обойтись,
а балбесы и рады). Вот это случай, когда действительно программистов ограничили не по делу, хотя умом и понятно, что «рыночек порешал».
> Ну "для сэбэ трошки" POP3 при грамотной настройке работает нормально. И проблем не возникает, если грамотно настроить маршрутизацию почты так, чтоб она была доступна везде в нужных местах. Но это, повторю, верно "для сэбэ трошки" - для людей, умеющих работать грамотно - програмимстов, сисадминов и т.п. А для смертных в промышленных масштабах про POP3 сказать ничего не могу - не работал с почтой масштабно аки крупный почтовый провайдер.
Ну начинается. Вкратце — нет, не работает. Можно сколько угодно обкладывать старый протокол костылями (там маршрутизацию подстроить, там плюнуть, тут подпереть, опросом сервер задолбить, опять же), но это называется «закат Солнца вручную». Т.е. вместо того чтобы сразу взять нормальный протокол (который тоже не сказать, что сильно молодой, между прочим) и получить массу полезных фич бесплатно, начинается накостыливание ради, вероятно, поддержки чувства собственной важности.
В итоге полученный франкенштейн и будет заведомо хуже работать (не иметь ряда полезных возможностей, создавать лишнюю активность на сервере), и ресурсов будет тратиться (как на настройку/поддержку, так и сервером и клиентами на работу) куда больше. Причём, тут не надо никаких масштабов крупного провайдера. Даже для переписки двух человек важно иметь нулевую (за вычетом собственно времени перекачки по каналам связи) задержку получения новых сообщений (да здравствует достающаяся по сути бесплатно возможность общаться в режиме чата, никак не ломающая возможность общения и в более традиционном формате) и возможность иметь с любого устройства доступ к своим перепискам, заботливо рассортированным по папкам (причём, и отправленные письма, и ответы на них хранятся вместе и отображаются цепочками, ровно как тут на форуме, без всяких нелепых костылей, типа Bcc на себя). Попытка изобразить эту функциональность на базе POP3 обречена на провал, хотя формально часть (но только часть) возможностей и можно кое-как накостылить дополнительными телодвижениями (теша себя тем что, чай, не простой смертный, а ого-го какой нормальный пользователь).
Нет ни одной разумной причины использовать POP3 вместо IMAP4 (даже миф про разницу в потреблении трафика оказался мифом), ровно так же как и нет ни одной разумной причины использовать EventStream вместо WebSocket. Есть разве что одна полуразумная причина «у меня так уже было настроено и работает, мне не нужны фичи и я очень не хочу ничего сломать», но это применимо только к машинно-машинному взаимодействию, а для живых пользователей всё-таки плохо подходит (рано или поздно вносить изменения приходится и нужно заранее представлять их цену в случае одной реализации и другой). И уж точно не нужно тащить это барахло в новые инсталляции. Да, очень часто новые технологии хуже старых (в чём-то или, нередко, вообще во всём), регулярно такое вижу, но эти примеры — редкий случай, когда это точно не так, но находится целая армия упирающихся тупо ради своих, сугубо субъективных причин.
И вот это явление, называемое «закат Солнца вручную» много где проникает. И полбеды что люди своё время тратят на такую кочергу, так ещё и другим частенько этим создают неудобства.
> Если задача стоит так, что общаться должен только браузер (юзеру ж не скажешь - установи себе программу какую-то), то получается, что надо именно браузер заставлять коннектиться к серверу.
Как это не скажешь (если только это не восточный пользователь, у которого все сайты через мини-приложения внутри одного комбайна под названием gosuslugi^W WeChat), столько лет ставили программы и продолжают ставить (хотя и всё менее охотно). Успех ряда проприетарных программ (неэтично их лишний раз называть, но мы понимаем о каких программах для обмена сообщениями и файлами, просмотра карт и, например, удалённого доступа к рабочему столу может идти речь) ясно показывает, что если оно того стоит и сделано по уму — пользователь ещё как поставит. Как тут не вспомнить слова (цитирую по памяти, так что не совсем дословно, но суть должна была сохраниться) из полурекламной статьи одного хостера: «не стоит недооценивать пользователей; по нашему опыту, нет таких скриптов, с установкой которых на сервер не разобралась бы очередная instagram-дива ради накрутки +30% like'ов на своих фотографиях».
> Да-да. Я тоже думал про то, что эти фичи упростят жизнь злоумышленникам. И тоже думал про то, что нужны ограничители, которые регулирует не юзер (которые максимальные разрешения навыдаёт), а такие, которые помогают коннектиться только к "своему сайту/домену" - для многих задач этого достаточно. Ну, например, чат без сервера. Ну не будут же браузеры участников чата коннкетиться куда попало, если им сообщения надо гонять только в своём чате.
А совсем без сервера не получится в любом случае, проблему bootstrap'а никто не отменял. Т.е. либо придётся на старте вбивать адреса руками (опять закатываем вручную?), либо пользоваться своим сервером, либо общественным (к этому в т.ч. относится использование DNS, например). Причём, «либо» тут в смысле неисключающего или. А если полагаться на общественную инфраструктуру, то использование общедоступных STUN/TURN серверов для начального соединения не сильно отличается от того чтобы полагаться на работу DNS. Это не говоря уж про такие занятные штуки, как mDNS.
> Ну браузеры внутри одной локалки - это сильно упрощённый пример.
Он не столько упрощённый, сколько ИМХО самый распространённый пример такого стечения обстоятельств.
> А я ж могу точно знать, что у юзера, например, в Уфе браузер на белом IP и к нему можно отправить запрос, например, из Магадана. Я же точно знаю, что NAT между обоими браузерами отсутствует. Ну откуда я это знаю - это "по условиям задачи".
Это замечательно, верю, но теперь нужно не забыть прикинуть, кому нужны именно так построенные задачи. Даже если таких случаев в окружении много (и потому кажется, что их вообще много), они составляют невесомые доли процента от общего числа пользователей. И если дать возможность такие задачи решать так, как этого хочется отдельным, гм, специфичным разработчикам, хорошо жить станет долям процентов, зато остальным участникам процесса (т.е. многим девяткам) станет хуже. Т.е. повторюсь, когда речь идёт о массовых решениях, нужно думать не только о возможной пользе для лично себя и ближайшего окружения, но и потенциальных проблемах для остальных.
> Но не смотря на это всё-равно получается так: "мы вам упростили жизнь и теперь вам самим не надо пробивать NAT" (даже если никаким NAT'ом по дороге и не пахнет). Да это ж какая-то медвежья услуга получилась: NAT пробивать не надо, а всё-равно фичи пробивания в нагрузку бери, пожалуйста, и не сетуй. :-)
Опять же, ИМХО, эти фичи достаются бесплатно. Т.е. когда они не нужны, они ничего плохого и не делают, а когда нужны (и тут слишком много девяток) — просто работают. Да, есть некоторое неприятное ощущение от того что нужно или иметь свой сервер сигнализации, или пользоваться любыми общественными (а их более чем достаточно, чтобы совсем уж без связи не остаться, не говоря уж про возможность в этом случае поднять свой на любом из хостов участников, раз они все по условию задачи без NAT), но сейчас (в мире отсутствия полного глобального запрета на торренты и прочий P2P) наличие общедоступного STUN/TURN сервера является чем-то столь же само собой разумеющимся, как и наличие работающего DNS. Так что, ИМХО, не тот случай, когда нужно воротить нос и из-за заморачивания по поводу мелкой потенциальной проблемы устраивать реальную и большую (ударение и так, и так).
> Работает, бывает, хороший сайт и через некоторое время работать нормально перестаёт - после прихода на работу в этот сайт вебмастера, который начальству говорит: мой предшественник - профан и мне теперь придётся у вас тут всё перенастроить по другому. Результат - сайт нормально работать перестаёт. Да и не только сайт и не только компьютеры.
Отож, классика жанра, к сожалению. Но, справедливости ради, у таких историй есть, как минимум, две стороны. Одна (вина которой чаще всего очевидна) — пришедший профан, который полез вносить изменения, не удостоверившись в понимании что, как и _зачем_ было сделано, в наличии бекапов (и того что восстановление из них работает) и, собственно, плана постепенных изменений (включающего в т.ч. некоторое понимание того, что делать, если в какой-то момент поведение системы идёт не по плану). Вторая — предыдущий админ, который мог неограниченно копить технический долг (не устанавливать обновления, втыкать всё новые и новые костыли, регулярно вручную «подшаманивать» отваливающиеся куски системы, борясь вручную с симптомами вместо исправления проблем, настраивать что-то без понимания копипастой и т.д.; и всё это документировать, в лучшем случае, только в унесённой с собой тетрадке, а то и вообще в голове, да и то через раз). Пока такой админ регулярно занимается своим «закатом Солнца вручную», снаружи может быть обманчивая иллюзия идиллии (которая и откладывается в голове у начальства, так что вина этой стороны может быть крайне неочевидной), но настроенная таким образом система имеет свойство быстро и, что важно, неожиданно (через недели или месяцы после ухода шамана) ломаться сама, даже без всяких изменений. А кому не повезёт в этот момент оказаться рядом, на того все шишки и посыпятся, даже если он и бекапами озаботился и разобраться пытался, прежде чем менять. А в силу отсутствия документации и ряда чудом работавших решений (которые даже сам предыдущий админ не понимает как работали) такие системы очень трудно чинятся и, тем более, переносятся на новую платформу. Клубок очень легко запутывается и очень трудно распутывается, скажем так. Бывает, впрочем, и третья сторона, которая наблюдает со стороны и, в силу устройства своей психики (это вообще довольно стандартный защитный механизм у мозга, просто в разной мере проявляется), легко забывает о прошлых проблемах и столь же легко раздувает нынешние, в итоге текущий админ постоянно (до самого его ухода в более здоровое место) поливается отборными помоями и по делу, и без дела, но когда он становится бывшим админом, то новому получателю помоев постоянно упоминается как пример идеала. Это уже, конечно, не из технической области фактор, но тоже важный для полноценного рассмотрения вопроса. Как говорится, плавали, знаем.
