问题描述
我正在iOS和Android中构建本地移动应用程序。这些应用程序需要从服务器进行实时更新，与任何其他基于网络的应用程序（Facebook，Twitter，社交游戏，如朋友之类的话等）相同。我认为使用HTTP长轮询来解决这个问题，因为长时间的轮询可能会对电池寿命造成不利影响，特别是在大量的TCP设置/拆卸时。使移动应用程序使用持久TCP套接字建立与服务器的连接，并将RPC样式命令发送到服务器以进行所有Web服务通信，这可能是有意义的。这一方面，将需要一个服务器来处理长时间的TCP连接，并且一旦了解了传递到TCP管道上的数据，就能够与Web服务通话。我正在考虑使用JSON或XML传递纯文本的数据。
也许基于Erlang的RPC服务器对于像这样的基于网络的应用程序来说可以做得很好。这将允许移动应用程序从服务器发送和接收来自一个连接的数据，而不需要多个安装/拆卸，单个HTTP请求将使用iOS上的NSURLConnection等操作。由于没有Web浏览器不涉及，我们不需要处理移动客户端级别的HTTP的细微差别。许多这些COMET和长轮询/流服务器都是基于HTTP构建的。我正在考虑通过TCP使用纯文本协议是足够好的，将使客户端更加灵敏，允许从服务器接收更新，并通过传统的长轮询和流式传输模式保持电池寿命。
有没有人现在用他们的原生iOS或Android应用程序？你写了你自己的服务器，还是有一些开源的东西，我可以开始与今天的工作，而不是重新发明轮？有没有什么理由为什么只使用基于TCP的RPC服务是比使用HTTP更糟糕的决定？
我还研究了HTTP流水线，但它并不是值得在客户端实施的麻烦。此外，我不确定是否允许在客户端< - >服务器通信通道中进行双向通信。
任何见解将不胜感激。
使用自己的协议滚动的TCP套接字比HTTP特别是移动设备上的资源性质好得多。 Erlang会做得很好，但是从你的协议开始。 Erlang特别适用于 表达式。但是，您仍然可以根据需要使用纯文本。 JSON（需要一个解析器： Mochijson2.erl ）。
我亲自为我们的Erlang服务器和移动设备使用了原始TCP套接字的项目。但是，根据您选择的端口号，路由器将根据服务提供商的安全策略阻止/丢弃数据包。但是，我仍然认为HTTP可以工作。人们在Facebook Mobile上聊天，从他们的设备发送Twits e.t.c，并确信这些社交引擎使用某种长轮询或服务器推送，或使用HTTP。移动设备的后期功能有所提高。
滚动您自己的基于TCP的协议带有许多挑战：端口选择，在客户端和服务器上分析数据，安全问题等使用HTTP将让您想到实际的问题，而不是在客户端或服务器上花时间纠正协议问题。您上面提到的设备如Android和IOS（Ipad，Iphone e.t.c）非常有能力处理HTTP COMET（长轮询）。当您按照 以及这些 。
让我终于谈谈这些设备的HTTP优点。如果要使用移动设备的Web技术，例如 ， ， 和 ，他们的SDK和库已经为您完成了优化，或者有很好的记录方式可以使您的应用程序有效率。此外，这些技术还有API可以访问本机设备的资源，如电池检查，短信，彩信，GSM广播频道，联系人，照明，GPS和内存;全部作为JavaScript类中的API。如果您使用本地编程语言（如 ， 或 与使用上述CSS3，HTML5和JavaScript工具的Web技术相比。使用上述Web工具可以通过说 轻松分发您的应用程序或 ，从经验中。
请注意，如果您使用HTTP，测试将很容易。所有您需要的是一个公共的域，所以移动设备上的小部件通过Internet找到您的服务器。如果您角色自己的TCP / IP协议，则网络路由器可能会对您使用的端口号造成破坏，除非您计划使用端口80或其他已知端口，但是仍然需要将服务器IP设置为公开。有一个简短的说明：如果将TCP服务器放在与测试Mobile的Internet连接相同的ISP上，则ISP路由器将在源网络和目标网络后面看到它们。但是总而言之，滚动自己的协议有挑战。
编辑：使用HTTP，您将受益于 。在Erlang实施的Web服务器（特别是 和 ）优于REST服务。看看这篇文章： 。对于mochiweb，有一篇有趣的文章： ，分为3部分。此外，您还可以查看 。
I'm building native mobile applications in both iOS and Android. These apps require "realtime" updates from and to the server, same as any other network-based application does (Facebook, Twitter, social games like Words with Friends, etc)
I think using HTTP long polling for this is over kill in the sense that long polling can be detrimental to battery life, especially with a lot of TCP setup/teardown. It might make sense to have the mobile applications use persistent TCP sockets to establish a connection to the server, and send RPC style commands to the server for all web service communication. This ofcourse, would require a server to handle the long-lived TCP connection and be able to speak to a web service once it makes sense of the data passed down the TCP pipe. I'm thinking of passing data in plain text using JSON or XML.
Perhaps an Erlang based RPC server would do well for a network based application like this. It would allow for the mobile apps to send and receive data from the server all over one connection without multiple setup/teardown that individual HTTP requests would do using something like NSURLConnection on iOS. Since no web browser isn't involved, we don't need to deal with the nuances of HTTP at the mobile client level. A lot of these "COMET" and long-polling/streaming servers are built with HTTP in mind. I'm thinking just using a plain-text protocol over TCP is good enough, will make the client more responsive, allow for receiving of updates from the server, and preserve battery life over the traditional long polling and streaming models.
Does anyone currently do this with their native iOS or Android app? Did you write your own server or is there something open sourced out there that I can begin working with today instead of reinventing the wheel? Is there any reason why using just a TCP based RPC service is a worse decision than using HTTP?
I also looked into HTTP pipelining, but it doesn't look to be worth the trouble when it comes to implementing it on the clients. Also, I'm not sure if it would allow for bi-directional communication in the client<->server communication channel.
Any insight would be greatly appreciated.
Using TCP sockets with your own protocol rolled down is quite better than HTTP especially with the nature of resources on the mobile devices. Erlang will do quite well, however lets start from your protocol. Erlang excels well at this especially with the Bit Syntax expressions. However still, you could use plain text as you wish. JSON (would need a parser: Mochijson2.erl found in Mochiweb library) and XML (will need a parser: Erlsom).
I have personally worked on a project in which we were using raw TCP Sockets with our Erlang Servers and Mobile Devices. However, depending on the Port numbers you choose, Routers along the way would block/Drop packets depending on the security policies of service providers. However, i still think that HTTP can work. People chat on Facebook Mobile, send Twits e.t.c from their devices and am sure these social engines use some kind of Long Polling or Server Push or whatever but using HTTP. The mobile devices have advanced in capability of late.
Rolling your own TCP Based protocol comes with a number of challenges: Port selection, Parsing of data both at the client and server, Security issues e.t.c. Using HTTP will let you think of the actual problem than spending time correcting protocol issues at client or server. The Devices you've mentioned above like Android and IOS (Ipad, Iphone e.t.c) are very capable of handling HTTP COMET (Long polling). Am sure when you follow the standards for Web Applications on Mobile devices as well as these W3C Mobile Web Best Practices, your app will function well using HTTP.
Using HTTP methods will quicken the work and there are a lot of libraries on the SDKs of these Devices which would assist you prototype the solution you want as compared to the situation of rolling your own TCP-based plain text protocol. To back up this reasoning, look through these W3C findings.
Let me finally talk of the HTTP benefits on these Devices. If you are to use Web technologies for Mobile devices, such as Opera Widgets, Phone Gap, Sencha Touch, and JQuery Mobile, their SDKs and Libraries have Optimizations already done for you or have well documented ways in which your app can be made efficient. Further still, these technologies have the APIs to access the native Devices' resources like Battery check, SMS, MMS, GSM broadcast channels, Contacts, Lighting, GPS , and Memory; all as APIs in the JavaScript classes. It would become hard (inflexible) if you use native programming languages like J2ME, Mobile Python or Symbian C++ / Qt as compared to using Web technologies like CSS3, HTML5 and JavaScript tools mentioned above. Using the Web tools mentioned above will make your app easily distributable by say Ovi Store or Apple Store, from experience.
Take note that if you use HTTP, testing will be easy. All you need is a public Domain so the Widgets on the mobile device locates your servers over the Internet. If you role your own TCP/IP protocol, the Network Routers may be disruptive against the Port number you use unless you plan on using port 80 or another well known port, but then still your Server IP would have to be made Public. There is a short cut to this: if you put your TCP Server behind the same ISP as your testing Mobile's Internet connection, the ISP routers will see both source and destination as behind its Network. But all in all, there are challenges with rolling your own protocol.
Edit: Using HTTP, you will benefit from REST. Web Servers implemented in Erlang (especially Yaws and Mochiweb) excel at REST services. Look at this article: RESTFUL services with Yaws. For mochiweb, there is an interesting article about: A million User comet application using Mochiweb which is broken into 3 parts. Further still, you could look at the solution given to this question.
这篇关于基于TCP的RPC服务器（Erlang或类似的东西）用于iOS / Android应用程序通信的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！