從IIS 5.1 FTP服務器返回的意外字節序列

.NET Framework 1.0啓動後，沒有可用於.NET的良好FTP客戶端實現，因此我使用System.Net.Socket編寫了自己的實現。最近我不得不對它進行一些更改，並且在調試過程中，當關閉連接時，我注意到我正在測試的IIS 5.1 FTP服務器（WinXP SP 2）的亂碼輸出。從IIS 5.1 FTP服務器返回的意外字節序列

的通信是這樣的：

Send: QUIT<CRLF> 
Receive: 221<CRLF><NUL>?<ETX><NUL> 
(socket closed)

FTP命令通道處理程序是面向行的使用CRLF作爲終止子，以及在所述第一CRLF之後接收的四個字節等待第二CRLF引起超時錯誤。整個序列由單個套接字讀操作返回，並且我已驗證從套接字返回的字節數是正確的。

這個字節序列與此服務器保持一致，我想知道這是否是預期的/可以預防的，或者我應該簡單地「快速修復」它將其添加到我的「MS FTP Server怪癖」列表中。

來源

2009-12-14 EventHorizon

IIRC您可以在FTP站點的設置中更改QUIT消息，也許此元數據庫屬性包含無效數據。 – Lucero 2009-12-14 12:30:04

我試着改變退出消息，它和221一樣出現。額外的字節仍然出現，但現在他們已經改變：「221再見？q 」 – EventHorizon 2009-12-14 12:57:58

如果FTP服務器連接自動下降，你會得到一個超時？順便說一句：我可以用telnet複製到端口21，但它的垃圾值不同於你的（xp sp3）。漂亮的錯誤。 – 2010-01-19 20:54:48

雖然不理想，但它看起來像FTP服務器正在返回一個正確的響應，然後是意想不到的東西。如果我正在設計這個類，我會讓它保留一個未報告文本的緩衝區（如果你在一次讀取中讀取的內容少於整行），並且調用該函數返回一行文本，將它剝離並在CRLF之前返回，並將其餘部分留給下一個函數 - 只有在沒有完整行返回時纔會等待更多。

這應該解決上述情況。你的函數已經足夠返回「221」，調用者將解釋爲「221」，並且調用者不會要求更多，這將阻止最終的等待。

或者，或者另外：如果函數可以檢測到套接字關閉（因爲您的文章使得它看起來像是在它發送響應之後從遠程站點發出），它也可以防止等待。

來源

2010-01-24 14:41:11

我還沒有完全測試過，但由於回覆不包含續行短劃線，因此丟棄剩餘字節應該是安全的。你的解決方案應該也可以工作，但不應該保留這些額外的位。 – EventHorizon 2010-02-22 21:42:45

從IIS 5.1 FTP服務器返回的意外字節序列

回答

相關問題