用於實時應用程序的異步與同步套接字服務器

Question

我目前正在開發一個需要向實時進程發送和接收命令的 C# 套接字服務器。 客戶端是 android 設備。 目前實時要求是“軟”的，但未來可能會出現更嚴格的時序要求。 可以說，將來可能會向可能具有潛在危險的起重機發送命令。

該服務器正在運行，並且與我當前的同步套接字服務器設計看起來非常好。 我有單獨的線程來接收和發送數據。 我想知道是否有任何理由嘗試異步服務器套接字方法？ 它能否提供更高的穩定性和/或更快的性能？

Answer 1

我將掩蓋實時的定義，並說異步 sockets 不會使請求過程的主體更快，但會增加並發性（您可以在任何時候接受的請求數量）。 如果所有處理器都忙於處理某些事情，您將不會獲得任何收益。 這只會讓您在處理器等待套接字接收某些東西的情況下獲得收益。

只是關於實時的說明，如果您的實時要求類似於需要保證及時響應，那么 C# 和 .NET 不會給您這樣的保證。 但是，這取決於您當前和未來對“軟”的定義。 您可能碰巧獲得了良好的響應時間，但不要將其與真正的實時系統混淆。

Answer 2

如果您懷疑應用程序中異步的有用性，那么您絕對應該閱讀此內容。 它讓您清楚地了解異步解決方案可以為您的應用程序添加什么

Answer 3

我認為您不會獲得更高的穩定性或更快的性能。 如果它真的是一個“實時”系統，那么它應該是同步的。 如果您可以容忍“接近實時”並且存在長時間運行或昂貴的計算操作，那么您可以考慮采用異步方法。 如果不需要，我不會增加復雜性。

Answer 4

如果它是實時的，那么您絕對希望您的通信由隊列支持，以便您可以證明該隊列上的時間邏輯。 這就是 nio/io-completion-ports/async 給你的。 如果您使用同步編程，那么您在將數據從 RAM 復制到網卡時會浪費您的 CPU。

此外，這意味着您的服務器絕對是單線程的。 即使使用異步，您也可能只有一個線程，但仍然能夠處理數千個請求。

例如，假設客戶想要執行 DOS 攻擊。 他將連接並發送一個字節的數據。 您的應用程序現在將無法接收該連接超時的進一步命令，這可能非常大。 使用異步，您將 ACK SYN package 返回，但您的代碼不會等待完整傳輸。