我目前正在为 iOS 设计一个应用程序（使用 MonoTouch），它将在 Windows Azure 上运行一个服务器组件。该应用程序本质上是一个聊天类型的应用程序，用户将在其客户端中生成消息并将它们发送到服务器，然后服务器需要将这些消息转发（尽可能快）到用户可能正在发送消息的其他客户端至。
我的问题是 - 是否有推荐的做法来构建这样的应用程序，客户端需要从服务器接收“推送”消息？
我考虑了一些选择，但希望得到反馈。
第一种选择是使用 Apple 的推送通知服务 (APN)。我对此有两个担忧——首先，客户端只需要在他们在线时接收消息（APNs 也会在应用程序关闭时发送消息，我不需要或不想要）；其次，有可能会有大量消息，我知道苹果可能会对此感到不满（完全公平）。
我考虑的第二个选项是使用 Web 服务（基于 WCF）并让客户端每（例如）2-3 秒调用一次该服务，这是我们可以容忍的最大延迟。不过，这似乎涉及大量可能不必要的网络流量（“你有什么要给我的吗？”、“没有”、重复令人作呕）。
第三种选择是在客户端和服务器之间保持持久的 Web 服务连接。当客户端应用程序启动时，它会在后台线程上调用 Web 服务方法。服务器将保持连接打开（不返回任何内容），如果有任何消息通过，它将立即返回它们。此连接可能会在 2 分钟后超时，此时它将重新建立。这似乎可以满足我的要求，但我再次担心，任何时候都会有很多连接打开到服务器，这可能会不必要地占用服务器资源。
第四种选择是通过 TCP（或 UDP，尽管根据我的发现，Windows Azure 不支持此）使用持久连接。这似乎是一个不错的选择，但同样，在服务器使用方面可能有点过头了——任何时候都可能有数百甚至数千个客户端连接。
第五个选择是让服务器以某种方式将消息直接推送到客户端，可能通过让客户端运行迷你 Web 服务器或类似的方式。但是，由于该应用程序将在 3G 和 WiFi 网络（超出我的控制范围）上运行，我不希望传入端口会为此类事情打开。
如果有人有任何其他建议，或者认为上述选项之一是个好主意（或者是解决此类问题的标准方法），我很想听听。
提前致谢，
约翰