openfire 用戶端無響應處理方法

無響應對端的處理

當串連某個流的實體在一段時間內沒有接收到同樣串連到該流的另一對等端發來的任何XMPP資訊，那麼該對等端可能是無響應的。有幾個原因很可能引起這種情況發生：

1. 底層的TCP串連死掉。
2. 儘管當底層的TCP串連仍然是啟用的時候，XML流被中斷了。
3. 對等端是閒置，只是沒有通過其串連的XML流發送XMPP資訊到該實體。

這三個條件最好被分別對待，像下面章節描述的一樣。

實現注意:為了處理無響應的對等端，我們把兩個單向的TCP串連當作一個在概念上相當的雙向的TCP串連（見4.5節（方向性））;然而，實現者要知道在兩個單向的TCP串連的情況下，在XMPP應用程式層對等端對通訊的響應將從其第二個TCP串連返回。此外，在每個方向上的多個資料流的使用（大型的XMPP服務提供者間的伺服器到伺服器之間的串連經常這麼部署）使得對XMPP流和底層TCP連線應用程式級檢查進一步複雜化了，因為任何給定的初始流和任何給定的響應流之間沒有必然聯絡。

死串連

如果底層的TCP串連是死的，流層級的檢查（例如：[XEP-0199]和[XEP-0198]）是無效的。因此，不管有沒有流錯誤都沒必要關閉流，恰當的做法是直接終止TCP串連。

檢查TCP串連的一個通用方法是在XML節之間發送一個空格符（U+0020）,發送空格在XML流中是被允許的，下面第11.7節中將進行描述。發送這樣的一個空格被稱作“空格保持啟用”（詞語“whitespace
ping”通常被使用，儘管事實上它不是一個ping,因為“pong”是不可能的）。然而，在TLS認證和SASL認證期間，發送空格符是不允許的，下面第5.3.3節和第6.3.5節將會描述。

中斷的流

即使底層的TCP串連仍然是啟用的，對等端很可能從來不對實體發出的XMPP通訊請求作出響應，不管是正常的節還是例如在[XEP-0199]中所定義的應用程式層級ping那樣的專門流通訊檢查，或者在[XEP-0198]中定義的更全面的流管理協議。在這種情況下，對實體來說恰當的做法是發送<connection-timeout/>流錯誤（第4.9.3.4節）來關閉中斷的流。

空閑對端

即使底層的TCP串連仍然啟用，並且流沒有被中斷，對等端很可能在一段時間內都沒有發送XML節。在這種情況下，對等端可以（MAY）關閉流（像第4.4節描述的一樣），而不是讓不再使用的流開啟著。如果空閑對等端沒有關閉流，那麼與該流關聯的另一端或者可以（MAY）通過使用第4.4節描述的握手方式來關閉該流，或者發送一個流錯誤（例如：<resource-constraint/>（第4.9.3.17節），如果實體已經到了開啟TCP串連數的限制，或者<policy-violation/>（第4.9.3.14節），如果串連已超出本地逾時政策）來關閉該流。然而，層（下面第13.3節指定）的順序要符合，在得出對等端處於空閑狀態的結論前，另一端需要去核實底層TCP串連仍然是啟用的並且流沒有被中斷（前面已描述）。此外，在接受空閑對等端時最好寬容一點，因為經驗表明，這樣做可以提高在XMPP網路上通訊的可靠性，並且保持兩個伺服器之間的流比積極地去逾時一個流通常更有效。