2012-08-14 70 views
2

我正在處理大量異步閱讀的應用程序。爲了提高性能,我希望直接從SslStream進行Read的同步呼叫,前提是呼叫不會阻塞。我可以依賴DataAvailable進行SSL封裝的網絡流嗎?

SslStream本身不提供DataAvailable屬性,如底層的NetworkStream

因此,鑑於我知道這是一個包裝的網絡流正在讀取,將trueDataAvailable保證調用SslStream不會導致塊?

像這樣:

public void Read(NetworkStream netStream, SslStream sslStream) 
{ 
    // given that netStream is the inner stream of sslStream 
    if (netStream.DataAvailable) 
    { 
     // Will not block 
     sslStream.Read(...); 
    } 
    else 
    { 
     // Would block 
     sslStream.Read(...); 
    } 
} 

SslStream已經被驗證,並準備去。我不確定除了加密/解密之外是否還有額外的開銷。我假設答案依賴於SslStream是否需要從基礎流讀取多個字節以讀取一個加密字節。

回答

2

不,它不能保證,因爲下一層有SSL記錄,而且你可能還沒有收到完整的記錄,而從密碼學的角度來說,除非你擁有一切,否則不能做任何事情,如你首先必須檢查MAc的完整性目的。

但更重要的是,我質疑整個戰略。只需在正常代碼中發佈所需的讀數:不要試圖猜測哪種模式在每種情況下都能發揮最佳效果。 SSL開銷可能會淹沒同步/異步差異,而網絡帶寬限制會使它們都陷入癱瘓。

+0

謝謝。除非我知道這個流是沒有SSL的普通網絡流,否則我會一直使用異步閱讀。 – Dervall 2012-08-15 06:08:53

1

它取決於使用中的密碼 - 使用RC4或另一個流密碼的端點一次可能可解密一個字節,但不能保證。爲DES或其他塊密碼配置的端點將一直等到滿塊可用。

你可以做一些棘手的東西與一個peekable中間緩衝流,並嘗試確保你有一個合理的塊大小之前進行阻塞閱讀,但這是討厭的。

如果你絕對不能阻止,我會堅持BeginRead和完成委託。

+0

不確定使用什麼密碼。我不確定我是否可以檢查數據流中的可用數據量,只有在下一次呼叫將被阻止時纔可以。這將是非常好的,以避免額外的開銷。 – Dervall 2012-08-14 17:20:38

+1

您需要整個SSL記錄才能做任何事情,因爲您首先必須檢查MAC。在檢查MAC之前傳遞任何字節是不正確的,而不正確的則表明它們可用。 – EJP 2012-08-14 23:57:59

相關問題