【问题标题】:Can server-to-client messaging rely on APNS?服务器到客户端的消息传递可以依赖 APNS 吗?
【发布时间】:2012-06-13 16:09:23
【问题描述】:

我正在开发一个消息传递应用程序,但对于如何将数据从服务器发送到客户端感到两难。

我正在使用集中式服务器设计,其中客户端使用NSURLConnection 向服务器发送消息,服务器不保留和管理打开的套接字,也无法为其中一个客户端发送消息。所以客户端使用一个计时器,每 2 秒查询一次服务器,看看是否有新数据在等待它们。

这种方法的问题是每 2 秒轮询一次服务器似乎会很快耗尽电池电量,所以我想也许不是客户端轮询服务器,而是 使用 APNS* 所以当服务器有一些新信息 **给客户端,服务器会发送一个推送通知 ***给客户端,然后客户端去获取来自服务器的数据。

* 使用 APNS - 如果客户端允许,客户端当然可以禁用此选项。所以我会检查每次应用程序进入前台时是否允许推送,如果没有,我将返回轮询方法。

** 新信息可以是从短信到服务器管理员消息的任何内容。 (并且有很多管理消息...)
例如,在我的应用中,用户可以看到他们的朋友状态(在线/离线),所以如果 user1 和 user2 是朋友,并且 user2 只是将他的状态从在线更改为离线,那么服务器需要发送这个新信息(管理消息 = user2_offline ) 到 user1。

*** 推送通知服务器发送的是空的(没有数据/声音),它只是客户端的触发器获取新信息,因此如果向客户端发送推送并且客户端应用程序已关闭,他将不会注意到任何内容。 (如果应用程序正在运行,那么它将从服务器获取新信息)

这种方法是否适用于需要大量推送通知使用的大型消息传递应用程序?

为了清楚起见,我的主要担忧是:
1. APNS 是否足够可靠,我可以将其用作我的核心服务器到客户端消息传递机制?
2. 苹果是否会批准每天从我的服务器发送的数千或数十万条推送通知?

【问题讨论】:

  • 在构建自己的轮询机制之前,先看看 SocketIO(长轮询)。

标签: iphone objective-c ios push-notification apple-push-notifications


【解决方案1】:

APNS 是否足够可靠,我可以将其用作我的核心服务器到客户端消息传递机制?

。为了完整起见,让我重复一下原因。

  1. Apple 本身否认可靠性阅读Programming Guide
  2. 另外,APNS 有一个 QoS 组件,它可能会以实时为代价来提高可靠性(例如,我可以要求 APNS 在 4 周内随时发送通知,如果设备无法访问,则重试),这没有用在你的情况下。
  3. 根据您的要求,如果您发送静默推送(没有用户可见消息的推送),则不能作为高优先级推送发送,这会进一步降低可靠性。这是一个相关的报价

    “静默通知并不意味着让您的应用保持清醒状态 背景,也不是为了高优先级更新。 APNs 将静默通知视为低优先级,并可能限制其 如果总数变得过多,则完全交付。实际上 限制是动态的,可以根据条件改变,但尽量不要 每小时发送多个通知。”

Apple 是否会批准每天从我的服务器发送的数千或数十万条推送通知?

一般来说,APNS 在负载方面不会有任何问题,但它有节流功能,它们可能会限制你的通知,请参阅上面的第 3 点

恕我直言,您应该看看 XMPP,因为该协议只是为您的用例而设计的,并且它们在所有平台上都有广泛的社区支持。我建议您查看https://github.com/robbiehanson/XMPPFramework 之类的内容,并在您的后端设置一个 XMPP 服务器,该服务器将处理消息和状态消息以及管理消息。

如果你已经评估过 XMPP 并且不想使用它,我建议你需要在 iOS App 中构建一个智能系统,它根据 App State 采用不同的策略,比如下面,你可以有下面的策略

  1. 基于实时套接字的方法 -> 建立永久套接字连接并尽可能保持数据同步(这是当您的应用程序运行到前台或后台时)
  2. 您谈到的轮询系统,可以在调用您的应用进行后台获取/位置更新等时使用。
  3. 当您的服务器检测到设备没有活动套接字并且很长时间没有轮询时,将 APNS 与用户可见的消息传递 + 自定义数据一起使用

【讨论】:

    【解决方案2】:

    我在这个领域工作了一段时间,根据我的经验,我认为你解决问题的方法将无济于事。首先请允许我强调一些关于 APN 特征的重要事实:

    1. APN 不可靠,不能保证 100% 到达客户。
    2. 根据 Apple 的文档,APN 是尽最大努力,因此很多时候它们可能无法达到。
    3. APN 内部不保存数据,因此即使它们到达您的客户端应用程序,它们内部也不会为应用程序保存任何数据。
    4. APN 只是通知用户发生了与您的应用相关的事情,而其中的消息(显示在 APN 的警报框中的文本)由 iOS 而非您的应用处理。这就是为什么使用 iOS 4 的设备显示 APN 的方式与使用 iOS 5 的设备不同,这是操作系统的工作而不是您的应用。
    5. 收到通知时显示在应用程序图标上的徽章值是您的服务器的责任,而不是设备操作系统的责任。换句话说,当 APN 到达设备时,它应该为您的应用程序提供新的通知计数值。操作系统不会为此做任何事情。

    话虽如此,我想解释一下此类应用程序通常是如何设计的。首先,它不是由 URL 连接完成的,并且客户端不会每隔一段时间检查服务器。通常您有一个客户端/服务器架构,其中您的客户端是设备上的应用程序,而服务器是驻留在服务器机器上的真实服务器程序。服务器可以是 Microsoft(例如使用 C#)或 MAC(使用 Objective C)。服务器有一个数据库,它在其中存储信息。一些重要信息(与您的问题相关)是 APN 计数值、您要传递的消息、客户端在线或离线的状态。

    当一个客户端喜欢向另一个客户端发送一些东西,或者当服务器想向一个客户端(或所有客户端)发送一些东西时,会检查接收客户端是否在线或离线。如果他在线,则直接发送消息,并且通常在 TCP 套接字上进行通信。如果用户离线,则服务器将存储需要发送给客户端的消息,增加 APN 计数值,向该接收者发送 APN。当该收件人在线时,服务器会注意到这一点(因为建立了连接和握手),因此将从数据库中获取所有未传递的消息并将它们发送给他......

    这是一个漫长的过程,我希望我能够向你解释一下。在所有情况下,我都不认为你的方法是实用的,也不能让你获得真正的工作。

    【讨论】:

    • 如果有兴趣从使用套接字的客户端/服务器开始,您可能有兴趣从here开始阅读
    • “APN 内部不保存数据,因此即使它们到达您的客户端应用程序,它们内部也不会为应用程序保存任何数据。”这是不正确的 - 您可以将自己的有效负载放入其中(尽管 APN 的总大小有限制)
    • 首先感谢您的回答,但我认为关于 APNS 事实存在一些误解:(1,2) 我知道 APNS 是尽最大努力,服务器可以检查客户端是否收到推送不是他会重新发送。 (3) 这不正确,我可以用它发送有效载荷,但这不是我的目的,正如我所写:“推送通知服务器发送的是空的(没有数据/声音),它只是客户端获取的触发器新信息”(4,5) 我知道但与我的需求无关..
    • 关于您的其余解释,再次感谢,但这是我已经知道的事情,我现在无法更改服务器,该应用程序几乎完成了,它与当前设计工作得很好,我'我只是担心它会如何处理大量用户和大量推送通知......
    猜你喜欢
    • 2018-05-10
    • 2018-06-20
    • 1970-01-01
    • 2013-04-24
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-02-21
    • 2010-11-05
    相关资源
    最近更新 更多