complex-event-processing - 使用＆＃34;建议＆＃34;在QuarkIoE实时通知中

根据http://cumulocity.com/guides/reference/real-time-notifications/，发起握手以接收实时通知的客户可以在其请求正文中包含建议。此建议可以具有超时（＆＃34;发送连接消息和服务器响应之间的最长时间（以毫秒为单位）。＆＃34;）和间隔（＆＃34;服务器将关闭会话的时间段，如果没有收到来自客户端的下一个连接消息。＆＃34;）。我不理解这些参数以及它们如何适用于我的长轮询连接。

为什么服务器会对客户端用于连接呼叫的超时感兴趣？它应该在可用时立即发送通知（即＆＃34;实时＆＃34;）。确实如此，正如预期的那样。即使我指定了非常短的超时，但实际上我的连接使用了更长的超时，那么我仍然会收到这两个时间点之间发生的通知而没有任何问题。当我指定一个很长的超时时，我立即收到通知。这对于懒惰的通知是有意义的，但我没有在文档中看到提及这些通知。那么这个值是什么意思呢？
间隔是什么意思？如果我指定一个短暂的间隔，但在两次连续的连接呼叫之间等待更长时间，那么服务器不＆＃34;关闭会话＆＃34;，如果这意味着我的clientID变得无效我需要做一个新的握手。也许只是保证的最短时间，服务器必须保持会话？即客户端希望在连接之间等待的最长时间[等待更长时间可能会或可能不会在服务器自行决定]？它也不是队列实际被清除的时间，因为如果我在没有连接的情况下触发通知，并在间隔时间过后重新连接，那么该通知仍然可以正常传送。 / LI>
如果我们将它与SmartREST通知进行比较，我们发现它应该以相反的方式工作，恕我直言更有意义：服务器将建议发送到客户端，告诉它应该如何配置自己。在这种情况下的含义可能仍然有点含糊不清，但至少处理可能更直接（=只是服务器建议）：
1. 超时：不要使用更长的超时时间，因为服务器不希望保持连接打开时间超过X.不要使用更短的超时，因为服务器可能需要X时间来生成所有回复通知。
2. 间隔：不要比Y更快地重新连接，因为服务器内部通知分配甚至不能快速运行。在重新连接之前不要等待超过Y，因为内部队列不会缓冲通知超过Y.（在CometD参考中，这两个被命名为 interval 和 maxInterval < / em>，很明显他们是独立的。）

[免责声明：我是CometD领导和Bayeux协议维护者]

虽然timeout的定义是正确的，但interval的定义是错误的。正确的定义是Bayeux协议规范here。

为清楚起见，您在上面提及的是＆＃34; connect＆＃34;实际上是/meta/connect频道上的一条消息，它是Bayeux协议的心跳机制。

timeout的含义是长轮询的本质。在长轮询中，服务器在没有事件的情况下进行轮询以转发给客户端。服务器保留轮询的时间（同样，在没有事件的情况下）是timeout参数指定的内容。这就是为什么它是一个超时：它等待事件，如果没有，它会超时并回复客户端（带有空响应）。

timeout参数通常在服务器上配置，但客户端可以覆盖它（在它发送的每个建议中以瞬态方式），服务器应该遵守客户端值。通常，这是由客户端实现完成的，而不是由应用程序完成的 - timeout参数对于应用程序是不透明的。

interval的含义是客户端在发出另一个/meta/connect请求之前收到/meta/connect回复后等待的时间。可以在服务器和客户端上配置interval参数。

这两个参数共同调整长轮询。

例如，您可以通过拥有(timeout=0, interval=3000)对，每隔3秒简单地实现正常轮询。服务器将看到客户端请求timeout=0并且应该尊重它，以便它立即回复，即使没有可用的事件。反过来，客户端将在发出另一个/meta/connect请求之前等待3秒钟。

另一方面， long 轮询有例如(timeout=10000, interval=0)对，如果没有，服务器最多持有/meta/connect 10秒转发给客户的事件。

重载服务器可以向客户端发送interval=500的建议，以减少它处理的负载。在发出另一条/meta/connect消息之前，所有客户端将在客户端等待500毫秒，从而为服务器提供恢复时间。

timeout参数对TCP连接空闲超时有影响：如果timeout太长，某些服务器（或网络组件）可能会在服务器有机会之前关闭TCP连接回复/meta/connect。 Java Servlet容器永远不会关闭待处理请求的TCP连接（根据Servlet规范），但是配置为反向代理调用的Java Servlet容器前面的Apache | Nginx可能会早于{{1 }}

timeout参数影响服务器应该在内存中维护一个似乎已经消失的客户端的会话。如果interval太大，服务器可能会使该客户端的会话失效。

如果QuarkIoE产品正如他们在文档中所说的那样解释interval，那么它就违反了Bayeux协议。我认为这是一个文档错误。

使用＆＃34;建议＆＃34;在QuarkIoE实时通知中

1 个答案: