具有嘗試捕獲SocketException的C＃非阻塞接收套接字，性能

Question

我正在寫類似於撲克的游戲，並且在網絡上使用Winodws套接字。 服務器使用C ++編寫，客戶端使用C＃編寫。 服務器使用客戶端，而客戶端使用System.Net/System.Net.Sockets。 他們與我所見有所不同。

好的，因此對於我的發送/接收消息功能，我使用非阻塞套接字。 通過服務器，一切工作完美。 我調用了我的非阻塞發送/接收函數，我正在完美地發送/接收所有數據，並且當沒有數據要接收時，我檢查WSAGetLastError，如果該錯誤具有著名的WSAEWOULDBLOCK錯誤代碼，那么我將其忽略並繼續前進。

現在，在客戶端，如果沒有要接收的數據，則將引發異常，而不是類似於WSAGetLastError的函數，它會拋出一個SocketException，錯誤代碼為10035 / WSAEWOULDBLOCK。 為此，我在try-catch塊中添加了我的接收函數。 根據我的閱讀，try-catch塊僅在引發異常時才是性能重的，如果沒有拋出異常，則性能不會嚴重下降。 對於消息接收，我有一個時間間隔為100ms的DispatcherTimer，它在try-catch塊中包含大約50-60行代碼，但是接收在第二行中，並且在這里引發了異常，因此它將異常移到catch在代碼的一部分中，有一個簡單的if塊，該塊檢查異常是否不是WSAEWOULDBLOCK異常並進行打印。

我實際上沒有明確的問題，我只需要一些建議。 我的問題：

計時器一啟動，性能就會大大下降。 這是從異常拋出嗎？ 我應該使用單獨的線程而不是DispatcherTimer來檢查傳入消息嗎？ 我喜歡DispatcherTimer的想法，因為我不必處理跨線程操作。 另外，我當然已經閱讀了有關異步套接字的信息，但我不知道。 在我看來，無阻塞套接字至少對於C ++也是一個不錯的選擇。 這個C＃異常正在改變整個事情。

希望您對客戶的設計有所了解。 在服務器端，我很好。 客戶端只是一個窗口，DispatcherTimer每100毫秒運行一次，並檢查傳入消息。 我的問題是性能和簡單的代碼設計（盡管我不怕長代碼，只要有必要）。 思考？

Answer 1

我只是使用了異步套接字，性能問題就消失了。

謝謝大家的幫助