使用 GMail API 进行长轮询答案

【问题标题】：Long polling with GMail API使用 GMail API 进行长轮询
【发布时间】：2014-10-10 20:06:52
【问题描述】：

我正在构建一个将运行数天的安装，并且需要从 GMail 收件箱实时获取通知。 Gmail API 非常适合我需要的许多功能，所以我想使用它。但是，它没有像 IMAP 这样的 IDLE 命令。

现在我已经创建了一个 GMail API 实现，它每隔几秒就轮询一次邮箱。这很好用，但一段时间后超时（我得到“对等方重置连接”）。那么，关闭 sesson 并每隔半小时左右重新启动一次以使其保持活动状态（就像 IDLE 一样）是否合理？这是一个可怕的骇客，会让谷歌在半夜闯入我的大门吗？

正确的解决方案是否也是使用 IMAP 登录并使用 IDLE 通知我的 GMail API 模块启动并在更改发生时提取更改？还是我应该把它吸干并创建一个仅 IMAP 的实现？

【问题讨论】：

【解决方案1】：

肯定会推荐反对 IMAP，请注意，即使使用 IMAP IDLE 命令，它也不是实时的——它只是每隔几 (5?) 秒轮询一次，然后推出连接。（自己试验一下，看看那里的延迟。）

经常查询 history.list() 非常便宜，应该没问题。如果这是针对大量用户的，您可能需要进行一些优化，例如针对非活动邮箱的智能回退（例如，每次没有更新回退时额外增加 5 秒，最长可达一两分钟）？

除非您每秒钟都在拥有 100 万用户，否则 Google 绝对不会破门而入，甚至可能不会注意到这一点。 :)

真正需要 API 的推送通知。

【讨论】：

太棒了！这正是我正在做的！我很感兴趣听到 IDLE 也不是真正的推动。似乎“对等方重置连接”选项可能只是主机进入睡眠状态。需要进行更多测试。
奇怪的是，我是否需要每隔几分钟就分解/重建监视器，就像在 IMAP IDLE 中一样？有什么原因吗？
不确定你的意思，你能澄清/重申一下吗？
抱歉。使用 IMAP 时服务器超时，“typically occurs after 30 minutes with no activity”。那篇文章建议每 15 分钟左右发送一个“无操作”命令 (NOOP) 以使其保持打开状态。在其他地方，我读到应该关闭并重新启动连接。这里的等价物是什么？我还需要担心吗？这将运行几天，我不希望它在一夜之间超时而没有任何活动。
IMAP 是单个连接，因此与服务器和代理的 tcp 超时开始发挥作用，迫使需要保持连接。与 HTTP 连接不同。

【解决方案2】：

由于您超出了 Google 配额，您的连接被对等方重置。每个 GMail API 请求都定义了配额here。

【讨论】：