问GCM协议中意外的ACKing行为

EN

我们正在使用GCM的XMPP协议向客户发送推送通知，我们面临的问题是，当以高速发送xmpp消息时，我们不再接收来自GCM的“ack”或“nack”消息，这是我们对此问题进行的几次测试的结果：

1. 500条XMPP消息-每0.25秒发送一次：
   • 所有消息都会被添加。

​

1. 500条XMPP消息-每0.1秒发送一次：
   • 平均而言，仍有4条消息未加标记。

​

1. 500条XMPP消息-每0.01秒发送一次：
   • 72条信息仍未被锁定

​

1. 500条XMPP消息-发送时没有睡眠时间(尽可能快)
   • 在不到0.5秒内达到GCM设置的100条未加加消息限制！

​

当我们查看500多条消息时，结果就更糟糕了，例如：

1. 每0.1秒发送4000条XMPP消息：
   • 平均而言，未加标记的信息数量上升到大约16条。

​

1. 4000个XMPP消息-每0.01秒发送一次：
   • 平均而言，在第800条xmpp消息中，达到了100个未加加限制。

​

？

这些结果来自于在Google自己的云(Google云计算服务器)上进行的测试，而在任何其他地方进行测试都会产生更糟糕的结果(正如我们所测试的，速度不能超过1 1Msg/0.4S )我们正在使用GCM的XMPP协议来交付push nould while (!)100无加限制)

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

1. 忽略100无加限制并继续发送，但这意味着我们不知道我们的消息是否被gcm接收。
2. 我们可以在几秒钟后重新发送任何未加标记的消息，但是复制消息(对相同的客户端)是一个结果。
3. 等着看他们是否会在不久的将来被抓到，但到目前为止还没有起作用。当我们到达未加加限制时，挂起的消息永远不会被加上去(根据我们的经验)。
4. 限制我们发送XMPP消息的速度，但是这个解决方案极大地损害了我们实际使用XMPP的主动权！

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