Unexpected byte sequence returned from IIS 5.1 FTP server

Question

Back when the .NET Framework 1.0 was launched, there were no good FTP client implementations for .NET, so I wrote my own implementation using System.Net.Socket. Recently, I had to make some changes, and during debugging I noticed distorted output from the IIS 5.1 FTP server that I tested (WinXP SP 2) when closing the connection.

The connection is as follows:

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

The FTP server channel handler is line oriented using CRLF as a terminator, and after receiving four bytes after the first CRLF, it expects a second CRLF that causes a timeout error. The whole sequence is returned with a single socket read operation, and I have verified that the byte count returned from the socket is correct.

This byte sequence was compatible with this server, and I was wondering if this is expected / can be prevented, or if I just try to "fix it quickly" by adding it to my list of "MS FTP Server Privileges".

Answer 1

Although not perfect, it seems like the FTP server is returning the correct answer, followed by unexpected things. If I were developing a class, I would keep a buffer of unregistered text (which probably already exists if you read less than a full line in one reading), and when the function is called to return a line of text, parse it and return the material before CRLF , and leave the rest for the next function - only if it waits more when the full string is not returned.

This should solve the above situation. Your function has enough to return "221", which the caller will interpret as successful, and the caller will not request more, which will prevent the final wait.

Alternatively, or additionally: if the function can detect the socket is closing (since your mail makes it look like it is from a remote site after sending a response), this can also prevent waiting in this case.