Servidor RPC baseado em TCP (Erlang ou algo semelhante?) Para comunicação de aplicativos iOS / Android

Estou criando aplicativos móveis nativos no iOS e no Android. Esses aplicativos requerem atualizações "em tempo real" de e para o servidor, da mesma forma que qualquer outro aplicativo baseado em rede (Facebook, Twitter, jogos sociais como o Words with Friends etc.)

Acho que o uso de sondagens longas por HTTP para isso acaba com a morte, no sentido de que as sondagens longas podem ser prejudiciais à vida da bateria, especialmente com muitas configurações / desmontagens de TCP. Pode fazer sentido que os aplicativos móveis usem soquetes TCP persistentes para estabelecer uma conexão com o servidor e enviem comandos no estilo RPC ao servidor para toda a comunicação de serviço da web. É claro que isso exigiria que um servidor manipulasse a conexão TCP de longa duração e pudesse falar com um serviço da Web, uma vez que entendesse os dados transmitidos pelo canal TCP. Estou pensando em passar dados em texto sem formatação usando JSON ou XML.

Talvez um servidor RPC baseado em Erlang funcione bem para um aplicativo baseado em rede como este. Isso permitiria que os aplicativos móveis enviassem e recebessem dados do servidor em uma conexão sem várias configurações / desmontagens que as solicitações HTTP individuais fariam usando algo como NSURLConnection no iOS. Como nenhum navegador da web não está envolvido, não precisamos lidar com as nuances do HTTP no nível do cliente móvel. Muitos desses servidores "COMET" e de pesquisa longa / streaming são criados com o HTTP em mente. Acho que apenas o uso de um protocolo de texto sem formatação sobre TCP é bom o suficiente, tornará o cliente mais responsivo, permitirá o recebimento de atualizações do servidor e preservará a vida útil da bateria nos modelos tradicionais de pesquisa e streaming longos.

Alguém atualmente faz isso com o aplicativo nativo para iOS ou Android? Você escreveu seu próprio servidor ou há algo de código aberto por aí com o qual eu possa começar a trabalhar hoje em vez de reinventar a roda? Existe alguma razão pela qual usar apenas um serviço RPC baseado em TCP é uma decisão pior do que usar HTTP?

@I também investigou o pipelining HTTP, mas não parece valer a pena quando se trata de implementá-lo nos clientes. Além disso, não tenho certeza se isso permitiria a comunicação bidirecional no canal de comunicação do cliente <-> servidor.

Qualquer insight seria muito apreciad

questionAnswers(6)

yourAnswerToTheQuestion