从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服务器返回的意外字节序列

回答

相关问题