用于iOS / Android应用程序通信的基于TCP的RPC服务器(Erlang或类似的?)

我在iOS和Android上构build原生移动应用程序。 这些应用程序需要来自服务器的“实时”更新,与任何其他基于networking的应用程序(Facebook,Twitter,社交游戏,如Words of Friends等)相同,

我认为使用HTTP长轮询对于这种情况已经过分了,因为长时间轮询会对电池寿命造成不利影响,尤其是在大量TCP设置/拆卸的情况下。 让移动应用程序使用永久的TCP套接字来build立与服务器的连接,并发送RPC样式的命令到服务器以进行所有的Web服务通信可能是有意义的。 这当然需要一个服务器来处理长期的TCP连接,并且一旦理解了通过TCPpipe道的数据,就能够与Web服务通信。 我正在考虑使用JSON或XML以纯文本格式传递数据。

也许基于Erlang的RPC服务器对于像这样的基于networking的应用程序来说可能会很好。 这将允许移动应用程序发送和接收来自服务器的数据全部通过一个连接,而没有多个设置/拆卸单个的HTTP请求会使用像iOS上的NSURLConnection。 由于不涉及Web浏览器,我们不需要在移动客户端处理HTTP的细微差别。 很多这些“COMET”和长轮询/stream媒体服务器都是以HTTP为基础构build的。 我正在考虑在TCP上使用纯文本协议是否足够好,会使客户端更具响应性,允许从服务器接收更新,并在传统的长轮询和stream式传输模式上保持电池寿命。

有没有人目前这样做与他们的本机iOS或Android应用程序? 你有没有写自己的服务器,还是有开源的东西,我可以开始工作,而不是重新发明轮子? 为什么只使用基于TCP的RPC服务比使用HTTP更糟?

我也研究过HTTPstream水线,但是在客户端上实现它看起来并不值得。 另外,我不确定是否允许在客户端服务器通信通道中进行双向通信。

任何有识之士将不胜感激。

使用您自己的协议下的TCP套接字比HTTP更好,尤其是移动设备上的资源。 Erlang会做得很好,但是让我们从你的协议开始吧。 特别是在位语法expression式中,Erlang很擅长。 不过,你仍然可以使用纯文本。 JSON(需要一个parsing器:在Mochiweb库中findMochijson2.erl )和XML(需要parsing器: Erlsom )。

我个人曾在一个项目中使用原始TCP套接字与我们的Erlang服务器和移动设备。 但是,根据您select的端口号,路由器会根据服务提供商的安全策略阻止/丢弃数据包。 不过,我仍然认为HTTP可以工作。 人们在Facebook Mobile上聊天,从他们的设备发送Twits等,并确保这些社交引擎使用某种长轮询或服务器推或任何,但使用HTTP。 移动设备的function已经进入了后期。

滚动您自己的基于TCP的协议带来了许多挑战:端口select,在客户端和服务器parsing数据,安全问题等使用HTTP可以让您想到实际的问题,而不是花时间在客户端或服务器上纠正协议问题。 上面提到的设备,如Android和IOS(Ipad,Iphone等),能够处理HTTP COMET(长轮询)。 当您遵循移动设备上的Web应用程序标准以及这些W3C Mobile Web最佳实践时 ,您的应用程序将使用HTTP良好运行。

使用HTTP方法将加速工作,并且在这些设备的SDK上有许多库,这将有助于您制作您想要的解决scheme的原型,而与自己的基于TCP的纯文本协议的情况相比。 为了支持这个推理,看看这些W3C的发现

最后让我谈谈这些设备上的HTTP优势。 如果您要为移动设备(如Opera WidgetPhone GapSencha TouchJQuery Mobile)使用Web技术,则他们的SDK和库已经为您完成了优化,或者具有良好文档logging的方式来使您的应用程序变得高效。 此外,这些技术还具有API访问本地设备的资源,如电池检查,短信,彩信,GSM广播频道,联系人,照明,GPS和内存; 全部作为JavaScript类中的API。 与使用上述CSS3,HTML5和JavaScript工具等Web技术相比,如果使用J2MEMobile PythonSymbian C ++ / Qt等本机编程语言,将会变得很难(不灵活)。 使用上面提到的Web工具可以让您的应用程序轻松地通过Ovi商店Apple Store的经验来分配。

请注意,如果您使用HTTP,testing将很容易。 所有你需要的是一个公共领域,所以移动设备上的小工具通过互联网find你的服务器。 如果您使用自己的TCP / IP协议,则除非您计划使用端口80或其他众所周知的端口,否则networking路由器可能会破坏您使用的端口号,但是您的服务器IP仍然必须公开。 这里有一个捷径:如果你把你的TCP服务器放在与你的移动互联网连接相同的ISP后面,那么ISP路由器将会在它的networking后面看到源和目的地。 但是总而言之,在推出自己的协议方面存在挑战。

编辑:使用HTTP,您将受益于REST 。 在Erlang中实现的Web服务器(特别是YawsMochiweb )在REST服务方面performance优异。 看看这篇文章: Yaws的RESTful服务 。 对于mochiweb,有一篇关于以下内容的有趣文章: 使用Mochiweb的一百万个用户彗星应用程序被分成三部分。 还有,你可以看看这个问题解决scheme

有Android和iOS的ZeroMQ构build。 Java和ObjC绑定也存在。

HTTP是针对大量响应的不经常请求而创build的。 传输非常大量的小数据块是非常低效的。 在典型情况下,http头可以是实际有效载荷大小的两倍。 HTTP的唯一强大的一面是它的习惯,即“一刀切”的业力。

如果你想要轻量级和快速的解决scheme,我想ZeroMQ可以是一个完美的解决scheme。

使用HTTP而不是定制服务的一个原因是它在传输层面得到了广泛的支持。

通过移动设备,用户可能在酒店,机场,咖啡厅或企业局域网上使用Wi-Fi。 在某些情况下,这意味着必须通过代理连接。 如果应用程序能够使用设备的代理设置进行连接,则应用程序的用户将会感到最开心。 这提供了最less的惊喜 – 如果网页浏览工作,那么应用程序也应该工作。

HTTP非常简单,编写一个接受来自客户端的HTTP请求的服务器并不困难。 如果你决定走这条路,最好的解决scheme就是你不需要支持的解决scheme。 如果你可以在Erlang中编写一些支持应用程序更改的东西,那么这听起来像是一个合理的解决scheme。 如果你不习惯这样做,那么PHP或J2EE可以获得廉价劳动力的奖励。

尽pipeHTTP得到广泛的支持,但一些成功的项目是基于其他协议的。 Sipdroid开发人员发现持久的TCP连接可以大大延长电池寿命。 他们关于这个主题的文章没有涉及到服务器端,但它确实给出了他们在客户端的方法的高级描述。

Erlang非常适合您的使用情况。 为了节省电话的电池寿命,我更喜欢使用TCP over HTTP。

通常让设备和服务器之间的通信正常运行将是非常容易的。 你在两者之间使用的协议是最需要的工作。 然而,在使用gen_fsm时,在Erlang中编写协议是非常直截了当的

你应该在Erlang工厂检查metajack的谈话 ,突出他的解决scheme,为他的iPhone游戏Snack Words一个非常相似的用例。

我工作的应用程序连接到一个微软的HTTP服务器与移动设备的长期HTTP / HTTPS连接,以允许推送型数据发送到移动。 它的工作原理,但移动端有很多小问题。

  • 为了让客户端获得“数据包”,我们把http连接设置为Chucked Encoding模式,这样每个数据包就在一个卡盘中 。

  • 在每个移动设备上,并不是所有的本地http API服务都会支持在数据“卡盘”到达时给您打电话,这些数据通常不会等到服务器的所有数据都已经到达,然后再用数据调用应用程序。 支持部分数据callback的平台是(我发现):

    • 塞class
    • Windows Mobile

  • 不支持部分数据callback的平台:

    • IOS
    • 黑莓

  • 对于不支持部分callback的平台,我们用自己的sock支持编写了我们自己的http连接代码,使用chucked编码支持。 其实不是很难。

  • 不要依赖于一个chuck是你的数据包之一,http代理或本地的http api实现可能会打破这个假设。

  • 在具有此背景多任务规则的 IOS上,意味着当应用程序处于后台时,无法保持此连接。 你真的需要使用苹果推送通知服务,并因此受到限制。

  • 永远不要相信移动蜂窝networking,我已经看到最奇怪的东西继续像服务器端看到http连接丢弃,然后重新连接(和重播原始的http请求),而在移动端,你看不到任何连接下降。 基本上把连接视为不可靠的地方可能会丢失数据。 我们最终实现了像序列号scheme那样的“tcp”,以确保我们不会丢失数据。

  • 使用http / https可以更轻松地通过客户站点上的防火墙规则。

我不确定使用http / https长期的连接是我们做出的最明智的决定,但是在我出现之前就已经很久了,所以我必须忍受掉它。

作为一种替代,我们也在看网页套接字,但是在网页套接字规范处于stream动状态,并且通常不太好遵循的时候,我不知道它是否能够正常工作。

所以这是我使用http / https作为长期实时连接的经验。

你的milage可能会有所不同。

这一切取决于你发送的数据 – 它的大小,及时性的重要性,更新的频率等。

如果你正在寻找一个相当懒惰的更新和详细的数据(JSON说),然后去一个HTTP彗星模式,因为你会发现更容易浏览标准的networking设备,如其他答案突出显示。 例如,如果您在企业防火墙/代理的后面,http将是一个更安全的赌注。

然而,如果你正在做小数据量的快速事情,那么就去一些本土的东西,并利用TCP连接。 这是更重要的,你会发现实际performance更好。 简单的数据结构,并使用快速的运算符来根据需要分割数据。

正如其他海报所指出的,电池的使用是一个大问题。 如果你不小心的话,你可以通过在口袋里烧一个洞来吃电池。 将持续2天的电池变成持续6小时的电池是非常容易的。

最后,如果你对时间敏感,不要相信networking。 如果你不是,那么通过HTTP进行的长时间轮询对你来说将会很好。 但是,如果您正在寻找高性能的消息传递,那么要清醒地意识到移动networking不是一个端到端的TCP连接。 您的请求会因行程时间和延迟而有所不同。

所以回到你想要做的应用程序。 正如你正在为iOS(本地明显口授)和Andriod构build,我会利用苹果推送服务和他们的通知框架。 build立你的后端服务来谈谈,并提供非苹果设备(即HTTP或TCP级听众)的接口。 这样一个平台和多个“网关”为您的应用程序。 如果你愿意的话,你也可以通过推送服务来做RIM。