Неожиданная последовательность байтов, возвращенная с FTP-сервера IIS 5.1

Question

Назад, когда был запущен .NET Framework 1.0, хороших реализаций FTP-клиентов для .NET не было, поэтому я написал свою собственную реализацию с использованием System.Net.Socket. Недавно мне пришлось внести в него некоторые изменения, и во время отладки я заметил искаженный вывод с FTP-сервера IIS 5.1, с которым я тестирую (WinXP SP 2) при закрытии соединения.

Связь идет так:

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

Обработчик канала команд FTP ориентирован на линию с использованием CRLF в качестве терминатора, и после получения четырех байтов после первого CRLF он ожидает второй CRLF, вызывающий ошибку времени ожидания. Вся последовательность возвращается единственной операцией чтения сокета, и я проверил, что число байтов, возвращенное из сокета, является правильным.

Эта последовательность байтов согласована с этим сервером, и мне было интересно, можно ли это предотвратить / можно предотвратить, или мне просто нужно «быстро исправить», добавив его в мой список «причуд MS FTP-сервера». 1008 *

Answer 1

Хотя это и не идеально, похоже, что FTP-сервер возвращает правильный ответ, за которым следуют неожиданные вещи.Если бы я проектировал класс, я бы держал в нем буфер незарегистрированного текста (который вы, вероятно, уже сделали, если вы читаете меньше, чем полная строка за одно чтение), и когда вызывается функция для возврата строкитекст, удалите его и верните материал до CRLF и оставьте остаток для следующей функции - только если он будет ждать больше, когда не будет полной строки для возврата.

Это должно решитьвышеуказанная ситуация.Ваша функция имеет достаточно, чтобы вернуть «221», что вызывающий будет интерпретировать как успешный, и вызывающий не будет просить больше, что предотвратит окончательное ожидание.

В качестве альтернативы или дополнительно: если функция моглаопределить закрытие сокета (поскольку ваше сообщение выглядит так, как будто оно поступает с удаленного сайта после отправки ответа), в этом случае это также может предотвратить ожидание.