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

Я создаю родные мобильные приложения как в 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, но не стоит беспокоиться о том, как это реализовать на клиентах. Кроме того, я не уверен, что это позволит двунаправленную связь на клиентском канале связи <-> сервера.

Любое понимание было бы высоко оценено.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • Symbian
    • Windows Mobile

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

    • IOS
    • ежевика

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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