原本 dispatch_by_order 迴圈中，socket.block 方法是掛起協程阻塞的，當客戶端socket主動斷開的時候，socket 協程被喚醒發現 connected 為 false，繼續執行了 close_channel_socket(self) 和 wakeup_all(self)，進而呼叫 socket.close 關閉了 socket 。所以，channel:request 中的_block_connect_ 方法 check_connection 返回false，執行了相關的重連邏輯。更新版本後，dispatch_by_order 迴圈中不處理客戶端 socket 主動關閉，從而 channel:request 中_block_connect_ 方法 check_connection 返回true，重連邏輯沒有被執行，直接在已經斷開的 socket 上執行 write 方法報錯，報錯之後 socket 關閉標識會被更新，所以在下一次執行_channel:request_ 的時候，重連邏輯會被觸發執行。
我的處理比較粗暴，如果請求失敗，執行一次select 1, 這時重連是成功的，然後再執行之前的失敗請求
@lokerli 提供的方法，select 1，會觸發socketchannel報錯並更新_socket.__closed_標識，再執行正式的請求就會重連返回正確的訊息了。 我們現在採取的方式是pcall呼叫資料庫查詢方法，如果報錯再執行一遍。
local cmd = {}
local pool = {}
local size = 10
local index = 1
local function getdb()
local db = pool[index]
index = index + 1
if index > size then
index = 1
endreturn db
endfunction cmd.query(sql)
local db = getdb()
local ok, result = pcall(db.query, db, sql)
print(ok, result)
if not ok then
result = db:query(sql)
endprint(dump(result))
return result
end可是專案遇到的問題是，更新skynet版本後，每天早上mysql的query方法都會報錯，並且一直沒有重連成功。因為處於測試階段，所以晚上並沒有活動的資料庫連線，wait_timeout的超時時間過了後，資料庫連線就斷開了。我猜測是這個樣子，但是為什麼不能重連成功呢？
後來確認是mysql斷開確實是因為wait_timeout預設為8小時，專案開發階段晚上並沒有活動的資料庫連線，所以早上上班測試的發現連線已經斷開。一直沒有被發現的原因，是因為以前sockectchannel自動重連。又因為採用了100大小的連線池，所以錯認為一直重連不成功，只是沒有在乙個連線中重複請求罷了。
經測試，redis斷開之後，也是第二次才能重連成功。
@cloudwu 雲大，不清楚當初那個patch [bugfix: socketchannel order mode may blocked. (used by redis driver)] 的修改初衷是為了什麼，難道現在重連必須二次才能成功嗎？還是我的理解有錯誤，希望你能指點一二。
websocket 斷線重連
摘要websocket reconnect websocket是html5發布之後出現的一種新技術，說它是新技術，其實也不是多新的技術了，因為畢竟也有2 3年了，但是找了很多國內的例項，缺發現不多，不知道是它不好用呢，還是說這種技術原來就有缺陷呢，咱們暫且不說，今天我們就來介紹一下websocket...
斷線重連機制
zookeeper的客戶端具有自動重連機制，當出現網路異常時，客戶端會自動重連直到與集群中的某台機器連線成功，連線過程如下圖所示 1.網路異常情況包括網路閃斷 zk伺服器宕機等情況，這會導致連線斷開connection loss，此時客戶端會收到事件none disconnected 2.如果在se...
TCP斷線重連
struct sockaddr in tempsadd tempsadd.sin family af inet tempsadd.sin port htons m serverport tempsadd.sin addr.s addr inet addr m serverip.c str if 1 ...