当套接字可用时使用 HTTP 长轮询（例如 iPhone、Blackberry）
我目前正在服务器和 Web/iPhone/Blackberry 客户端上使用 Node.js 编写一个简单的跨平台应用程序。带宽和延迟要求与您在 IRC“派对游戏”或任何聊天系统中看到的类似。我使用 HTTP 长轮询（双向使用 JSON）开发了 Web 客户端。
对于 iPhone/blackberry，我可以使用内置的 HTTP 库与我当前的实现进行对话，或者我可以在服务器上编写一个套接字侦听器并使用套接字与其进行对话。这样做有什么好处吗？为什么非浏览器 HTTP 客户端似乎不受欢迎？
I'm currently writing a simple cross platform app with Node.js on the server and web/iPhone/Blackberry clients. Bandwidth and latency requirements are similar to something you would see in an IRC "party game" or any chat system. I've developed the web client using HTTP long polling (speaking JSON both ways).
For iPhone/blackberry I could use the built in HTTP libraries to talk to my current implementation, or I could write a socket listener on the server and talk to it using sockets. Is there any advantage to doing so? Why do non-browser HTTP clients seem to be discouraged?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
无法与 iPhone 对话，因为我对网络堆栈的技术细节了解不够，但对于 BlackBerry，来自浏览器的 HTTP 请求的处理方式通常与应用程序发起的请求不同。 BlackBerry 作为一种解决方案，不仅包含设备端 TCP/HTTP 堆栈，还包含 BlackBerry 服务，其中包括（取决于您是否是企业）带有移动数据服务 (BES/MDS) 的 BlackBerry Enterprise Server，托管在您的企业网络或 Research In Motion 托管的 BlackBerry Internet Services (BIS) 服务器，该服务器代理来自移动浏览器的所有连接。这些服务器可以做很多事情，包括处理 cookie、身份验证和内容转码的某些方面，以使移动设备更容易使用内容（图像等）。对于 BES/MDS，它们甚至可以充当 HTTPS 连接中的安全端点。
无论如何，这也意味着您期望从正常 TCP/HTTP 连接获得的许多功能实际上是在设备外发生的，因此可以由运营商、企业或 RIM 控制。简单的套接字是不同的，因为中间的各种服务器不能像对 HTTP 连接那样对 TCP 套接字做出尽可能多的假设，因此它们不能干扰您的 HTTP 请求。出于这个原因，许多 BlackBerry 应用程序实际上最终会在套接字层之上编写自己的 HTTP 客户端，因此，如果您必须执行类似 HTTP 长轮询（Comet？）之类的操作，那么一定要将其编写在套接字连接之上，不是内置的 HTTP 连接。
Can't speak to iPhone as I don't know enough about the technical details of the network stack, but for BlackBerry HTTP requests from the browser are treated differently from app-initiated requests in general. BlackBerry as a solution consists not just of a device-side TCP/HTTP stack, but the BlackBerry service, which includes (depending on if you're enterprise or not) a BlackBerry Enterprise Server with Mobile Data Services (BES/MDS) hosted on your enterprise network, or a Research In Motion hosted BlackBerry Internet Services (BIS) server, which proxy all connections from the mobile browser. These servers can do a lot of things, including handling some aspects of cookies, authentication, and content transcoding to make content more consumable by the mobile device (images and the like). For a BES/MDS they can even act as the secure endpoint in an HTTPS connection.
Anyway, this also means that a lot of the functionality you'd expect from a normal TCP/HTTP connection actually happens off the device, and so can be controlled by a carrier or enterprise or RIM. Bare-bones sockets are different because the various servers in the middle can't make as many assumptions about a TCP socket as they can about an HTTP connection, so they can't mess around with your HTTP requests. A lot of BlackBerry apps actually end up writing their own HTTP client on top of the socket layer for that very reason, so if you have to do something like an HTTP long poll (Comet?) definitely write it on top of the socket connection, not the built-in HTTP connection.