![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
WebSockets - почто стояли на майдане?
ссылка
Вкратце - технология, по которой коннект с веб-браузера на сервер будет висеть пока не сдохнет, а сервер при желании сможет в этот коннект срать данными, которые браузер будет обрабатывать.
Выглядит, конечно, весьма привлекательно длянеадекватов любителей делать интерактивщину на вебе.
Только вот представьте себе, что счас вся серверная и прочая инфраструктура заточена под, условно говоря, "короткий запрос-короткий ответ". Я уже несколько раз сталкивался с кривонастроенными сетями у клиентов, где долговисящие запросы просто обрывались где-то в середине сети. При этом обычные всякие почты, вебы и говноторенты в таких условиях работают более менее нормально. А вот если запросу в целях работы нужно висеть установленному - жопа и смерть, 5-10 минут неактивности и гамон.
Там по ссылке где нибудь упоминается обработка ошибок? Или keep-alive пакеты на уровне протокола? Ах, да, я забыл, в гугле не бывает зависающего сетевого оборудования, сдохших свитчей и неправильно настроенных прокси, натов и файрволлов, поэтому обработкой ошибок никто не заморачивается. "У нас на столе все работает".
Надеюсь, гугол это протолкнет в мейнстрим и начнется еще лет десять ебосрани для всех ИТшников, сисадминов, к которым будет приходит руководство и требовать чтобы "у меня веб-приложение должно работать" и веб-разработчиков, которым придется выламывать себе мозг, делая нормальную обработку ошибок с помощью костылей и хаков.
Вкратце - технология, по которой коннект с веб-браузера на сервер будет висеть пока не сдохнет, а сервер при желании сможет в этот коннект срать данными, которые браузер будет обрабатывать.
Выглядит, конечно, весьма привлекательно для
Только вот представьте себе, что счас вся серверная и прочая инфраструктура заточена под, условно говоря, "короткий запрос-короткий ответ". Я уже несколько раз сталкивался с кривонастроенными сетями у клиентов, где долговисящие запросы просто обрывались где-то в середине сети. При этом обычные всякие почты, вебы и говноторенты в таких условиях работают более менее нормально. А вот если запросу в целях работы нужно висеть установленному - жопа и смерть, 5-10 минут неактивности и гамон.
Там по ссылке где нибудь упоминается обработка ошибок? Или keep-alive пакеты на уровне протокола? Ах, да, я забыл, в гугле не бывает зависающего сетевого оборудования, сдохших свитчей и неправильно настроенных прокси, натов и файрволлов, поэтому обработкой ошибок никто не заморачивается. "У нас на столе все работает".
Надеюсь, гугол это протолкнет в мейнстрим и начнется еще лет десять ебосрани для всех ИТшников, сисадминов, к которым будет приходит руководство и требовать чтобы "у меня веб-приложение должно работать" и веб-разработчиков, которым придется выламывать себе мозг, делая нормальную обработку ошибок с помощью костылей и хаков.
no subject
no subject
no subject
в общем-то чаты и вейвы и без того на лонг поллинге работают, так что хуже уже не будет.
хотя у флэша отродясь был RTSP, но это очень специфическая хренотень, и неудобная маленько.
no subject
На самом деле, у флеша есть другая штука — sockets. Просто сокеты которыми можно коннектится к серверу и получать данные (пакеты терминируются нулём). Т.е. вебсокеты уже есть много лет и уже много лет много где используются. Но глючат.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Серьезный софт например на том же perl был изначально заточен на обработку запросов в рабочем цикле fastcgi либо mod_perl, а вот PHP совершенно stateless по своей идеологии, но пытаться на нём это изобразить определенно будут, причем силами всё тех же мальчиков-вебмастеров.
no subject