在Cumulocity實時通知中使用「建議」

Question

根據http://cumulocity.com/guides/reference/real-time-notifications/，啓動用於接收實時通知的握手的客戶端可以在其請求主體中包含建議。這個建議可以有一個超時（「以毫秒爲單位最大時間一個連接消息，並從服務器響應的發送之間。」）和間隔（「期間，高於該服務器將關閉會話，如果沒有接收到下一個從連接消息客戶。」）。我不明白這些參數以及它們如何適用於我的長輪詢連接。

1. 爲什麼服務器會對客戶端用於連接呼叫的超時感興趣？它應該立即發送通知（即「實時」）。正如預期的那樣的確如此。即使當我指定一個非常短暫的超時時間，但實際上爲連接使用了更長的超時時間時，我仍然會收到這兩個時間點之間發生的通知，而沒有任何問題。當我指定很長的超時時間時，我會立即收到通知。這對延遲通知是有意義的，但我沒有在文檔中看到這些提及。那麼這個價值是什麼意思？
2. 間隔是什麼意思？如果我指定一個短的時間間隔，但等待兩個更長的時間之間連續接通呼叫，那麼服務器不不「關閉會話」，如果這意味着我的clientID的失效，我需要做一個新的握手。也許這只是保證的最短時間，服務器必須保持會話？即客戶端希望被允許在連接之間等待的最長時間[並且等待時間更長可能或者可能不起作用，在服務器的判斷中]？也不是實際清除隊列之後的時間，因爲如果我在未連接時觸發通知，並且在間隔時間過後重新連接，那麼該通知仍可以正常傳送。

如果我們比較，爲SmartREST通知我們看到有它應該以相反的方式，其中，恕我直言，更有意義的工作：服務器發送建議到客戶，告訴它應該如何配置它自己。在這種情況下，意義可能仍然是有些模糊，但至少處理可能會更直接（=只是做作爲服務器建議）：

1. 超時：請不要使用較長的超時，因爲服務器沒有按」 t要保持連接的打開時間超過X.請勿縮短超時時間，因爲服務器可能需要X時間才能生成響應的所有通知。
2. 間隔：由於服務器內部通知分配甚至不跑那麼快不重新連接於Y快。在重新連接之前不要等到比Y更長的時間，因爲內部隊列不會緩存通知的時間超過Y.（在CometD參考中，這兩個名稱分別爲區間和maxInterval，所以很明顯它們是獨立的。）

爲什麼「建議方向」相反的兩種情況？我應該如何（如果有的話）使用建議進行定期的實時通知握手？

非常感謝有這方面的澄清。

Answer 1

[免責聲明：我是的cometd鉛和貝葉協議維護者]

雖然timeout的定義是正確的interval定義是錯誤的。正確的定義在Bayeux協議規範here。

爲了清楚起見，上面稱爲「連接」的內容實際上是/meta/connect通道上的一條消息，它是Bayeux協議的心跳機制。

timeout的含義是長輪詢的本質。 在長時間輪詢中，服務器在沒有事件的情況下保持輪詢以中繼到客戶端。服務器持有投票多長時間（同樣，沒有事件）是參數指定的內容。 這就是爲什麼它是一個超時：它等待事件，如果沒有，超時並回復客戶端（無響應）。

timeout參數通常在服務器上配置，但客戶端可以覆蓋它（在發送的每個通知中都是瞬態方式），服務器應該遵守客戶端值。通常這是由客戶端實現完成的，而不是由應用程序完成的 - 對於應用程序，timeout參數是不透明的。

interval的含義是客戶端在發出另一個/meta/connect請求之前收到/meta/connect回覆後等待多長時間。 可以在服務器和客戶端上配置參數interval。

這兩個參數一起工作來調節長輪詢。

例如，您可以簡單實現正常每3秒輪詢一次(timeout=0, interval=3000)。 服務器將會看到客戶端請求timeout=0，並且應該遵守該規定，以便即使沒有可用的事件也會立即回覆。 反過來，客戶端會在發出另一個/meta/connect請求之前等待3秒鐘。

在另一方面，一個長輪詢具有例如，一對(timeout=10000, interval=0)，其中服務器爲至多10秒保持/meta/connect如果沒有活動中繼到客戶端。

一個過載的服務器可能會發送給客戶一個建議interval=500減少它處理的負載。所有客戶端將在發送另一個/meta/connect消息之前在客戶端等待500毫秒，以便服務器恢復時間。

的timeout參數的影響相對於TCP連接空閒超時：如果timeout太長，有些服務器（或網絡組件）可以關閉TCP連接的服務器必須回覆/meta/connect的機會了。 Java Servlet容器永遠不會在掛起的請求（每個Servlet規範）上關閉TCP連接，但在配置爲反向代理這些調用的Java Servlet容器前面的Apache | Nginx可能會早於timeout指定的關閉TCP連接。

interval參數會影響服務器應該在內存中維護一個會話的時間，這個時間似乎已經消失了。 如果interval太大，服務器可能會過期該客戶端的會話。

如果Cumulocity產品正在解釋他們在文檔中說的interval，那麼這違反了Bayeux協議。我寧願認爲這是一個文檔錯誤。