實時應用異步與同步套接字服務器

我目前正在開發一個C＃套接字服務器，需要發送和接收命令到實時進程。客戶端是一個Android設備。目前實時需求是「軟」的，但是在將來可能會出現更嚴格的時間要求。比方說，將來可能會將命令發送給可能有潛在危險的起重機。實時應用異步與同步套接字服務器

服務器正在工作，看似與我目前的同步套接字服務器設計很好。我有單獨的線程來接收和發送數據。我想知道是否有任何理由嘗試異步服務器套接字方法？它能提供更多的穩定性和/或更快的性能嗎？

來源

2011-08-16 Cartaya

異步設計只會是有益的如果你有多個客戶和/或多個消息/連接並行處理...在這些情況下異步設計使你的服務器更好的可擴展性 – Yahia

我將討論實時定義，並說異步套接字不會使請求過程的主體更快，但會增加併發性（您可以在任何時候執行的請求數）。如果所有處理器都在忙於處理某些東西，則不會獲得任何收益。這隻會讓你在處理器等待插槽接收某些東西的情況下獲益。

只需要實時記錄，如果您的實時需求與需要x時間保證響應的情況類似，那麼C＃和.NET將不會爲您提供這樣的保證。但是，這取決於您目前和未來對「軟」的定義。您可能會遇到發生以獲得良好響應時間，但不要將其與真正的實時系統混淆。

來源

2011-08-16 14:27:19

感謝您的回答亞當！我想我對所有關於異步套接字服務器的帖子都感到困惑，但現在我知道它們在什麼情況下。我完全同意你的說明，C＃不適合實時需求。如果涉及到更難的需求，我可能會用C做一個服務器。另一件事，TCP套接字是實時通信的一個可行選擇，還是我應該考慮其他的東西？ – Cartaya

如果你正在做同步C與異步C＃相比，你自己做了一個很大的不當行爲。 – Henrik

通過潛在媒體（即網絡）的任何形式的通信對於實時系統來說都不會很輝煌。如果你想要可靠性，TCP是一個很好的選擇。 –

如果您懷疑您的應用程序中異步應用程序的有用性，那麼您一定要閱讀this。它讓你清楚地瞭解異步解決方案可以爲你的應用增加什麼

來源

2011-08-16 14:27:33

感謝您發佈LMAX參考。很有意思。 – kakridge

http://disruptor.googlecode.com/files/Disruptor-1.0.pdf - 這是您應該閱讀的文章，而不是Fowler的剪切複製粘貼簡化;） – Henrik

我不認爲你會獲得更多的穩定性或更快的性能。如果它確實是一個「實時」系統，那麼它應該是同步的。如果你可以容忍「接近實時」，並且有長時間運行或昂貴的計算操作，那麼你可以考慮採用異步方法。儘管如此，我不會增加複雜性。

來源

2011-08-16 14:29:41 kakridge

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

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

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

來源

2011-08-16 14:53:42 Henrik

他使用UDP。 ACK攻擊不適用。您的建議不會加強他申請的實時性;它提高了CPU性能和網絡安全性。能夠在異步消息隊列中按照時間邏輯編寫只有當你的服務速度落後時纔有操縱隊列內容以「趕上」的緯度;並且它引入了同步解決方案可以避免的服務速率中的僞隨機波動（儘管如果與'起重機'的鏈接是完全專用/可預測的潛在的，這只是真正相關的）。 –

他說他在使用UDP？我找不到那個。我不確定我是否同意你的看法，但是使用異步而不是同步套接字（給定多個連接）會減少延遲，這是互聯網上的殺手 - 而且互聯網不會將可預測的潛在軟件包發送給你的進程 - - 所以我不明白你在說什麼適用。另外，如果有波動，這又有什麼關係 - 這是什麼意思？ - 在這裏猜測 - 包裹可能無序到達並任意推遲。 – Henrik

你說得對，他沒有提到UDP。我不知道我爲什麼這麼認爲，也許參考一個工業應用程序（起重機）把它放在我的頭上。 –

實時應用異步與同步套接字服務器

回答

相關問題