根据http://cumulocity.com/guides/reference/real-time-notifications/启动握手以接收实时通知的客户端可以在其请求主体中包含建议。此建议可能有超时("发送连接消息和服务器响应之间的最大时间(以毫秒为单位)。")和间隔。("如果没有收到来自客户端的下一条连接消息,服务器将关闭会话的时间段。")。我不了解这些参数以及它们如何应用于我的长轮询连接。
- 为什么服务器会对客户端用于连接调用的超时感兴趣?它应该在通知可用时立即发送通知(即"实时")。事实上,正如预期的那样。即使我指定了一个很短的超时,但实际上我的连接使用了一个更长的超时,我仍然会收到这两个时间点之间发生的通知,而不会出现任何问题。当我指定长超时时,我会立即收到通知。这对于惰性通知来说是有意义的,但我在文档中没有提到这些通知。那么,这个价值观的意义是什么呢
- 间隔是什么意思?如果我指定了一个短的间隔,但在两个连续的连接调用之间等待更长的时间,那么服务器不会"关闭会话",如果这意味着我的客户端ID无效,我需要进行新的握手。也许这只是保证的最短时间,服务器必须保持会话?即,客户端希望在连接之间等待的最长时间[根据服务器的判断,等待更长的时间可能有效,也可能无效]?这也不是队列实际被清除的时间,因为如果我在未连接时触发通知,并在间隔时间过后重新连接,那么通知仍然可以正常传递
如果我们将其与SmartREST通知进行比较,我们会发现它应该以相反的方式工作,IMHO更有意义:服务器向客户端发送建议,告诉它应该如何配置自己。这种情况下的含义可能仍然有些模糊,但至少处理可以更直接(=按照服务器的建议进行):
- timeout:不要使用更长的超时,因为服务器不想让连接打开的时间超过X。不要使用更短的超时,否则服务器可能需要X时间来生成响应的所有通知
- interval:重新连接的速度不要快于Y,因为服务器内部通知分发的运行速度甚至没有那么快。在重新连接之前不要等待超过Y的时间,因为内部队列不会缓冲超过Y的通知
为什么在这两种情况下"建议方向"相反?我应该如何(如果有的话)使用该建议进行定期的实时通知握手?
非常感谢你对此的澄清。
[免责声明:我是CometD的负责人和Bayeux协议的维护者]
虽然timeout
的定义是正确的,但interval
的定义是错误的。正确的定义在这里的Bayeux协议规范中。
为了清楚起见,上面所说的"连接"实际上是/meta/connect
通道上的一条消息,这是Bayeux协议的心跳机制。
timeout
的含义是长轮询的本质。在长轮询中,在没有要中继到客户端的事件的情况下,由服务器进行轮询。轮询由服务器保持的时间(同样,在没有事件的情况下)是timeout
参数指定的。这就是为什么它是超时:它等待事件,如果没有,它就会超时并回复客户端(返回空响应)。
timeout
参数通常在服务器上配置,但客户端可以覆盖它(在它发送的每个建议中都是临时的),服务器应该遵守客户端的值。通常,这是由客户端实现完成的,而不是由应用程序完成的——timeout
参数对应用程序来说是不透明的。
interval
的含义是客户端在收到/meta/connect
回复后等待多长时间,然后再发出另一个/meta/connect
请求。CCD_ 11参数既可以在服务器上配置,也可以在客户端上配置。
这两个参数协同工作以调整长轮询。
例如,您可以通过使用(timeout=0, interval=3000)
对来实现每3秒一次正常轮询。服务器将看到客户端请求的timeout=0
,并且应该遵守这一点,因此即使没有可用的事件,它也会立即回复。反过来,客户端将等待3秒钟,然后再发出另一个/meta/connect
请求。
另一方面,例如,长轮询具有对(timeout=10000, interval=0)
,其中如果没有事件要中继到客户端,则服务器保持/meta/connect
最多10秒。
过载的服务器可以向客户端发送具有interval=500
的建议以减少其处理的负载。所有客户端都将在客户端等待500毫秒,然后再发出另一条/meta/connect
消息,给服务器恢复时间。
timeout
参数与TCP连接空闲超时有关:如果timeout
太长,某些服务器(或网络组件)可能会在服务器有机会回复/meta/connect
之前关闭TCP连接。Java Servlet Containers从不在挂起的请求上关闭TCP连接(根据Servlet规范),但配置为反向代理调用的Java Servlet Container前面的Apache|Nginx可能会在timeout
指定的时间之前关闭TCP连接。
interval
参数对服务器应该在内存中为似乎已经消失的客户端维护会话的时间有影响。如果interval
太大,则服务器可能会使该客户端的会话过期。
如果Cumulocity乘积像他们在文档中所说的那样解释interval
,那么这违反了Bayeux协议。我认为这是一个文件错误。