根据http://cumulocity.com/guides/reference/real-time-notifications/发起握手以接收实时通知的客户端可以在其请求正文中包含建议。这个建议可以有一个超时（“发送连接消息和服务器响应之间的最大时间，以毫秒为单位。”）和一个间隔（“如果没有收到来自客户端的下一个连接消息，服务器将关闭会话的时间段。”） . 我不了解这些参数以及它们如何应用于我的长轮询连接。
- 为什么服务器会对客户端用于其连接调用的超时感兴趣？它应该在通知可用时立即发送通知（即“实时”）。正如预期的那样，确实如此。即使我指定了一个非常短的超时，但实际上为我的连接使用了更长的超时，我仍然会收到发生在这两个时间点之间的通知而没有任何问题。当我指定长时间超时时，无论如何我都会立即收到通知。延迟通知是有意义的，但我没有看到文档中提到这些。那么这个值是什么意思呢？
- 间隔的含义是什么？如果我指定一个较短的间隔，但在两次连续的连接调用之间等待更长的时间，那么服务器不会“关闭会话”，如果这意味着我的 clientID 变得无效并且我需要进行新的握手。也许这只是保证的最短时间，服务器必须保持会话？即客户端希望被允许在连接之间等待的最长时间[并且等待更长的时间可能会或可能不会起作用，由服务器自行决定]？这也不是实际清除队列的时间，因为如果我在未连接时触发通知，并在间隔时间过去后重新连接，那么该通知仍然可以正常传递。
如果我们将其与 SmartREST 通知进行比较，我们会发现它应该以相反的方式工作，恕我直言，这更有意义：服务器将建议发送给客户端，告诉它应该如何配置自己。这种情况下的含义可能仍然有些模棱两可，但至少处理可能更直接（=按照服务器的建议做）：
- 超时：不要使用较长的超时，因为服务器不希望保持连接打开的时间超过 X。不要使用较短的超时，因为服务器可能需要 X 时间来生成响应的所有通知。
- 间隔：不要比 Y 更快地重新连接，因为服务器内部通知分发甚至没有运行得那么快。在重新连接之前不要等待超过 Y，因为内部队列不会缓冲超过 Y 的通知。（在 CometD 参考中，这两个被命名为interval和maxInterval，因此很明显它们是独立的。）
为什么两个场景的“建议方向”是相反的？我应该如何（如果有的话）将建议用于定期实时通知握手？
非常感谢您对此的任何澄清。