Вы когда нибудь задавались вопросом, как этому «чертовому» хакеру удается вновь и вновь появляться в системе, несмотря на то, что вы, казалось бы, полностью закрыли для него доступ? Если вы хотите заниматься хакингом в будущем, это руководство окажет вам неоценимую помощь. Также оно будет полезно и администраторам, так как даже в 2000 году существует великое множество способов нелегально проникнуть в UNIX, Windows 2000 и, конечно же, в Windows 98, равно как и в любую другую систему. Ни в коем случае не рассматривайте эту книгу как всеобъемлющий труд, отвечающий на все жизненные ситуации.

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

Что такое разгон видеокарт?

Под разгоном видеокарт подразумевается увеличение рабочих частот видеокарты. Но также разгоном можно назвать и другие способы внештатного увеличения производительности, будь то разблокировка дополнительных конвейеров на Radeon 9500/9800SE, или включение HyperZ на Radeon LE.

Имеет ли это практический смысл?

Несомненно. Разгон видеокарты является, без преувеличения, самым эффективным средством увеличения производительности компьютера в играх и других 3D-приложениях, за исключением лишь тех случаев, когда производительность сдерживает скорость платформы (читай, связки процессор+память).

Опасно ли это?

Нет. Шанс сгорания видеокарты при разгоне гораздо меньше чем допустим процессора. Да и вообще видеокарта не может сгореть от самого разгона, зато может от перегрева, хотя в большинстве случаев, при перегреве графического процессора машина попросту зависнет.

С другой стороны, работа на внештатных частотах, равно как форсированная работа любого другого компонента компьютера значительно сокращает срок службы карты. И эта особенность могла бы быть весьма серьезным сдерживающим фактором, если бы не одно «но» - срок службы видеокарты составляет куда более восьми лет, и даже при разгоне он уж меньше, чем лет пять не будет. А если посмотреть на существующую гонку технологии, в игровых компах карты более лет двух не держатся, так что если Вы не планируете оставлять видеокарту лет эдак на шесть, Вы можете совершенно спокойно её разогнать.

Вопросы гарантии

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

Младшие и старшие модели

Ни для кого не секрет, что новые модели видеокарт выпускают так называемыми «линейками». Происходит это следующим образом – выходит какой-либо чип, затем на его основе выпускают сразу несколько видеокарт с разными частотами, а в некоторых случаях и на разных дизайнах с разной шириной шины памяти.

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

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

Что же до памяти, то тут всё немного хуже – младшие модели оснащается более медленными чем старшие чипами, и разогнать память на младшей модели до частот старшей удается далеко не всегда.

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

Какой прирост можно получить при разгоне видеокарты?

Здесь все зависит от условий тестирования, ну и естественно от степени увеличения частот. Хуже всего с этим у noname-карт, произведенных китайскими умельцами и у флагманских моделей линеек (например, GeForce4 Ti4600 или RADEON 9700 PRO). В первом случае карты слабо разгоняются из-за некачественных компонентов, коими оснащают свои продукты китайские умельцы, во втором же случае, платы и без того работают почти на предельных частотах, как мы уже сказали в предыдущем абзаце.

Как правило, при разгоне таких карт можно достичь лишь 15-20% прироста частот. Со средними и младшими моделями в линейках ситуация обстоит получше, потенциал для повышения частот побольше и разгоном таких карт можно улучшить производительность на 20-40%.

Самый хороший вариант - всевозможные оверклокерские сэмплы. На них прирост может составить 35-50%, а порой и больше.

Теперь несколько слов о картах с пониженной структурой организации памяти. Бытует мнение, что на таких картах бессмысленно разгонять чип, однако лично я совершенно с этим не согласен. Дело в том, что пользователи таких карт, как правило, играют в режимах типа 800x600 или 1024x768, и низкая пропуская способность памяти в таких режимах несильно ограничивает производительность, а вот на графический процессор нагрузка, наоборот больше.

Что такое синхронные и асинхронные частоты?

Частоты чипа и памяти видеокарты могут быть синхронными, то есть одинаковыми, или же асинхронными, иначе говоря, различными. Но в чем разница?

При работе видеокарты и обмене данными между графическим процессором (чипом) и памятью видеокарты, происходит синхронизация сигналов. В случае, если чип и память работают на одинаковых частотах, сигналы проходят одновременно и не уходит дополнительного времени на их синхронизацию, если же частоты различны, перед обменом данных, видеокарта должна синхронизовать сигналы, на что, разумеется, уходит немного времени.

Из этого, недолго думая, можно сделать простое умозаключение о том, что на синхронных частотах видеокарта будет работать немного быстрее, нежели на асинхронных. Но есть один момент…

Синхронные частоты выгодно ставить лишь в том случае, если возможные асинхронные частоты не слишком сильно отличаются. Например, у нас есть возможность поставить максимальные частоты 450/460 и больше частоты выставить нельзя. В таком случае, намного эффективнее будет пожертвовать десятью мегагерцами памяти ради синхронности поставить 450/450 – в таком случае видеокарта почти наверняка будет быстрее. Однако если же у нас есть возможность поставить частоты, например 475/450 или 450/480, такие варианты будут предпочтительнее синхронных 450/450 за счет значительно больших результирующих частот.

Что такое технологический процесс чипа и время доступа памяти, как они влияют на разгон?

Любой оверклокер обязательно должен знать, что такое технологический процесс чипа и время доступа памяти. Знание этих двух определений значительно поморгает в примерном определении максимальных частот разгоняемой видеокарты.

Но что же это такое? При изготовлении любого чипа играет весьма важную роль размер элементов микросхемы, ведь степень интеграции может быть разной, в один чип можно «набить» два миллиона транзисторов, в другой – сто два. И когда физический размер кристалла микросхемы ограничен, играет очень большую роль размер элементов микросхемы и расстояние между элементами в кристалле. Этот размер и называют технологическим процессом, и чем он меньше, тем большее количество элементов поместить в чип, тем меньшие токи требуют элементы для питания, тем меньше энергии выделяет чип, и, наконец, на тем больших частотах он может работать.

В настоящий момент подавляющее большинство чипов выпускают по технологическому процессу 0,13 и 0,15 микрон, а на стадии активного освоения находится и 0,11 микрон.

Что же касается памяти, то здесь крайне важную роль играет время доступа. Любые чипы памяти имеют заявленное производителем время, в течение которого происходит считывание инфы из ячейки памяти, и чем это время меньше, тем соответственно, быстрее работает память, и тем больше ее рабочие частоты. Зависимость примерной рабочей частоты о т времени доступа памяти предельно проста, и ее можно описать следующими формулами:

Частота памяти DDR = (1000/время доступа) X 2
Частота памяти SDR = 1000/время доступа

Следующий вопрос заключается в том, как можно узнать время доступа памяти. Как правило, время доступа скрыто в конце первой строчки маркировки. Например, на микросхемах памяти Samsung в конце первой строчки можно найти надпись типа TC-33 или TC40. Это означает, что память имеет время доступа 3,3 и 4 наносекунд соответственно, хотя в некоторых случаях, время обозначается не цифрой, а специальной маркировкой, например чипы памяти Samsung со временем доступа 2,8 нс. обозначаются как GC2A.

Не забывайте также, что точную информацию о чипе памяти можно получить на сайте производителя, либо просто воспользовавшись поиском по строчке с маркировкой памяти в том же Google.

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

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

Отказы аппаратных средств

Исчезновение данных может быть вызвано отказом различных устройств - жестких дисков и дисковых контроллеров, соединительных кабелей, оперативной памяти или центрального процессора компьютера. Внезапное отключение электропитания при отсутствии источника бесперебойного питания - также одна из наиболее распространенных причин исчезновения данных. В зависимости от того, что происходило в компьютере на момент отказа, последствия могут оказаться более или менее тяжелыми.

Отказы дисковых контроллеров

Чаще всего нам встречались случаи потерь данных при отказах дисковых контроллеров. При этом в момент аварии контроллер выполнял операцию записи, которая завершалась с ошибками. Как следствие, оказывались разрушенными системные области диска, после чего все данные или часть их становились недоступны.

Заметим, что дисковые контроллеры современных файловых серверов, таких, как Compaq Proliant, протоколируют сбои аппаратных средств и позволяют выполнять диагностику. Это дает возможность обнаружить опасные симптомы еще до того, как они приведут к отказу. Например, в одной компании на протяжении нескольких недель контроллер диска записывал в системный журнал сообщения о возможном отказе кэш-памяти, встроенной в контроллер. И когда эта память, наконец, отказала, пропало несколько гигабайт важных данных.

Зеркальные диски

Наиболее простой способ увеличения надежности хранения данных - подключить к одному контроллеру два жестких диска и средствами ОС выполнить их зеркальное отображение. При этом один диск играет роль основного, а другой дублирует всю информацию, записываемую на основной диск. При выходе из строя основного диска его функции автоматически переходят к зеркальному диску, в результате чего система продолжает работать без аварийной остановки.

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

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

Такие ОС, как Microsoft Windows NT и Novell NetWare способны создавать зеркальные диски программным путем без применения дополнительного оборудования.

Отказы кэш-памяти

Как вы, вероятно, знаете, кэш-память значительно ускоряет операции записи данных на диск и чтения с диска за счет временного хранения данных в очень быстрой оперативной памяти. Если данные кэшируются при чтении, то отказ кэш-памяти не приведет к их потере, так как на диске они останутся в неизменном виде. Что же касается кэширования при записи, то эта операция несет в себе потенциальную опасность.

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

Операционные системы обычно выполняют дополнительное кэширование данных, записываемых на диск или считываемых с диска, в основной оперативной памяти компьютера. Поэтому отказы оперативной памяти, а также внезапное отключение электропитания могут привести (и обычно приводят!) к возникновению фатальных неисправностей файловой системы. Именно поэтому так важно снабжать компьютеры, и особенно серверы, устройствами бесперебойного питания. Кроме того, такие устройства должны быть в состоянии корректно завершать работу ОС компьютера без вмешательства человека. Только в этом случае отключения электропитания не приведут к потере данных.

Неисправности электроники в дисках

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

Замена контроллера диска

Иногда данные пропадают после замены дискового контроллера на контроллер другого типа (такая проблема обычно возникает с контроллерами SCSI). Операционная система в этих случаях просто отказывается монтировать диск. Выбрав правильный тип контроллера, обычно удается легко ликвидировать данную проблему, однако так бывает не всегда.

Сбои, возникающие из-за пыли

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

Когда компьютер переносят с одного места на другое, комочки пыли перекатываются внутри корпуса и могут привести к замыканию. Именно так пропали данные на сервере у одного из наших клиентов после перестановки сервера из одной стойки в другую.

Чтобы уменьшить вероятность возникновения сбоев из-за пыли, используйте в ответственных случаях специальные пылезащищенные корпуса и периодически выполняйте профилактические работы, удаляя пыль при помощи специального "компьютерного" пылесоса.

Конечно же вы попадали в такую ситуацию, когда приложение, разработанное вами ранее, могло быть снова использовано в рамках другого проекта. Вначале вы конечно же подумали, что это не создаст никаких проблем. Всего-то необходимо скопировать код из одного каталога в другой! Со временем вы осознали, что проекты могут различаться между собой различными параметрами, пусть даже самыми незначительными. Например, это может быть e-mail адрес на который отсылаются сообщения. В таком случае вам ничего не остается, как открыть множество файлов в редакторе и изменить их содержимое, вставляя нужный e-mail при помощи функции найти/заменить. Эта статья расскажет вам о том, как можно избавить себя от подобной работы, а так же порекомендует ряд дополнительных средств для создания и чтения конфигурационных файлов.

Повторное использование кода

Компьютер был изобретен для того, чтобы избавить человека от лишней работы. Развитие компьютерных технологий привело к тому, что человек стал стремиться все меньше времени проводить за компьютером. Допустим, вы программист. Не будь компьютера, вы бы остались без работы. Но в то же время вы стараетесь с помощью компьютера упростить свою ежедневную работы, с этой целью вы используете, например, функцию автозавершения кода в редакторе. Мы хотим подвести вас к той мысли, что код созданный вами, должен быть организован так, чтобы работы по его модификации были сведены к минимуму. Чаще всего это удается, когда вы создаете код, автоматизирующий рутинные операции, такие как создание и прорисовка формы, а так же отправка e-mail. Однако не стоит забывать, что функции для выполнения рутинных операций никогда не бывают на 100% идентичными в различных приложениях. Один формуляр не похож на другой, а сообщения электронной почты предназначены разным адресатам. Однако логика на уровне приложения остается прежней, функции различаются между собой только некоторыми параметрами. Таким образом, вы должны ясно представлять свою цель – разработать код, параметры которого можно было бы определять извне.

Модульная организация

Для решения этой задачи, планируя структуру приложения, вы должны позаботиться о модульности. То есть вам необходимо поместить часто используемые функции или классы в отдельный файл, который будет подключаться через require_once. В этом случае файлы приложения не будут наполнены избыточным кодом. Допустим, вы часто осуществляете запись в лог-файл. В таком случае было бы неплохо код, выполняющий эту операцию, заключить в рамки класса или функции. Будет еще лучше, если вы воспользуетесь уже готовым классом, взятым из какой-нибудь библиотеки исходных кодов, например PEAR.

Параметры процедурального кода

После того, как вы проанализировали код, выделили повторяющиеся фрагменты, распределили их по классам и функциям, необходимо подумать о выделении необходимых параметров, значения которых будут устанавливаться извне. Если речь идет о процедуральном коде, самым простым решением является использование глобальных переменных, которые необходимо определить в отдельном файле. Это позволит в дальнейшем без проблем изменять их значения.

Листинг 1 демонстрирует функцию, которая занимается отправкой e-mail. В ее теле содержится только одна php-функция - mail(). Таким образом, мы избавляемся от необходимости каждый раз указывать получателя при отправке сообщения. Следующая переменная, которую мы определяем, обозначает префикс, предшествующий теме сообщения. Конфигурационный файл, подключаемый через require_once, мог бы выглядеть следующим образом.

Listing 1

PHP - Код

$to = 'webmaster@localhost';
  $prefix = '[Testinstallation] ';

PHP - Код

function sendMail( $subject, $body )
  {
    global $to, $prefix;
    $subject = $prefix . $subject;
    return mail( $to, $subject, $body );
  }
  require_once 'config1.php';
  sendMail( 'Test', 'Это тестовое сообщение.' );

Есть способ лучше

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

Глобальные переменные, которые мы используем, могут породить конфликты в пространстве имен.

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

Для того, чтобы получить доступ к различным переменным, необходимо обращаться к массиву $_GLOBALS.

Вместо php-модулей существуют другие форматы, которые могут быть легко поняты и изменены дилетантами, а так же php-скриптами. Мы имеем в виду два формата: этого широко используемые операционной системой Windows ini-файлы, а так же формат XML.

PHP уже содержит функцию parse_ini_file(), которая без проблем читает ini-файлы. Такой файл имеет очень простую структуру. Каждой опции может быть присвоено только одно значение, а в качестве оператора присваивания используется знак равенства. Конфигурационный файл из предыдущего примера выглядел бы следующим образом в ini-формате.

PHP - Код

to = "webmaster@localhost"
prefix = "[Testinstallation] "

После считывания ini-файла, имя которого передается в качестве параметра функции parse_ini_file(), мы получаем ассоциативный массив, имеющий вид:

PHP - Код

Array
(
  [to] => webmaster@localhost
  [prefix] => [Testinstallation]
)

В листинге 2 находится функция отправки почты, основанная на ini-файлах:

Listing 2

PHP - Код

function sendMail( $subject, $body )
  {
    $config = parse_ini_file( 'config1.ini' );
    $to = $config['mail_to'];
    $prefix = $config['mail_prefix'];
    $subject = $prefix . $subject;
    return mail( $to, $subject, $body );
  }
  sendMail( 'Test', 'Это тестовое письмо.' );

Если вы уже прочитали документацию по функции parse_ini_file(), вы кончено же заметили, что она может принимать и второй параметр. Он необходим, если вы хотите разделить ini-файл на несколько разделов или секций. Предположим, вам необходимо сохранить несколько настроек электронной почты. Тогда ini-файл будет выглядеть следующим образом:

PHP - Код

[errors]
to = "webmaster@localhost"
prefix = "[Testinstallation] "

[contact]
to = "kunde@test.de"
prefix = "[Contact]

"

Если вы при вызове parse_ini_file() передаете true в качестве второго параметра, в этом случае php будет искать в файле секции, а затем вернет многомерный массив, в котором каждой секции (errors и contact) будет соответствовать определенный набор значений:

PHP - Код

Array
(
  [errors] => Array
  (
    [to] => webmaster@localhost
    [prefix] => [Testinstallation]
  )
  [contact] => Array
  (
    [to] => kunde@test.de
    [prefix] => [Testinstallation]
  )
)

Особые значения в ini-файлах

При использовании ini-файлов вы должны иметь в виду, что некоторые особые значения могут быть представлены строками. Допустим, вы определяете значение опции как true или yes (без кавычек), в таком случае они автоматически конвертируются в число 1, а false или no – в пустую строку. К сожалению, при этом не генерируется никакой ошибки. Поэтому не пытайтесь использовать no для сокращенного обозначения Норвегии.

Listing 3

PHP - Код

$config = parse_ini_file( 'config2.ini', true );
  echo '<pre>';
  print_r( $config );
  echo '</pre>';

Безопасность

Вы должны понимать то, что если конфигурационный файл используется для хранения важных данных, например паролей, необходимо позаботиться о том, чтобы содержимое такого файла не попало в web-браузер. Простейший выход из положения заключается в том, чтобы хранить конфигурационные файлы вне корневой директории сайта, например здесь: /etc/myApp/config

Если этого сделать нельзя, в таком случае можно изменить расширение файла. Для конфигурационного файла в формате модуля php необходимо всегда выбирать расширение .php. В этом случае сервер проанализирует php-файл, а пользователь увидит пустую страницу. С ini-файлами такое не пройдет, однако сервер Apache предоставляет возможность защитить данные. Просто поместите в каталог, где хранятся ini файл с именем .htaccess В него нужно поместить следующие строки:

Код

<Files *.ini>
Order deny,allow
Deny from all
</Files>

Теперь сервер перестанет выдавать файлы с расширением ini, а опции приложения будут скрыты от пользователей.
Другие средства

Кончено же вы не являетесь единственным разработчиком, который сталкивается с проблемой обеспечения гибкости настроек веб-приложения. Поэтому некоторые программисты уже разработали библиотеки классов, которые переводят работу с конфигурационными файлами на абстрактный уровень, а так же упрощают запись и чтение различных форматов конфигурационных файлов.
PEAR::Config

Одним из классов, который может пригодится при чтении и записи конфигурационных файлов является PEAR::Config [3]. Как и все классы PEAR, PEAR::Config инсталлируется при помощи PEAR-Installer по команде

Код

pear install Config

Этот класс является многоформатным, поскольку работает с конфигурационными файлами в форматах XMIL, ini, Apach-Style (гибрид XML и ini), а также php-массивами. Достоинством данного класса является то, что API для взаимодействия со всеми форматами одинаков. Т.е. логика работы с конфигурационными файлами в формате XML ничем не отличается от логики работы с ini-файлами. Вследствие этого необходимо, чтобы все форматы имели одинаковую структуру. Конфигурационные файлы, с которыми работает PEAR::Config, состоят, как и ini-файлы из секций.

Изменим снова наш пример. Сначала мы создаем объект Config, а затем вызываем его метод parseConfig(). Поскольку метод позволяет считывать различные форматы файлов, при вызове его необходимо передавать параметр, уточняющий формат. Для конфигурационных файлов в формате ini в качестве такого параметра используется строка iniFile. После считывания файла, мы не получаем опции в виде массива, вместо этого создается объект-контейнер, который дает доступ ко всем настройкам. Хотя во многих случаях бывает желательно получить опции в форме массива. Для этого используется метод toArray(). Листинг 4 демонстрирует считывание ini-файла:

Listing 4

PHP - Код


  require_once 'Config.php';

  $config = new Config();
  $root =& $config->parseConfig('config2.ini', 'IniFile');

  $settings = $root->toArray();

  echo "<pre>";
  print_r( $settings );
  echo "</pre>";

С первого взгляда это может показаться несколько запутанным. Однако преимущество данного подхода заключается в том, что один и тот же метод используется для чтения всех форматов файлов, поддерживаемых PEAR::Config. Измененные опции могут быть также сохранены в любом формате:

PHP - Код

$root->writeDatasrc( 'config2.conf', 'Apache' );

Листинг 5 содержит код, где серия опций помещается в массив, который затем сохраняется в формате XML. Если вы хотите побольше узнать о PEAR::Config необходимую информацию вы сможете найти в документации по PEAR[5] или в DevShed-Tutorial [6].

Listing 5

PHP - Код

require_once 'Config.php';

  $settings = array(
    'errors' => array(
      'email' => 'webmaster@localhost',
      'prefix' => '[ERRORS]',
    )
  );

  $config = new Config();
  $root =& $config->parseConfig($settings, 'PHPArray');
  $root->writeDatasrc( 'config2.xml', 'XML' );

patConfiguration

Альтернативным классом для работы с конфигурационными файлами является patConfiguration[7], однако он предназначен исключительно для работы с файлами в формате XML. После скачивания архива, его необходимо распаковать. Сам класс находится в директории include. patConfiguration предварительно определяет Tag-Set, который затем наполняется данными. К тому же этот класс предоставляет возможность указать тип опции: целое число, число с плавающей точкой, булевское значение. Типичный конфигурационный файл, созданный patConfiguration, имеет следующую структуру:

Код

<configuration>
<path name="fehler">
<configValue name="email" type="string">webmaster@localhost</configValue>
<configValue name="priority" type="float">100</configValue>
</path>
</configuration>

После создания объекта класса, может быть вызван метод parseConfigFile(). Доступ к опциям осуществляется через getConfigValue(). В качестве параметра этот метод может принимать путь к нужной опции. Вернемся к нашему примеру. Допустим, мы хотим получить e-mail адрес, на который высылается сообщение об ошибке. В этом случае используется путь errors.email. Если путь не указан, тогда все параметры передаются в массив. Листинг 6 демонстрирует код, который можно использовать для считывания файлов.
patConfiguration 2.0.0

В данный момент многоформатная версия patConfiguration находится в стадии разработки. Возможно, при публикации статьи эта версия уже станет доступной. Впрочем, самую новую версию для разработчиков вы можете скачать с сайта snaps.php-tools.net/downloaden.

В этом примере вы уже заметили, что внутри тега указывается тип значения. Названия типов идентичны тем, что используются в php-функции settype(). Если тип не указан, тогда значение интерпретируется как строка. Для часто используемых опций можно определить отдельный тег.

Код

<configuration>
<define tag="priority" type="float"/>
<define tag="email" type="string"/>
<path name="fehler">
<email>webmaster@localhost</email>
<priority>100</priority>
</path>
</configuration>

Наряду с функцией getConfigValue, существует функция setConfigValue(), с помощью которой можно изменить значение опции. Затем конфигурационный файл может быть заново записан с помощью writeConfigFile() (см листинг 7).

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

Дополнительную информацию вы сможете найти на PHP Application Tools-Homepage и в patConfiguration-Tutorial на DevShed [8].

Listing 7

PHP - Код

require_once 'include/patConfiguration.php';

  $config = new patConfiguration(
     array(
       "configDir" =>"./",
       "errorHandling" =>"nice_die"
     )
  );
  $config->parseConfigFile( 'config6.xml' );
  $config->setConfigValue( 'errors.email', 'errors@localhost' );
  $config->writeConfigFile( 'config6_new.xml', 'xml', array( 'mode' => 'pretty' ) );

Заключение

Забота о гибкости настроек приложения может сберечь много времени, особенно если его компоненты предполагается использовать в других проектах. Вы потратите еще меньше времени, если доверите работу с конфигурационными файлами одному из готовых классов. Выбор между PEAR::Config и patConfiguration зависит от задачи. Преимуществом PEAR::Config является поддержка различных форматов конфигурационных файлов, в то время как patConfiguration прекрасно работает с XML, так же предоставляет ряд дополнительных возможностей. Однако с появлением версии 2.0.0 этот пакет будет иметь одинаковый API для считывания ini и wddx файлов. PHP-массив поддерживаются уже в текущей версии.

Какие жесткие диски лучше установить на компьютере с windows 2000/XP: ata (иначе ide) или scsi? Спор о сравнительных достоинствах и недостатках дисков ata и scsi – один из самых давних в отрасли. В одной из статей я уже сравнивал технические характеристики различных вариантов этих технологий и рассказывал, как их использовать в системах на базе windows nt.

За последнее время появились новые реализации интерфейсов ata и scsi. Сфера scsi расширилась и теперь охватывает ultra2 scsi, волоконно-оптический канал, ultra160 scsi и новейший стандарт – ultra320 scsi. Максимальная пропускная способность этих устройств составляет 80, 100, 160 и 320 Мбайт/с, соответственно. Однако высокая скорость всегда была достоинством scsi, поэтому более важным событием стало сокращение ценового разрыва между технологией scsi и ее конкурентами.

ATA догоняет

Последние стандарты ata 66 (или ultra dma/66, или udma/66) и ata 100 (или ultra dma/100, или udma/100) обеспечивают быструю передачу данных в пакетном и непрерывном режимах (66 и 100 Мбайт/с, соответственно). Планка производительности ata поднимется еще выше с появлением в 2002 г. стандарта se-rialata (первые устройства будут обеспечивать скорость передачи данных 150 Мбайт/с, а в дальнейшем – до 300 и даже 600 Мбайт/с). Таким образом, ata уже годится не только для пользовательских систем и корпоративных настольных компьютеров начального уровня, но и для машин, к дисковой подсистеме которых предъявляются повышенные требования.

Реально на офисных однодисковых системах обычно не удается достигнуть максимального быстродействия. Системные ограничения (например, возможности микросхем ata, архитектура системной шины, физические ограничения диска) часто снижают скорость пересылки данных. Тем не менее, в основном из-за дороговизны scsi (которая объясняется высокой стоимостью контроллера и диска), ata преобладает везде, кроме настольных рабочих станций самого высокого уровня. Однако, чтобы добиться максимальной производительности дисков ata на компьютерах win-dows 2000, недостаточно просто установить новые накопители и подключить кабели.

Стараясь идти в ногу с технологией ata, разработчики microsoft дополнили windows 2000 новыми возможностями и уделяют ata больше внимания при подготовке различных пакетов исправления и программных заплаток. Чтобы эффективно использовать устройства ata на компьютерах windows 2000, требуется иметь базовые знания об интерфейсе ata, необходимых аппаратных средствах и программном обеспечении (например, пакетах исправления и заплатках windows 2000, встроенных драйверах и драйверах независимых поставщиков).

Аппаратные средства

Во-первых, в системе должен быть установлен контроллер, который поддерживает скоростные режимы ata. Самые распространенные стандарты современных дисков – ata/33 (ultra dma/33 или udma/33), ata/66 и ata/100. Практически все контроллеры ata обратно совместимы с дисками прежних стандартов. Например, контроллер ata/100 обычно совместим с дисками ata/33 и даже старыми стандартами ide и eide.

В большинстве систем контроллер реализован в микросхемах ata на системной плате (львиная доля рынка микросхем ata принадлежит компании intel, но есть и другие поставщики, такие, как viahardware.com). Однако в некоторых случаях контроллер может быть размещен на плате расширения pci, например в raid-контроллере ata.

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

Если микросхемы ata расположены на системной плате, необходимо убедиться, что bios системы поддерживает нужные режимы ata. По всей вероятности, конкретный режим ata реализован в наборе микросхем, но он может отсутствовать в редакции bios, регулярно обновляемой поставщиками ПК и системных микросхем. В этом случае новую версию bios можно получить на web-сайте изготовителя системной платы или компьютера.

Затем следует убедиться, что аппаратные средства обеспечивают нужный режим ata и настроены на оптимальную производительность. Во-первых, все жесткие диски должны поддерживать необходимые режимы ata (например, ata/66, ata/100). Во-вторых, важно распределить диски по отдельным каналам, так как по умолчанию канал ata работает со скоростью самого медленного диска. Если диски ata/33 и ata/100 установлены в одном канале, то скорость передачи данных будет определяться быстродействием ata/33. Поэтому следует разместить медленные устройства ata (например, устройства cd-rom, cd-r, cd-rw, zip, старые жесткие диски) на одном канале, а скоростные жесткие диски – на другом.

Кроме того, необходимо верно выбрать кабели. В спецификациях ata/33, ata/66 и ata/100 указывается, что устройства следует подключать через специальный 80-жильный ленточный кабель, а не 40-жильные кабели, применявшиеся в прежних дисках ata. Дополнительные жилы кабеля нужны для заземления и увеличивают соотношение сигнал/шум при передаче данных. И наконец, накопители следует подключать к 80-жильному кабелю иначе, чем к прежним 40-жильным кабелям. Главное устройство (drive 0) необходимо разместить на конце 80-жильного кабеля, а вторичный накопитель (drive 1) нужно подключить к среднему разъему. Синий разъем на одном конце предназначен для системной платы или платы контроллера, серый разъем в середине – для вторичного устройства, а черный разъем на другом конце – для главного устройства.

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

Многие фирмы, пользуясь ситуацией, предлагают свои услуги по восстановлению информации с вышедшего из строя накопителя. Очевидно, это обходится недешево и целесообразно только тогда, когда на диске находилось что-то действительно ценное. В противном случае легче просто смириться с потерей.

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

Один из самых частых отказов винчестеров фирмы western digital (а также и некоторых других) выглядит следующим образом: жесткий диск не опознается bios, а головки при этом отчетливо стучат. Скорее всего, по какой-то причине не работает блок термокалибровки, и устройство не может обеспечить нужный зазор между головкой и рабочей поверхностью "блина". Обычно это происходит при отклонении от нормального температурного режима эксплуатации, например, в зимнее время, когда жесткие диски в плохо отапливаемых помещениях "выстывают" за ночь (при температуре 18...210С жесткий диск часто может исправно функционировать и с испорченным механизмом термокалибровки). Попробуйте дать поработать винчестеру в течение нескольких часов, чтобы он прогрелся, при этом рано или поздно винчестер попадает в необходимый диапазон температур и работоспособность (возможно, временно) восстанавливается. Разумеется, первым делом нужно скопировать всю информацию, поскольку работоспособность такого диска уже не гарантируется. То же можно рекомендовать и в отношении устаревших моделей без термокалибровки; часто они оказываются зависимыми от температурного режима, и с ростом износа винчестера эта зависимость проявляется все сильнее.

Вторым по распространенности отказом является выход из строя модуля диагностики при полной исправности остальных компонентов. Как это ни покажется парадоксальным, но полностью рабочий винчестер не проходит диагностику. При этом в регистре ошибок (порт ox1f1 для первого жесткого диска) могут содержаться значения, приведенные ниже:
Диагностические ошибки
Бит Содержимое Источник ошибки
7 0 Ошибка master диска
1 Ошибка slave диска
2-0 011 Ошибка секторного буфера
100 Ошибка контрогльной суммы, не устранимая избыточным кодированием
101 Ошибка микроконтроллера

Разные biosы могут различно реагировать на такую ситуацию, но все варианты сводятся к одному - жесткий диск не определяется и не "чувствуется". Однако на уровне портов ввода/вывода устройство функционирует отлично. Заметим, что существуют такие материнские платы (особенно среди новых моделей), которые, обнаружив ошибку микроконтроллера винчестера, просто отключают питание жесткого диска. Несложно написать для испорченного таким образом винчестера драйвер, который обеспечит работу с диском через высокоуровневый интерфейс int 0x13. Например, следующая процедура обеспечивает посекторное чтение и запись через порты ввода/вывода для первого жесткого диска в chs режиме.

lba mode для упрощения понимания не поддерживается. Необходимую техническую информацию обычно можно найти на сайте производителя вашего жесткого диска.

Этот фрагмент может служить вполне работоспособным ядром для драйвера 16-ти разрядного режима. Для упрощения понимания не включена задержка после каждого обращения к порту. В зависимости от соотношений скорости вашего процессора и контроллера диска эта задержка может и не потребоваться (в противном случае рекомендуется читать регистр статуса ox1f7, дожидаясь готовности контроллера). При этом не следует спешить с заменой такого жесткого диска на новый, с подобной неисправностью можно успешно работать не год и не два. Последнее, правда, лишь при условии, что все используемое программное обеспечение не будет конфликтовать с нестандартным драйвером. Писать драйвер, скорее всего, придется вам самому, поскольку не известно ни одной коммерческой разработки в этом направлении, а все любительские разработки выполнены в основном "под себя". Так, например, драйвер от kpnc hddfix3a поддерживает только винчестеры primary master до пятисот мегабайт и не работает в среде windows 95 (разработан на год раньше ее появления).

Более легкий, но не всегда осуществимый путь - запретить тестирование жестких дисков biosом или, по крайней мере, игнорировать результаты такового. Как это осуществить, можно прочесть в руководстве на материнскую плату (или обратиться за помощью к службе технической поддержки фирмы-производителя, поскольку в руководствах пользователя такие тонкости нередко опускают). Например, попробуйте установить "halt on" в "never" или перезаписать flach bios, модифицировав его так, чтобы тот не выполнял подобную проверку. Если Вам повезет, жесткий диск заработает! Однако иногда все же происходят и аппаратные отказы. Например, у винчестеров фирм samsung и conner отмечены случаи отказа модуля трансляции мультисекторного чтения/записи. Если это не будет обнаружено внутренним тестом устройства, то такой жесткий диск вызовет зависание операционной системы на стадии ее загрузки. Для предотвращения этого достаточно добавить в config.sys ключ multi-track=off и отключить аналогичные опции в blose. При этом, проиграв в скорости, все же можно заставить жесткий диск сносно работать. Понятно, что эксплуатировать восстановленный таким образом диск длительное время нерационально по причине потери быстродействия. Лучше приобрести новый, на который и скопировать всю информацию. С другой стороны, такой жесткий диск все же остается полностью рабочим и успешно может служить, например, в качестве резервного.

На том же connere эпизодически выходит из строя блок управления позиционированием головок, так что последние уже не могут удержаться на дорожке и при обращении к следующему сектору немного "уползают". При этом считывание на выходе дает ошибочную информацию, а запись необратимо затирает соседние сектора. Бороться с этим можно позиционированием головки перед каждой операцией записи/чтения, обрабатывая за один проход не более сектора. Понятно, что для этого необходимо вновь садиться за написание собственного драйвера. К счастью, он достаточно простой (можно использовать аппаратное прерывание от жесткого диска int 0x76 irq14, вставив в тело обработчика команду сброса контроллера. В данном случае подразумевается, что контроллер используемого жесткого диска проводит рекалибровку головки во время операции сброса. Некоторые модели этого не делают. В этом случае придется прибегнуть к операции позиционирования головки (функция ОхС дискового сервиса 0x13). Первые модели от вторых можно отличить временем, требуемым на сброс контроллера. Понятно, что электроника "сбрасывается" мгновенно, а позиционирование головки требует хоть и не большого, но все же заметного времени. Современные модели с поддержкой кэширования этого часто не делают или "откладывают" операции с головкой до первого к ней обращения. Разумеется, в этом случае кэширование придется выключить. Большинство bios позволяет это делать без труда, и нет нужды программировать контроллер самостоятельно. В другом случае вышедший из строя блок позиционирования (трансляции) подводит головки вовсе не к тому сектору, который запрашивался. Например, головки могли физически сместиться с оси, "уползая" в сторону. Разумеется, этот дефект можно скорректировать программно, достаточно проанализировать ситуацию и логику искажения трансляции. Многие модели позиционируют головку, используя разметку диска, что страхует от подобных поломок (к сожалению, сейчас от такого подхода большинство фирм отказались, выигрывая в скорости).

Конечно, все описанные программные подходы в действительности не устраняют неисправность, а только позволяют скопировать с казалось бы уже нерабочего винчестера ценные и еще не сохраненные данные. При этом ни к чему писать универсальный драйвер для win32 и защищенного режима. Вполне можно ограничиться dos-режимом. Для копирования файлов последнего должно оказаться вполне достаточно, конечно за исключением тех случаев, когда диск был отформатирован под ntsf или другую, не поддерживаемую ms-dos, систему. К счастью, для многих из них есть драйверы, которые позволяют "видеть" подобные разделы даже из "голой" ms-dos. В крайнем случае, можно ограничиться посекторным копированием на винчестер точно такой же топологии. При этом совершенно не имеет значения используемая файловая система и установленная операционная система.

Посекторно скопировать диск на винчестер с иной топологией трудно, но возможно. Дело в том, что многие современные контроллеры жестких дисков позволяют пользователю менять трансляцию произвольным образом. Для этого необходимо приобрести винчестер, поддерживающий lba-режим (а какой из современных жестких дисков его не поддерживает?). При этом он может быть даже большего объема, нежели исходный, но это никак не помешает копированию. Другой вопрос, что без переразбиения скопированный таким образом диск не "почувствует" дополнительных дорожек и следует запустить norton disk doctor, который устранит эту проблему.

Достаточно часто нарушается вычисление зон предком-пенсации. Дело в том, что плотность записи на разных цилиндрах не одинакова, так как линейная скорость растет от центра диска к периферии. Разумеется, гораздо легче постепенно уплотнять записи, нежели искать некий усредненный компромисс. На всех существующих моделях плотность записи изменяется скачкообразно и на последних моделях программно доступна через соответствующие регистры контроллера. При этом значения, выставленные в bios, практически любой жесткий диск (с интерфейсом ide) просто игнорирует. Предыдущие модели не имели с этим проблем, и только винчестеры, выпущенные в течение последних двух лет, склонны к подобным поломкам. Скорее, даже не к поломкам, а к сбоям, в результате которых искажается хранимая где-то в недрах жесткого диска информация. Если контроллер позволяет ее программно корректировать, то считайте, что ваш жесткий диск спасен. Конечно, придется пройти сквозь мучительные попытки угадать оригинальные значения, однако это можно делать и автоматическим перебором до тех пор, пока винчестер не начнет без ошибок читать очередную зону. Помните, что любая запись на диск способна нарушить низкоуровневую разметку винчестера, после чего последний восстановлению не подлежит и его останется только выкинуть. Производите только чтение секторов!

Если же контроллер не позволяет программно управлять предкомпенсацией, то еще не все потеряно. Попробуйте перед каждым обращением делать сброс контроллера, а точнее, его рекалибровку (команда ixh). В некоторых случаях это срабатывает, поскольку с целью оптимизации скорости обмена предкомпенсацией обычно управляет не один блок. И, кроме того, иногда контроллер кэша не учитывает предкомпенсацию, а его сброс реализует последнюю аппаратно. К сожалению, это по большей части догадки и результаты экспериментов автора, так как техническая документация фирм-производителей по этому поводу не отличается полнотой, а местами содержит противоречия. Можно испытать и другой способ - попробовать перезаписать микрокод контроллера (команда 92h). Конечно, это доступно только для специалистов очень высокого класса, но ведь доступно! Заметим, что не все контроллеры поддерживают такую операцию. С другой стороны, это и хорошо, так как уменьшает вероятность сбоя и не дает некорректно работающим программам (вирусам в том числе) испортить дорогое устройство. Жесткие диски от samsung обладают еще одной неприятной особенностью - часто при подключении шлейфа "на лету", при включенном питании, они перестают работать. Внешне это выглядит так: индикатор обращения к диску постоянно горит, но диск даже не определяется biosom, или определяется, но все равно не работает. Близкое рассмотрение показывает, что на шине пропадает сигнал готовности устройства. В остальном контроллер остается неповрежденным. Разумеется, если не обращать внимание на отсутствие сигнала готовности, то с устройством можно общаться, делая вручную необходимые задержки (поскольку физическую готовность устройства уже узнать не представляется возможным, приходится делать задержки с изрядным запасом времени). При этом, к сожалению, придется отказаться от dma-mode (а уж тем более ultra-dma) и ограничиться pio 1 (с небольшим риском - pio 2) режимом. Конечно, писать соответствующий драйвер вам придется опять самостоятельно. Разумеется, скорость обмена в режиме pio 1 по сегодняшним меркам совершенно неудовлетворительна и не годится ни для чего другого, кроме как копирования информации со старого на новый винчестер, но некоторые "нечистоплотные" продавцы компьютерной техники как-то ухитряются устанавливать подобные экземпляры на продаваемые машины. Будьте осторожны! Учитывая, что написание подобных драйверов для win32 - трудоемкое занятие, большинство ограничивается поддержкой одной лишь ms-dos, и вовсе не факт, что компьютер, демонстрирующий загрузку win95, содержит исправный, а не реанимированный подобным образом жесткий диск.

У жестких дисков фирмы samsung при подключении "налету" может появляться другой неприятный дефект - при запросах на чтение контроллер периодически "повисает" и не завершает операцию. В результате "замирает" вся операционная система (впрочем, windows nt с этим справляется, но, вероятно, не всегда). На первый взгляд может показаться, что с этого винчестера несложно скопировать ценные файлы, но при попытке выполнить это выясняется, что диск "зависает" все чаще и чаще и копирование растягивается до бесконечности. Однако если выполнить сброс контроллера, то можно будет повторить операцию. Это можно сделать аппарат -но, подпаяв одну кнопку на линию сброса и статуса. Последнее нужно для указания на ошибочную ситуацию, чтобы операционная система повторила незавершенную операцию. Если этого не сделать, то часть секторов не будет реально прочитана (записана). Или можно выполнять сброс автоматически, например, по таймеру. Чтобы не сталкиваться с подобной ситуацией, никогда не следует подсоединять/отсоединять винчестер при включенном питании. Очень часто это приводит к подобным ошибкам, хотя производители других фирм, по-видимому, как-то от этого все же защищаются, ибо аналогичной ситуации у них практически не встречается. Все же не стоит искушать судьбу... От аппаратных ошибок теперь перейдем к дефектам поверхности. Заметим сразу, что последнее встречается гораздо чаще и проявляется намного коварнее. Обычно это ситуация, в которой мало что можно предпринять. Но достичь главной цели - спасти как можно больше уцелевших данных - довольно часто удается. Возьмем такую типичную ситуацию как ошибка чтения сектора. Маловероятно, чтобы сектор был разрушен целиком. Чаще всего "сыплется" только какая-то его часть, а все остальные данные остаются неискаженными. Существуют контроллеры двух типов. Первые, обнаружив расхождение контрольной суммы считанного сектора, все же оставляют прочитанные данные в буфере и позволяют их извлечь оттуда, проигнорировав ошибку чтения. Вторые либо очищают буфер, либо просто не сбрасывают внутренний кэш, в результате чего все равно прочитать буфер невозможно. На практике обычно встречаются последние. При этом сброс кэша можно инициировать серией запросов без считывания полученных данных. Кэш при этом переполняется, и наиболее старые данные будут вытолкнуты в буфер. Остается их только прочесть. Конечно,-это крайне медленно, но, к сожалению, универсальной команды сброса кэша не существует. Разные разработчики реализуют это по-своему (впрочем, иногда это можно найти в документации на чипы, используемые в контроллере). western digital сообщает в техническом руководстве что при длинном чтении сектора без повтора контроль сектора не выполняется и он будет-таки целиком помещен в буфер. Кстати, так и должно быть по стандарту. Увы, остальные фирмы от него часто отклоняются по разным соображениям. Остается определить, какие же из прочитанных данных достоверные, а какие нет (если этого не видно "визуально" - например, в случае текстового или графического файлов)? Разумеется, в подобных рамках задача кажется неразрешимой, но это не совсем так. Дело в том, что можно произвести не только короткое, но и длинное чтение (ox22h req ploin long with retry), для чего можно использовать следующую процедуру. При этом кроме собственно данных читаются также и корректирующие коды. Автоматическая коррекция не выполняется (хотя некоторые контроллеры это реализуют аппаратно и не могут отключить автокоррекцию; в документации этот момент, кстати, не уточняется). Как правило, используются корректирующие коды Рида-Соломона, хотя последнее не обязательно. Математические законы позволяют не только определить место возникновения сбоя, но и даже восстановить несколько бит. При больших разрушениях можно определить только место сбоя, но достоверно восстановить информацию не удается.

Модуляция при записи такова, что все биты, стоящие справа от сбойного, уже не достоверны. Точнее, не все, а только в пределах одного пакета. Обычно за один раз записывается от 3 до 9 бит (необходимо уточнить у конкретного производителя) и содержимое остальных пакетов, как правило, остается достоверным. Самое интересное, что зачастую сбойный пакет можно восстановить методом перебора! При этом можно даже рассчитать, сколько вариантов должно получиться. Учитывая хорошую степень "рассеяния" корректирующих кодов можно сказать, что не очень много. И таким образом можно восстановить казалось бы безнадежно испорченные сектора, а вместе с ними и файлы, расположенные "поверх" последних.

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

Для того чтобы воспользоваться некоторыми советами в данном обзоре, необходимо вносить изменения в Реестр. Будьте предельно осторожны! Ошибки при редактировании системных файлов могут привести к серьезным проблемам.

---

Чтобы уберечься от неприятностей, скопируйте Реестр и другие важные файлы, прежде чем вносить в них какие-либо изменения. Сделать это просто.

Достаточно перейти в меню Start и щелкнуть на разделе Programs в Windows Me или All Programs в Windows XP. Выберите пункты Accessories (Стандартные), System Tools (Служебные) и System Restore (Восстановление системы).

Создайте точку восстановления, выбрав функцию Create a restore point и щелкните на кнопке Next. Дайте описание точки восстановления и щелкните на кнопке Next в Windows Me или Create в Windows XP.

Если в системе возникли неполадки, но запустить Windows все же удается, вновь обратитесь к System Restore (как описано выше) и выберите функцию восстановления прежнего состояния Restore my computer to an earlier time.

Если Windows не загружается, нажмите клавишу F8, когда дается старт попытке загрузить операционную систему. Пользователям Windows Me следует загрузиться в режиме Safe Mode и запустить System Restore. В Windows XP можно воспользоваться режимом Safe Mode или восстановить последнюю корректную конфигурацию (Last Known Good Configuration).

Для программирования расширенных хранимых процедур Microsoft предоставляет ODS (Open Data Service) API набор макросов и функций, используемых для построения серверных приложений позволяющих расширить функциональность MS SQL Server 2000.

---

Расширенные хранимые процедуры - это обычные функции написанные на С/C++ с применением ODS API и WIN32 API, оформленные в виде библиотеки динамической компоновки (dll) и призванные, как я уже говорил, расширять функциональность SQL сервера. ODS API предоставляет разработчику богатый набор функций позволяющих передавать данные клиенту, полученные от любых внешних источников данных (data source) в виде обычных наборов записей (record set). Так же, extended stored procedure может возвращать значения через переданный ей параметр (OUTPUT parametr).

Как работают расширенные хранимые процедуры.

* Когда клиентское приложение вызывает расширенную хранимую процедуру, запрос передаётся в TDS формате через сетевую библиотеку Net-Libraries и Open Data Service ядру MS SQL SERVER.
* SQL Sever находит dll библиотеку ассоциированную с именем расширенной хранимой процедуры и загружает её в свой контекст, если она не была загружена туда ранее, и вызывает расширенную хранимую процедуру, реализованную как функцию внутри dll.
* Расширенная хранимая процедура выполняет на сервере необходимые ей действия и передаёт набор результатов клиентскому приложению, используя сервис предоставляемый ODS API.


Особенности расширенных хранимых процедур.

* Расширенные хранимые процедуры - это функции выполняющиеся в адресном пространстве MS SQL Server и в контексте безопасности учётной записи под которой запущена служба MS SQL Server;
* После того, как dll библиотека с расширенными хранимыми процедурами была загружена в память, она остаётся там до тех пор, пока SQL Server не будет остановлен, или пока администратор не выгрузит её принудительно, используя команду :
DBCC DLL_name (FREE).
* Расширенная хранимая процедура запускается на выполнение так же, как и обычная хранимая процедура:
EXECUTE xp_extendedProcName @param1, @param2 OUTPUT
@param1 входной параметр
@param2 входной/выходной параметр


Внимание!
Так как расширенные хранимые процедуры выполняются в адресном пространстве процесса службы MS SQL Server, любые критические ошибки, возникающие в их работе, могут вывести из строя ядро сервера, поэтому рекомендуется тщательно протестировать Вашу DLL перед установкой на рабочий сервер.

Создание расширенных хранимых процедур.

Расширенная хранимая процедура эта функция имеющая следующий прототип:

Код

SRVRETCODE xp_extendedProcName (SRVPROC * pSrvProc);

Параметр pSrvProc указатель на SRVPROC структуру, которая является описателем (handle) каждого конкретного клиентского подключения. Поля этой структуры недокументированны и содеражат информацию, которую библиотека ODS использует для управления коммуникацией и данными между серверным приложением (Open Data Services server application) и клиентом. В любом случае, Вам не потребуется обращаться к этой структуре и тем более нельзя модифицоравать её. Этот параметр требуется указывать при вызове любой функции ODS API, поэтому в дальнейшем я небуду останавливаться на его описании.
Использование префикса xp_ необязательно, однако существует соглашение начинать имя расширенной хранимой процедуры именно так, чтобы подчеркнуть отличие от обычной хранимой процедуры, имена которых, как Вы знаете, принято начинать с префикса sp_.
Так же следует помнить, что имена расширенных хранимых процедур чувствительны к регистру. Не забывайте об этом, когда будете вызвать расширенную хранимую процедуру, иначе вместо ожидаемого результата, Вы получите сообщение об ошибке.
Если Вам необходимо написать код инициализации/деинициализации dll, используйте для этого стандартную функцию DllMain(). Если у Вас нет такой необходимости, и вы не хотите писать DLLMain(), то компилятор соберёт свою версию функции DLLMain(), которая ничего не делает, а просто возвращает TRUE. Все функции, вызываемые из dll (т.е. расширенные хранимые процедуры) должны быть объявлены, как экспортируемые. Если Вы пишете на MS Visual C++ используйте директиву __declspec(dllexport). Если Ваш компилятор не поддерживает эту директиву, опишите экспортируемую функцию в секции EXPORTS в DEF файле.
Итак, для создания проекта, нам понадобятся следующие файлы:

* Srv.h заголовочный файл, содержит описание функций и макросов ODS API;
* Opends60.lib файл импорта библиотеки Opends60.dll, которая и реализует весь сервис предоставляемый ODS API.

Microsoft настоятельно рекомендует, чтобы все DLL библиотеки реализующие расширенные хранимые процедуры экспортировали функцию:

Код

__declspec(dllexport) ULONG __GetXpVersion()
{
return ODS_VERSION;
}

Когда MS SQL Server загружает DLL c extended stored procedure, он первым делом вызывает эту функцию, чтобы получить информацию о версии используемой библиотеки.

Для написания своей первой extended stored procedure, Вам понадобится установить на свой компьютер:

- MS SQL Server 2000 любой редакции (у меня стоит Personal Edition). В процесе инсталляции обязательно выберите опцию source sample
- MS Visual C++ (я использовал версию 7.0 ), но точно знаю подойдёт и 6.0

Установка SQL Server -a нужна для тестирования и отладки Вашей DLL. Возможна и отладка по сети, но я этого никогда не делал, и поэтому установил всё на свой локальный диск. В поставку Microsoft Visual C++ 7.0 редакции Interprise Edition входит мастер Extended Stored Procedure DLL Wizard. В принципе, ничего сверх естественного он не делает, а только генерирует заготовку шаблон расширенной хранимой процедуры. Если Вам нравятся мастера, можете использовать его. Я же предпочитаю делать всё ручками, и поэтому не буду рассматривать этот случай.

Теперь к делу:
- Запустите Visual C++ и создайте новый проект - Win32 Dynamic Link Library.
- Включите в проект заголовочный файл - #include <srv.h>;
- Зайдите в меню Tools => Options и добавьте пути поиска include и library файлов. Если , при установке MS SQL Server, Вы ничего не меняли, то задайте:

- C:Program FilesMicrosoft SQL Server80ToolsDevToolsInclude для заголовочных файлов;
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsLib для библиотечных файлов.
- Укажите имя библиотечного файла opends60.lib в опциях линкера.

На этом подготовительный этап закончен, можно приступать к написанию своей первой extended stored procedure.

Постановка задачи.

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

Разработать расширенную хранимую процедуру для MS SQL Server 2000, которая получает полный список пользователей зарегистрированных в домене, и возвращает его клиенту в виде стандартного набора записей (record set). В качестве первого входного параметра функция получает имя сервера содержащего базу данных каталога (Active Directory), т.е имя контролера домена. Если этот параметр равен NULL, тогда необходимо передать клиенту список локальных групп. Второй параметр будет использоваться extended stored procedure для возварата значения результата успешной/неуспешной работы (OUTPUT параметр). Если, расширенная хранимая процедура выполнена успешно, тогда необходимо передать количество записей возвращённых в клиентский record set , если в процессе работы не удалось получить требуемую информацию, значение второго параметра необходимо установить в -1, как признак неуспешного завершения.

Условный прототип расширенной хранимой процедуры следующий:

Код

xp_GetUserList(@NameServer varchar[15], @CountRec int OUTPUT);

.
А вот шаблон расширенной хранимой процедуры, который нам предстоит наполнить содержанием:

Код

#include <windows.h>
#include <srv.h>
#define XP_NOERROR 0
#define XP_ERROR -1


__declspec(dllexport) SERVRETCODE xp_GetGroupList(SRVPROC* pSrvProc)
{

//Проверка кол-ва переданных параметров

//Проверка типа переданных параметров

//Проверка, является ли параметр 2 OUTPUT параметром

//Проверка, имеет ли параметр 2 достаточную длину для сохранения значения

//Получение входных параметров

//Получение списка пользователей

// Посылка полученных данных клиенту в виде стандартного набора записей (record set)

//Установка значения OUTPUT параметра

return (XP_NOERROR);
}

Работа с входными параметрами

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

Первое действие, которое должна выполнить наша exteneded stored procedure , - получить параметры, которые были переданы ей при вызове. Следуя приведённому выше алгоритму нам необходимо выполнить следующие действия:

- Определить кол-во переданных параметров;
- Убедится, что переданные параметры имеют верный тип данных;
- Убедиться, что указанный OUTPUT параметр имеет достаточную длину, для сохранения в нём значения возвращаемого нашей extended stored procedure.
- Получить переданные параметры;
- Установить значения выходного параметра как результат успешного/неуспешного завершения работы extended stored procedure .

Теперь рассмотрим подробно каждый пункт:

Определение количества переданных в расширенную хранимую процедуру параметров

Для получения количества переданных параметров необходимо использовать функцию:

Код

int srv_rpcparams ( SRV_PROC * srvproc );

.
При успешном завершении функция возвращает количество переданных в расширенную хранимую процедуру параметров. Если extended stored procedure была вызвана без параметров - srv_rpcparams ввернёт -1. Параметры могут быть переданы по имени или по позиции (unnamed). В любом случае, нельзя смешивать эти два способа. Попытка передачи в функцию входных параметров по имени и по позиции одновременно - приведёт к возникновению ошибки, и srv_rpcparams вернёт 0 .

[pagebreak]

Определение типа данных и длины переданых параметров

Для получения информации о типе и длине переданных параметров Microsoft рекомендует использовать функцию srv_paramifo. Эта универсальная функция заменяет вызовы srv_paramtype, srv_paramlen, srv_parammaxlen, которые теперь считаются устаревшими. Вот её прототип:

Код

int srv_paraminfo (
SRV_PROC * srvproc,
int n,
BYTE * pbType,
ULONG* pcbMaxLen,
ULONG * pcbActualLen,
BYTE * pbData,
BOOL * pfNull );

.
.
.
.
.
.
.
.
.
.
pByte - указатель на переменную получающую информацию о типе входного параметра;
pbType задаёт порядковый номер параметра. Номер первого параметра начинается с 1.
pcbMaxLen - указатель на переменную, в которую функция заносит максимальное значение длины параметра. Это значение обусловлено конкретным типом данных переданного параметра, его мы и будем использовать, чтобы убедиться втом, что OUTPUT параметр имеет достаточную длину для сохранения передаваемых данных.
pcbActualLen указатель на реальную длину параметра переданного в расширенную хранимую процедуру при вызове. Если передаваемый параметр имеет нулевую длину, а флаг pfNull устанавлен в FALSE то (* pcbActualLen) ==0.
pbData - указатель на буфер, память для которого должна быть выделена перед вызовом srv_paraminfo. В этом буфере функция размещает полученные от extended stored procedure входные параметры. Размер буфера в байтах равен значению pcbMaxLen. Если этот параметр установлен в NULL, данные в буфер не записываются, но функция корректно возвращает значения *pbType, *pcbMaxLen, *pcbActualLen, *pfNull. Поэтому вызывать srv_paraminfo нужно дважды: сначала с pbData=NULL, потом, выделив необходимый размер памяти под буфер равный pcbActualLen, вызвать srv_paraminfo второй раз, передав в pbData указатель на выделенный блок памяти.
pfNull указатель на NULL-флаг. srv_paraminfo устанавливает его в TRUE, если значение входного параметра равно NULL.

Проверка, является ли второй параметр OUTPUT параметром.

Функция srv_paramstatus() предназначена для определения статуса переданного параметра:

Код

int srv_paramstatus (
SRV_PROC * srvproc,
int n
);

.
.
.
.
.
n - номер параметра переданного в расширенную хранимую процедуру при вызове. Напомню: параметры всегда нумеруются с 1.
Для возврата значения, srv_paramstatus использует нулевой бит. Если он установлен в 1 переданный параметр является OUTPUT параметром, если в 0 обычным параметром, переданным по значению. Если, exteneded stored procedure была вызвана без параметров, функция вернёт -1.

Установка значения выходного параметра.

Выходному параметру, переданному в расширеную хранимую можно передать значение используя функцию srv_paramsetoutput. Эта новая функция заменяет вызов функции srv_paramset, которая теперь считается устаревашай, т.к. не поддерживает новые типы данных введённые в ODS API и данные нулевой длины.

Код

int srv_paramsetoutput (
SRV_PROC * srvproc,
int n,
BYTE * pbData,
ULONG cbLen,
BOOL fNull
);

.
.
.
.
.
.
.
.
n - порядковый номер параметра, которому будет присвоено новое значение. Это должен быть OUTPUT параметр.
pbData указатель на буфер с данными, которые будут посланы клиенту для установки значения выходного параметра.
cbLen длина буфера посылаемых данных. Если тип данных переданного OUTPUT параметра определяет данные постоянной длины и не разрешает хранение значения NULL (например SRVBIT или SRVINT1), то функция игнорирует параметр cbLen. Значение cbLen=0 указывает на данные нулевой длины, при этом парметр fNull должен быть установлен в FALSE.
fNull установите этот его в TRUE, если возвращаемому параметру необходимо присвоить значение NULL, при этом значение cbLen должно быть равно 0, иначе функция завершится с ошибкой. Во всех остальных случаях fNull=FALSE.
В случае успешного завершения функция возвращает SUCCEED. Если возвращаемое значение равно FAIL, значит вызов был неудачным. Всё просто и понятно
Теперь мы достаточно знаем, для того чтобы написать свою первую расширенную хранимую процедуру, которая будет возвращать значение через переданный ей параметр.Пусть, по сложившейся традиции, это будет строка Hello world! Отладочну версию примера можно скачать здесь.

Код

#include <srv.h>

#define XP_NOERROR 0
#define XP_ERROR 1

#define MAX_SERVER_ERROR 20000
#define XP_HELLO_ERROR MAX_SERVER_ERROR+1

void printError (SRV_PROC*, CHAR*);

#ifdef __cplusplus
extern "C" {
#endif

SRVRETCODE __declspec(dllexport) xp_helloworld(SRV_PROC* pSrvProc);

#ifdef __cplusplus
}
#endif

SRVRETCODE xp_helloworld(SRV_PROC* pSrvProc)
{
char szText[13] = "Hello World!";
BYTE bType;
ULONG cbMaxLen;
ULONG cbActualLen;
BOOL fNull;

/* Определение количества переданных в расширенную хранимую
процедуру параметров */
if (srv_rpcparams(pSrvProc) != 1)
{
printError(pSrvProc, "Не верное количество параметров!");
return (XP_ERROR);
}

/* Получение информации о типе данных и длине переданых параметров */
if (srv_paraminfo(pSrvProc, 1, &bType, &cbMaxLen,
&cbActualLen, NULL, &fNull) == FAIL)
{
printError (pSrvProc,
"Не удаётся получить информацию о входных параметрах ...");
return (XP_ERROR);
}

/* Проверяем, является ли переданный параметр OUTPUT параметром */
if ((srv_paramstatus(pSrvProc, 1) & SRV_PARAMRETURN) == FAIL)
{
printError (pSrvProc,
"Переданный параметр не является OUTPUT параметром!");
return (XP_ERROR);
}

/* Проверяем тип данных переданного параметра */
if (bType != SRVBIGVARCHAR && bType != SRVBIGCHAR)
{
printError (pSrvProc, "Не верный тип переданного параметра!");
return (XP_ERROR);
}

/* Убедимся, что переданный параметр имеет достаточную длину для сохранения возвращаемой строки */
if (cbMaxLen < strlen(szText))
{
printError (pSrvProc,
"Передан параметр не достаточной длины для сохранения n возвращаемой строки!");
return (XP_ERROR);
}

/* Устаналиваем значение OUTPUT параметра */
if (FAIL == srv_paramsetoutput(pSrvProc, 1, (BYTE*)szText, 13, FALSE))
{
printError (pSrvProc,
"Не могу установить значение OUTPUT параметра...");
return (XP_ERROR);
}

srv_senddone(pSrvProc, (SRV_DONE_COUNT | SRV_DONE_MORE), 0, 1);
return (XP_NOERROR);
}

void printError (SRV_PROC *pSrvProc, CHAR* szErrorMsg)
{
srv_sendmsg(pSrvProc, SRV_MSG_ERROR, XP_HELLO_ERROR, SRV_INFO, 1,
NULL, 0, 0, szErrorMsg,SRV_NULLTERM);

srv_senddone(pSrvProc, (SRV_DONE_ERROR | SRV_DONE_MORE), 0, 0);
}

. Не рассмотренными остались функции srv_sendmsg и srv_senddone. Функция srv_sendmsg используется для посылки сообщений клиенту. Вот её прототип:

Код

int srv_sendmsg (
SRV_PROC * srvproc,
int msgtype,
DBINT msgnum,
DBTINYINT class,
DBTINYINT state,
DBCHAR * rpcname,
int rpcnamelen,
DBUSMALLINT linenum,
DBCHAR * message,
int msglen
);

msgtype определяет тип посылаемого клиенту сообщения. Константа SRV_MSG_INFO обозначает информационное сообщение, а SRV_MSG_ERROR сообщение об ошибке;
msgnum номер сообщения;
class - степень тяжести возникшей ошибки. Информационные сообщения имеют значение степени тяжести меньшее или равное 10;
state номер состояния ошибки для текущего сообщения. Этот параметр предоставляет информацию о контексте возникшей ошибки. Допустимые значения лежат в диапазоне от 0 до 127;
rpcname в настоящее время не используется;
rpcnamelen - в настоящее время не используется;
linenum здесь можно указать номер строки исходного кода. По этому значению, в последствие будет легко установить в каком месте возникла ошибка. Если Вы не хотите использовать эту возможность, тогда установите linenum в 0;
message указатель на строку посылаемую клиенту;
msglen определяет длину в байтах строки сообщения. Если это строка заканчивается нулевым символом, то значение этого параметра можно установить равным SRV_NULLTERM.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.

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

Код

int srv_senddone (
SRV_PROC * srvproc,
DBUSMALLINT status,
DBUSMALLINT info,
DBINT count
);

status - статус флаг. Значение этого параметра можно задавать использую логические операторы AND и OR для комбинирования констант приведённых в таблице:
Status flag Описание
SRV_DONE_FINAL Текущий набор результатов является окончательным;
SRV_DONE_MORE Текущий набор результатов не является окончательным следует ожидать очердную порцию данных;
SRV_DONE_COUNT Параметр count содержит верное значение
SRV_DONE_ERROR Используется для уведомления о возникновении ошибок и немедленном завершении.
into зарезервирован, необходимо установить в 0.
count количество результирующих наборов данных посылаемых клиенту. Если флаг status установлен в SRV_DONE_COUNT, то count должен содержать правильное количество посылаемый клиенту наборв записей.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.

Установка расширенных хранимых процедур на MS SQL Server 2000

1.Скопируйте dll библиотеку с расширенной хранимой процедурой в каталог binn на машине с установленным MS SQL Server. У меня этот путь следующий: C:Program FilesMicrosoft SQL ServerMSSQLBinn;
2.Зарегистрирйте расширенную хранимую процедуру на серверt выполнив следующий скрипт:

Код

USE Master
EXECUTE SP_ADDEXTENDEDPROC xp_helloworld, xp_helloworld.dll
Протестируйте работу xp_helloworld, выполнив такой скрипт:
Код:
DECLARE @Param varchar(33)
EXECUTE xp_helloworld @Param OUTPUT
SELECT @Param AS OUTPUT_Param

Заключение

На этом первая часть моей статьи закончена. Теперь я уверен Вы готовы справиться с нашим техническим заданием на все 100%. В следующей статье Вы узнаете:
- Типы данных определённые в ODS API;
- Особенности отладки расширенных хранимых процдур;
- Как формировать recordset-ы и передавать их клиентскому приложению;
- Чстично мы рассмотрим функции Active Directory Network Manegment API необходимые для получения списка доменных пользователей;
- Создадим готовый проект (реализуем наше техническое задание)
Надеюсь - до скорой встречи!

Развитие сети Internet обострило и в очередной раз выявило проблемы, возникающие при безопасном подключении к Internet корпоративной сети. Связано это в первую очередь с тем, что сеть Internet разрабатывалась как открытая, предназначенная для всех, система. Вопросам безопасности при проектировании стека протоколов TCP/IP, являющихся основой Internet, уделялось очень мало внимания.

---

Для устранения проблем, связанных с безопасностью было разработано много различных решений, самым известным и распространенным из которых является применение межсетевых экранов (firewall). Их использование - это первый шаг, который должна сделать любая организация, подключающая свою корпоративную сеть к Internet. Первый, но далеко не последний. Одним межсетевым экраном для построения надежного и защищенного соединения с Internet не обойтись. Необходимо реализовать целый ряд технических и организационных мер, чтобы обеспечить приемлемый уровень защищенности корпоративных ресурсов от несанкционированного доступа.

Межсетевые экраны реализуют механизмы контроля доступа из внешней сети к внутренней путем фильтрации всего входящего и исходящего трафика, пропуская только авторизованные данные. Все межсетевые экраны функционируют на основе информации, получаемой от различных уровней эталонной модели ISO/OSI, и чем выше уровень OSI, на основе которого построен межсетевой экран, тем выше уровень защиты, им обеспечиваемый. Существует три основных типа межсетевых экранов - пакетный фильтр (packet filtering), шлюз на сеансовом уровне (circuit-level gateway) и шлюз на прикладном уровне (application-level gateway). Очень немногие существующие межсетевые экраны могут быть однозначно отнесены к одному из названных типов. Как правило, МСЭ совмещает в себе функции двух или трех типов. Кроме того, недавно появилась новая технология построения межсетевых экранов, объединяющая в себе положительные свойства всех трех вышеназванных типов. Эта технология была названа Stateful Inspection. И в настоящий момент практически все предлагаемые на рынке межсетевые экраны анонсируются, как относящиеся к этой категории (Stateful Inspection Firewall).

На российском рынке средств защиты информации сейчас сложилась такая ситуация, что многие поставщики межсетевых экранов (МСЭ), предлагая свой продукт, утверждают, что он один решит все проблемы заказчика, обеспечив надежную защиту всех ресурсов корпоративной сети. Однако, это не так. И не потому что предлагаемый межсетевой экран не обеспечивает необходимых защитных механизмов (правильный выбор межсетевого экрана - это тема отдельной статьи), а потому что самой технологии присущи определенные недостатки.

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

Отсутствие защиты от авторизованных пользователей

Наиболее очевидный недостаток межсетевых экранов - невозможность защиты от пользователей, знающих идентификатор и пароль для доступа в защищаемый сегмент корпоративной сети. Межсетевой экран может ограничить доступ посторонних лиц к ресурсам, но он не может запретить авторизованному пользователю скопировать ценную информацию или изменить какие-либо параметры финансовых документов, к которым этот пользователь имеет доступ. А по статистике не менее 70% всех угроз безопасности исходит со стороны сотрудников организации. Поэтому, даже если межсетевой экран защитит от внешних нарушителей, то останутся нарушители внутренние, неподвластные МСЭ.

Для устранения этого недостатка нужны новые подходы и технологии. Например, использование систем обнаружения атак (intrusion detection systems). Данные средства, ярким примером которых является система RealSecure, обнаруживают и блокируют несанкционированную деятельность в сети независимо от того, кто ее реализует - авторизованный пользователь (в т.ч. и администратор) или злоумышленник. Такие средства могут работать как самостоятельно, так и совместно с межсетевым экраном. Например, система RealSecure обладает возможностью автоматической реконфигурации межсетевого экрана CheckPoint Firewall-1 путем изменения правил, запрещая тем самым доступ к ресурсам корпоративной сети с атакуемого узла.

Отсутствие защиты новых сетевых сервисов

Вторым недостатком межсетевых экранов можно назвать невозможность защиты новых сетевых сервисов. Как правило, МСЭ разграничивают доступ по широко распространенным протоколам, таким как HTTP, Telnet, SMTP, FTP и ряд других. Реализуется это при помощи при помощи механизма "посредников" (proxy), обеспечивающих контроль трафика, передаваемого по этим протоколам или при помощи указанных сервисов. И хотя число таких "посредников" достаточно велико (например, для МСЭ CyberGuard Firewall их реализовано более двухсот), они существуют не для всех новых протоколов и сервисов. И хотя эта проблема не столь остра (многие пользователи используют не более десятка протоколов и сервисов), иногда она создает определенные неудобства.

Многие производители межсетевых экранов пытаются решить указанную проблему, но удается это далеко не всем. Некоторые производители создают proxy для новых протоколов и сервисов, но всегда существует временной интервал от нескольких дней до нескольких месяцев между появлением протокола и соответствующего ему proxy. Другие разработчики межсетевых экранов предлагают средства для написания своих proxy (например, компания CyberGuard Corporation поставляет вместе со своим МСЭ подсистему ProxyWriter позволяющую создавать proxy для специфичных или новых протоколов и сервисов). В этом случае необходима высокая квалификация и время для написания эффективного proxy, учитывающего специфику нового сервиса и протокола. Аналогичная возможность существует и у межсетевого экрана CheckPoint Firewall-1, который включает в себя мощный язык INSPECT, позволяющий описывать различные правила фильтрации трафика.

Ограничение функциональности сетевых сервисов

Некоторые корпоративные сети используют топологию, которая трудно "уживается" с межсетевым экраном, или используют некоторые сервисы (например, NFS) таким образом, что применение МСЭ требует существенной перестройки всей сетевой инфраструктуры. В такой ситуации относительные затраты на приобретение и настройку межсетевого экрана могут быть сравнимы с ущербом, связанным с отсутствием МСЭ.

Решить данную проблему можно только путем правильного проектирования топологии сети на начальном этапе создания корпоративной информационной системы. Это позволит не только снизить последующие материальные затраты на приобретение средств защиты информации, но и эффективно встроить межсетевые экраны в существующую технологию обработки информации.

Если сеть уже спроектирована и функционирует, то, возможно, стоит подумать о применении вместо межсетевого экрана какого-либо другого решения, например, системы обнаружения атак.

Потенциальная опасность обхода межсетевого экрана

Межсетевые экраны не могут защитить ресурсы корпоративной сети в случае неконтролируемого использования в ней модемов. Доступ в сеть через модем по протоколам SLIP или PPP в обход межсетевого экрана делает сеть практически незащищенной. Достаточно распространена ситуация, когда сотрудники какой-либо организации, находясь дома, при помощи программ удаленного доступа типа pcAnywhere или по протоколу Telnet обращаются к данным или программам на своем рабочем компьютере или через него получают доступ в Internet. Говорить о безопасности в такой ситуации просто не приходится, даже в случае эффективной настройки межсетевого экрана.

Для решения этой задачи необходимо строго контролировать все имеющиеся в корпоративной сети модемы и программное обеспечение удаленного доступа. Для этих целей возможно применение как организационных, так и технических мер. Например, использование систем разграничения доступа, в т.ч. и к COM-портам (например, Secret Net) или систем анализа защищенности (например, Internet Scanner и System Scanner). Правильно разработанная политика безопасности обеспечит дополнительный уровень защиты корпоративной сети, установит ответственность за нарушение правил работы в Internet и т.п. Кроме того, должным образом сформированная политика безопасности позволит снизить вероятность несанкционированного использования модемов и иных устройств и программ для осуществления удаленного доступа.

Потенциально опасные возможности

Новые возможности, которые появились недавно, и которые облегчают жизнь пользователям Internet, разрабатывались практически без учета требований безопасности. Например, WWW, Java, ActiveX и другие сервисы, ориентированные на работу с данными. Они являются потенциально опасными, так как могут содержать в себе враждебные инструкции, нарушающие установленную политику безопасности. И если операции по протоколу HTTP могут достаточно эффективно контролироваться межсетевым экраном, то защиты от "мобильного" кода Java и ActiveX практически нет. Доступ такого кода в защищаемую сеть либо полностью разрешается, либо полностью запрещается. И, несмотря на заявления разработчиков межсетевых экранов о контроле апплетов Java, сценариев JavaScript и т.п., на самом деле враждебный код может попасть в защищаемую зону даже в случае полного их блокирования в настройках межсетевого экрана.

Защита от таких полезных, но потенциально опасных возможностей должна решаться в каждом конкретном случае по-своему. Можно проанализировать необходимость использования новой возможности и совсем отказаться от нее; а можно использовать специализированные защитные средства, например, систему SurfinShield компании Finjan или SafeGate компании Security-7 Software, обеспечивающие безопасность сети от враждебного "мобильного" кода.

Вирусы и атаки

Практически ни один межсетевой экран не имеет встроенных механизмов защиты от вирусов и, в общем случае, от атак. Как правило, эта возможность реализуется путем присоединения к МСЭ дополнительных модулей или программ третьих разработчиков (например, система антивирусной защиты ViruSafe для МСЭ CyberGuard Firewall или система обнаружения атак RealSecure для МСЭ CheckPoint Firewall-1). Использование нестандартных архиваторов или форматов передаваемых данных, а также шифрование трафика, сводит всю антивирусную защиту "на нет". Как можно защититься от вирусов или атак, если они проходят через межсетевой экран в зашифрованном виде и расшифровываются только на оконечных устройствах клиентов?

В таком случае лучше перестраховаться и запретить прохождение через межсетевой экран данных в неизвестном формате. Для контроля содержимого зашифрованных данных в настоящий момент ничего предложить нельзя. В этом случае остается надеяться, что защита от вирусов и атак осуществляется на оконечных устройствах. Например, при помощи системных агентов системы RealSecure.

Снижение производительности

Несмотря на то, что подсоединение к сетям общего пользования или выход из корпоративной сети осуществляется по низкоскоростным каналам (как правило, при помощи dialup-доступа на скорости до 56 Кбит или использование выделенных линий до 256 Кбит), встречаются варианты подключения по каналам с пропускной способностью в несколько сотен мегабит и выше (ATM, T1, E3 и т.п.). В таких случаях межсетевые экраны являются самым узким местом сети, снижая ее пропускную способность. В некоторых случаях приходится анализировать не только заголовок (как это делают пакетные фильтры), но и содержание каждого пакета ("proxy"), а это существенно снижает производительность межсетевого экрана. Для сетей с напряженным трафиком использование межсетевых экранов становится нецелесообразным.

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

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

Отсутствие контроля своей конфигурации

Даже если все описанные выше проблемы решены, остается опасность, что межсетевой экран неправильно сконфигурирован. Приходится сталкиваться с ситуацией, когда приобретается межсетевой экран, первоначальная конфигурация которого осуществляется специалистами поставщика и тем самым, как правило, обеспечивается высокий уровень защищенности корпоративных ресурсов. Однако, с течением времени, ситуация меняется, - сотрудники хотят получить доступ к новым ресурсам Internet, работать с новым сервисами (RealAudio, VDOLive и т.п.) и т.п. Таким образом, постепенно защита, реализуемая межсетевым экраном, становится дырявой как решето, и огромное число правил, добавленных администратором, сводятся к одному: "разрешено все и всем".

В этом случае помогут средства анализа защищенности. Средства анализа защищенности могут тестировать межсетевой экран как на сетевом уровне (например, подверженность атакам типа "отказ в обслуживании"), так и на уровне операционной системы (например, права доступа к конфигурационным файлам межсетевого экрана). Кроме того, при сканировании возможна реализация атак типа "подбор пароля", позволяющие обнаружить "слабые" пароли или пароли, установленные производителем по умолчанию. К средствам, проводящим такие проверки, можно отнести, например, систему Internet Scanner американской компании Internet Security Systems (ISS).

Заключение

Ознакомившись с описанными проблемами, многие могут сделать вывод, что межсетевые экраны не могут обеспечить защиту корпоративной сети от несанкционированного вмешательства. Это не так. Межсетевые экраны являются необходимым, но явно недостаточным средством обеспечения информационной безопасности. Они обеспечивают лишь первую линию обороны. Не стоит покупать межсетевой экран только потому, что он признан лучшим по результатам независимых испытаний. При выборе и приобретении межсетевых экранов необходимо тщательно все продумать и проанализировать. В некоторых случаях достаточно установить простейший пакетный фильтр, свободно распространяемый в сети Internet или поставляемый вместе с операционной системой, например squid. В других случаях межсетевой экран необходим, но применять его надо совместно с другими средствами обеспечения информационной безопасности.