差異處

這裏顯示兩個版本的差異處。

--- java:web:wicket:websocket_disconn_handling [2018/11/02 23:28]
tony
+++ java:web:wicket:websocket_disconn_handling [2023/06/25 09:48] (目前版本)
@@ 行 2: / 行 2: @@
 ====== Wicket - Websocket disconnection handling ======
 ===== Problem =====
-造成websocket突然斷線的原因很多，像是網路不穩定或是閒置過久遭server或是browser中斷連線等，都有可能導致接下來的工作不正常。因此我們需要方法去處理連線中斷的情況。
+造成Websocket突然斷線的原因很多，像是網路不穩定或是閒置過久遭server或是browser中斷連線等，都有可能導致接下來的工作不正常。因此我們需要方法去處理Websocket連線中斷的情況。本篇文章分享我們有使用過的解決方式，供大家參考。
 ===== How to? =====
-我們Web框架使用Apache Wicket(6.22)，而Server是Jetty(9.3.9)。(Wicket本身不支援ping&pong操作，因此ping&pong操作不在我的考慮範圍內)
+我們Web框架使用Apache Wicket(6.22)，而Server是Jetty(9.3.9)。我們最早使用的解法是在server side判斷連線狀態，但這並非百分之百的解決方式，所以最近改使用client side的解法。除此之外，ping&pong也是一種解決方法，但由於Wicket本身不支援，且套用send message去實作較複雜，因此不在本篇文章討論範圍內。
 ==== Handle On Server Side ====
-我們最早版本是在Server Side根據user request做處理，假如user request對應的websocket連線已中斷，那我們就會透過AjaxRequestTarget送一個reload給client:
+我們在Server Side根據user request做處理，假如user request對應的Websocket連線已中斷，那我們就會透過AjaxRequestTarget送一個reload給client:
 <code java>
 public class WebSocketCheckListener extends AbstractRequestCycleListener {
@@ 行 32: / 行 32: @@
 }
 </code>
-這做法不是不好，只是有點繞。假如連線問題是client可以得知的，是不是交由client去處理就好了呢?
+這做法很簡單，但server無法百分之百的偵測到連線中斷。我們就曾經在會議中，於切換完ip的電腦繼續使用我們的web；但由於Websocket斷線而造成後來的畫面無法正常顯示。因此我們開始考慮client side的作法。
 ==== Handle On Client Side ====
-Wicket Websocket client的api可以參考[[https://cwiki.apache.org/confluence/display/WICKET/Wicket+Native+WebSockets|link]]。在callback的event中，我們會希望發生網路問題或者是websocket中斷時，closed與error的event會被呼叫，而我們也只需要處理這兩種訊息；然而經過我實際在chrome、firefox、ie11上，分別對client、server做網路連線中斷相關測試後，發現事與願違。\\
+Wicket Websocket client的api可以參考[[https://cwiki.apache.org/confluence/display/WICKET/Wicket+Native+WebSockets|link]]。在callback的event中，我們會希望發生網路問題或者是Websocket中斷時，closed與error的event會被呼叫，而我們也只需要處理這兩種訊息；然而經過我實際在chrome、firefox、ie11上，分別對client、server做網路連線中斷相關測試後，發現事與願違。\\
 \\
 舉例來說，在我將server網路線拔除再插回去時，不會有任何事件發生，直到client發送訊息給server後，才會發生closed event。面對這樣問題，我就需要透過send message來偵測Websocket是否斷線。
@@ 行 53: / 行 53: @@
 });
 </code>
-closed event的部分我最後再說明，請讓我先說明連線偵測的部分。由於我們的操作都是屬於ajax的request，且這樣的偵測做在client有請求時才發送會比定時有效率；因此我們將這個檢查放在ajax請求前的事件中，主要做以下幾件事情:
+closed event的部分我最後再說明，請讓我先說明連線偵測的部分。由於我們的操作都是屬於ajax的request，且偵測做在client有請求時才發送會比定時發送有效率；因此我們將這個檢查放在ajax請求前的事件中，主要做以下幾件事情:
   - 連線關閉時，重新建立連線；此時Wicket.WebSocket.INSTANCE未被初始化。
-  - 假如Wicket.WebSocket.INSTANCE有被初始化，但isWSConnected為false，代表正在建立連線中。
+  - 假如Wicket.WebSocket.INSTANCE有被初始化，但isWSConnected為false，代表正在建立連線中。我們會略過偵測動作。
-  - 透過Wicket.WebSocket.send發送訊息給server，確認網路狀態。
+  - 最後是透過Wicket.WebSocket.send發送訊息給server，以確認網路狀態。詳細內容後面說明。
 <code javascript>
 Wicket.Event.subscribe('/ajax/call/beforeSend', function(jqEvent, attributes, jqXHR, errorThrown, textStatus) {
@@ 行 68: / 行 68: @@
 		try {
-			sendPing = false;
 			Wicket.WebSocket.send('ping');
-			sendPing = true;
+			_lastSendPing = new Date();
 		} catch(e) {
 			console.log(e.messsage);
@@ 行 79: / 行 78: @@
 });
 </code>
-Wicket.WebSocket.send後，有可能會發生closed，也有可能會發生error，也有可能會拋例外。在我目前的測試結果，是還沒出現發生例外的情況。
+Wicket.WebSocket.send後，有可能會發生closed，也有可能會發生error，也有可能會拋例外；這時大家可能會問: 為何你closed event不直接像其它案例一樣，重新建立連線就好? 這是由於我們希望使用者在一段時間沒任何操作後，會自動登出系統；然而重新建立連線的動作，是會延展session時間而導致不會timeout，因此我們僅在使用者有操作後的closed event才會重新建立連線。最後就是對closed event的處理:
+<code javascript>
+Wicket.Event.subscribe("/websocket/closed", function(jqEvent) {
+	isWSConnected = false;
+	Wicket.WebSocket.close();
+	if( !_lastSendPing ) {
+		return;
+	}
+	var isPingExpired = (new Date()- _lastSendPing) >= 10*1000;
+	_lastSendPing = null;
+	if( isPingExpired ){
+		return;
+	}
+	Wicket.WebSocket.createDefaultConnection();
+});
+</code>
+這裡搭配偵測斷線的動作，假如在send message後的10秒內發生closed，就會重新連線。這裡使用Date而不用Boolean是考慮到send message正常，但因其它原因closed時，flag為true而做了非預期的重新連線。假如send message能夠做成callback method，會比較理想，否則使用我目前的方法實做會較容易。
+\\
+\\
+希望以上內容對大家有幫助。
 ===== Reference =====
   * [[https://cwiki.apache.org/confluence/display/WICKET/Wicket+Native+WebSockets|Wicket Native WebSockets]]
+======  ======
+----
+\\
+~~DISQUS~~