跳到主要內容

Wicket - Websocket disconnection handling

Problem

造成Websocket突然斷線的原因很多,像是網路不穩定或是閒置過久遭server或是browser中斷連線等,都有可能導致接下來的工作不正常。因此我們需要方法去處理Websocket連線中斷的情況。本篇文章分享我們有使用過的解決方式,供大家參考。

How to?

我們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:

public class WebSocketCheckListener extends AbstractRequestCycleListener {
 
	@Override
	public void onRequestHandlerScheduled(RequestCycle cycle, IRequestHandler handler) {
		if (!(handler instanceof AjaxRequestTarget))
			return;
 
		AjaxRequestTarget target = (AjaxRequestTarget) handler;
		Page page = target.getPage();
 
		Application application = Application.get();
 
		IWebSocketSettings webSocketSettings = IWebSocketSettings.Holder.get(application);
		IWebSocketConnectionRegistry webSocketConnectionRegistry = webSocketSettings.getConnectionRegistry();
 
		IKey key = new PageIdKey(page.getPageId());
		IWebSocketConnection conn = webSocketConnectionRegistry.getConnection(application, page.getSession().getId(), key);
 
		if (conn == null || !conn.isOpen()) {
			target.appendJavaScript("location.reload()");
		}
	}
}

這做法很簡單,但server無法百分之百的偵測到連線中斷。我們就曾經在會議中,於切換完ip的電腦繼續使用我們的web;但由於Websocket斷線而造成後來的畫面無法正常顯示。因此我們開始考慮client side的作法。

Handle On Client Side

Wicket Websocket client的api可以參考link。在callback的event中,我們會希望發生網路問題或者是Websocket中斷時,closed與error的event會被呼叫,而我們也只需要處理這兩種訊息;然而經過我實際在chrome、firefox、ie11上,分別對client、server做網路連線中斷相關測試後,發現事與願違。

舉例來說,在我將server網路線拔除再插回去時,不會有任何事件發生,直到client發送訊息給server後,才會發生closed event。面對這樣問題,我就需要透過send message來偵測Websocket是否斷線。

首先讓我們處理最簡單的部分,error event。目前只會發生在網路有問題的情況,因此處理很簡單,就是重新連線。在這裡我使用了一個名為isWSConnected的變數,是用來區別websocketed是否已處於連線的狀態: (假如我可以改Wicket的js,我不會想這麼做)

Wicket.Event.subscribe("/websocket/error", function(jqEvent) {
	isWSConnected = false;
	Wicket.WebSocket.close();
	Wicket.WebSocket.createDefaultConnection();
});

在成功建立連線後,我們server會給client發送訊息,因此針對message event我們會將isWSConnected設為true;假如你把isWSConnected設定放在open event中,有可能Websocket會是處於連線中的狀態:

Wicket.Event.subscribe("/websocket/message", function(jqEvent, message) {
	isWSConnected = true;
	// handle message
});

closed event的部分我最後再說明,請讓我先說明連線偵測的部分。由於我們的操作都是屬於ajax的request,且偵測做在client有請求時才發送會比定時發送有效率;因此我們將這個檢查放在ajax請求前的事件中,主要做以下幾件事情:

  1. 連線關閉時,重新建立連線;此時Wicket.WebSocket.INSTANCE未被初始化。
  2. 假如Wicket.WebSocket.INSTANCE有被初始化,但isWSConnected為false,代表正在建立連線中。我們會略過偵測動作。
  3. 最後是透過Wicket.WebSocket.send發送訊息給server,以確認網路狀態。詳細內容後面說明。

Wicket.Event.subscribe('/ajax/call/beforeSend', function(jqEvent, attributes, jqXHR, errorThrown, textStatus) {
	if( !Wicket.WebSocket.INSTANCE ){
		Wicket.WebSocket.createDefaultConnection();
	} else {
		if( !isWSConnected ) {
			console.log('websocket is connecting..');
			return;
		}
 
		try {
			Wicket.WebSocket.send('ping');
			_lastSendPing = new Date();
		} catch(e) {
			console.log(e.messsage);
			Wicket.WebSocket.close();
			Wicket.WebSocket.createDefaultConnection();
		}
	}
});

Wicket.WebSocket.send後,有可能會發生closed,也有可能會發生error,也有可能會拋例外;這時大家可能會問: 為何你closed event不直接像其它案例一樣,重新建立連線就好? 這是由於我們希望使用者在一段時間沒任何操作後,會自動登出系統;然而重新建立連線的動作,是會延展session時間而導致不會timeout,因此我們僅在使用者有操作後的closed event才會重新建立連線。最後就是對closed event的處理:

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();
});

這裡搭配偵測斷線的動作,假如在send message後的10秒內發生closed,就會重新連線。這裡使用Date而不用Boolean是考慮到send message正常,但因其它原因closed時,flag為true而做了非預期的重新連線。假如send message能夠做成callback method,會比較理想,否則使用我目前的方法實做會較容易。

希望以上內容對大家有幫助。

Reference

留言

這個網誌中的熱門文章

PostgreSQL - Unattended installation on windows

Introduction 要將別人軟體包裝到自己軟體中,不可或缺的東西就是Unattended installation。以Unattended installation來說,我們可以選擇透過Installer的silent mode安裝,也可以透過把目標軟體做成portable的版本。本篇文章分享這兩種方法,教導大家如何將PostgreSQL透過Unattended installation方式安裝到目標系統成為service。 Note. 本篇以PostgreSQL 10.7為例。 Install with installer Tips 安裝程式或反安裝程式的參數,除了可以直接上官網搜尋Installation User Guide以外,也可以直接使用help參數查詢: postgresql- 10.7 - 2 -windows-x64.exe --help Windows安裝程式主要有EnterpriseDB與BigSQL兩種。BigSQL版本安裝元件是透過網路下載且支援參數不如EnterpriseDB版本多,以我們需求來說,我們傾向於使用EnterpriseDB版本。接下來分享給大家安裝與反安裝方法。 Installation @ echo off set INSTALL_DIR =C:\postgres10 set INSTALLER =postgresql- 10.7 - 2 -windows-x64.exe   rem options for installation set SSMDB_SERVICE =postgresql- 10 set MODE =--unattendedmodeui none --mode unattended   set DB_PASSWD =--superpassword postgres set DB_PORT =--serverport 5432   set SERVICE_NAME =--servicename % SSMDB_SERVICE %   set PREFIX =--prefix "%INSTALL_DIR%" set DATA_DIR =--datadir "%INSTALL_DIR%\data"   set OPTIONS =

How to install RIDE on Windows?

Introduction 多年沒在Windows上開發RobotFramework,趁著這次整理一下RIDE安裝方法。 目前RIDE最新版本與Python對應版本如下: (3.6 < python <= 3.11) Install current released version (2.0.8.1) with: pip install -U robotframework-ride 安裝Python 直接到Python官網找尋最新的3.11版本,我使用3.11.9: link 。安裝就是一直下一步而已。 安裝wxPython 每次安裝RIDE最困難的都是wxPython。看了一下 官網 描述,我就姑且相信一下: 接著進入下 載頁面 就有安裝教學。基本上就是到Python目錄下的Scripts直接執行以下command: pip install -U wxPython 安裝RIDE 接著就如RIDE官網所說,執行以下command: pip install -U robotframework-ride 啟動RIDE 直接在相同目錄下執行ride就可以啟動了,你也可以直接在桌面建ride連結,加快下次啟動時間。 沒想到這次這麼順利就安裝完成了。因為我是使用java去啟動robot framework,就不特別講要怎麼使用pip安裝robot framework了。

Hello World!

即將要搬家,因此舊網頁內容將慢慢轉移至Blogger。 如果要存取舊網頁,可以使用以下連結: https://wiki.tonylin.idv.tw/dokuwiki/doku.php