Все элементарно: это обычный сокет, т.е. мы имеем реальную асинхронную связь. А XHR такого не умеет.

Поддерживают только современные, JS тут не спасет. Я помаленьку пилил библиотечку для вебсокетов, не допилил еще до конца: то влом вдруг стало, то некогда.

Время вебсокетов еще не настало, можно словить проблем на совершенно разных уровнях (фронт-энд, прокси, браузер). А вообще предназначен для постоянного двустороннего обмена данными, не ломая совместимость с обычным HTTP.

Очень хочется отказаться от AJAX, ибо он устанавливает кучу лишних соединений

Ничего он не устанавливает, все сервера давно умеют Keepalive.

Есть библиотеки, которые предоставляют механизм для обмена сообщениями с клиентом, используя что есть (вебсокеты, xhr).

Есть библиотеки, которые предоставляют механизм для обмена сообщениями с клиентом, используя что есть (вебсокеты, xhr).

Нет. Или я плохо искал: единственное, что нашел (почему и стал свое пилить) — cwebsockets почти двухлетней давности (естественно, нерабочая).

http://socket.io

JS тут не спасет

Почитал тут про websocket.io. Ещё про какие-то страшные уязвимости пишут, но это же пофиксят, так?

И где там серверная часть? Хрень какая-то... Где С?

Может и пофиксят. Я про уязвимости не слышал.

Вроде бы тут (github.com) есть что-то.

Там не хрень, а node.js. Хотя список фоллбэков (включая долбофлэш) делает сам socket.io хренью.

Интересно другое: они сам протокол уже устаканили? Застал время, когда он менялся еженедельно, @*%#&.

Почитать на опеннете здесь.

Где С?

В ядре и контроллерах, где ему и положено быть.

Как раз в процессе фикса уязвимостей (хотя уязвимости ли это, вопрос спорный) они и меняли протокол весьма интенсивно.

Если я правильно понимаю, что значит статус RFC, то устаканили.

Мдэ... по сравнению с тем, что я щупал, его усложнили до чёртиков... ну, хоть устаканили, и на том спасибо. Будем расчехляться.

Socket.IO как фолбэк для сокетов если что. Штука для реалтаймого соеденения с сервером, сервер сам может инициировать отсыл информации. Недавно добавили поддержку в nginx и теперь можно откуда угодно работать с ними, без поддержки у бэкенда. Вообще штука полезная только для реалтайм чатов или игр, может коллаборативной работы, но в большинстве случаев для всего хватает Server-Sent Events - тоже самое почти, только сервер - клиент связь, а не двухсторонняя

Устаканили же! И стандарт уже нормальный, а не "демо".

// ничего, как понадобится — допишу библиотечку и буду юзать.

Збс

Хм, действительно, скачал простенький примерчик под ноду, УМВР и безо всяких соцкет.ио. Можно теперь пилить нетормозные пайпы к stdio консольных прог на вебморду.

https://github.com/davidmoreno/onion вебсокеты на отдельном бранче. пуре си. лицензионная чоткость

Systemd is integrated.

Лук настолько крут, что это не он встраивается в системд, а системд встраивается в него?

Именно за этим я и начал ковырять AJAX, потом метнулся к вебсокетам :)

нее. это не смотри. я тоже удивился шо за барахло. там интегрирован systemd сокет чисто для теста

У дураков мысли сходятся. Небось, тоже пилишь принципиально новый десктоп?

Но преподнесли так, как будто... Ладно, пока обойдусь нодой, будет тормозить - перейду на пуреЦ.

я бы предпочел руби ноде. сама по себе идея создания ноды нормальная. а по факту нижайший порог вхождения породил цунами параши

Я бы предпочёл питон, но что-то мне подсказывает, что для ноды, а точнее, для V8, этот протолол куда нативнее, чем для любой другой технологии.

Я бы предпочел tomcat, но очень лениво до седьмой версии обновляться.

Ты не поверишь...

Ну и на каком этапе? Полноэкранную запускалку вебкита (чистый си) подогнать?

нативнее в смысле раньше запилена поддержка?

в таком случае представляю вам посоны самое нативное выпадающее меню http://www.milonic.com/ ие3+. Я когда увидел это - со стула упал. А когда узнал что оно до сих пор используется - провалился на этаж ниже.

Распространяет эту парашу своим клиентам http://www.volusion.com/ за большую деньгу. Так вот к нам обратился очень жирный клиент и буквально плачет «сделайте что нибудь с этим меню. пожалуйста». Палить клиента не буду. вот пример сайта с тем же меню

+ НИКОГДА не обращайтесь на такие ынтырпрайз говносервисы

нативнее в смысле раньше запилена поддержка?

В смысле поддержка глубже встроена.

Я когда увидел это - со стула упал.

Аналогично.

Было бы неплохо ссылку на гит. У меня фф с каким-то левым патчем на полноэкранный режим. Запускается он долго, а у меня целевая платформа — встраиваемые системы (знаю, что это извращение).

Недавно обсуждали же. Везде заменять не стоит, потому что траффик не пакуется.

Вебсокеты будут хороши, когда надо с сервера слать короткие нотификейшены клиенту (например, что-то сказали в чатике, или пришло письмо). Ну еще бывает, что надо с клиента серверу что-то короткое быстро слать, но это в основном в играх встречается.

Большинство библиотек предоставлят универсальный интерфейс, а как они там внутри повяжутся с вервером - вас волновать не будет.

Проблема только одна. Качество библиотек хреновое. В обсновном память течет. Хотя у меня были кейзы, когда человек мог законнектиться только эксплорером, потому что он не поддерживал вебсокеты и фолбечился на лонгполл. А фаерфокс и опера обламывались, и почему-то не делали откат на альтернативные протоколы.

В общем, если собираетесь внедрять - готовьтесь к массе увлекательных приключений. Естественно, получать задания на прохождение квестов вы будете в самый последний момент, когда все в продакшене.

Ах, да. Совсем забыл. Ни одна из библиотек, которые я знаю, не умеет шарить соединения между вкладками браузера.

Видимо, разработчикам эта функциональность не очевидна. Или они, как майкрософт, «предоставляют партнерам возможности для дополнения функционала».

шаринг данных между вкладками реализуется с помощью событий которые генерирует localStorage (ie8+, в остальных случаях по таймеру) реализуется элементарно, даже соединение, хотя не во всем понимаю зачем, случаи когда нужно достаточно редки.

Не умеет сжатие? А deflate-frame — это что?

А чтобы расшарить одно соединение между вкладками браузера есть какой-то костыль с использованием кук, ЕМНИП.

Имеет ли он те же функции, что AJAX? Имеет ли он то же назначение?

Всё же это немного разные вещи, хотя и с частично пересекающейся областью применения. Например, запрашивать какие-нибудь данные просто для отображения один раз (без реалтайма, постоянных обновлений и прочей обратной связи) гораздо проще через ajax.

Очень хочется отказаться от AJAX, ибо он устанавливает кучу лишних соединений.

Не он, а ты в своём коде:) Ещё не факт, кстати, что одно постоянно висящее соединение лучше, чем пара непостоянных коротких запросов. Всё зависит от задачи.

Вопрос не в том, как оно реализуется, а в том, какого хера это не включено в базовую поставку.

Не поддерживает пока сжатие никто.

У меня на фонтелле 1000 уников в день, осенью гонял всё на вебсокетах. Вообще все запросы от клиента к серверу. Оказалось проще переключиться на аякс, чем добиться вменяемой работы. То количество косяков, которое вылезло на сервере и клиенте, в реальном продакшене с 30к уников мне нафик не надо.

Вебсокеты реально использовать во вторичных плюшках, которые не жалко если сломаются. Ну, например, если не придет сразу уведомление о почте или о новом сообщении в чате - никто не помрет, а большинство и не заметит даже.

Конечно, когда-нибудь библиотеки доведут до ума. НО (!) я пока не видел больших деплоев. И очень бы хотелось пообщаться с теми, у кого заработает. Потому что запуск на локалхосте в 2 экземплярах - это совсем не то.

То есть, например, у меня есть страница, на которой будет выводиться список комнат чата. Допустим, кто-то создал новую комнату. Тогда клиенту по вебсокету приходит буквально «новая комната». После этого отправляется аякс запрос на сервер за моделью?? Или лучше по сокету прислать джисон этой модели??

Конечно сразу апдейт модели шлется. Там же относительно немного.

Вот если будете по клику на клиенте запрашивать вебсокетами обновления на 100-500 килобайт - сразу заметите что интерфейс тупит на несжатых данных. В этом случае аякс выгоднее. А еще проще и надежнее.

https://groups.google.com/forum/?fromgroups=&hl=ru#!topic/faye-users/429V...

Вот пруф насчет текущей памяти. Джеймс еще един косяк зафиксил на той неделе. Кстати, этот же пакет используется в SockJS, так что не думаю, что с ним ситуация была лучше, как бы его не хвалили. Он просто менее распространен, поэтому меньше отзывов о фейлах

Гита (пока) нет, есть вот что. 25 строчек, не считая мейкфайла. Запускаемый урл - первый и единственный аргумент командной строки.

А чтобы расшарить одно соединение между вкладками браузера есть какой-то костыль с использованием кук, ЕМНИП.

Устаревшая инфа, есть postMessage.

шаринг данных между вкладками реализуется с помощью событий которые генерирует localStorage (ie8+, в остальных случаях по таймеру)

Ехал кОстыль через кОстыль. postMessage/onmessage же (кстати, тоже осёл8+, а в браузерах можно ещё и нативными объектами JS обмениваться).

postMessage это для общения меж фрэймами или когда одно окно (или вкладка) было открыто jsом из другого. а для общения между вкладками которые были созданы не зависимо друг от друга и находятся на одном домене используются события localStorage.

Не поддерживает пока сжатие никто.

Sec-WebSocket-Extensions: deflate-frame не поддерживет ни один браузер, ни одна серверная часть или ни одна костылелиба?

А, они независимо созданы, но всё равно, что мешает засветить текущий id окна в localStorage и дальше гонять данные по postMessage?

Насчет всех-все-всех не знаю. Самые популярные либы, Faye и Socket.io точно не поддерживают. Как в браузерах - ХЗ.

Вот например https://github.com/LearnBoost/socket.io/issues/1148

id окна? м? window это объект, никаких идентификаторов (полей по которому его можно было бы получить) нету, передать сам window (в смысле указатель на него) из одного окна в другое независимо созданное нельзя, т.к. в локалсторадж надо все сериализовывать, я посмотрю как ты цикличный объект в json превращать будешь, а даже если превратишь то я посмотрю как ты по нему обратишься из другого окна к тому чей виндоу был сериализован, так как это будет уже другой объект.

в локалсторадж надо все сериализовывать

В браузерах - не надо. man structured clone algorithm.