iPhone上的COMET（服务器推送到客户端）[关闭]答案

【问题标题】：COMET (server push to client) on iPhone [closed]iPhone上的COMET（服务器推送到客户端）[关闭]
【发布时间】：2010-09-25 04:15:31
【问题描述】：

我正在寻找从我的服务器到我的 iPhone 应用程序的某种套接字/COMET 类型的功能。本质上，任何时候用户设法在服务器上设置任意对象“脏”，比如更新他们的地址..反馈应该从服务器推送到任何保持对服务器进行实时轮询的客户端。我想这个流行语是彗星。我知道有用于 Web 浏览器应用程序的 DWR，所以我在想，也许最好在我的每个控制器中设置一个隐藏的 UIWebView，这样我就可以从他们的 javascript 框架中开箱即用 COMET？有没有更优雅的方法？

【问题讨论】：

标签： iphone objective-c cocoa-touch http comet

【解决方案1】：

有几种解决方案可用于使用STOMP 客户端。

STOMP 非常简单轻巧，非常适合 iPhone。

我使用this one 作为我的起点，发现它非常好。它有一些对象分配/内存泄漏问题，但是一旦我掌握了 iPhone 编程的窍门，这些问题就很容易解决了。

希望有帮助！

【讨论】：

【解决方案2】：

你可以在你的应用程序中使用普通的 TCP/IP 套接字吗？

A) 如果是，那么原始 TCP/IP 套接字绝对是更优雅的解决方案。在您的 iPhone 应用程序中，您只需等待通知事件。只要您的应用程序打开，套接字就会打开。如果您愿意，您甚至可以使用 HTTP 协议/标头。

在服务器端，您可以使用一些框架来编写有效处理数千个打开的 TCP/IP 连接的服务器。例如Twisted、EventMachine 或 libevent。然后只需将服务器主套接字绑定到 http 端口（80）。

这个想法是使用一个服务器，每个客户端只保留一个数据结构。从某个数据库应用程序接收更新事件，然后将其推送到正确的客户端。

B) 不，您必须在 iPhone 端使用 Apache 和 http 客户端。 那么您应该知道，整个 COMET 解决方案实际上是针对 HTTP 协议和 Apache / PHP 的限制而工作的。

Apache 旨在处理许多短时连接。据我所知，只有最新版本的 Apache（mpm worker）可以有效地处理大量打开的连接。以前 Apache 为每个连接保留一个进程。

Web 浏览器对一个 Web 服务器的并发打开连接有限制（实际上是 URL 地址，例如 www.foo.com，而不是 www.foo.com 的 IP 地址）。并且限制是 2 个连接。此外，浏览器将只允许 AJAX 连接到从其下载主 HTML 页面的同一服务器。

【讨论】：

【解决方案3】：

我写了一个web server 来做这种事情。我正在使用长轮询通过服务器推送实时更新，例如，我有 safari on the iPhone 显示该数据。

一个给定的服务器实例应该能够处理几千个并发客户端，而无需太费力。我有一个计划将它们放在一个层次结构中，以允许更多的水平缩放（应该很简单，但不会影响我当前的应用程序）。

【讨论】：

【解决方案4】：

WebSync 有一个可以在 iPhone 上运行的 javascript 客户端，如果你想要的话

【讨论】：

【解决方案5】：

长时间轮询对您想要实现的目标有用吗？您可以在几行常规 Javascript 中实现客户端，这将比任何框架都轻。

在 ObjC 中实现它也很简单（连接，等待响应或超时，重复）

我的问题Simple "Long Polling" example code? 的答案希望能解释长轮询是多么简单..

基本上，您只需像往常一样请求一个 URL - 网络服务器会接受连接，但在可用之前不会发送任何数据。当您收到数据或连接超时时，您重新连接（并重复）

最复杂的部分是服务器端，因为您不能使用像 Apache 这样的常规线程网络服务器，尽管 Comet 也是如此。

【讨论】：

【解决方案6】：

StreamHub Comet Server 可与 iPhone 一起使用，无需任何插件或任何东西。只需在我的 iPhone 上浏览他们的网站，所有示例都有效，不需要安装 Flash 或任何东西。

【讨论】：

【解决方案7】：

您是否希望/已经通过 http 为您的应用程序进行通信？如果没有，您可以使用 CFNetwork 框架使用套接字 (TCP/UDP) 来允许您的应用程序和服务器进行通信。从我所看到的 CFNetwork 堆栈来看，它非常酷，并且可以非常严格地读写流，并允许同步和异步通信。它还允许您在套接字上定义回调，从而让您获得有关接收到数据、建立连接等事件的通知。因此，在您的示例中，您可以通过套接字将信息发送到服务器，然后您可以定义一个回调将侦听流中的传入数据，然后相应地更新您的应用程序。

编辑：做了更多研究，如果您采用套接字方法，您可能还想查看 NSStream 类。它们是构建在 CFSocket 之上的 Cocoa 抽象。

【讨论】：

使用原始套接字会更容易（而且性能肯定会更好），但某些运营商不支持。确保提供 Comet 或标准 HTTP 轮询后备
很好地呼吁运营商支持，一开始没想到...

【解决方案8】：

您没有提及您使用的服务器端技术。但如果它是 microsoft .net（或任何其他遇到此问题的谷歌用户），comet 有一个简单的选项：http://www.codeplex.com/ncomet。

【讨论】：

【解决方案9】：

COMET、LightStreamer、AJAX 所有这些垃圾都被破坏了。 TCP 的基本原理是，如果没有 ping 流量，就无法保证“保持活动”。因此，如果要保证任何体面的可靠性或及时交付，你可以忘记长轮询。

这只是 2003 年跛脚狂热开始时每个人都看穿的炒作..

【讨论】：

如果需要，您可以随时发送心跳作为响应的一部分。对于 javascript 响应，您可以发送 void();每隔一段时间，直到你有真正的数据要发送。 Comet 在 HTTP 是强制性的情况下是一个很好的解决方案（即 Web 应用程序、仅限 HTTP 的外部蜂窝网络等）
重点是它不再是一个长时间运行的轮询，加上你需要另一个 TCP 连接，再加上在服务器上维护......
所以 JavaScript 必须发送并继续发送。让它超过 10 秒，你就会知道 UI 体验会很糟糕。现在开始缩放它。即使有持久的连接，当它变坏时，它真的会像所有黑客攻击一样变得糟糕......
Facebook Chat 和 Gmail 中的 Google Talk 客户端都能够毫无问题地做到这一点（两者都可以正常扩展）您只需要每 ~250 秒左右发送一次心跳（TCP 限制，而不是 HTTP ) HTTP 1.1 将允许将连接重用于多个请求。
说您的 Gmail 始终是响应式的？啊，即使在内部也是众所周知的问题。 250 秒是巨大的，为了及时交付，您通常需要 5 秒的 ping，如果某事需要 2 倍资源，它几乎可以告诉您一切。破碎的。 TCP 没有限制 ~1 秒，它是特定于应用程序的选择。