如何從客戶端找出TCP服務器的狀態（在冗餘服務器的情況下）？

我有這種情況。我有一個冗餘的TCP服務器設置，它接受一個輸入，然後永遠拋出大量數據包。在閱讀它們時，我也試圖通過在套接字上執行send來跟上TCP客戶端的服務器狀態。但我的服務器冗餘共享一個虛擬IP。所以如果服務器1關閉，服務器2啓動並使用相同的VIP（在所有時間點VIP都啓動並運行）。所以我的發送技術是能夠找出這種情況。我Server2上等待客戶端的投入，但由於發送沒有做我期望它做的工作，我不能夠重新發送輸入。如何從客戶端找出TCP服務器的狀態（在冗餘服務器的情況下）？

int status = ::send (m_sock, s.c_str(), s.size(), MSG_NOSIGNAL); 
    if (status == -1) 
    { 
     return false; 
    } 
    else 
    { 
     return true; 
    }

有人可以幫我怎麼弄出這種故障轉移？ TCP會話狀態信息也必須從主服務器到次級，這需要特殊的軟件複製 -

來源

2011-08-23 shKv

什麼你問？您的故障轉移是否已經運行並且想要了解服務器何時死亡？你在問如何設置這樣的場景？ – cnicutar

故障轉移在服務器端工作得很好。但是我的客戶在這個過程中迷失了方向，因爲在故障轉移之後服務器期望客戶端輸入。我的客戶不能發送輸入，除非它能理解故障轉移發生。這是我被卡住了。 – shKv

請解釋故障轉移的工作原理。 – cnicutar

好吧，拼湊的東西放在一起，我開始在這裏得到的圖片。

的OP使用故障轉移的某種在遠程服務器實際上並沒有保持狀態

的軌跡你不從發送得到EPIPE的原因是這東西發生這種情況：

你send數據。 send疏導和段開始行進
遠程服務器接收數據。「誰是是這傢伙？RST！」
你得到的RST但send已經返回。連接被撕裂，但也沒有辦法通知你的（它不具有任何超出帶外機制）
做另一send

總之，如果你想測試如果連接仍然活着：

send數據
等一等（RTT和例如）
send再次

如果你沒有得到第二send後EPIPE，連接仍上漲。另一種方案：應該被解釋爲

send數據「說些如果你還活着！」
等一等
如果超時後仍未收到確認，連接是死

來源

2011-08-23 06:45:13 cnicutar

這並不是那麼簡單，最終你會在程序中看到RST，但不能保證它會在第二次發送。 – EJP

@EJP RST將斷開連接，所以第二個RST將以-1失敗。 – cnicutar

謝謝大家的幫助！我終於發現服務器發送了一條保持活動的消息，我可以用它來服務我的目的。 – shKv

TCP會話不能簡單地由第二臺服務器接管第一的IP地址從一臺服務器故障轉移到另一個。

來源

2011-08-23 06:14:06 caf

你知道這樣的軟件嗎？它應該很難序列化套接字，inpcb，tcpcb並將其移動到另一臺機器上： - ？ – cnicutar

@ cincutar：不，我只聽說過它的存在，真的很棘手的部分是同步應用程序層... – caf

最終發送到已接管一定會失敗，因爲該服務器將不知道來自客戶端的IP連接的服務器：端口，因此它會發出一個RST，這回來爲的send（）返回-1和errno = ECONNRESET。這幾乎肯定不會發生在故障轉移之後的第一次發送，因爲異步和緩衝。

來源

2011-08-23 06:32:59 EJP

如何從客戶端找出TCP服務器的狀態（在冗餘服務器的情況下）？

回答

相關問題