Как бы вы решили такую проблему совместимости?

Поскольку статья была написана еще в 2006 году, до выпуска Windows Vista, Реймонд, конечно, уже дал ответ. Так что, для чистоты эксперимента, не спойлите пожалуйста в комментариях.

Привет всем, у вас есть шанс решить одну настоящую проблему совместимости. Ответа еще нет: я жду, как вы будете ее решать. Это реальный баг в трекере Widnows Vista.


Итак, бета тестер сообщил, что Windows Explorer не может показать более чем сто файлов из сетевых папок, расположенных на серверах определённого производителя. Ответственные команды изучили проблему, и выяснили, что сервер неправильно обрабатывает некоторые типы запросов. Несмотря на то, что сервер заявлял, что он поддерживает и «быстрые» и «медленные» запросы, на «быстрый» запрос он возвращал только первые 100 файлов из каталога, и потом выдавал странный код ошибки. С другой стороны, если Explorer переключался в «медленный» режим, все работало хорошо. («Быстрые» запросы появились только в Windows Vista, Windows XP поддерживал только «медленные»). Дополнительная информация: апдейт к серверному ПО, исправляющий эту ошибку, был уже выпущен, однако вендор продолжал поставлять старую версию драйвера.

Что вы бы сделали в такой ситуации? Вот некоторые варианты, выберете свой или предложите новый.

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

Не обращать внимание на неправильную работу стороннего драйвера. Люди, кому не повезло купить подобное устройство, будут получать неполный список файлов. Опубликовать KB, объясняющее проблему, и направлять пользователей к вендору за обновленным драйвером.

Плюсы

• Операционная система остается «чистой», без всяких хаков совместимости.

Минусы

• Пользователи с такой проблемой могут даже не понять, что она существует. Даже если пользователь что-то заметит, вряд ли он знает, как искать в KB по имени вендора (или даже дистрибьютора) чтобы посмотреть, есть ли с ним какие-то проблемы. И даже если пользователь сможет найти KB, ему придется обращается напрямую к производителю, минуя дистрибьютора, что может нарушить его гарантию.
• Если файловый сервер работает, как NAS, пользователь, скорее всего даже не знает, что работает внутри запечатанной пластиковой коробки. Для апгрейда нужно будет ждать, пока вендор выпустит новую прошивку, а до тех пор пользователю придется терпеть потерю данных.
• Если сервер не находится под контролем пользователя, то ему придется просить администратора про апгрейд драйвера, и надеяться, что администратор на это пойдет.
• Так как Windows XP не использует «быстрые» запросы и не имеет этой проблемы, пользователи будут считать это багом в Windows Vista.

Автоматически диагностировать ошибочный драйвер, и выдавать диалог предупреждения

Explorer должен распознать этот странный код ошибки, и показать диалог, который скажет «Сервер \\servername похоже, работает со старой версией драйвера XYZ, которая неправильно работает с каталогами с большим количеством файлов. Не все файлы показаны здесь. Обратитесь к администратору \\servername для апгрейда драйвера». И галочка «Не показывать сообщение снова».

Плюсы

• Пользователю будет сообщено о неполном результате

Минусы

• Пользователь ничего не сможет сделать с этим неполным результатом. Это будет похоже на «Ха ха, ты проиграл!»
• Пользователи часто не знают, кто администратор сервера, и пожелание обратиться к администратору обычно вызывает реакцию – “Ух, а кто это?”, или даже “Это же я! И я абсолютно не понимаю, что это сообщение значит”. (Вспоминаем про домашний NAS)
• Администратор может иметь свои причины не апгрейдить драйвер на сервере (например, потому что это нарушает гарантию), и вряд ли будет доволен тем, что пользователи постоянно сообщают ему содержание нового диалога.
• И, так как Windows XP не поддерживает «быстрые» запросы, пользователи будут это считать багом в Windows Vista.

Автоматически диагностировать ошибочный драйвер, и в следующий раз применять другой тип запроса

Explorer должен распознать этот странный код ошибки, и сказать «Ок, этот сервер имеет ошибочный драйвер. Уже поздно что либо делать, но в следующий раз, я буду использовать медленный запрос для доступа к серверу».
Чтобы исключить возможность DOS атаки, надо запоминать только, скажем, 16 последних серверов (если список будет неограничен, атакующий может переполнить всю память, создав сервер, который отвечает миллионом различных имен с этим кодом ошибки).

Плюсы:

• Windows автоматически определяет проблему и решает ее.

Минусы

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

Сделать настройку в сетевом клиенте, которая включает «медленный» режим.

Добавить настройку в сетевом клиенте «Если кто то спрашивает, поддерживает ли сервер быстрые запросы, всегда говорить, Нет, даже если сервер сказал Да». В этом случае, никакая из программ не будет пробовать использовать «быстрый» режим, все будут использовать только медленный. Но, по крайней мере, это будет работать.

Плюсы

• Если эта настройка включена, пользователь никогда не получит неправильные данные

Минусы

• Так как определение не автоматическое, проблемы те же, что и в первом случае «Не делать ничего». Пользователи должны знать, что у них проблема и знать, что искать, чтобы найти эту настройку в KB. До этого, подведение будет выглядеть так, как будто это баг в Windows Vista.
• Сервера, которые работают нормально, будут тоже работать в медленном режиме, несмотря на то, что правильно поддерживают «быстрые» запросы.

Сделать настройку в Explorer, которая включает «медленный» режим

Сделать настройку в Explorer, которая говорит «Всегда используй медленный режим, никогда не используй быстрые запросы». Запросы будут идти медленнее, но всегда будут работать. Но, это повлияет только на работу Explorer; другие программы, которые спросят «Поддерживает ли сервер быстрые запросы?», получат соответствующий ответ, и при попытке использовать «быстрые» запросы, получат все те же проблемы, что уже решил Explorer.

Плюсы

• Если эта настройка включена, пользователь никогда не получит неправильные данные

Минусы

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

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

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

Плюсы:

• Все просто работает.

Минусы:

• «Быстрый режим» можно было вообще не разрабатывать. Он отключен по умолчанию, и почти никто не озаботится тем, чтобы включить его, потому что все и так работает
• Люди будут обвинять Microsoft в нечестной игре, так как клиенты работают в «медленном режиме», несмотря на то, что сервера поддерживают «быстрый». И, конечно, продукты Microsoft будут уступать конкурентам, которые поддерживают быстрый режим безо всяких ограничений.

Будьте креативны. Если приводите свое решение, составьте также список плюсов и минусов.

Еще один очевидный вариант, не описанный Реймондом в статье, но отвеченный в комментариях.

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

Не подходит, потому что: сетевой клиент возвращает список не по завершению запроса, а частями, асинхронно, во время выполнения. Так что первая часть списка может быть возвращена (и использована программой-клиентом) еще до того, как сетевой клиент получит ошибку и поймет, что надо перечитать список.

А также отвечаю сразу на комментарий типа «Майкрософту надо открывать и полностью документировать свои протоколы, сами виноваты». Баг, о котором пишет Реймонд, никакого отношения к правильному исполнению протокола не имеет.