定時器的異步HttpWebRequest問題

情況：我正在使用HttpWebRequest.BeginGetResponse記錄在msdn中。我有一個計時器每10秒發送一次請求。當我測試它時，我收到了xml結構化的信息。定時器的異步HttpWebRequest問題

結果：處於客戶位置並且正在運行該工具，我收到了不完整的（因此不可解析的）xml（每個大約4KB）。我可以在瀏覽器中查看並完全看到它（顯然是通過瀏覽器的同步請求？！）。我使用關於內容長度的標題信息來確定我的接收緩衝區大小。

是什麼引起的？我不知道。數據相當小。我仍然使用developer fusion中描述的ThreadPool.RegisterWaitForSingleObject方法來定義超時，我也選擇了10秒以及超時。也許這不是一個明智的決定，它可能應該小於定時器間隔。事情是，我無法在這些條件下再次測試它。這是在一個生產現場，我沒有洞察網絡設置。在家裏，這些要求同時運行得很好。

我對這個領域並不是很有經驗，但是當一個計時器在完全接收到響應流之前觸發一個新的請求會發生什麼，超時時間是否等於計時器間隔？任何其他提示什麼可能是瓶頸？

來源

2009-08-13 rdoubleui

你怎麼接收數據？你是通過流讀取數據嗎？你是否使用返回的內容作爲Stream.Read的輸入參數？ Stream.Read的一個不完全明顯的特性是不能保證返回您請求的數據量。當你調用下面的函數

public abstract int Read(byte[] buffer, int offset, int count)

將返回多少實際的數據讀取。所以你可以讓它讀1000，它返回400，然後還有600字節留下來閱讀。這意味着您必須繼續調用Read直到它返回0（這意味着流中沒有更多數據）。

我也會說你不應該使用內容長度標題信息來調整你的緩衝區大小。相反，你應該創建一個動態調整大小的緩衝區（例如通過使用MemoryStream對象）並從響應流中讀取，直到它返回0爲止。至少，我是這麼做的。然後，如果服務器更改實現，那麼您的解決方案將繼續工作，以便不再發送該響應頭。甚至更好，因爲你正在加載XML，創建一個XmlDocument，並要求它直接從Http響應流中加載。

來源

2009-08-19 13:29:48 Pete

謝謝你的提示，我似乎錯誤地使用了Stream.Read方法。 – rdoubleui 2009-08-25 19:21:30

解決方案很簡單。只有在處理完響應後才啓動定時器。

來源

2009-08-13 09:49:23

我想這將是我需要的。那回答我的意思是說我是否需要照顧它。我無法相信我在10秒內無法收到4KB。 – rdoubleui 2009-08-14 09:01:38

但是，那麼我的計時器將無法控制一定的時間間隔。也許我不應該強制我的應用程序進入這些時間間隔，因爲這取決於連接質量。 – rdoubleui 2009-08-17 19:31:42

如果它是您要連接的另一臺服務器，那麼來自服務器的響應也可能是「分塊」。我在某處看到，httpwebrequest在分塊的服務器上存在一個錯誤，它不會返回完整的文件

如果確實如此，請確保服務器沒有爲http流量啓用「分塊模式」。

或者，如果這不在您的範圍之內，請使用普通套接字自己執行請求，發送http請求並獲取完整結果。

之前在這條路線走，首先確保該分塊模式是這裏的問題

來源

2009-08-13 09:50:45 Toad

分塊模式也是一個選項，我會嘗試瞭解更多。儘管它必須以某種方式與該網絡上的流量相關聯，因爲正如我所說，它同時在家中的另一臺電腦上運行。一旦我找到了一些東西，我會給予反饋。 – rdoubleui 2009-08-14 09:08:26

定時器的異步HttpWebRequest問題

回答

相關問題