Какие конкретные случаи использования требуют BOSH через WebSockets и длинный опрос? [закрытый]

сначала позвольте мне обратиться к готовности WebSockets:

WebSockets реализация Hixie-76 протокол поставляется и включен по умолчанию в Chrome, Safari и iOS (iPhone и iPad). Протокол Hixie-76 также поставляется, но по умолчанию отключен в Firefox 4 и Opera 11. The web-socket-js проект-это Flash-прокладка / polyfill, которая добавляет поддержку WebSocket (Hixie-76) в любой браузер со вспышкой.

другими словами, WebSockets доступен практически для каждого браузера в дикой природе.

причина, по которой Opera и Mozilla решили отключить протокол по умолчанию, заключается в теоретической озабоченности тем, что могут быть некоторые сломанные HTTP-прокси/посредники, которые могут быть атакованы/отравлены с помощью версий протокола Hixie. То же самое относится и к Flash, но Mozilla и Opera чувствовали более высокую ответственность за код, который они отправляют. Версии протокола HyBi (протокол был перенесен в IETF HyBi working group) решить проблему безопасности.

Mozilla, Opera, Google и Microsoft работают над реализацией протокола HyBi (хотя Microsoft поддерживает их как скачать отдельно на данный момент). Есть ветвь web-socket-js С поддержкой HyBi-07.

обновление: по состоянию на февраль 2013 года, последний hybi / IETF RFC 6455 spec поддерживается Chrome 14, Firefox 7, IE10, Opera 12.1, Safari 6.0 и web-socket-js Flash shim / polyfill. На мобильных устройствах IETF6455 поддерживается Safari на iOS 6.0, Opera Mobile 12.1, Chrome 14 для Android, Firefox 7 для Android и Blackberry 7. Оригинальный браузер Android по умолчанию не имеет поддержки WebSocket.

серверы WebSocket просты в реализации. Существует множество автономных и плагинов, большинство из которых поддерживают протокол Hixie-76 и HyBi версии:

• libwebsockets
• причал
• pywebsockets
• websockify
• розетка.IO
• phpwebsocket
• протокол:: WebSocket (perl)
• em-websocket (Руби)
• узел-websocket-сервер

BOSH vs WebSockets:

• задержка: хотя проект документа BOSH претендует на очень низкую задержку, BOSH будет трудно конкурировать с WebSockets. Если у вас нет идеальных условий, в которых HTTP / 1.1 поддерживается всеми посредниками и целевым сервером, клиенту BOSH и диспетчеру соединений необходимо будет восстановить соединения после каждого пакета и каждого таймаута запроса. Это значительно увеличит задержку и задержку дрожания. Низкий джиттер часто более важен для приложений реального времени, чем средняя задержка. Соединения WebSocket будут очень похожи по задержке и дрожанию на необработанные TCP-соединения. И даже в идеальных условиях задержка связи между клиентом и сервером BOSH (и, следовательно, туда и обратно) всегда будет выше, чем WebSockets: BOSH по-прежнему должен соблюдать HTTP-запрос-ответ семантика. Http streaming включает несколько ответов на запрос (путем разделения "одного" ответа на несколько частей), но не наоборот (каждое сообщение клиента является новым запросом).
• накладные расходы малого пакета: в WebSockets есть два байта накладных расходов кадрирования для небольших сообщения. В BOSH каждое сообщение имеет заголовки HTTP-запросов и ответов (легко 180+ байт для каждого раунда). Кроме того, каждое сообщение завернуто в XML (предположительно необязательно, но спецификация не определяет, как) с несколькими атрибутами, связанными с сеансом.
• сложности: хотя BOSH использует существующие механизмы в браузере, для реализации семантики BOSH требуется умеренно сложная библиотека JavaScript. Управление этим в Javascript также увеличит задержку и дрожание по сравнению с реализацией native / browser (или даже Flash).
• тяга: BOSH начал жизнь как способ сделать XMPP более эффективным. Он вырос из Сообщество XMPP и из того, что я могу сказать, получило очень мало тяги за пределами этого сообщества. Проекты документов для BOSH и XMPP разделены, но, похоже, очень мало реального использования BOSH без XMPP.

обновление:

только что нашел видео, где Ян Фетт обсуждает преимущества WebSockets над API канала, который похож на BOSH (в 44:00)