RPC-сервер на основе TCP (Erlang или что-то подобное?) Для связи приложений iOS / Android

Question

Я создаю собственные мобильные приложения для iOS и Android. Эти приложения требуют обновления в режиме реального времени с сервера и на сервер, так же как и любое другое сетевое приложение (Facebook, Twitter, социальные игры, такие как «Слова с друзьями» и т. Д.)

Я думаю, что использование длинного опроса HTTP для этого является чрезмерным уничтожением в том смысле, что длительный опрос может отрицательно сказаться на сроке службы батареи, особенно при большой настройке / отключении TCP. Возможно, имеет смысл, чтобы мобильные приложения использовали постоянные сокеты TCP для установления соединения с сервером и отправляли на сервер команды в стиле RPC для всех подключений веб-служб. Это, конечно, потребует, чтобы сервер обрабатывал долгоживущее TCP-соединение и имел возможность общаться с веб-сервисом, как только он понял данные, передаваемые по TCP-каналу. Я думаю о передаче данных в виде простого текста с использованием JSON или XML.

Возможно, RPC-сервер на основе Erlang хорошо подойдет для такого сетевого приложения. Это позволило бы мобильным приложениям отправлять и получать данные с сервера по всему соединению без многократной настройки / разрыва, которую отдельные HTTP-запросы будут выполнять, используя что-то вроде NSURLConnection на iOS. Поскольку ни один веб-браузер не задействован, нам не нужно разбираться с нюансами HTTP на уровне мобильного клиента. Многие из этих «COMET» и серверов с длинным опросом и потоковой передачей построены с учетом HTTP. Я думаю, что использование простого текстового протокола поверх TCP достаточно хорошо, оно сделает клиент более отзывчивым, позволит получать обновления с сервера и сохранит время автономной работы по сравнению с традиционными моделями длительного опроса и потоковой передачи.

Кто-нибудь в настоящее время делает это с родным приложением для iOS или Android? Вы написали свой собственный сервер или есть что-то с открытым исходным кодом, с которым я могу начать работать сегодня вместо того, чтобы заново изобретать колесо? Есть ли причина, по которой использование только RPC-сервиса на основе TCP является худшим решением, чем использование HTTP?

Я также изучил конвейеризацию HTTP, но, похоже, не стоит беспокоиться о том, чтобы реализовать его на клиентах. Кроме того, я не уверен, разрешит ли это двунаправленную связь в клиентском <-> канале связи сервера.

Любое понимание будет с благодарностью.

Answer 1

Использование сокетов TCP с вашим собственным протоколом свернуто гораздо лучше, чем HTTP, особенно с учетом характера ресурсов на мобильных устройствах.Erlang будет хорошо, но давайте начнем с вашего протокола.Erlang хорошо справляется с этим, особенно с выражениями Bit Syntax .Тем не менее, вы можете использовать простой текст по своему желанию.JSON (потребуется анализатор: Mochijson2.erl , найденный в библиотека Mochiweb ) и XML (потребуется анализатор: Erlsom ).

Я лично работал над проектом, в котором мы использовали необработанные сокеты TCP с нашими серверами Erlang и мобильными устройствами.Однако, в зависимости от выбранных номеров портов, маршрутизаторы на этом пути будут блокировать / отбрасывать пакеты в зависимости от политик безопасности поставщиков услуг.Тем не менее, я все еще думаю, что HTTP может работать.Люди общаются на Facebook Mobile, отправляют Twits и т. Д. Со своих устройств, и я уверен, что эти социальные движки используют какой-либо тип Long Polling или Server Push или что-то еще, но используют HTTP.В последнее время мобильные устройства стали более продвинутыми.

Использование собственного протокола на основе TCP сопряжено с рядом проблем: выбор порта, анализ данных как на клиенте, так и на сервере, проблемы безопасности и т. Д. Использование HTTP позволит вамПодумайте о реальной проблеме, чем тратить время на исправление проблем с протоколом на клиенте или сервере.Устройства, которые вы упомянули выше, такие как Android и IOS (Ipad, Iphone и т. Д.), Очень способны обрабатывать HTTP COMET (длинный опрос).Если вы соблюдаете стандарты для веб-приложений на мобильных устройствах , а также W3C Best Web Practices , ваше приложение будетхорошо функционируют, используя HTTP.

Использование методов HTTP ускорит работу, и в SDK этих устройств имеется множество библиотек, которые помогут вам создать прототип решения, которое вы хотите, по сравнению с ситуацией использования собственного TCPпростой текстовый протокол.Чтобы подкрепить эти рассуждения, просмотрите эти W3C выводы .

Позвольте мне наконец поговорить о преимуществах HTTP на этих устройствах.Если вы хотите использовать веб-технологии для мобильных устройств, такие как Opera Widgets , Phone Gap , SenchaКоснитесь и JQuery Mobile , в их SDK и библиотеках уже есть оптимизация, или есть хорошо документированные способы повышения эффективности вашего приложения.Кроме того, эти технологии имеют API для доступа к ресурсам собственных устройств, таким как проверка заряда батареи, SMS, MMS, каналы вещания GSM, контакты, освещение, GPS и память;все как API в классах JavaScript.Это станет трудным (негибким), если вы будете использовать родные языки программирования, такие как J2ME , Mobile Python или SymbianC ++ / Qt по сравнению с использованием веб-технологий, таких как CSS3, HTML5 и инструменты JavaScript, упомянутые выше.Использование веб-инструментов, упомянутых выше, сделает ваше приложение легко распространяемым, скажем, Магазин Ovi или Apple Store , исходя из опыта.

Обратите внимание, что если вы используете HTTP, тестирование будет простым.Все, что вам нужно, это общедоступный домен, поэтому виджеты на мобильном устройстве обнаруживают ваши серверы через Интернет.Если вы используете свой собственный протокол TCP / IP, сетевые маршрутизаторы могут нарушать работу используемого вами номера порта, если только вы не планируете использовать порт 80 или другой хорошо известный порт, но в этом случае IP-адрес вашего сервера все же необходимо будет сделать общедоступным.Существует короткий путь к этому: если вы разместите свой TCP-сервер за тем же Интернет-провайдером, что и тестируемое подключение к Интернету вашего мобильного устройства, маршрутизаторы Интернет-провайдера будут видеть источник и назначение как за своей сетью.Но в целом, есть проблемы с прокруткой собственного протокола.

Редактировать: Используя HTTP, вы получите REST .Веб-серверы, реализованные на языке Erlang (особенно челюсти и Mochiweb ), превосходят службы REST.Посмотрите на эту статью: RESTFUL сервисы с Yaws .Для mochiweb есть интересная статья о: Кометном приложении на миллион пользователей, использующем Mochiweb , которое разбито на 3 части.Кроме того, вы можете взглянуть на решение , данное этому вопросу .

Answer 2

Существует ZeroMQ сборок для Android и iOS. Привязки Java и ObjC также существуют.

HTTP был создан для нечастых запросов с большими ответами. Это очень неэффективно для передачи очень больших объемов маленьких порций данных. В типичной ситуации заголовки http могут быть в два раза больше фактической полезной нагрузки. Единственная сильная сторона HTTP - это его привычность, его карма «один размер подходит всем».

Если вы хотите легкое и быстрое решение, я думаю, ZeroMQ может быть идеальным решением.

Answer 3

Одной из причин использования HTTP вместо пользовательской службы является то, что она широко поддерживается на транспортном уровне.

С мобильными устройствами пользователь может пользоваться Wi-Fi в отеле, аэропорту, кафе.или корпоративная локальная сеть.В некоторых случаях это означает необходимость подключения через прокси.Пользователи вашего приложения будут счастливы, если приложение сможет использовать прокси-настройки устройства для подключения.Это дает наименьший сюрприз - если веб-браузер работает, то приложение также должно работать.

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

Хотя HTTP и пользуется широкой поддержкой, некоторые успешные проекты основаны на других протоколах.Разработчики Sipdroid обнаружили, что постоянные TCP-соединения значительно увеличивают время автономной работы.Их статья по этой теме не касается серверной части, но дает общее описание их подхода к клиенту.

Answer 4

Erlang очень хорошо подходит для вашего случая использования.Я бы предпочел использовать TCP по HTTP для экономии заряда аккумулятора телефона, как вы уже отмечали.

Как правило, установление связи между устройством и сервером будет очень простым.Протокол, который вы используете между ними, - это то, что потребует большей работы.Однако написание протоколов в Erlang поразительно прямолинейно при использовании gen_fsm

Вы должны ознакомиться с talk metajack на фабрике Erlang, которая подчеркивает его решение в очень похожем случаеего игра для iPhone Snack Words .

Answer 5

Все зависит от того, какие данные вы отправляете - размер, критичность своевременности, частота обновления и т. Д.

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

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

Опять же, как отмечали другие авторы, использование батареи является большой проблемой. Если вы не будете осторожны, вы съедите батарею, буквально сжёг дыру в кармане. Очень легко превратить батарею, которая длится 2 дня, в батарею, которая будет работать 6 часов.

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

Итак, вернемся к тому, что вы хотите сделать с приложением. Поскольку вы создаете для iOS (очевидно, родного) и Andriod, я бы использовал Apple Push Services и их систему уведомлений. Создайте свои серверные службы, чтобы поговорить об этом, а также предоставьте интерфейсы для устройств, не принадлежащих Apple (т. Е. Слушателей уровня http или tcp). Таким образом, одна платформа и несколько шлюзов для ваших приложений. Затем вы можете сделать RIM через их службу push, если хотите.

Answer 6

Я работаю над приложением, которое подключается к http-серверу Microsoft с долгоживущими подключениями http / https к мобильным устройствам, чтобы разрешить отправку данных push-типа на мобильный телефон. Это работает, но есть много маленьких ошибок на мобильной стороне.

• Чтобы клиент получил «пакеты» данных, мы переводим соединение http в режим Chucked Encoding , чтобы каждый пакет находился в одном пакетном пакете.

• Не все нативные службы HTTP API на каждом мобильном телефоне будут поддерживать обратный вызов при поступлении «куска» данных, если они не ожидают прибытия всех данных с сервера перед вызовом. приложение вернулось с данными. Платформы, которые поддерживают обратные вызовы с частичными данными, (которые я нашел):

  • Symbian
  • Windows Mobile

• Платформы, которые не поддерживают частичные обратные вызовы данных:

  • IOS
  • Blackberry

• Для платформ, которые не поддерживают частичные обратные вызовы, мы написали наш собственный код http-соединения с поддержкой кодирования по чаку с использованием встроенной поддержки sock. Это на самом деле не очень сложно.

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

• В IOS с этим фоном правила многозадачности означает, что вы не можете поддерживать это соединение, пока ваше приложение находится в фоновом режиме. Вам действительно нужно использовать услугу Apple Push Notification и жить в соответствии с ее ограничениями.

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

• Использование http / https упрощает прохождение правил брандмауэра на сайтах клиентов.

Я не уверен, что использование долгоживущих соединений http / https было самым мудрым решением, которое мы когда-либо принимали, но оно было принято задолго до того, как я появился, поэтому я должен смириться с последствиями этого.

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

Итак, это мой опыт использования http / https в качестве долговременного соединения в реальном времени.

Ваш пробег может варьироваться.