Альтернативная реализация Server Push / Comet для браузера Android без отправки 4KB сообщений? - PullRequest
5 голосов
/ 23 ноября 2011

Я занимаюсь разработкой веб-приложения, которое использует метод Comet Hidden iFrame для передачи данных с сервера в мобильный браузер.

В Mobile Safari все отлично работает, но Android гораздо более болезненный.Похоже, для отправки сообщения с сервера необходимо отправить 4 КБ сообщения.Это относится не только к первым сообщениям.

Некоторые люди пытались реализовать Comet с использованием потоковой передачи XMLHttpRequest, но у них были те же проблемы с размером 4 КБ (http://code.google.com/p/android/issues/detail?id=13044)

заполнить сообщения до 4 КБ?

Протестировано на Android 2.1,2.2

Событие, отправленное на сервер, похоже, не поддерживается даже на версии Android 4.0 http://caniuse.com/eventsource

То же самое для websockethttp://caniuse.com/websockets

спасибо

-seb

Ответы [ 3 ]

2 голосов
/ 23 ноября 2011

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

Я считаю, что для вашей конкретной проблемы WebSockets - лучшая технология в сочетании с сервером WebSocket (node.js, Kaazing) с хорошими вариантами восстановления. Я больше знаком с Kaazing: он обеспечивает практически ту же производительность в браузерах, не совместимых с WebSocket, что и нативную производительность WebSocket. Подробнее об эмуляции WebSocket вы можете найти этот пост полезным в эмуляции WebSocket .

1 голос
/ 14 февраля 2012

На Android, и с браузерами, и с RGD. WebSockets:

  • Поддержка Firefox Mobile (включая окончательный RFC6455)

  • встроенный браузер не поддерживает WS вообще (до Android 4 включительно)

  • Chrome для мобильных устройств (полная RFC6455) .. доступна только для Android 4

1 голос
/ 23 ноября 2011

Эта проблема с буфером 4 КБ существует уже давно и все еще имеет место в настольных браузерах, а также в Android Internet.app (о котором я не знал).

Решение - отправитькусок 4KB с начальным соединением.И это один из сценариев, где HTTP Streaming является лучшим решением, чем HTTP Long-Polling .С потоковой передачей вы сохраняете соединение открытым, когда доступны новые данные, в отличие от Long-Polling, когда вы закрываете, а затем заново открываете соединение.Этот метод означает, что существует начальный неудачный кусок 4 КБ бесполезных данных, но все данные помимо этого являются фактическими данными (пригодными для использования).Я потратил часы своей жизни, возиться с этим размером буфера, и он иногда несовместим между веб-браузерами.

Но есть такие компании, как Caplin Systems , которые используют потоковую передачу HTTP на своем уровне предприятияприложения, используемые многочисленными финансовыми учреждениями, поэтому можно обеспечить стабильную работу.

Кому-нибудь удалось внедрить методы Comet в браузере Android без необходимости добавлять сообщения в 4 КБ?

Маловероятно, что это когда-либо случится.А WebSockets (как отметил @Peter Moskovits) - это способ, которым эта двунаправленная связь (с акцентом на толчок в настоящий момент) будет достигнута кросс-браузерно в будущем.Для Android это означает, что пользователю также потребуется установить на своем устройстве Flash для интернет-приложения, чтобы поддерживать технику аварийного переключения Flash, которая потребуется, поскольку на данный момент Android изначально не поддерживает WebSockets.

...