IIS 流式传输/将 JSON 推送到 iOS

Posted 2023-02-24

【中文标题】IIS 流式传输/将 JSON 推送到 iOS

【英文标题】：IIS Streaming/Pushing JSON to iOS

【发布时间】：2012-04-24 15:37:02

【问题描述】：

快速版：

我想将来自 IIS WCF RESTfull web 服务的及时数据更新（以 JSON 格式）发送到 ios 自定义应用程序。由于带宽成本和我需要达到的更新率，我不想进行轮询。我的客户通过互联网与他们的服务器通信。

我对自己的选择感到困惑，而且我阅读的大部分信息都已过时，针对网络浏览器或媒体流。

我应该使用当前的最佳实践/标准实践吗？

额外细节：

我有大约 25-100 个 iOS (v5.1) 客户端 (iPad)。 我希望我的客户在事件发生后大约 5 秒内看到更新。 我的客户每天 24 小时运行，并通过 3G 网络进行通信。 应用程序只需要在运行时接收数据（无需在应用程序最小化时显示通知）。 使用第 3 方服务，或必须在我端设置特殊服务器是不行的。 无论我做什么都需要与我现有的 IIS WCF Web 服务很好地集成。

【问题讨论】：

***.com/a/6837111/53313（尽管问题已结束）提供了一些信息。

【参考方案1】：

不需要额外的研究，因为您提出了一个完全受限的问题：

只有两种选择：推或拉，拉被排除在外。 只有一种推送方式：APNS。 没有第三方协助，只有一个选择：建立 APNs 提供商。

【讨论】：

.. 至少似乎有一些选项：SignalR、Websockets、socket.io、某种类型的 Comet，使用 JSONObjectWithStream 方法。 ...或者您是说这些都不可行？

你说得对，长连接是推或拉的替代方案，但如果带宽成本和更新率排除了轮询，那么它不也排除了套接字吗？跨度>

100s 是一个很小的客户群。为什么排除民意调查？

我不排除投票 - 如果这是我唯一的选择，那么它将是选择。我认为每个轮询将有一个 2K 的 http 请求和一个 1K 的空响应 - 这相当于 53M/天/客户端的轮询开销。我的事件比较少见，几乎所有的民意调查都会返回一个空的响应——因此推送似乎是有道理的。我假设我的推送连接在其生命的大部分时间里都是安静的（没有数据）。

你是说你需要每五秒钟从客户端到服务器发布 2k 吗？我认为空响应是几十个字节，而不是 1k。