GCM XMPP 协议中的意外确认行为

Question

我们正在使用 GCM 的 XMPP 协议向我们的客户发送推送通知，我们面临的问题是在高速发送 xmpp 消息时，我们没有收到 'ack' 或 'nack'不再有来自 GCM 的消息，这些是我们针对此事所做的几次测试的结果：

1. 500 条 XMPP 消息 - 每 0.25 秒发送一次：
   • 所有消息都已确认
2. 500 条 XMPP 消息 - 每 0.1 秒发送一次：
   • 平均而言，约有 4 条消息未被确认
3. 500 条 XMPP 消息 - 每 0.01 秒发送一次：
   • 72 条消息仍未确认
4. 500 条 XMPP 消息 - 发送时没有休眠时间（越快越好）
   • 在不到 0.5 秒的时间内达到了 GCM 设置的 100 条未确认消息的限制！

当我们处理超过 500 条消息时，结果会更糟，例如：

5. 4000 条 XMPP 消息 - 每 0.1 秒发送一次：
   • 平均而言，未确认消息的数量上升到大约 16
6. 4000 条 XMPP 消息 - 每 0.01 秒发送一次：
   • 平均而言，在第 800 条 xmpp 消息中达到了 100 个未确认的限制。

——————————————————————————————————

这些结果来自在 Google 自己的云（Google 云计算服务器）上进行的测试，而在任何其他地方进行测试时，会产生更糟糕的结果（正如我们测试的那样，没有速度超过1Msg/0.4S w 我们正在使用 GCM 的 XMPP 协议来传递推送实际上可以生存（！）100 unacked 限制）

这对我们来说太糟糕了，因为没有最优解，我们现在该怎么办？

1. 忽略 100 个未确认的限制并继续发送，但这意味着我们不知道 gcm 是否收到我们的消息。
2. 我们可以在几秒钟后重新发送任何未确认的消息，但结果是重复的消息（发送到相同的客户端）。
3. 等着看他们在不久的将来是否会被攻击，但到目前为止还没有奏效。当我们达到未确认的限制时，挂起的消息永远不会被确认（根据我们的经验）
4. 限制我们发送 XMPP 消息的速度，但这个解决方案极大地危害了我们必须实际使用 XMPP 的主要主动性！

如有任何帮助或指导，我们将不胜感激。

Answer 1

我也遇到了同样的问题。我曾经为 gcm 的 NACK 发送 ACK，当我停止这样做时，一切都非常顺利。检查您是否发送了不必要的 ACK。