Сервер RPC на основе TCP (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, но, похоже, это не стоит проблем, когда дело доходит до ее реализации на клиентах . Кроме того, я не уверен, разрешит ли это двунаправленную связь в канале связи клиент <-> сервер.

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