Какую библиотеку WebSocket использовать в приложении Android?

Я хочу добавить Сервис в свое приложение для Android, которое работает в фоновом режиме с использованием соединения WebSocket (возможно, в течение нескольких часов или даже дней) и регулярно отправляет некоторые данные на сервер.

Теперь, похоже, существует множество библиотек WebSocket для Java, и я не уверен, какой из них я должен использовать:

  • TooTallNate / Java-WebSocket Описание от GitHub: Баботированная версия клиента и сервера WebSocket, написанная на 100% Java. Http://java-websocket.org/ – Это связано с моим первым результатом поиска в googling "android websocket" . Тем не менее, у него есть довольно много открытых вопросов, особенно о SSL-соединениях, и, похоже, в настоящий момент он не поддерживается.

  • Koush / AndroidAsync Описание от GitHub: асинхронный сокет, http (клиент + сервер), websocket и библиотека socket.io для Android. На основе nio, а не потоков. – Опять много открытых вопросов, но, похоже, активность поддерживается / работает.

  • Project Tyrus Описание с сайта: JSR 356: API Java для WebSocket – Реализация ссылок – это сделано Oracle. Не уверен, работает ли он на Android.

  • Информация о клиенте Jetty WebSocket Client с веб-сайта: Jetty также предоставляет клиентскую библиотеку Jetty WebSocket для написания облегчить общение с серверами WebSocket. – Снова: Не уверен, работает ли он на Android.

  • Codebutler / android-websockets Описание от GitHub: Минимальные веб-интерфейсы (hybi13 / RFC) для Android – этот используется в примере schwiz / android-websocket , который является принятым ответом на вопрос StackOverflow « Как сделать Android-устройство поддерживает TCP-соединение с Интернетом без блокировки слежения? ».

  • Atmosphere / wasync Описание от GitHub: WebSockets с резервным транспортом клиентской библиотеки для Node.js, Android и Java http://async-io.org

  • TakahikoKawasaki / nv-websocket-client Описание от GitHub: Высококачественная реализация клиента WebSocket на Java.

  • Square / okhttp Описание от GitHub: клиент HTTP + SPDY для приложений Android и Java. Http://square.github.io/okhttp/Он имеет модуль Websocket . Как упоминалось scorpiodawg , OkHttp имеет встроенную поддержку websocket с версии 3.5.

  • Firebase / TubeSock Описание от GitHub: клиентская библиотека WebSocket, реализованная в Java

  • Autobahn | Android ( GitHub ) Описание с сайта: Autobahn | Android – это сетевая библиотека с открытым исходным кодом для Java / Android, созданная проектом Autobahn, которая реализует протокол WebSocket и протокол обмена сообщениями веб-приложений (WAMP) для создания собственного мобильного WebSocket / WAMP клиентов. – cloudurfin отметил, что это не поддерживает wss.

Кроме того, есть родная клиентская библиотека socket.io для Android:

  • Nkzawa / socket.io-client.java Описание от GitHub: полнофункциональная клиентская библиотека Socket.IO для Java, совместимая с Socket.IO v1.0 и новее.

Использовать клиент сокета socket.io для Android было бы удобно для меня, потому что я планирую использовать nodejs / socket.io для веб-интерфейса в любом случае. Но родной клиент довольно молод и имеет несколько открытых проблем. И в дополнение к этому, я понимаю, что приложение для Android не имеет никакой пользы от использования клиентской библиотеки socket.io (кроме совместимости с сервером socket.io 1.0), поскольку поддержка WebSocket может быть обеспечена на стороне клиента ,

Мои требования заключаются в следующем:

  • Совместимость с Android API 9 и выше
  • Возможность подключения через SSL
  • Держите соединение в течение длительного времени без необходимости держать постоянный валок
  • Совместимость с доступной версией сервера nodejs websocket или с socket.io

Любые предложения, которые являются правильной библиотекой для этих требований?

Некоторые заметки.

  • Koush / AndroidAsync не выполняет закрытие рукопожатия, которое требуется RFC 6455 . См. Это для деталей.

  • Проект Tyrus работает на Android, но убедитесь, что его лицензия ( CDDL 1.1 и GPL 2 с CPE ) и его размер ( уменьшение размера банка клиента WebSocket с помощью ProGuard ) соответствуют вашим требованиям. Также обратите внимание, что Tyrus может генерировать исключение, когда размер текста большой (вероятно, это ошибка). См. Это для деталей.

  • Jetty : 2-летняя электронная почта в списке почтовых рассылок для приставок говорит: «В настоящее время у нас нет Android-совместимого клиента Jetty 9 WebSocket. Планируется попытка резервного копирования Jetty WebSocket Client с JDK 7 на JDK 5/6 для Android Но его более низкий приоритет, чем завершение нашей реализации JSR-356 Java WebSocket API (javax.websocket) ». В текущем документе Jetty о своем API-интерфейсе WebSocket Client ничего не говорится об Android.

  • Codebutler / android-websocket не выполняет закрытие рукопожатия, которое требуется RFC 6455 и может вызывать исключение при закрытии. Смотрите это .

  • Atmosphere / wasync использует AsyncHttpClient / async-http-client как свою реализацию WebSocket. Поэтому вместо этого следует упомянуть AsyncHttpClient / async-http-client.

  • Firebase / TubeSock не проверяет Sec-WebSocket-Accept . Это является нарушением RFC 6455 . Кроме того, у TubeSock есть ошибка при построении текстового сообщения. Вы будете сталкиваться с ошибкой рано или поздно, если вы используете многобайтовые символы UTF-8 для текстовых сообщений. См. Выпуск 3 в приложении « delight-im / Android-DDP» для длинного списка проблем TubeSock.

Точки рассмотрения

Вопросы оценки при выборе клиентской реализации WebSocket, написанной на Java:

  1. Соблюдение . Не небольшое количество реализаций не реализует закрытие рукопожатия, требуемое RFC 6455 . (Что произойдет, если закрытие рукопожатия не будет выполнено?).
  2. Требуемая версия Java . Java SE 5, 6, 7, 8 или Java EE? Работает даже на Android?
  3. Размер . Некоторые реализации имеют много зависимостей.
  4. Поддержка wss .
  5. Поддержка HTTP-прокси .
  6. Wss через поддержку HTTP-прокси . См. Рисунок 2 в разделе Как веб-сокеты HTML5 взаимодействуют с прокси-серверами о том, что должна делать клиентская библиотека WebSocket для поддержки wss через HTTP-прокси.
  7. Гибкость настройки SSL . SSLSocketFactory и SSLContext должны быть SSLSocketFactory без лишних ограничений.
  8. Пользовательские заголовки HTTP в начале рукопожатия , включая основную проверку подлинности.
  9. Пользовательские заголовки HTTP в согласовании HTTP-прокси , включая проверку подлинности на прокси-сервере.
  10. Возможность отправки всех типов фреймов (продолжение, двоичный, текст, закрыть, пинг и понг) или нет. Большинство реализаций не предоставляют разработчикам средства для отправки фрагментированных фреймов и незапрашиваемых кадров pong вручную.
  11. Интерфейс Listener для приема различных событий WebSocket. Плохой интерфейс заставляет разработчиков расстраиваться. Богатый интерфейс помогает разработчикам писать надежные приложения.
  12. Возможность запросить состояние WebSocket или нет. RFC 6455 определяет состояния CONNECTING, OPEN, CLOSING и CLOSED, но некоторые реализации поддерживают свой внутренний переход состояния определенным образом.
  13. Возможность установки значения тайм-аута для подключения сокета . (Эквивалентно второму аргументу метода Socket. connect (SocketAddress endpoint, int timeout) )
  14. Возможность доступа к базовому сырым сокетам .
  15. Интуитивно понятный простой в использовании API или нет.
  16. Хорошо документированы или нет.
  17. Поддержка RFC 7692 (расширения сжатия для WebSocket) (ака permessage-deflate).
  18. Поддержка перенаправления (3xx).
  19. Поддержка аутентификации Digest .

Nv-websocket-клиент охватывает все вышеперечисленное, за исключением последних двух. Кроме того, одна из его небольших, но удобных функций – периодически отправлять кадры ping / pong. Это может быть достигнуто только путем вызова setPingInterval / setPongInterval (см. JavaDoc ).

Отказ от ответственности: Такахико Кавасаки является автором nv-websocket-клиента.

Некоторые другие соображения:

Тирус работает на Android. Тем не менее, библиотеки SSL, которые он использует в Android 5.0, являются ошибочными и не позволяют SSL-квитирование . Предполагается, что это исправлено в новых версиях Android, но с тем, что Android не обновляется на многих устройствах, это может быть проблемой для вас.

В зависимости от того, как SSL реализуется для других реализаций websocket, это также может быть проблемой.

У AndroidAsync нет этой проблемы с SSL. У этого есть другие проблемы, такие как невозможность установить тайм-ауты .