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

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

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

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

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

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

Любое понимание было бы весьма полезным.

Ответ 1

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

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

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

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

Позвольте мне, наконец, поговорить о преимуществах HTTP для этих Устройств. Если вы хотите использовать веб-технологии для мобильных устройств, например Виджеты Opera, Телефонный зазор, Sencha Touch b > и JQuery Mobile, их SDK и библиотеки имеют уже сделанные оптимизации или хорошо документированы в которое ваше приложение может быть эффективным. Кроме того, эти технологии имеют API для доступа к ресурсам собственных устройств, таких как проверка батареи, SMS, MMS, широковещательные каналы GSM, контакты, освещение, GPS и память; все как API-интерфейсы в классах JavaScript. Было бы трудно (негибко), если вы используете родные языки программирования, такие как J2ME, Mobile Python или Symbian С++/Qt по сравнению с использованием технологий Web, таких как CSS3, HTML5 и JavaScript, упомянутых выше. Использование упомянутых выше веб-инструментов сделает ваше приложение легко распространяемым, скажем, Ovi Store или Apple Store, из опыта.

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

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

Ответ 2

Есть ZeroMQ для Android и iOS. Также существуют привязки Java и ObjC.

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Чтобы клиент получал "пакеты" данных, мы помещаем http-соединение в режим Chucked Encoding, чтобы каждый пакет в одном пакетированном пакете.
Не все службы HTTP-интерфейса на каждом мобильном телефоне будут поддерживать обратный вызов, когда придет "патрон" данных, на тех, которые обычно не ждут, пока все данные с сервера не поступят до вызова приложение обратно с данными. Платформы, которые поддерживают обратные вызовы с частичными данными (я нашел):
- Symbian
- Windows Mobile
Платформы, которые не поддерживают обратные вызовы частичных данных:
- IOS
- Blackberry
Для платформ, не поддерживающих частичные обратные вызовы, мы написали собственный код http-соединения с поддержкой поддержки кодирования с поддержкой поддержки носков. Это на самом деле не очень сложно.
Не полагайтесь на то, что один патрон является одним из ваших пакетов, HTTP-прокси или встроенными реализациями HTTP-api может нарушить это предположение.
В IOS с этим фоном правила многозадачности означает, что вы не сможете сохранить это соединение, пока ваше приложение находится в фоновом режиме. Вам действительно нужно использовать службу Apples Push Notification и жить по ее ограничениям.
Никогда не доверяйте мобильным сотовым сетям, я видел, как самые неприятные вещи происходят, как на стороне сервера, видя, как происходит соединение с http-соединением, а затем повторно подключаться (и воспроизводить оригинальный HTTP-запрос), в то время как на мобильном устройстве вы не см. любое падение соединения. В основном рассматривайте связь как ненадежную, где данные могут отсутствовать. Мы завершили внедрение схемы с номером "tcp", чтобы гарантировать, что мы не потеряем данные.
Использование http/https упрощает прохождение правил брандмауэра на сайтах клиентов.

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

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

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

Ваше перемещение может отличаться.

Ответ 6

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

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

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

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

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

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