Как бы вы решили эту проблему совместимости: сетевые возможности взаимодействия

Это перевод How would you solve this compatibility problem: Network interoperability. Автор: Реймонд Чен.

Итак, товарищи, вот ваш шанс решить реальную проблему по обеспечению обратной совместимости. У этой задачи пока нет готового ответа; я хочу посмотреть, как вы попытаетесь её решить. Это задача - реальный баг в коде Windows Vista.

Один бета-тестер сообщил, что Проводник не может показать более чем около сотни файлов в каталоге на сервере с запущенным программным обеспечением от определённого производителя. Команды Оболочки (Shell) и сети вместе расследовали эту проблему и отследили её до сервера, который неверно обрабатывал определённые запросы каталогов. Хотя сервер декларирует поддержку как т.н. медленных, так и т.н. быстрых запросов (slow query/fast query), но если вы просите его сделать быстрый запрос, то он вернёт вам только около сотни файлов, а затем сдастся со странной ошибкой. С другой стороны, если Проводник переключится на использование медленного запроса, то всё будет работать нормально (Windows XP всегда использует медленные запросы). Дополнительные данные: в этом году было выпущено обновление к программному обеспечению сервера, которое исправляет этот баг. Однако (на момент написания этой заметки) все продолжают использовать бажную версию драйвера.

Что нам следует сделать? Вот несколько вариантов. Выберите один из них или придумайте свой собственный!

Ничего не делать

Не делать никаких обходных путей для этой проблемы. Люди, которые работают с определённой реализацией, будут получать неполные листинги каталогов. Опубликовать статью в Knowledge Base, описывающую проблему и направляющую клиентов на обновление драйвера.

Преимущества:

• Операционная система остаётся "чистой", неиспорченной хаками совместимости.

Недостатки:

• Клиенты с этой проблемой могут даже не знать, что она у них есть.
• Даже если клиенты что-то заметят, вовсе не обязательно, что они знают, что им надо искать решение по имени производителя (в сравнении с именем распространителя ПО) в Knowledge Base.
• И даже если клиент найдёт статью Knowledge Base, им придётся как-то обойти их распространителя ПО (distributor) и получить обновление напрямую от производителя (vendor). Такое действие может обнулить их гарантию/поддержку.
• Если ПО сервера работает на NAS (network attached storage), то пользователь даже не знает, что находится внутри этой запечатанной пластмассовой коробочки. Обновление серверного ПО должно подождать, пока распространитель не выпустит обновление прошивки (firmware upgrade). До тех пор пользователь будет испытывать потери данных (файлы после первой сотни будут невидимыми).
• Если пользователь не владеет файловым сервером, то лучшее, что они могут сделать - попросить администратора этого сервера обновить ПО/прошивку и надеяться, что он на это согласится.
• Поскольку Windows XP не использует быстрые запросы, то на ней эта проблема не проявляется. Пользователи будут интерпретировать эту ситуацию как баг в Windows Vista.

Авто-определить бажный драйвер и вывести диалог с предупреждением

Проводнику следует уметь распознавать странные коды ошибок и показывать сообщение об ошибке пользователю, говоря: "Похоже, что на сервере \\servername установлена старая версия драйвера XYZ, которая неверно отображает содержимое больших папок. В папке показаны не все существующие элементы. Пожалуйста, свяжитесь с администратором машины \\servername, чтобы он обновил драйвер" (опционально: с галочкой "Больше не показывать этот диалог").

Преимущества:

• Пользователи будут знать, что они получили неполный результат.

Недостатки:

• Пользователь ничего не может сделать с этой ошибкой. Этот диалог больше похож на: "Ха-ха, ты проиграл".
• Пользователи часто просто не знают, кто является администраторами машин, так что сказать им связаться с администратором - это просто способ их расстроить: "Откуда я знаю, кто это, а?", или, даже хуже: "Да это я и есть! И я понятия не имею, про что ты мне сейчас говоришь" (рассмотрите случай с устройством NAS).
• Администратор машины может иметь свои причины для откладывания обновления ПО (к примеру, потому что у него закончился срок поддержки), но на них будут постоянно давить пользователи из-за этого (нового) диалога.
• Поскольку Windows XP не использует быстрые запросы, то на ней эта проблема не проявляется. Пользователи будут интерпретировать эту ситуацию как баг в Windows Vista.

Авто-определить бажный драйвер и использовать обходной путь в следующий раз

Проводнику следует уметь распознавать странные коды ошибок и говорить: "Ох, должно быть, на этом сервере установлено то самое бажное ПО. Уже слишком поздно делать что-то насчёт текущей операции, но я запомню это и в следующий раз всё сделаю верно: используя медленный способ во всех будущих запросах к этому серверу".

Чтобы избежать проблемы отказа в обслуживании (denial-of-service), надо запоминать только последние 16 (к примеру) серверов, которые подвержены этой проблеме (если бы список "известных плохих серверов" был бы неограничен, то атакующий мог бы потратить всю память на вашей машине созданием сервера, который отзывается на биллион различных имён, и использованием HTTP-перенаправления для посещения всех этих серверов по очереди).

Преимущества:

• Windows умеет авто-определять проблему и сама её исправляет.

Недостатки:

• Самый первый запрос к большому каталогу для бажного сервера вернёт неверную информацию. Если этот запрос был сделан ради чего-то с длительным временем жизни (вроде дерева папок Проводника), то неверные результаты могут существовать продолжительное время.
• Если вы регулярно посещаете более 16 (к примеру) бажных серверов, то вы периодически будете выпадать из кэша и периодически получать неполные папки на очередном 17-м сервере.
• Возможно, также нужно будет разработать (и протестировать) механизм, который администраторы сети могли бы использовать для развёртывания на местах "списка известных плохих серверов". В этом случае сервера из такого списка не будут иметь проблемы "первый запрос возвращает неверные результаты".
• Поскольку Windows XP не использует быстрые запросы, то на ней эта проблема не проявляется. Пользователи будут интерпретировать эту ситуацию как баг в Windows Vista.

Завести настройку, которая переводит сетевой клиент в "медленный режим"

Добавить настройку сетевого клиента Windows, которая говорит "Если кто-то спросит, поддерживает ли сервер быстрые запросы - всегда говорить 'Нет', даже если сервер сказал бы 'Да'." При таком поведении ни одна программа не будет использовать быстрые запросы; все всегда будут использовать медленные запросы. Перечисление каталогов будет работать медленнее, но, по крайней мере, они будут работать.

Преимущества:

• С настройкой, установленной в "медленный режим", вы никогда не встретитесь с проблемой неполных листингов.

Недостатки:

• Поскольку нет автоматического определения проблемы, то вы можете иметь те же проблемы, что и в пункте "Ничего не делать".
• Клиенты должны как-то узнать, что у них есть проблема, прежде чем они смогут произвести поиск решения и узнать о этой настройке. До этого момента ситуация для них будет выглядеть как баг в Windows Vista.
Такое поведение штрафует корректные файловые сервера, потому что с ними будут использоваться медленные запросы, даже хотя они полностью (и корректно) поддерживают быстрые запросы.

Завести настройку, которая переводит Проводник в "медленный режим"

Добавить настройку Проводника, которая говорит "Всегда выполнять медленные запросы, никогда не выполнять быстрые запросы". Перечисления каталогов будет работать медленнее, но, по крайней мере, оно будет работать. Но эта настройка влияет только на Проводник; если операцию запросит другая программа, то она может использовать быстрые запросы - только чтобы обнаружить проблему, которую обошёл Проводник.

Преимущества:

• С настройкой, установленной в "медленный режим", вы никогда не встретитесь с проблемой неполных листингов (в Проводнике).

Недостатки:

• Каждая программа, которая использует быстрые запросы, теперь должна иметь новую настройку, отключающую быстрые запросы.
• Плюс все недостатки из предыдущего пункта.

Отключить "быстрый режим" по умолчанию

Перестать поддерживать "быстрый режим" в сетевом клиенте, потому что он ненадёжен; существуют сервера, которые не корректно обрабатывают "быстрый режим". Поэтому надо заставить все программы изначально использовать "медленный режим". Опционально можно завести настройку, включающую "быстрый режим".

Преимущества:

• Все листинги каталогов будут полны. Всё будет "просто работать".

Недостатки:

• Это то же самое, как если бы возможность "быстрый режим" вообще не была изобретена: она выключена по умолчанию и никто никогда её не будет включать, потому что всё работает "достаточно хорошо" (нет проблемы, чтобы лезть в настройки за её исправлением).
• Люди будут обвинять Microsoft в нечестной бизнес-практике, поскольку клиент будет работать в "медленном режиме", даже хотя сервер говорит ему, что он поддерживает "быстрый режим". "Очевидно, что Microsoft сделала это, чтобы увеличить продажи своего продукта-конкурента, у которого не будет такого искусственного ограничителя скорости".

Что-то ещё

Будьте креативными. Придумайте что-то своё и укажите список достоинств и недостатков вашего метода.