Back when .NET Framework 1.0 was launched, there were no good FTP client implementations available for .NET so I wrote my own implementation using System.Net.Socket. Recently I had to make some changes to it, and while debugging I noticed garbled output from the IIS 5.1 FTP server I’m testing against (WinXP SP 2) when closing the connection.
The communication goes like this:
Send: QUIT<CRLF>
Receive: 221<CRLF><NUL>?<ETX><NUL>
(socket closed)
The FTP command channel handler is line-oriented using CRLF as terminator, and upon receiving the four bytes after the first CRLF it waits for a second CRLF causing a timeout error. The entire sequence is returned by a single socket read operation, and I’ve verified that the byte count returned from the socket is correct.
This sequence of bytes has been consistent against this server and I was wondering if this is expected/ can be prevented, or if I should simply “quick fix” it adding it to my list of “MS FTP Server quirks”.
While not ideal, it looks like the FTP Server is returning a correct response, just followed by unexpected stuff. If I were designing the class, I’d have it keep a buffer of unreported text (which you probably have already, in case you read less than a full line in one read), and when the function is called to return a line of text, have it strip out and return the stuff before the CRLF, and leave the rest for the next function – only having it wait for more when there isn’t a full line to return.
That should solve the above situation. Your function has enough to return “221”, which the caller will interpret as successful, and the caller won’t ask for more, which will prevent the final wait.
Alternatively, or additionally: If the function could detect the close of socket (since your post makes it look like this is coming from the remote site after it sends the response), it could prevent the wait in that case as well.