Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
К сожалению, да, на сегодня поддержка WebSockets в браузерах только-только появляется.
Я сделал небольшой тест, на котором можно проверить поддерживается ли она в вашем браузере: websockets.ru/test.html
Я сделал небольшой тест, на котором можно проверить поддерживается ли она в вашем браузере: websockets.ru/test.html
Стоит добавить, что для протокола Bayeux также существует поддержка в Dojo, jQuery. И фактически данный протокол не является составной частью CometD, но безусловно используется в нем.
Ну проверить наличие WebSocket проще простого window.WebSocket либо true, либо false :)
а есть ли поддержка STOMP на стороне клиента?
Это однозначно уловка для реализации двунаправленного обмена, что может пригодиться и для чата в том числе
Просто добавлю — насчет уловки, мысль не моя, а расхожее мнение. Например, cometdaily.com/2007/12/11/the-future-of-comet-part-1-comet-today/ — Comet is a giant hack
при всем уважении к автору, который видимо разбирается в теме, статья нечитабельна. Имхо лучше не вываливать 150 технологий в один пост.
К сожалению, вынужден с вами согласиться. Здесть проблема в том, что WebSockets это очень сильное расширение HTTP в первую очередь в плане идеи. Попытка воспринимать его привычно и приводит к таким недопониманиям. Поэтому нужно время и серия хороших статей, чтобы разработчики прочувствовали всю прелесть WebSockets.
С другой же стороны для новичков станет сразу понятно куда двигаться когда будет столько новых слов на одной странице имеюзих отношение к одной теме.
Большой плюс WebSockets в его простоте. Эта простота состоит из двух вещей:
— не нужно наворачиватьвелосипед на помед массу протоколов и хаков, чтобы добиться желаемого результата — я имею ввиду Comet и Bayuex.
— на клиенте все делается очень просто — вы получили сообщение — вы его обработали. В большинстве случаев нам даже не нужно усложнять себе жизнь и тащить сюда Stomp и Ampq.
Давайте подумаем, что такое «подписка» в терминах Stomp? По сути это выраженное желание пользователя получать информацию по какому-то каналу, на который он «подписывается». Как это будет звучать в терминах WebSockets? Просто открыв веб-сокет на определенный УРЛ! И этого достаточно для 90% приложений.
Дело в том, что с приходом веб-сокетов мы уже можем легко выйти за ограничения 2 коннектов на домен. Раньше мы были вынуждены мультиплексировать все данные по одному каналу (привет, Bayeux). Поэтому, нам надо в каждом сообщении иметь некий признак откуда оно пришло.
Но теперь в этом нет необходимости: мы просто открывем столько каналов сколько нам надо. Если мы открыли сокет на какой-то урл — то это и значит, что мы на него «подписались». Причем, обратите внимание6 информация из этого сокета будет сразу попадать в нужное место. Нам не надо определять из какого канала она пришла и направлять ее нужному классу/объекту/функции. Теперь это само собой будет правильно роутиться!
— не нужно наворачивать
— на клиенте все делается очень просто — вы получили сообщение — вы его обработали. В большинстве случаев нам даже не нужно усложнять себе жизнь и тащить сюда Stomp и Ampq.
Давайте подумаем, что такое «подписка» в терминах Stomp? По сути это выраженное желание пользователя получать информацию по какому-то каналу, на который он «подписывается». Как это будет звучать в терминах WebSockets? Просто открыв веб-сокет на определенный УРЛ! И этого достаточно для 90% приложений.
Дело в том, что с приходом веб-сокетов мы уже можем легко выйти за ограничения 2 коннектов на домен. Раньше мы были вынуждены мультиплексировать все данные по одному каналу (привет, Bayeux). Поэтому, нам надо в каждом сообщении иметь некий признак откуда оно пришло.
Но теперь в этом нет необходимости: мы просто открывем столько каналов сколько нам надо. Если мы открыли сокет на какой-то урл — то это и значит, что мы на него «подписались». Причем, обратите внимание6 информация из этого сокета будет сразу попадать в нужное место. Нам не надо определять из какого канала она пришла и направлять ее нужному классу/объекту/функции. Теперь это само собой будет правильно роутиться!
Здесь есть одно маленькое Но.
Серверу может поплохеть от количества коннектов, например память ядра для буферов соединений закончится, или как вариант закончится количество соединений разрешённое ядру, или CPU завершится на управлении коннектами.
В общем на сколько нибудь живых проектах это может стать существенной проблемой требующей внимания.
Как оптимизацию производительности серверной части, я рассматриваю использование одного канала с подписками.
Серверу может поплохеть от количества коннектов, например память ядра для буферов соединений закончится, или как вариант закончится количество соединений разрешённое ядру, или CPU завершится на управлении коннектами.
В общем на сколько нибудь живых проектах это может стать существенной проблемой требующей внимания.
Как оптимизацию производительности серверной части, я рассматриваю использование одного канала с подписками.
По сути STOMP или AMQP не обязательны, но с одним из них можно реализовать event-driven architecture и вовлечь в нее клиент через Web Sockets, не заботясь ни о семантике потоков сообщений, ни о масштабируемости системы в целом. В случае полноценного стартапа, а не отдельно взятой задачи — Message Queue это то что надо. А если система еще и гетерогенная, то без «очереди» вообще не обойтись.
Кстати, а насколько сложно будет пользоваться веб сокетами не из браузера? Есть ли какие-то библиотеки для работы с ними?
По-моему никаких проблем — еще глядишь в curl какой-нибудь добавят. А уж в скриптовые языки и подавно, как только программисту более менее серьезного уровня это понадобится.
Здесь требования к клиенту tools.ietf.org/html/draft-hixie-thewebsocketprotocol-68#page-14
В указаном примере WebSocket.js (http://github.com/gimite/web-socket-js/blob/master/flash-src/WebSocket.as) представлена имплементация на Actionscript
В указаном примере WebSocket.js (http://github.com/gimite/web-socket-js/blob/master/flash-src/WebSocket.as) представлена имплементация на Actionscript
Собственно единственная проблема, которая все портит…
А как быть с клиентами, которые выходят в инет через прокси, настроенный злобными админами, закрывшими соединения по всем портам кроме 80?
А как быть с клиентами, которые выходят в инет через прокси, настроенный злобными админами, закрывшими соединения по всем портам кроме 80?
а разве тут не через 80 порт всё идет?
Сross-domain policy, к сожалению лезет через 843й порт.
Да. Это имхо недоработка в самом флеше.
С другой стороны, если вы коннектитесь к своему домену, то эта политика не должна вызываться и мешать.
Кто спец по флеш сокетам, поправьте меня плз.
Кто спец по флеш сокетам, поправьте меня плз.
Насколько я помню, в любом случае флешом запрашивается файл crossdomain.xml. Причём сначала на порт, на который идет дальнейший коннект. В принципе проблема решаемая, и у меня работало, когда я изобретал подобный велосипед.
Но а вот через фаервол, почему-то пробиться не получилось. В чём была проблема, вспомнить не могу.
Так что мне тоже, хочется услышать мнение флеш специалистов по этому поводу.
Но а вот через фаервол, почему-то пробиться не получилось. В чём была проблема, вспомнить не могу.
Так что мне тоже, хочется услышать мнение флеш специалистов по этому поводу.
Можно ли его отдавать с самого порта, куда идет подключение?
Походу нет.
Или как-то указать в параметрах флешки или еще где-то, что файл может быть запрошен с другого порта?
Походу нет.
Или как-то указать в параметрах флешки или еще где-то, что файл может быть запрошен с другого порта?
The crossdomain.xml file affects HTTP, HTTPS and FTP access to content on your webserver. (You can read more about it here.) This file has no effect on socket connections. You must set up a socket policy server to allow Flash-based socket access.
www.lightsphere.com/dev/articles/flash_socket_policy.html
www.lightsphere.com/dev/articles/flash_socket_policy.html
То есть для сокетных коннектов единственный вариант — спец. сервер на 843 порту?
Судя по всему можно использовать и другие порты www.actionscript.org/forums/showthread.php3?t=193211
Так даже сам вебсокет сервер биндится на 10081 порт например.
И туда соединяются клиенты.
Правда если это станет общепринятым стандартом, я думаю 10081 будут открывать также как и 80.
И туда соединяются клиенты.
Правда если это станет общепринятым стандартом, я думаю 10081 будут открывать также как и 80.
поправьте, пожалуйста, опечатку Flesh-объекту -> Flash-объекту
автор, в соседнем топике есть реализация чата на вебсокетах, ссылку неплохо бы в статью добавить
Какая-то каша у вас в голове.
> Long polling
Long polling отличается от HTTP Stream тем, что соединение открыто до тех пор, пока не придет первый ответ от сервера, после чего сам сервер соединение и закрывает. Клиент тут же открывает новое. HTTP Stream дежит соединение постоянно, разрывается оно только из-за проблем с сетью. Лонг поллинг нужен, например, что бы обходить всякие антивирусы, которые не отдают браузеру http запрос до тех пор, пока он не будет закрыт.
> script tags или scriptTagProxy
Две совершенно разных вещи, первая называется jsonp, нужна поддержка сервера на который идет запрос, а вторая проксирует запрос через специальный сервер, который уже и делает запрос.
> JSONRequest object ( www.json.org/JSONRequest.html ) — реализует двух-стороннее соединения, посредством двух одновременных запросов (один на передачу, другой на прием).
Ну а это просто бред.
> Long polling
Long polling отличается от HTTP Stream тем, что соединение открыто до тех пор, пока не придет первый ответ от сервера, после чего сам сервер соединение и закрывает. Клиент тут же открывает новое. HTTP Stream дежит соединение постоянно, разрывается оно только из-за проблем с сетью. Лонг поллинг нужен, например, что бы обходить всякие антивирусы, которые не отдают браузеру http запрос до тех пор, пока он не будет закрыт.
> script tags или scriptTagProxy
Две совершенно разных вещи, первая называется jsonp, нужна поддержка сервера на который идет запрос, а вторая проксирует запрос через специальный сервер, который уже и делает запрос.
> JSONRequest object ( www.json.org/JSONRequest.html ) — реализует двух-стороннее соединения, посредством двух одновременных запросов (один на передачу, другой на прием).
Ну а это просто бред.
Вчера написал простенький чат на JS в стиле Google Waves (участники видят набор текста друг друга в реальном времени). Работает одинаково шустро в Chrome 4 (WebSocket) и FireFox 3.5/Opera 10 (эмуляция)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Двунаправленный асинхронный обмен данными в веб-приложениях