ПОКС


2.Опорная модель OSI
В общем случае задача сетевого программного обеспечения состоит в приеме запроса (обычно это запрос ввода-вывода) от приложения на одной машине, передаче его на другую машину, выполнения запроса на удаленной машине и возврате результата на первую машину. В ходе этих операций запрос несколько раз преобразуется. Высокоуровневый запрос (например, “прочитать N байтов из файла Xна машине Y”) требует, чтобы программное обеспечение определило, как достичь машины Y и какой коммуникационный протокол она “понимает”. Затем запрос должен быть преобразован для передачи по сети – например, разбит на короткие пакеты информации. Когда запрос достигнет другой стороны, необходимо проверить его целостность, декодировать и послать на выполнение соответствующему компоненту ОС. По окончании выполнения запрос должен быть декодирован для обратной передачи по сети.
Для помощи производителям в стандартизации и интегрировании производимого сетевого ПО, Международная организация по стандартизации (ISO, International Standart Organization) в 1984 году определила программную модельпересылки сообщений между компьютерами. Эта модель получила название опорной модели соединения открытых систем – Open Systems Interconnection(OSI) referencemodel. В модели OSI определены семь уровней программного обеспечения.
Опорная модель OSI - идеальная схема, точно реализованная на очень немногих системах, однако она часто используется при обсуждении основных принципов работы сетей. Каждый уровень одной из машин “считает”, что он “разговаривает” на одном и том же языке (или протоколе) с соответствующем уровнем другой ЭВМ (т.н. виртуальные связи между уровнями). Однако в действительности сетевой запрос должен “спуститься” до самого нижнего (физического) уровня (на котором обе ЭВМ в реальности обмениваются данными), затем он передается по физическому носителю и вновь “поднимается” до уровня, который его “поймет” и обработает. Набор протоколов, в соответствие с которым запрос проходит вниз по уровням сети и обратно, называется стеком протоколов (protocol stack). Каждый уровень несет ответственность за выполнение ограниченного набора функций и может взаимодействовать только с двумя непосредственно прилежащими уровнями.
Задача каждого уровня состоит в предоставлении обслуживания верхним уровням, абстрагируясь от того, каким образомреализовано это обслуживание.
Краткое описание  уровней модели OSI.
•  Прикладной уровень. Обрабатывает передачу данных между двумя сетевыми приложениями (включая проверку прав доступа, идентификацию взаимодействующих машин и инициирование передачи данных). Большинство сетевых программ-утилит фактически являются частью именно этого уровня.
•  Уровень представления. Отвечает за формирование данных (в том числе решает, должны ли строки заканчиваться парой символов “возврат каретки/перевод строки” - CR/LF) или только символом “возврат каретки” - CR; должны ли данные быть сжаты или закодированы и др.
•  Сеансовый уровень. Управляет соединением между взаимодействующими приложениями (включая синхронизацию высокого уровня и контроль за тем, какое из приложений “говорит”, а какое “слушает”).
•  Транспортный уровень. Осуществляет разбивку сообщения на пакеты и присваивает номера пакетам, чтобы гарантировать их прием в надлежащем порядке. Кроме того, изолирует сеансовый уровень влияния аппаратных изменений.
•  Сетевой уровень. Отвечает за маршрутизацию, управление интенсивностью трафика и межсетевой обмен. Сеансовый уровень – наиболее высокий из   уровней,   ”понимающих” топологию   сети (т.е. физическую конфигурацию машин в последней), тип физических соединений между ними и ограничения пропускной способности, длины используемых кабелей и др.•  Канальный уровень. Пересылает низкоуровневые кадры данных, ожидает подтверждения их получения и повторяет передачу кадров, потерянных в ненадежных линиях связи.
•  Физический уровень. Передает (и принимает) биты по сетевому кабелю (или другой физической передающей среде).
Уровни 1 и 2 (физический и канальный) являются уровнями аппаратных средствууровни 3, 4, 5 образуют подсетевой уровень сети, который содержит программные средства, управляющие аппаратными средствами сети. Подсетевой уровень определяет один из двух важных интерфейсов “прикладная программа – сеть”. Некоторые прикладные программы (особенно использующие интенсивный обмен данными – например, коммуникационные шлюзы) присоединяются к сети на уровне 5 (сеансовом), большинство же прикладных программ присоединены к сети на уровне 6 (уровне представления). Наконец, ПО управления сетью образует уровень 7 (прикладной).
Как было сказано, уровни OSI часто неточно соответствуют реальным программным модулям (например, транспортное программное обеспечение часто “пересекает” границы нескольких уровней). Фактически термин “транспорт” часто используется в качестве общего обозначения всех четырех нижних уровней, а расположенные на трех верхних уровнях компоненты именуют “пользователями транспорта”.
3 основные протоколы применяемые в компьютерных сетях
Для обеспечения согласованной работы в сетях передачи данных используются различные коммуникационные протоколы передачи данных - наборы правил, которых должны придерживаться передающая и принимающая стороны для согласованного обмена данными. Протоколы - это наборы правил и процедур, регулирующих порядок осуществления некоторой связи. Протоколы - это правила и технические процедуры, позволяющие нескольким компьютерам при объединении в сеть общаться друг с другом.
Существует множество протоколов. И хотя все они участвуют в реализации связи, каждый протокол имеет различные цели, выполняет различные задачи, обладает своими преимуществами и ограничениями.
Протоколы работают на разных уровнях модели взаимодействия открытых систем OSI/ISO (рис.5). Функции протоколов определяются уровнем, на котором он работает. Несколько протоколов могут работать совместно. Это так называемый стек, или набор, протоколов.
Как сетевые функции распределены по всем уровням модели OSI, так и протоколы совместно работают на различных уровнях стека протоколов. Уровни в стеке протоколов соответствуют уровням модели OSI. В совокупности протоколы дают полную характеристику функций и возможностей стека.
Передача данных по сети, с технической точки зрения, должна состоять из последовательных шагов, каждому из которых соответствуют свои процедуры или протокол. Таким образом, сохраняется строгая очередность в выполнении определенных действий.
Кроме того, все эти действия должны быть выполнены в одной и той же последовательности на каждом сетевом компьютере. На компьютере-отправителе действия выполняются в направлении сверху вниз, а на компьютере-получателе снизу вверх.
Компьютер-отправитель в соответствии с протоколом выполняет следующие действия: Разбивает данные на небольшие блоки, называемыми пакетами, с которыми может работать протокол, добавляет к пакетам адресную информацию, чтобы компьютер-получатель мог определить, что эти данные предназначены именно ему, подготавливает данные к передаче через плату сетевого адаптера и далее - по сетевому кабелю.
Компьютер-получатель в соответствии с протоколом выполняет те же действия, но только в обратном порядке: принимает пакеты данных из сетевого кабеля; через плату сетевого адаптера передает данные в компьютер; удаляет из пакета всю служебную информацию, добавленную компьютером-отправителем, копирует данные из пакета в буфер - для их объединения в исходный блок, передает приложению этот блок данных в формате, который оно использует.И компьютеру-отправителю, и компьютеру-получателю необходимо выполнить каждое действие одинаковым способом, с тем чтобы пришедшие по сети данные совпадали с отправленными.
Если, например, два протокола будут по-разному разбивать данные на пакеты и добавлять информацию (о последовательности пакетов, синхронизации и для проверки ошибок), тогда компьютер, использующий один из этих протоколов, не сможет успешно связаться с компьютером, на котором работает другой протокол.
До середины 80-ых годов большинство локальных сетей были изолированными. Они обслуживали отдельные компании и редко объединялись в крупные системы. Однако, когда локальные сети достигли высокого уровня развития и объем передаваемой ими информации возрос, они стали компонентами больших сетей. Данные, передаваемые из одной локальной сети в другую по одному из возможных маршрутов, называются маршрутизированными. Протоколы, которые поддерживают передачу данных между сетями по нескольким маршрутам, называются маршрутизируемыми протоколами.
Среди множества протоколов наиболее распространены следующие:· NetBEUI;
· XNS;
· IPX/SPX и NWLmk;
· Набор протоколов OSI.
Более подробно каждый стек протоколов будет рассмотрен в следующей главе.[1]
2 Обзор программных средств
2.1 Аутентификация и авторизация. Система Kerberos
Kerberos - это сетевая служба, предназначенная для централизованного решения задач аутентификации и авторизации в крупных сетях. Она может работать в среде многих популярных операционных систем. В основе этой достаточно громоздкой системы лежит несколько простых принципов.
· В сетях, использующих систему безопасности Kerberos, все процедуры аутентификации между клиентами и серверами сети выполняются через посредника, которому доверяют обе стороны аутентификационного процесса, причем таким авторитетным арбитром является сама система Kerberos.
· В системе Kerberos клиент должен доказывать свою аутентичность для доступа к каждой службе, услуги которой он вызывает.
· Все обмены данными в сети выполняются в защищенном виде с использованием алгоритма шифрования.
Сетевая служба Kerberos построена по архитектуре клиент-сервер, что позволяет ей работать в самых сложных сетях. Kerberos-клиент устанавливается на всех компьютерах сети, которые могут обратится к какой-либо сетевой службе. В таких случаях Kerberos-клиент от лица пользователя передает запрос на Kerberos-сервер и поддерживает с ним диалог, необходимый для выполнения функций системы Kerberos.
Итак, в системе Kerberos имеются следующие участники: Kerberos-сервер, Kerberos-клиент и ресурсные серверы (рис. 6). Kerberos-клиенты пытаются получить доступ к сетевым ресурсам - файлам, приложением, принтеру и т.д. Этот доступ может быть предоставлен, во-первых, только легальным пользователям, а во-вторых, при наличии у пользователя достаточных полномочий, определяемых службами авторизации соответствующих ресурсных сервер - файловым сервером, сервером приложений, сервером печати. Однако в системе Kerberos ресурсным серверам запрещается «напрямую» принимать запросы от клиентов, им разрешается начинать рассмотрение запроса клиента только тогда, когда на это поступает разрешение от Kerberos-сервера. Таким образом, путь клиента к ресурсу в системе Kerberos состоит из трех этапов:
1. Определение легальности клиента, логический вход в сеть, получение разрешения на продолжение процесса получения доступа к ресурсу.
2. Получение разрешения на обращение к ресурсному серверу.
3. Получение разрешения на доступ к ресурсу.
Для решения первой и второй задачи клиент обращается к Kerberos-серверу. Каждая из этих задач решается отдельным сервером, входящим в состав Kerberos-сервера. Выполнение первичной аутентификации и выдача разрешения на продолжение процесса получения доступа к ресурсу осуществляется так называемым аутентификационным сервером (Authentication Server, AS). Этот сервер хранит в своей базе данных информацию об идентификаторах и паролях пользователей.
Вторую задачу, связанную с получением разрешения на обращение к ресурсному серверу, решает другая часть Kerberos-сервера - сервер квитанций (Ticket-Granting Server, TGS). Сервер квитанций для легальных клиентов выполняет дополнительную проверку и дает клиенту разрешение на доступ к нужному ему ресурсному серверу, для чего наделяет его электронной формой-квитанцией. Для выполнения своих функций сервер квитанций использует копии секретных ключей всех ресурсных серверов, которые хранятся у него в базе данных. Кроме этих ключей сервер TGS имеет еще один секретный DES-ключ, который разделяет с сервером AS.
Третья задача - получение разрешения на доступ непосредственно к ресурсу - решается на уровне ресурсного сервера.
Изучая довольно сложный механизм системы Kerberos, нельзя не задаться вопросом: какое влияние оказывают все эти многочисленные процедуры шифрования и обмена ключами на производительность сети, какую часть ресурсов сети они потребляют и как это сказывается на ее пропускной способности?
Ответ весьма оптимистичный - если система Kerberos реализована и сконфигурирована правильно, она незначительно уменьшает производительность сети. Так как квитанции используются многократно, сетевые ресурсы, затрачиваемые на запросы предоставления квитанций, невелики. Хотя передача квитанции при аутентификации логического входа несколько снижает пропускную способность, такой обмен должен осуществляться и при использовании любых других систем и методов аутентификации. Дополнительные же издержки незначительны. Опыт внедрения системы Kerberos показал, что время отклика при установленной системе Kerberos существенно не отличается от времени отклика без нее - даже в очень больших сетях с десятками тысяч узлов. Такая эффективность делает систему Kerberos весьма перспективной.
Среди уязвимых мест системы Kerberos можно назвать централизованное хранение всех секретных ключей системы. Успешная атака на Kerberos-сервер, в котором сосредоточена вся информация, критическая для системы безопасности, приводит к крушению информационной защиты всей сети. Альтернативным решением могла бы быть система, построенная на использовании алгоритмов шифрования с парными ключами, для которых характерно распределенное хранение секретных ключей.
Еще одной слабостью системы Kerberos является то, что исходные коды тех приложений, доступ к которым осуществляется через Kerberos, должны быть соответствующим образом модифицированы. Такая модификация называется «керберизацией» приложения. Некоторые поставщики продают «керберизированные» версии своих приложений. Но если нет такой версии и нет исходного текста, то Kerberos не может обеспечить доступ к такому приложению. [6]
2.2 Установка и настройка протоколов сети
Как говорилось выше, среди множества протоколов можно выделить наиболее распространенные.NetBEUI - расширенный интерфейс NetBIOS. Первоначально NetBEUI и NetBIOS были тесно связаны и рассматривались как один протокол, затем производители их обособили и сейчас они рассматриваются отдельно. NetBEUI - небольшой, быстрый и эффективный протокол транспортного уровня, который поставляется со всеми сетевыми продуктами фирмы Microsoft. К преимуществам NetBEUI относятся небольшой размер стека, высокая скорость передачи данных и совместимость со всеми сетями Microsoft. Основной недостаток - он не поддерживает маршрутизацию, это ограничение относится ко всем сетям Microsoft.
Xerox Network System (XNS) был разработан фирмой Xerox для своих сетей Ethernet. Его широкое применение началось с 80=ых годов, но постепенно он был вытеснен протоколом TCP/IP. XNS - большой и медленный протокол, к тому же он применяет значительное количество широковещательных сообщений, что увеличивает трафик сети.
Набор протоколов OSI - полный стек протоколов, где каждый протокол соответствует конкретному уровню модели OSI. Набор содержит маршрутизируемые и транспортные протоколы, серии протоколов IEEE Project 802, протокол сеансового уровня, представительского уровня и нескольких протоколов прикладного уровня. Они обеспечивают полнофункциональность сети, включая доступ к файлам, печать и т.д. [1]
Особенно следует остановиться на стеке протоколов IPX/SPX. Этот стек является оригинальным стеком протоколов фирмы Novell, который она разработала для своей сетевой операционной системы NetWare еще в начале 80-х годов. Протоколы Internetwork Packet Exchange (IPX) и Sequenced Packet Exchange (SPX), которые дали имя стеку, являются прямой адаптацией протоколов XNS фирмы Xerox, распространенных в гораздо меньше степени, чем IPX/SPX. По количеству установок протоколы IPX/SPX лидируют, и это обусловлено тем, что сама ОС NetWare занимает лидирующее положение с долей установок в мировом масштабе примерно в 65%.
Семейство протоколов фирмы Novell и их соответствие модели ISO/OSI представлено на рис. 7
На физическом и канальном уровнях в сетях Novell используются все популярные протоколы этих уровней (Ethernet, Token Ring, FDDI и другие).
На сетевом уровне в стеке Novell работает протокол IPX, а также протоколы обмена маршрутной информацией RIP и NLSP. IPX является протоколом, который занимается вопросами адресации и маршрутизации пакетов в сетях Novell. Маршрутные решения IPX основаны на адресных полях в заголовке его пакета, а также на информации, поступающей от протоколов обмена маршрутной информацией. Например, IPX использует информацию, поставляемую либо протоколом RIP, либо протоколом NLSP (NetWare Link State Protocol) для передачи пакетов компьютеру назначения или следующему маршрутизатору. Протокол IPX поддерживает только дейтаграммный способ обмена сообщениями, за счет чего экономно потребляет вычислительные ресурсы. Итак, протокол IPX обеспечивает выполнение трех функций: задание адреса, установление маршрута и рассылку дейтаграмм.
Транспортному уровню модели OSI в стеке Novell соответствует протокол SPX, который осуществляет передачу сообщений с установлением соединений.
На верхних прикладном, представительном и сеансовом уровнях работают протоколы NCP и SAP. Протокол NCP (NetWare Core Protocol) является протоколом взаимодействия сервера NetWare и оболочки рабочей станции. Этот протокол прикладного уровня реализует архитектуру клиент-сервер на верхних уровнях модели OSI. С помощью функций этого протокола рабочая станция производит подключение к серверу, отображает каталоги сервера на локальные буквы дисководов, просматривает файловую систему сервера, копирует удаленные файлы, изменяет их атрибуты и т.п., а также осуществляет разделение сетевого принтера между рабочими станциями.
SAP (Service Advertising Protocol) - протокол объявления о сервисе - концептуально подобен протоколу RIP. Подобно тому, как протокол RIP позволяет маршрутизаторам обмениваться маршрутной информацией, протокол SAP дает возможность сетевым устройствам обмениваться информацией об имеющихся сетевых сервисах.
Серверы и маршрутизаторы используют SAP для объявления о своих сервисных услугах и сетевых адресах. Протокол SAP позволяет сетевым устройствам постоянно корректировать данные о том, какие сервисные услуги имеются сейчас в сети. При старте серверы используют SAP для оповещения оставшейся части сети о своих услугах. Когда сервер завершает работу, то он использует SAP для того, чтобы известить сеть о прекращении действия своих услуг.
В сетях Novell серверы NetWare 3.x каждую минуту рассылают широковещательные пакеты SAP. Пакеты SAP в значительной степени засоряют сеть, поэтому одной из основных задач маршрутизаторов, выходящих на глобальные связи, является фильтрация трафика SAP-пакетов и RIP-пакетов.
Особенности стека IPX/SPX обусловлены особенностями ОС NetWare, а именно ориентацией ее ранних версий на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами. Поэтому Novell нужны были протоколы, на реализацию которых требовалось минимальное количество оперативной памяти и которые бы быстро работали на процессорах небольшой вычислительной мощности. В результате, протоколы стека IPX/SPX до недавнего времени хорошо работали в локальных сетях и не очень - в больших корпоративных сетях, так как слишком перегружали медленные глобальные связи широковещательными пакетами, которые интенсивно используются несколькими протоколами этого стека (например, для установления связи между клиентами и серверами).
Это обстоятельство, а также тот факт, что стек IPX/SPX является собственностью фирмы Novell и на его реализацию нужно получать у нее лицензию, долгое время ограничивали распространенность его только сетями NetWare. Однако к моменту выпуска версии NetWare 4.0, Novell внесла и продолжает вносить в свои протоколы серьезные изменения, направленные на приспособление их для работы в корпоративных сетях. Сейчас стек IPX/SPX реализован не только в NetWare, но и в нескольких других популярных сетевых ОС - SCO UNIX, Sun Solaris, Microsoft Windows NT. [8]
4 классификация архитектур информационных приложений
В первой части курса мы кратко рассмотрели основные требования, которым должна удовлетворять информационная система, и задачи, которые должны решаться такой системой. При этом мы постоянно подчеркивали, что строгость соблюдения требований и фиксированность набора решаемых задач во многом являются условными в зависимости от конкретных целей, для достижения которых разрабатывается прикладная информационная система. Соответственно, проектирование и разработка информационной системы может базироваться на разных архитектурных решениях.
В этой части курса приводится классификация возможных архитектур информационных систем. Мы начинаем с традиционных архитектурных решений, основанных на использовании выделенных файл-серверов или серверов баз данных. Затем рассматриваются варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "склада данных" (DataWarehouse) - интегрированной информационной среды, включающей разнородные информационные ресурсы. Наконец, последняя выделяемая нами архитектура предназначена для построения глобальных распределенных информационных приложений с интеграцией информационно-вычислительных компонентов на основе объектно-ориентированного подхода.
Замечание по поводу терминологии. С терминологией в области информационных систем вообще, а русскоязычной терминологией в особенности дела обстоят неважно. Область информационных систем очень быстро развивается. Практически каждый год возникают новые технологии и архитектурные решения, для которых в маркетинговых целях придумываются оригинальные, привлекающие внимание названия, далеко не всегда точно отражающие смысл технологии и/или архитектуры. На самом деле, все подходы к организации информационных систем, рассматриваемые в этом курсе базируются на общей архитектуре "клиент-сервер". Различие состоит только в том, что делают клиенты и серверы. Тем не менее, чтобы не запутать читателя, далее мы вынуждены применять русскоязычные эквиваленты соответствующих англоязычных терминов.
Следует заметить, что как и любая классификация, наша классификация архитектур информационных систем не является абсолютно жесткой. В архитектуре любой конкретной информационной системы часто можно найти влияния нескольких общих архитектурных решений. Тем не менее, при архитектурном проектировании системы кажется полезным иметь хотя бы частично ортогонализированный архитектурный базис. В следующих частях курса мы подробно рассмотрим особенности каждой архитектуры и остановимся на методологиях и инструментально-технологических средствах, поддерживающих проектирование и разработку информационных систем в соответствующей архитектуре. 2.1. Файл-серверные приложения
По всей видимости, организация информационных систем на основе использования выделенных файл-серверов все еще является наиболее распространенной в связи с наличием большого количества персональных компьютеров разного уровня развитости и сравнительной дешевизны связывания PC в локальные сети. Чем привлекает такая организация не очень опытных в области системного программирования разработчиков информационных систем? Скорее всего, тем, что при опоре на файл-серверные архитектуры сохраняется автономность прикладного (и большей части системного) программного обеспечения, работающего на каждой PC сети. Фактически, компоненты информационной системы, выполняемые на разных PC, взаимодействуют только за счет наличия общего хранилища файлов, которое хранится на файл-сервере. В классическом случае в каждой PC дублируются не только прикладные программы, но и средства управления базами данных. Файл-сервер представляет собой разделяемое всеми PC комплекса расширение дисковой памяти (рисунок 2.1).
Не останавливаясь подробно на имеющихся на сегодняшнем рынке перспективных инструментальных средствах разработки файл-серверных приложений и не приводя анализа тенденций развития соответствующих технологий (этому посвящается третья часть курса), мы кратко перечислим основные достоинства и недостатки файл-серверных архитектур.
Конечно, основным достоинством является простота организации. Проектировщики и разработчики информационной системы находятся в привычных и комфортных условиях IBM PC в среде MS-DOS, Windows или какого-либо облегченного варианта Windows NT. Имеются удобные и развитые средства разработки графического пользовательского интерфейса, простые в использовании средства разработки систем баз данных и/или СУБД. Но во многом эта простота является кажущейся. (Как гласит русская пословица, "Простота хуже воровства", а здесь мы, как правило, имеем простоту на основе воровства программных продуктов для PC.)

Рис. 2.1. Классическое представление информационной системы в архитектуре "файл-сервер"
Во-первых, информационной системе предстоит работать с базой данных. Следовательно, эта база данных должна быть спроектирована. Почему-то часто разработчики файл-серверных приложений считают, что по причине простоты средств управления базами данных проблемой проектирования базы данных можно пренебречь. Конечно, это неправильно. База данных есть база данных. Чем качественнее она спроектирована, тем больше шансов впоследствии эффективно использовать информационную систему. Естественно, сложность проектирования базы данных определяется объективной сложностью моделируемой предметной области. Но, собственно, из чего должно следовать, что файл-серверные приложения пригодны только в простых предметных областях?
Во-вторых, как мы неоднократно подчеркивали в первой части курса, необходимыми требованиями к базе данных информационной системы являются поддержание ее целостного состояния и гарантированная надежность хранения информации. Минимальными условиями, при соблюдении которых можно удовлетворить эти требования, являются:
наличие транзакционного управления,
хранение избыточных данных (например, с применением методов журнализации),
возможность формулировать ограничения целостности и проверять их соблюдение.
В принципе, файл-серверная организация, как она показана на рисунке 2.1, не противоречит соблюдению отмеченных условий. В качестве примера системы, соблюдающей выполнение этих условий, но основанной на файл-серверной архитектуре, можно привести популярный в прошлом "сервер баз данных" Informix SE.
Длинноезамечание:Для сохранения четкости дальнейшего изложения нам необходимо несколько уточнить терминологию. Мы недаром написали "сервер баз данных" в кавычках применительно к СУБД Informix SE. При использовании этой системы копия программного обеспечения СУБД поддерживалась для каждого инициированного пользователем сеанса работы с СУБД. Грубо говоря, для каждого пользовательского процесса, взаимодействующего с базой данных создавался служебный процесс СУБД, который выполнялся на том же процессоре, что и пользовательский процесс (т.е. на стороне клиента). Каждый из этих служебных процессов вел себя фактически так, как если бы был единственным представителем СУБД. Вся синхронизация возможной параллельной работы с базой данных производилась на уровне файлов внешней памяти, содержащих базу данных. Условимся впредь называть такие СУБД не серверами баз данных, а системами управления базами данных, основанными на файл-серверной архитектуре (СУБД-ФС).
Под истинным сервером баз данных мы будем понимать программное образование, привязанное к соответствующей базе (базам) данных, существующее, вообще говоря, независимо от существования пользовательских (клиентских) процессов и выполняемое, вообще говоря (хотя и не обязательно) на выделенной аппаратуре (мы намеренно используем не очень конкретные термины "программное образование" и "выделенная аппаратура", потому что их конкретное воплощение различается в разных серверах баз данных). Истинные серверы баз данных существенно сложнее по организации, чем СУБД-ФС, на зато обеспечивают более тонкое и эффективное управление базами данных. Везде далее в этом курсе при употреблении термина "сервер баз данных" мы будем иметь в виду истинные серверы баз данных.
Но с другой стороны, в большинстве персональных СУБД эти условия не выполняются даже с помощью грубых приемов. В лучшем случае удается частично восполнить недостатки на уровне прикладных программ.
В третьих, интерфейс развитых серверов баз данных основан на использовании высокоуровневого языка баз данных SQL, что позволяет использовать сетевой трафик между клиентом и сервером баз данных только в полезных целях (от клиента к серверу в основном пересылаются операторы языка SQL, от сервера к клиенту - результаты выполнения операторов). В файл-серверной организации клиент работает с удаленными файлами, что вызывает существенную перегрузку трафика (поскольку СУБД-ФС работает на стороне клиента, то для выборки полезных данных в общем случае необходимо просмотреть на стороне клиента весь соответствующий файл целиком).
В целом, в файл-серверной архитектуре мы имеем "толстого" клиента и очень "тонкий" сервер в том смысле, что почти вся работа выполняется на стороне клиента, а от сервера требуется только достаточная емкость дисковой памяти (рисунок 2.2).

Рис. 2.2. "Толстый" клиент и "тонкий" сервер в файл-серверной архитектуре
Краткие выводы. Простое, работающее с небольшими объемами информации и рассчитанное на применение в однопользовательском режиме, файл-серверное приложение можно спроектировать, разработать и отладить очень быстро. Очень часто для небольшой компании для ведения, например, кадрового учета достаточно иметь изолированную систему, работающую на отдельно стоящем PC. Конечно, и в этом случае требуется большая аккуратность конечных пользователей (или администраторов, наличие которых в этом случае сомнительно) для надежного хранения и поддержания целостного состояния данных. Однако, в уже ненамного более сложных случаях (например, при организации информационной системы поддержки проекта, выполняемого группой) файл-серверные архитектуры становятся недостаточными. 2.2. Клиент-серверные приложения
Под клиент-серверным приложением мы будем понимать информационную систему, основанную на использовании серверов баз данных (см. длинное замечание в конце раздела 2.1). Общее представление информационной системы в архитектуре "клиент-сервер" показано на рисунке 2.3.
На стороне клиента выполняется код приложения, в который обязательно входят компоненты, поддерживающие интерфейс с конечным пользователем, производящие отчеты, выполняющие другие специфичные для приложения функции (пока нас не будет занимать, как строится код приложения).
Клиентская часть приложения взаимодействует с клиентской частью программного обеспечения управления базами данных, которая, фактически, является индивидуальным представителем СУБД для приложения.
(Здесь опять проявляются недостатки в терминологии. Обычно, когда компания объявляет о выпуске очередного сервера баз данных, то неявно понимается, что имеется и клиентская составляющая этого продукта. Сочетание "клиентская часть сервера баз данных" кажется несколько странным, но нам придется пользоваться именно этим термином.)
Рис. 2.3. Общее представление информационной системы в архитектуре "клиент-сервер"
Заметим, что интерфейс между клиентской частью приложения и клиентской частью сервера баз данных, как правило, основан на использовании языка SQL. Поэтому такие функции, как, например, предварительная обработка форм, предназначенных для запросов к базе данных, или формирование результирующих отчетов выполняются в коде приложения.
Наконец, клиентская часть сервера баз данных, используя средства сетевого доступа, обращается к серверу баз данных, передавая ему текст оператора языка SQL.
Здесь необходимо сделать еще два замечания.
Обычно компании, производящие развитые серверы баз данных, стремятся к тому, чтобы обеспечить возможность использования своих продуктов не только в стандартных на сегодняшний день TCP/IP-ориентированных сетях, но в сетях, основанных на других протоколах (например, SNA или IPX/SPX). Поэтому при организации сетевых взаимодействий между клиентской и серверной частями СУБД часто используются не стандартные средства высокого уровня (например, механизмы программных гнезд или вызовов удаленных процедур), а собственные функционально подобные средства, менее зависящие от особенностей сетевых транспортных протоколов. Когда мы говорим об интерфейсе на основе языка SQL, нужно отдавать себе отчет в том, что несмотря на титанические усилия по стандартизации этого языка, нет такой реализации, в которой стандартные средства языка не были бы расширены. Необдуманное использование расширений языка приводит к полной зависимости приложения от конкретного производителя сервера баз данных.
Мы остановимся на этих вопросах более подробно в четвертой части курса.
Посмотрим теперь, что же происходит на стороне сервера баз данных. В продуктах практически всех компаний сервер получает от клиента текст оператора на языке SQL.
Сервер производит компиляцию полученного оператора. Не будем здесь останавливаться на том, какой целевой язык используется конкретным компилятором; в разных реализациях применяются различные подходы (примеры см. в части 4). Главное, что в любом случае на основе информации, содержащейся в таблицах-каталогах базы данных производится преобразование непроцедурного представления оператора в некоторую процедуру его выполнения.
Далее (если компиляция завершилась успешно) происходит выполнение оператора. Мы снова не будем обсуждать технические детали, поскольку они различаются в реализациях. Рассмотрим возможные действия операторов SQL.
Оператор может относиться к классу операторов определения (или создания) объектов базы данных (точнее и правильнее было бы говорить про элементы схемы базы данных или про объекты метабазы данных). В частности, могут определяться домены, таблицы, ограничения целостности, триггеры, привилегии пользователей, хранимые процедуры. В любом случае, при выполнении оператора создания элемента схемы базы данных соответствующая информация помещается в таблицы-каталоги базы данных (в таблицы метабазы данных). Ограничения целостности обычно сохраняются в метабазе данных прямо в текстовом представлении. Для действий, определенных в триггерах, и хранимых процедур вырабатывается и сохраняется в таблицах-каталогах процедурный выполняемый код. Заметим, что ограничения целостности, триггеры и хранимые процедуры являются, в некотором смысле, представителями приложения в поддерживаемой сервером базе данных; они составляют основу серверной части приложения (см. ниже).
При выполнении операторов выборки данных на основе содержимого затрагиваемых запросом таблиц и, возможно, с использованием поддерживаемых в базе данных индексов формируется результирующий набор данных (мы намеренно не используем здесь термин "результирующая таблица", поскольку в зависимости от конкретного вида оператора результат может быть упорядоченным, а таблицы, т.е. отношения неупорядочены по определению). Серверная часть СУБД пересылает результат клиентской части, и окончательная обработка производится уже в клиентской части приложения.
При выполнении операторов модификации содержимого базы данных (INSERT, UPDATE, DELETE) проверяется, что не будут нарушены определенные к этому моменту ограничения целостности (те, которые относятся к классу немедленно проверяемых), после чего выполняется соответствующее действие (сопровождаемое модификацией всех соответствующих индексов и журнализацией изменений). Далее сервер проверяет, не затрагивает ли данное изменение условие срабатывания какого-либо триггера, и если такой триггер обнаруживается, выполняет процедуру его действия. Эта процедура может включать дополнительные операторы модификации базы данных, которые могут вызвать срабатывание других триггеров и т.д. Можно считать, что те действия, которые выполняются на сервере баз данных при проверке удовлетворенности ограничений целостности и при срабатывании триггеров, представляют собой действия серверной части приложения.
При выполнении операторов модификации схемы базы данных (добавления или удаления столбцов существующих таблиц, изменения типа данных существующего столбца существующей таблицы и т.д.) также могут срабатывать триггеры, т.е., другими словами, может выполняться серверная часть приложения.
Аналогично, триггеры могут срабатывать при уничтожении объектов схемы базы данных (доменов, таблиц, ограничений целостности и т.д.).
Особый класс операторов языка SQL составляют операторы вызова ранее определенных и сохраненных в базе данных хранимых процедур. Если хранимая процедура определяется с помощью достаточно развитого языка, включающего и непроцедурные операторы SQL, и чисто процедурные конструкции (например, языка PL/SQL компании Oracle), то в такую процедуру можно поместить серьезную часть приложения, которое при выполнении оператора вызова процедуры будет выполняться на стороне сервера, а не на стороне клиента.
При выполнении оператора завершения транзакции сервер должен проверить соблюдение всех, так называемых, отложенных ограничений целостности (к таким ограничениям относятся ограничения, накладываемые на содержимое таблицы базы целиком или на несколько таблиц одновременно; например, суммарная зарплата сотрудников отдела 999 не должна превышать 150 млн. руб.). Снова к проверке отложенных ограничений целостности можно относиться как к выполнению серверной части приложения.
Как видно, в клиент-серверной организации клиенты могут являться достаточно "тонкими", а сервер должен быть "толстым" настолько, чтобы быть в состоянии удовлетворить потребности всех клиентов (рисунок 2.4).

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

Рис. 2.5. "Потолстевший" клиент и "толстый" сервер в клиент-серверной архитектуре с поддержкой локального кэша на стороне клиентов
Сформулируем некоторые предварительные выводы. Архитектура "клиент-сервер" на первый взгляд кажется гораздо более дорогой, чем архитектура "файл-сервер". Требуется более мощная аппаратура (по крайней мере, для сервера) и существенно более развитые средства управления базами данных. Однако, это верно лишь частично. Громадным преимуществом клиент-серверной архитектуры является ее масштабируемость и вообще способность к развитию.
При проектировании информационной системы, основанной на этой архитектуре, большее внимание следует обращать на грамотность общих решений. Технические средства пилотной версии могут быть минимальными (например, в качестве аппаратной основы сервера баз данных может использоваться одна из рабочих станций). После создания пилотной версии нужно провести дополнительную исследовательскую работу, чтобы выяснить узкие места системы. Только после этого необходимо принимать решение о выборе аппаратуры сервера, которая будет использоваться на практике.
Увеличение масштабов информационной системы не порождает принципиальных проблем. Обычным решением является замена аппаратуры сервера (и, может быть, аппаратуры рабочих станций, если требуется переход к локальному кэшированию баз данных). В любом случае практически не затрагивается прикладная часть информационной системы. В идеале, которого, конечно же не бывает, информационная система продолжает нормально функционировать после смены аппаратуры. 2.3. Intranet-приложения
Возникновение и внедрение в широкую практику высокоуровневых служб Всемирной Сети Сетей Internet (e-mail, ftp, telnet, Gopher, WWW и т.д.) естественным образом повлияли на технологию создания корпоративных информационных систем, породив направление, известное теперь под названием Intranet. По сути дела, информационная Intranet-система - это корпоративная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. В последнем случае особенно важны средства защиты информации от несанкционированного доступа. Возможности и проблемы безопасных информационных Intranet-систем мы рассмотрим в пятой части курса.
Хотя в общем случае в Intranet-системе могут использоваться все возможные службы Internet, наибольшее внимание привлекает гипермедийная служба WWW (World Wide Web - Всемирная Паутина). Видимо, для этого имеются две основные причины. Во-первых, с использованием языка гипермедийной разметки документов HTML можно сравнительно просто разработать удобную для использования информационную структуру, которая в дальнейшем будет обслуживаться одним из готовых Web-серверов. Во-вторых, наличие нескольких готовых к использованию клиентских частей - браузеров, или "обходчиков" избавляет от необходимости создавать собственные интерфейсы с пользователями, предоставляя им удобные и развитые механизмы доступа к информации. В ряде случаев такая организация корпоративной информационной системы (рисунок 2.6) оказывается достаточной для удовлетворения потребностей компании.

Рис. 2.6. Простая организация Intranet-системы с использованием средств WWW
Однако, при всех своих преимуществах (простота организации, удобство использования, стандартность интерфейсов и т.д.) эта схема обладает сильными ограничениями. Прежде всего, как видно из рисунка 2.6, в информационной системе отсутствует прикладная обработка данных. Все, что может пользователь, это только просмотреть информацию, поддерживаемую Web-сервером. Далее, гипертекстовые структуры трудно модифицируются. Для того, чтобы изменить наполнение Web-сервера, необходимо приостановить работу системы, внести изменения в HTML-описания и только затем продолжить нормальное функционирование. Наконец, далеко не всегда достаточен поиск информации в стиле просмотра гипертекста. Базы данных и соответствующие средства выборки данных по-прежнему часто необходимы.
На самом деле, все перечисленные трудности могут быть разрешены с использованием более развитых механизмов Web-технологии. Эти механизмы непрерывно совершенствуются, что одновременно и хорошо и плохо. Хорошо, потому что появляются новые возможности. Плохо, потому что отсутствует стандартизация.
Что касается логики приложения, то при применении Web-технологии существует возможность ее реализации на стороне Web-сервера. Для этого могут использоваться два подхода - CGI (Common Gateway Interface) и API (Application Programming Interface). Оба подхода основываются на наличии в языке HTML специальных конструкций, информирующих клиента-браузера, что ему следует послать Web-серверу специальное сообщение, при получении которого сервер должен вызвать соответствующую внешнюю процедуру, получить ее результаты и вернуть их клиенту в стандартном формате HTTP (рисунок 2.7).

Рис. 2.7. Вызов внешней процедуры Web-сервера
Более подробно различия между подходами CGI и API мы рассмотрим в пятой части курса, а пока лишь заметим, что подход CGI является более надежным (внешняя программа выполняется в отдельном адресном пространстве), но менее эффективным, чем подход API (в этом случае внешние процедуры компонуются совместно со стандартной частью Web-сервера).
Аналогичная техника широко используется для обеспечения унифицированного доступа к базам данных в Intranet-системах. Язык HTML позволяет вставлять в гипертекстовые документы формы. Когда браузер натыкается на форму, он предлагает пользователю заполнить ее, а затем посылает серверу сообщение, содержащее введенные параметры. Как правило, к форме приписывается некоторая внешняя процедура сервера. При получении сообщения от клиента сервер вызывает эту внешнюю процедуру с передачей параметров пользователя. Понятно, что такая внешняя процедура может, в частности, играть роль шлюза между Web-сервером и сервером баз данных. В этом случае параметры должны специфицировать запрос пользователя к базе данных. В результате получается конфигурация информационной системы, схематически изображенная на рисунке 2.8.

Рис. 2.8. Доступ к базе данных в Intranet-системе
Конечно, мы привели только грубую схему организации доступа к базам данных. Более детальное обсуждение содержится в пятой части курса.
На принципах использования внешних процедур основывается также возможность модификации документов, поддерживаемых Web-сервером, а также создание временных "виртуальных" HTML-страниц.
Даже начальное введение в Intranet было бы неполным, если не упомянуть про возможности языка Java. Java - это интерпретируемый объектно-ориентированный язык программирования, созданный на основе языка Си++ с удалением из него таких "опасных" средств как адресная арифметика. Мобильные коды (апплеты), полученные в результате компиляции Java-программы, могут быть привязаны в HTML-документу. В этом случае они поступают на сторону клиента вместе с документом и выполняются либо автоматически, либо по явному указанию. Апплет может быть, в частности, специализирован как шлюз к серверу баз данных (или к какому-либо другому серверу). При применении подобной техники доступа к базам данных схема организации Intranet-системы становится такой как на рисунке 2.9.

Рис. 2.9. Доступ к базе данных на стороне клиента Intranet-системы
На наш взгляд, Intranet является удобным и мощным средством разработки и использования информационных систем. Как мы уже отмечали, единственным относительным недостатком подхода можно считать постоянное изменение механизмов и естественное отсутствие стандартов. С другой стороны, если информационная система будет создана с использованием текущего уровня технологии и окажется удовлетворяющей потребностям корпорации, то никто не будет обязан что-либо менять в системе по причине появления более совершенных механизмов. 2.4. Склады данных (DataWarehousing) и системы оперативной аналитической обработки данных
До сих пор мы рассматривали способы и возможные архитектуры информационных систем, предназначенных для оперативной обработки данных, т.е. для получения текущей информации, позволяющей решать повседневные проблемы корпорации. Однако у аналитических отделов корпорации и у высшего звена управляющего состава имеются и другие задачи: проанализировав поведение корпорации на рынке с учетом сопутствующих внешних факторов и спрогнозировав хотя бы ближайшее будущее, выработать тактику, а возможно, и стратегию корпорации. Понятно, что для решения таких задач требуются данные и прикладные программы, отличные от тех, которые используются в оперативных информационных системах. В последние несколько лет все более популярным становится подход, основанный на концепциях склада данных и системы оперативной аналитической обработки данных. Возможно, в российских условиях трудно производить долговременные прогнозы бизнес-деятельности (слишком изменчивы внешние факторы), но анализ прошлого и краткосрочные прогнозы будущего могут оказаться очень полезными.
Прежде чем перейти к обсуждению технических аспектов, коротко обсудим проблемы терминологии. Поскольку термины, связанные со складами данных не так давно появились и на английском языке, и смысл их постоянно уточняется, трудно найти правильные русскоязычные эквиваленты. На сегодняшний день "datawarehouse" разными авторами переводится на русский язык как "хранилище данных", "информационное хранилище", "склад данных". Поскольку термин "хранилище" явно перегружен (он соответствует и английским терминам "storage" и "repository"), в этом курсе мы будем использовать термин "склад данных". Еще хуже дела обстоят с термином "data mart". В четвертом номере журнала "СУБД" за 1996 г. в напечатанных подряд двух статьях авторы переводят этот термин как "витрина данных" и "секция данных" соответственно. Однако в Оксфордском толковом словаре единственным подходящем по смыслу толкованием смысла слова "mart" является "market place". Чтобы не умножать число требуемых сущностей мы будем использовать термин "рынок данных" (обсуждение этого понятия отложим до пятой части курса). Конечно, постепенно терминология будет согласована, но это произойдет только тогда, когда склады данных будут активно использоваться в России.
В этом разделе мы не будем рассматривать возможные технологические приемы реализации складов данных, а обсудим соответствующие вопросы на концептуальном уровне. Начнем с того, что главным образом различает оперативные и аналитические информационные приложения с точки зрения обеспечения требуемых данных. Замечание: речь идет о так называемых OLAP-системах (от On-Line Analitical Processing), т.е. аналитических системах, помогающих принимать бизнес-решения за счет динамически производимых анализа, моделирования и/или прогнозирования данных.
Основным источником информации, поступающей в оперативную базу данных является деятельность корпорации. Для проведения анализа данных требуется привлечение внешних источников информации (например, статистических отчетов). Тем самым, склад данных должен включать как внутренние корпоративные данные, так и внешние данные, характеризующие рынок в целом.
Если для оперативной обработки, как правило, требуются свежие данные (обычно в оперативных базах данных информация сохраняется не более нескольких месяцев), то в складе данных нужно поддерживать хранение информации о деятельности корпорации и состоянии рынка на протяжении нескольких лет (для проведения достоверных анализа и прогнозирования). Как следствие, аналитические базы данных имеют объем как минимум на порядок больший, чем оперативные.
Во многих достаточно крупных корпорациях одновременно существуют несколько оперативных информационных систем с собственными базами данных (как мы уже отмечали в этом курсе, это не очень хорошо, но часто неизбежно по историческим причинам). Оперативные базы данных могут содержать семантически эквивалентную информацию, представленную в разных форматах, с разным указанием времени ее поступления, иногда даже противоречивую (например, из-за ошибок ввода данных). Склад данных корпорации должен содержать единообразно представленные данные из всех оперативных баз данных. Эта информация должна максимально полно соответствовать текущему содержанию оперативных баз данных и быть согласованной. Отсюда следует необходимость наличия компонента склада данных, извлекающего информацию из оперативных баз данных и "очищающего" эту информацию.
Оперативные информационные системы проектируются и разрабатываются в расчете на решение конкретных задач. Обычно набор запросов к оперативной базе данных становится известным уже на этапе проектирования системы. Информация из базы данных выбирается часто и небольшими порциями. Поэтому при проектировании оперативной базы данных можно и нужно учитывать этот заранее известный набор запросов (с известными оговорками в связи с возможными переделками информационной системы). Набор запросов к аналитической базе данных предсказать невозможно. Склады данных для того и существуют, чтобы отвечать на неожиданные (ad hoc) запросы аналитиков. Можно рассчитывать только на то, что запросы будут поступать не слишком часто и затрагивать большие объемы информации. Размеры аналитической базы данных стимулируют использование запросов с агрегатами (сумма, минимальное, максимальное, среднее значение и т.д.).
Оперативные базы данных по своей природе являются сильно изменчивыми. Это учитывается в используемых СУБД. В частности, распространенным механизмом индексации являются B-деревья, модификация которых выполняется достаточно быстро, а строки в таблицах хранятся неупорядоченно. Аналитические базы данных меняются только тогда, когда в них загружается оперативная или внешняя информация. В результате оказывается разумным использовать другие, более быстрые при выполнении операций массовой выборки методы индексации, поддерживать упорядоченность информационных массивов, сохранять заранее вычисленные значения агрегатных функций и т.д.
Если для оперативных информационных систем обычно хватает защиты информации на уровне таблиц (по правилам SQL-ориентированных баз данных), то информация аналитических баз данных настолько критична для корпорации, что для ее защиты требуются более тонкие приемы (например, при использовании реляционных баз данных установка индивидуальных привилегий доступа для индивидуальных строк и/или столбцов таблицы). С учетом приведенных замечаний общая архитектура склада данных и системы аналитической обработки данных может выглядеть так, как показано на рисунке 2.10.

Рис. 2.10. Схематическое представление архитектуры аналитической информационной системы
В 1993 г. основоположник реляционного подхода к организации баз данных Эдвар Кодд, исходя из потребностей систем динамической аналитической обработки данных, сформулировал 12 основных требований к системам, поддерживающим аналитические базы данных. Мы приведем изложение этих требований, чтобы представить точку зрения проектировщика и разработчика системы аналитической обработки данных.
Многомерное концептуальное представление данных. Это требование возникает по той причине, что бизнес-пользователь естественно представляет историю и деятельность своей корпорации многомерными (например, одно измерение - время, другое - заказчики, третье - производимая продукция и т.д.). OLAP-модели должны поддерживать это представление и, естественно, оно должно хотя бы в какой-то мере опираться на возможности аналитической базы данных.
Прозрачность. Для бизнес-пользователя не должно быть существенно, где конкретно расположены средства динамического анализа данных. При разработке OLAP-систем следует придерживаться подхода открытых систем, что позволит размещать средства анализа в любом узле корпоративной сети.
Доступность. Логическая схема, с которой работает OLAP-система, должна отображаться в схемы разнородных физических хранилищ данных. При доступе к данным должно поддерживаться их единое и согласованное представление.
Согласованная эффективность производства отчетов. Эта эффективность не должна деградировать при увеличении числа измерений.
Архитектура "клиент-сервер". Серверный компонент OLAP-системы должен быть достаточно развитым, чтобы разнообразные клиенты могли подключаться к нему с минимальными усилиями и затратами на дополнительное "интегрирующее" программирование.
Родовая многомерность. Структурные и операционные возможности работы с каждым измерением данных должны быть эквивалентны. Для всех измерений должна существовать только одна логическая структура. Любая функция, применимая к одному измерению, должна быть применима к любому другому измерению.
Управление динамическими разреженными матрицами. Сервер OLAP-системы должен уметь эффективно хранить и обрабатывать разреженные матрицы. Физические методы доступа должны быть разнообразны, включая прямое вычисление, B-деревья, хэширование или комбинации этих методов.
Поддержка многопользовательского режима. OLAP-система должна поддерживать многопользовательский доступ к данным (по выборке и изменению), обеспечивая целостность и безопасность данных.
Неограниченные операции между измерениями. При выполнении многомерного анализа данных все измерения создаются и обрабатываются единообразно. OLAP-система должна быть в состоянии выполнять соответствующие вычисления между измерениями.
Интуитивное манипулирование данными. Манипуляции, подобные смене пути анализа или уровня детализации, должны выполняться с помощью прямого воздействия на элементы OLAP-модели без потребности использовать меню или другие вспомогательные средства.
Гибкая система отчетов. Бизнес-пользователь должен иметь возможность манипулировать данными, анализировать и/или синтезировать, а также просматривать их таким образом, как ему захочется.
Неограниченное число измерений и уровней агрегации. OLAP-сервер должен поддерживать не менее 15 измерений для каждой аналитической модели. Для каждого измерения должно допускаться неограниченное число определяемых пользователями агрегатов.
Основным выводом из материала этого раздела является то, что подход складов данных еще слишком молод, чтобы вокруг него сложился круг общепринятых понятий, терминов, технологических приемов. Тем не менее, он кажется настолько важным и перспективным, что многие компании (в том числе и ведущие производители СУБД) ведут активную работу, чтобы быть в авангарде этого направления. Существующие идеи и реализации мы рассмотрим в пятой части курса. 2.5. Интегрированные распределенные приложения
Нет никаких проблем, если с самого начала информационное приложение проектируется и разрабатывается в духе подхода открытых систем: все компоненты являются мобильными и интероперабельными, общее функционирование системы не зависит от конкретного местоположения компонентов, система обладает хорошими возможностями сопровождаемости и развития. К сожалению, на практике этот идеал является трудно достижимым. По разным причинам (мы перечислим некоторые из них ниже) возникают потребности в интеграции независимо и по-разному организованных информационно-вычислительных ресурсов. Видимо, ни в одной действительно серьезной распределенной информационной системе не удастся обойтись без применения некоторой технологии интеграции. К счастью, теперь существует путь решения этой проблемы, который сам лежит в русле открытых систем, - подход, предложенный крупнейшим международным консорциумом OMG (Object Management Group).
Остановимся на некоторых факторах, стимулирующих использование методов интеграции разнородных информационных ресурсов (здесь используются материалы статьи Л.А.Калиниченко и др. из журнала "СУБД" N 4, 1995 г.).
Неоднородность, распределенность и автономность информационных ресурсов системы. Неоднородность ресурсов может быть синтаксической (при их представлении используются, например, разные модели данных) и/или семантической (используются разные виды семантических правил, детализируются и/или агрегируются разные аспекты предметной области). Возможна и чисто реализационная неоднородность информационных ресурсов, обусловленная использованием разных компьютерных платформ, операционных систем, систем управления базами данных, систем программирования и т.д.
Потребности в интеграционном комплексировании компонентов информационной системы. Очевидно, что наиболее естественным способом организации сложной информационной системы является ее иерархически-вложенное построение. Более сложные функционально-ориентированные компоненты строятся на основе более простых компонентов, которые могли проектироваться и разрабатываться независимо (что порождает неоднородность; ниже мы приведем примеры).
Реинжинерия системы. После создания начального варианта информационной системы неизбежно последует процесс ее непрерывных переделок (реинжинерии), обусловленный развитием и изменением соответствующих бизнес-процессов корпорации. Реконструкция системы не должна быть революционной. Все компоненты, не затрагиваемые процессом реинжиниринга, должны сохранять работоспособность.
Решение проблемы унаследованных (legacy) систем. Любая компьютерная система (надеюсь, что это не относится к открытым системам в теперешнем понимании; только надеюсь, поскольку неизвестно, как отнесутся к нашим взглядам будущие поколения) со временем становится бременем корпорации. Постоянно (и чем раньше, тем лучше) приходится решать задачу встраивания устаревших информационных компонентов в систему, основанную на новой технологии. Нужно, чтобы эта задача была разрешимой, т.е. чтобы компоненты унаследованных систем сохраняли интероперабельность.
Повторно используемые (reusable) ресурсы. Технология разработки информационных систем должна способствовать использованию уже существующих компонентов, что в конечном итоге должно перевести нас от экстенсивного ручного программистского труда к интенсивным методам сборки ориентированной на конкретную область применения информационной системы.
Продление жизненного цикла информационной системы. Чем дольше живет и приносит пользу информационная система, тем это выгоднее для корпорации. Естественно, что для этого должна существовать возможность добавления в нее компонентов, спроектированных и разработанных, вообще говоря, в другой технологии.
Решение проблемы интеграции неоднородных информационных ресурсов началось с попыток интеграции неоднородных баз данных. Направление интегрированных или федеративных систем неоднородных БД и мульти-БД появилось в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД.
Основной задачей интеграции неоднородных БД является предоставление пользователям интегрированной системы глобальной схемы БД, представленной в некоторой модели данных, и автоматическое преобразование операторов манипулирования БД глобального уровня операторы, понятные соответствующим локальным СУБД. В теоретическом плане проблемы преобразования решены, имеются реализации.
При строгой интеграции неоднородных БД локальные системы БД утрачивают свою автономность. После включения локальной БД в федеративную систему все дальнейшие действия с ней, включая администрирование, должны вестись на глобальном уровне. Поскольку пользователи часто не соглашаются утрачивать локальную автономность, желая тем не менее иметь возможность работать со всеми локальными СУБД на одном языке и формулировать запросы с одновременным указанием разных локальных БД, развивается направление мульти-БД. В системах мульти-БД не поддерживается глобальная схема интегрированной БД и применяются специальные способы именования для доступа к объектам локальных БД. Как правило, в таких системах на глобальном уровне допускается только выборка данных. Это позволяет сохранить автономность локальных БД.
Как правило, интегрировать приходится неоднородные БД, распределенные в вычислительной сети. Это в значительной степени усложняет реализацию. Дополнительно к собственным проблемам интеграции приходится решать все проблемы, присущие распределенным СУБД: управление глобальными транзакциями, сетевую оптимизацию запросов и т.д. Очень трудно добиться эффективности. Как правило, для внешнего представления интегрированных и мульти-БД используется (иногда расширенная) реляционная модель данных. В последнее время все чаще предлагается использовать объектно-ориентированные модели, но на практике пока основой является реляционная модель. Поэтому, в частности, включение в интегрированную систему локальной реляционной СУБД существенно проще и эффективнее, чем включение СУБД, основанной на другой модели данных. Основным недостатком систем интеграции неоднородных баз данных является то, что при этом не учитываются "поведенческие" аспекты компонентов прикладной системы. Легко заметить, что даже при наличии развитой интеграционной системы, большинство из указанных выше проблем не решается. Естественным развитием взглядов на информационные ресурсы является их представление в виде набора типизированных объектов, сочетающих возможности сохранения информации (своего состояния) и обработки этой информации (за счет наличия хорошо определенного множества методов, применимых к объекту). Наиболее существенный вклад в создание соответствующей технологии внес международный консорциум OMG, выпустивший ряд документов, в которых специфицируются архитектура и инструментальные средства поддержки распределенных информационных систем, интегрированных на основе общего объектно-ориентированного подхода.
В базовом документе специфицируется эталонная модель архитектуры (OMA - Object Management Architecture) распределенной информационной системы (рисунок 2.11).

Рис. 2.11. Эталонная модель OMA
Согласованная с архитектурой OMA прикладная информационная система представляется как совокупность классов и экземпляров объектов, которые взаимодействуют при поддержке брокера объектных заявок (ORB - Object Request Broker). ORB, общие средства (Common Facilities) и объектные службы (Object Services) относятся к категории промежуточного программного обеспечения (middleware) и должны поставляться вместе. Объектные службы представляют собой набор услуг (интерфейсов и объектов), которые обеспечивают выполнение базовых функций, требуемых для реализации прикладных объектов и объектов категории "общие средства" (например, специфицированы служба именования объектов, служба долговременного хранения объектов, служба управления транзакциями и т.д.). Общие средства содержат набор классов и экземпляров объектов, поддерживающих функции, полезные в разных прикладных областях (например, средства поддержки пользовательского интерфейса, средства управления информацией и т.д.).
В основе OMA лежит базовая объектная модель COM (Core Object Model), в которой специфицированы такие понятия, как объект, операция, тип, подтипизация, наследование, интерфейс. Определены также способы согласованного расширения COM в разных объектных службах.
Интерфейсы объекта-клиента и объекта-сервера должны быть определены на специальном языке IDL (Interface Definition Language), который очень напоминает компонент спецификации класса (без реализации) языка Си++. Обращения к ORB могут быть сгенерированы статически при компиляции спецификаций IDL или выполнены динамически с использованием специфицированного в документах OMG API брокера объектных заявок. Правила построения и использования ORB определены в документе OMG CORBA (Common Object Request Broker Architecture).
В седьмой части курса мы рассмотрим более подробно все понятия, введенные в этом разделе.
Основным выводом из материала данного раздела является то, что проблемы интеграции неоднородных информационных ресурсов являются актуальными для корпораций и существуют технологии, позволяющие решать эти проблемы.
В заключение второй части курса повторим, что приведенная классификация методов и технологий не является ортогональной. В реальной жизни требуется использовать разумные сочетания технологических и архитектурных решений. Цель курса не состоит в том, чтобы выдать готовые рецепты построения информационной системы. Мы стремимся погрузить слушателей в мир информационных технологий с тем, чтобы впоследствии было проще ориентироваться в этом мире и понимать значение его сущностей.
5 файл-серверные приложения
Как мы уже отмечали, по поводу файл-серверных приложений имеется значительная путаница в терминологии. В этом курсе мы будем называть файл-серверной информационной системой систему, которая в основном базируется на персональных компьютерах, используя в качестве внешней поддержки один или несколько файловых серверов, обеспечивающих значительные возможности управления внешней памятью, но не обладающих "интеллектом", поддерживая в основном только управление файлами. Практически во всех файл-серверных средствах и методологиях имеется тенденция к переходу к технологии "клиент-сервер". Выражая только свое личное мнение, заметим, что файл-серверные архитектуры являются в большой степени облегченными вариантами клиент-серверных архитектур "для бедных", хотя во многих случаях предлагаемые решения являются достаточными для небольшого по объему класса информационных систем. 3.1. Традиционные средства и методологии разработки файл-серверных приложений
Пожалуй, стоит отметить, что хотя для разработки файл-серверных приложений имеется целый ряд инструментальных средств, отсутствуют общепринятые методологии. Вернее сказать, что когда методологии используются, то они те же, что в к клиент-серверных приложениях. Обычно же файл-серверные приложения проектируются и разрабатываются "по месту" без использования каких-либо стандартных методов. 3.1.1. Системы программирования и библиотеки
Системы программирования третьего поколения 3GL являются предшественниками современных инструментальных средств и могут использоваться для разработки информационных приложений при наличии соответствующих встроенных или библиотечных средств для реализации диалога и доступа к базам данных.
Системы программирования для персональных компьютеров прошли долгий путь развития. Можно выделить три четкие языковые линии, которые оказывали друг на друга большое влияние, взаимно обогащаясь - это Си, Паскаль и Бейсик.
Отметим основные вехи на пути развития систем программирования:
Переход от одиночных утилит систем программирования к интегрированным диалоговым средам программирования (например, семейство Turbo-продуктов фирмы Borland);
Развитие инструментальных наборов, расширяющих возможности систем программирования, в частности, в области диалога (разного рода Tool Box);
Появление объектно-ориентированных диалектов языков Си и Паскаль; заметим, что по нашему мнению, несмотря на то, что Паскаль является более строгим и корректным языком, феномен Си++ имеет большее значение в силу наличия стандарта;
Возникновение операционной среды Windows со встроенной поддержкой диалога и первых Windows-приложений с помощью SDK (Software Development Keet);
Создание объектно-ориентированных библиотек, поддерживающих диалоговый режим работы в среде DOS и Windows (TurboVision, Object Windows и MFC);
Появление систем программирования, облегчающих создание приложений для DOS и Windows;
Развитие механизма встраивания и связывания объектов OLE 2;
Переход к визуальным системам программирования (Visual Си++, Delphi, Visual Basic), которые ориентированы на разработку информационных приложений.
Поддержка диалогового режима развивалась совместно с развитием самих систем программирования и была естественным образом интегрирована с ними. Библиотеки же доступа к базам данных развивались своим путем. Наибольшее число библиотек доступа из языков программирования уровня 3GL к реляционным СУБД на персональных компьютерах поддерживает семейство xBase (Clipper, FoxPro, dBase). Из языков программирования чаще всего используется Си. Также можно отметить наличие таких библиотек, как CodeBase и DBTools (фирма Rogue Wave).
В библиотеке CodeBase используются те же форматы данных, индексов и memo-файлов, что и в СУБД dBase IV. Имеется возможность поддержки индексных файлов Clipper и memo-файлов dBase III Plus. Имеющиеся в библиотеке CodeBase функции могут не только выполнять все стандартные операции СУБД семейства xBase, но и позволяют устанавливать фильтры, задавать отношения, вычислять допустимые в СУБД выражения. Библиотечные функции поддерживают многопользовательские режимы работы в локальной сети и в среде многозадачной ОС, обеспечивая блокировку как на уровне файлов, так и записей. В комплект поставки входят тексты функций, что позволяет адаптировать их для конкретного использования.
Библиотека DBTools является многоплатформенной библиотекой для языков Си/Си++ и рассчитана на поддержку семейства СУБД xBase, Informix, Oracle и др. 3.1.2. Средства и методы разработки приложений на основе СУБД на персональных компьютерах
Приложения, созданные с использованием инструментальных средств программирования приложений, связанных с использованием баз данных на персональных компьютерах, занимают существенную долю файл-серверных приложений. Если рассматривать только "реляционные" (вернее, табличные) СУБД, то семейство xBase-продуктов является явным лидером по использованию для разработки одиночных и групповых информационных приложений. Следующее место занимает СУБД Paradox, а далее идут приложения, базирующиеся на использовании системы управления записями Clarion. Особняком стоят такие пакеты, как MS Access и Lotus Approach, которые позволили взглянуть по-новому на возможности персональных СУБД и до сих пор не оценены по-настоящему как профессиональные средства разработки приложений. Можно отметить следующие вехи на пути развития инструментальных средств и самих СУБД на персональных компьютерах:
Появление компонентов Assistant и Application Generator в dBase III Plus, упрощающих работу пользователя и позволяющих генерировать простейшие приложения или макеты приложений;
Выход в свет dBase-совместимых систем программирования (dBFast и Clipper), создающих исполняемый модуль приложения; разработка быстрого интерпретатора FoxBase для частично откомпилированного кода dBase-совместимых приложений;
Возникновение системы Paradox с оригинальным макроязыком PAL, существенно ориентированной на конечного пользователя;
Развитие многопользовательских версий СУБД для локальных сетей персональных компьютеров, дополненных средствами синхронизации на основе блокировок файлов и записей;
Появление системы dBase IV, включающую диалоговую среду Control Center, индексы, встроенные в файл БД, поддержку языка SQL и средства защиты БД;
Развитие Clipper с объектной ориентацией;
Обеспечение доступа из файл-серверных приложений к серверам БД (Borland SQL Link и Microsoft Connectivity Kit);
Внедрение технологии Rushmore, ускоряющей доступ к данным при помощи использования индексов;
Появление в FoxPro развитой среды разработки, ориентированной на разработку проектов и близкой по возможностям к средствам 4GL;
Дальнейшее расширение средств диалога (Foundation Read) в направление событийной управляемости;
Первые версии инструментальных средств, поддерживающие Windows-приложения, а вместе с ними типы данных Blob (Binary Large Objects);
Появление универсальных интерфейсов к различным СУБД (Borland IDAPI и Microsoft ODBC);
Первый продукт MS Access, направленный сугубо на создание Windows-приложений и содержащий средства объектно-ориентированного диалога, событийно-управляемого программирования, визуального конструирования интерфейса пользователя и многие другие черты, присущие системам программирования 4GL и RAD;
Появление новых визуальных объектно-ориентированных инструментальных средств и СУБД на ПК (MS Access 2.0, Visual FoxPro, CA-VisualObjects и Visual dBase).
3.2. Новые средства разработки файл-серверных приложений
Чем дальше, тем больше файл-серверные приложения сближаются с более развитыми технологиями клиент-серверных приложений. В последнее время появилась целая серия программных продуктов, позиционируемая одновременно как средства "легкой" разработки приложений для персональных компьютеров, так и более "тяжеловесной" разработки приложений в технологии "клиент-сервер". Это и хорошо, поскольку позволяет плавно изменять технологию. 3.2.1. Общая характеристика современных средств
В индустрии СУБД для персональных компьютеров отразились тенденции нормализации систем (Rightsizing). В последнее время в этой области происходили два встречных процесса: (1) разукрупнение серверов БД - появление новых версий серверов БД Informix, Oracle и т.д. сначала в варианте для рабочих групп, а потом облегченные версии для одиночных персональных компьютеров; (2) укрупнение СУБД для персональных компьютеров - новые "персональные" СУБД и связанные с ними инструментальные средства развивались в сторону "истинно реляционных" СУБД, т.е. серверов БД, приложений клиент-сервер и инструментальных средств программирования 4GL и быстрой разработки RAD.
Новые СУБД для персональных компьютеров и соответствующие инструментальные средства разработки файл-серверных приложений обладают перечисленными ниже общими чертами.
Визуальный характер программирования приложений особенно в части создания диалогового графического интерфейса пользователя. Это множество поддерживаемых диалоговых объектов, поддержка механизма drag-and-drop и наличие мастеров, помогающих реализовать сложные процедуры.
Управляемость приложений в соответствии с событиями диалога и обеспечение доступа к БД позволяет строить гибкий интерфейс пользователя и поддерживать ссылочную целостность БД.
Встроенная поддержка языка структурированных запросов SQL (Standard Query Language) закладывает возможность масштабирования создаваемых файл-серверных приложений до уровня приложений клиент-сервер.
Имеется возможность построения приложений клиент-сервер за счет реализации доступа к серверам БД напрямую или через интерфейс ODBC для открытого взаимодействия с базами данных.
Использование объектно-ориентированного языка разработки приложений (по крайней мере в части диалога) позволяет широко использовать механизм наследования и тем самым использовать ранее произведенные программные компоненты.
Поддержка компонентно-ориентированного программирования дает возможность расширения приложений за счет использования готовых внешних визуальных объектов типа VBX и OCX (ActiveX).
"Истинно реляционная" база данных представляет собой объединенный набор файлов, содержащий таблицы, индексы и т.п., что облегчает сопровождение БД и приложений и является основой для поддержки целостности данных.
Поддерживается общий для информационной системы словарь данных (data dictionary), который содержит описание структуры БД, типы полей, правила поддержки ограничений целостности и т.п.
Поддержка целостности БД (данных, ссылок и транзакций) позволяет создавать приложения с необходимым уровнем надежности и сохранности данных.
Возможности серверных процедур обработки (триггеров и хранимых процедур) закладывают основу для масштабирования приложений, позволяют гибко распределять прикладную логику между клиентом и сервером при переходе к архитектуре клиент-сервер.
Хранение в БД описания проекта создаваемого приложения является прообразом репозитория инструментальных средств быстрой разработки RAD и CASE-систем.
Рассмотрим подробнее несколько примеров сравнительно новых инструментальных средств: MS Access 2.0, Visual FoxPro и CA-VisualObjects. 3.2.2. Примеры новых подходов
3.2.2.1. Пакет MS Access
Microsoft Access - первая СУБД для персональных компьютеров, созданная для работы в среде Windows и несущая в себе многие черты новых инструментальных средств для разработки файл-серверных приложений. Эта система ориентирована как на конечных пользователей, так и на профессиональных программистов, облегчая и тем, и другим разработку и доступ к БД, быстрое создание информационных приложений с графическим интерфейсом. Система может работать в следующих версиях операционных систем: Windows 3.1, Windows 95 и Windows NT. Пакет Microsoft Access 2.0 полностью поддерживает кириллицу, в частности, сортировку данных в соответствии с русским алфавитом. Microsoft Access является составной частью семейства программ Microsoft Office. Все семейство основано на IntelliSense - интеллектуальной технологии, которая "чувствует", что нужно пользователю, и дает требуемый результат, автоматически выполняя рутинные операции и упрощая сложные задачи. Например, наличие десятков мастеров (Wizards), помогает автоматизировать массу операций от создания форм до написания программ. От пользователя требуется ответить лишь на несколько простых вопросов. Ниже приводится перечень некоторых необходимых мастеров:
мастер Table Wizards;
мастер Command Button Wizards;
мастер Form Wizards;
мастер Report Wizards;
мастер Mail Merge Wizards.
Мастер Table Wizards создает структуры базы данных и таблиц таким образом, что пользователи могут сразу же получать результаты.
Мастер Command Button Wizards создает функциональные кнопки, что избавляет пользователя от потребностей в программировании.
Мастера Form Wizards и Report Wizards используются при создании сложных форм и отчетов. Для создания более простых форм и отчетов можно использовать такие функции как Автоформа (AutoForm) и Автоотчет (AutoReport).
Мастер Mail Merge Wizard работает совместно с Microsoft Word, облегчая подготовку почтовых рассылок - необходимо только выделить данные для слияния или документ, который необходимо отослать.
MS Word можно также использовать для непосредственной работы с данными в Microsoft Access. В Microsoft Access имеются службы Графического конструктора связей (Graphical System Relationships Builder) и Графического запроса (Graphical query). Эти средства позволяют не только создать базу данных, но и наглядно сконструировать ее, что приближает Microsoft Access к CASE-средствам. Графический конструктор связей позволяет интуитивно конструировать базу данных, используя мышь для организации связи между таблицами, а функция Графического запроса упрощает создание даже очень сложных запросов - все что нужно, это мышью соединить поля, которые нужно включить в запрос. В Microsoft Access существуют функции и технологии, увеличивающие скорость и упрощающие использование конечных средств. К ним относятся:
технология Rushmore;
быстрая сортировка (QuickSort);
средство наиболее часто выполняемых запросов (Top Value queries).
Технология Rashmore ускоряет выполнение запросов в 100 раз по сравнению с версией 1.0 Microsoft Access. Быстрая сортировка мгновенно сортирует данные пользователя. Средство поддержки наиболее часто выполняемых запросов позволяет быстро выбрать наиболее важные для пользователя данные (например, 10 основных заказчиков, 15 основных адресатов и т.д.).
В Microsoft Access имеется ряд средств для совместного использования информации с другими приложениями. OfficeLinks с применением технологии OLE 2.0 позволяет передавать информацию из одной программы в другую. С помощью кнопок Analyze It и Publish It пользователь может перенести данные в Excel или Word для анализа, включения в отчет или слияния с другими данными для отправки почты. Наличие кнопки Mail It облегчает обмен информацией с другими членами рабочей группы - пользователь может послать информацию через Microsoft Mail или другую программу электронной почты.
Microsoft Access может работать с большинством форматов файлов (напрямую или через импорт/экспорт) - это позволяет пользователю максимально использовать имеющиеся наработки, поскольку Microsoft Access обеспечивает полную поддержку Btriеve, dBASE III PLUS и dBASE IV, Microsoft FoxPro 2.x, Paradox, Miсrosoft SQL Server, SYBASE SQL Server. Кроме того, возможно использование драйверов ODBC для доступа к другим базам данных.
Microsoft Access представляет мощный инструментарий для разработчика. Универсальная среда разработчика со встроенным отладчиком обеспечивает возможности программирования на уровне Microsoft Visual Basic. Управление событиями позволяет настраивать приложение в процессе исполнения, облегчая создание надежных приложений. Каскадные обновления и удаления помогают поддерживать целостность данных. Проверка правильности ввода на уровне процессора данных сохраняет целостность данных приложения - если разработчик создает правило ввода данных, пользователи могут его обойти.
Конструктор Меню (Menu Builder) предоставляет графический инструментарий для создания меню без программирования. Скорость разработки в Microsoft Access можно повысить с помощью двух отдельно поставляемых пакетов: Microsoft Access Solutions Pack и Microsoft Access Developer's Toolkit. Microsoft Access Solutions Pack содержит четыре готовых универсальных приложения для информационного обеспечения бизнеса:
Sales Manager - облегчает хранение, отслеживание и нахождение информации о контактах с заказчиками и деловых возможностях;
Asset Tracker - помогает при учете и управлении активами;
Registration Desk - упрощает рутинную, но необходимую работу по регистрации событий;
Service Desk - повышает качество услуг, помогая обрабатывать заявки на обслуживание, от регистрации до завершения обработки и проверки.
Microsoft Access Developer's Toolkit содержит инструменты, необходимые для создания приложений для Microsoft Access, такие как компилятор справок, исполняемая версия Microsoft Access, Microsoft Graph, Setup Wizard, документацию и пример программ создания объектов, обеспечивающих доступ к данным, мастеров и кнопок управления OLE 2.0, справочник по Microsoft Access (Microsoft Access Language Reference) и Руководство для опытного пользователя (Advanced Topics). 3.2.2.2. Система Visual FoxPro
В Visual FoxPro присутствуют многие новые черты: объектно-ориентированный язык, активный словарь, встроенные средства обращения к серверам баз данных и т.д.
Начнем со средств построения интерфейса и новых терминов, которые приходится осваивать разработчикам. Visual FoxPro уже не стоит особняком от остальных продуктов Microsoft, как это было в версиях 2.х. Интерфейс самого продукта и приложений, которые разрабатываются на его основе, соответствуют стандартам, принятым в комплексе программных продуктов Microsoft Office и в средствах разработки, подобных Visual Basic. Более того, Visual FoxPro полностью интегрируется с остальными приложениями Microsoft Office с помощью OLE Automation. Программа, написанная на Visual FoxPro, сможет полноценно общаться с Microsoft Word, Microsoft Excel и любыми другими приложениями, поддерживающими OLE 2.0. Как и прежде, поддерживается динамический обмен данными DDE.
Использование механизма наследования классов позволяет создавать произвольное число модифицированных форм; при корректировке исходного класса все изменения будут отражены в формах, построенных на его основе. В качестве объекта может выступать любой элемент формы, и это дает неограниченные возможности по модификации форм из программы. Возможность сохранить часто употребляемую форму как класс и строить на ее основе другие формы снимает проблему с параметризацией для приведения интерфейса в соответствие с новыми требованиями. В составе формы-класса может быть любой стандартный элемент интерфейса (кнопки, поля вывода, независимые и зависимые переключатели); в определении класса можно использовать и так называемые "OLE custom controls - OCX", что позволяют делать только самые развитые средства программирования в стиле С++. Для начинающих предусмотрены уже знакомые с версии 2.6 "Мастера", которые облегчат построение формы, отчета, таблицы и запроса.
Инструментальные средства не поддерживают browse и Foundation Read. Вместо Browse - объект с названием Grid, которым можно управлять как любым другим объектом формы. Причем управлять можно не только как единым монолитом, а с точностью до ячейки. То есть можно сделать все ячейки, где значение баланса меньше нуля, красными, а остальные - зелеными; можно встроить в ячейку элемент check box, если это поле содержит логические величины. Такого рода формы можно создавать как в Конструкторе форм, так и программным путем. Если используется Конструктор форм, то простое "перемещение" таблицы из окружения формы в область формы автоматически создает этот элемент интерфейса. Теперь окружение формы или отчета создается визуально и полностью контролируемо.
Вместо Foundation Read используется команда Read Events, переводящая Visual FoxPro в состояние ожидания, из которого его выводит только какое-либо действие пользователя. Список событий, на которые Visual FoxPro может реагировать, достаточно велик. При этом программа ведет себя, как "настоящее Windows-приложение": обработка событий встроена в сам продукт. Совместимость со старыми версиями поддерживается полностью, и весь старый процедурный код по-прежнему будет работать; однако Visual FoxPro - это новые подходы, новые технологии и новые требования, поэтому разработчику нужно освоить такие понятия, как инкапсуляция, полиморфизм, триггеры, хранимые процедуры, события, методы, наследование.
Для хранения описаний проектов, отчетов, баз данных и т.п. практически везде используются .DBF-файлы. Многие утилиты написаны на самом Visual FoxPro.
В смысле управления базами данных фирма Microsoft продвинула пакет Visual FoxPro очень далеко. У Visual FoxPro наконец появилось настоящее понимание базы данных как совокупности таблиц, индексов и всякого рода дополнительной информации, описывающей правила, которым должны подчиняться данные при вводе или модификации.
Несмотря на то, что по-прежнему можно использовать самостоятельные .DBF-файлы, при "привязывании" таблицы к единому файлу базы данных имеются следующие преимущества: длинные имена таблиц и полей (до 254 символов), вспомогательные имена и комментарии для каждого поля; значения по умолчанию для каждого поля; правила ввода как на уровне поля, так и на уровне записи; триггеры, срабатывающие при удалении, обновлении и добавлении записи; хранимые процедуры, которые хранятся в базе данных и не требуют дополнительного указания библиотеки процедур (кстати, таких библиотек теперь можно открывать сколько угодно).
Помимо локальных данных, все больший интерес разработчиков вызывают данные, хранимые серверами баз данных (например, Microsoft SQLServer). Обращение к такой информации обычно подразумевает работу в системе, построенной на базе архитектуры клиент-сервер. Раньше доступ к этим данным обеспечивался средствами программного продукта FoxPro Connectivity Kit, продававшегося отдельно и позже включенного в состав FoxPro 2.6 Professional Edition. Теперь же все средства, необходимые для построения запросов к серверу баз данных, встроены в Visual FoxPro. Все, что нужно - это просто установить Visual FoxPro. Доступ к данным производится через интерфейс ODBC. В частности, есть возможность получать динамически обновляемые результаты запросов. Для управления процессом можно использовать один из новых элементов интерфейса - таймер, который через определенные промежутки времени выполняет запрос к серверу, так что у пользователя на экране всегда будет находиться наиболее свежая информация.
Все компоненты объединяет значительно модифицированный Менеджер проектов. В проект можно включать таблицы, базы данных и классы. Очень интересно построено само окно Менеджера проектов. Его не только можно превратить в узкую полоску и разместить где-нибудь с краю, но можно также "оторвать" любой из отдельных "листков" проекта и перемещать по экрану.
Пакет Visual FoxPro - это полноценное 32-разрядное приложение, которое работает не только под 16-разрядными Windows 3.x, но и под Windows NT и Windows 95. При установке на Windows 3.x или Windows для рабочих групп Visual FoxPro инсталлирует Win32s. Развитые новые возможности требуют достаточно мощной техники. По своим требованиям к технике Visual FoxPro похож на Microsoft Access 2.0.
3.2.2.3. Среда программирования CA-Visual Objects
Новый продукт СА-VisualObjects, разработанный фирмой Computer Associates, является преемником широко распространенной системы программирования Clipper. Он ориентирован на создание информационных приложений с графическим интерфейсом пользователя в среде Windows.
С точки зрения синтаксиса VisualObjects почти на 90 процентов совпадает с CA-Clipper. Но VisualObjects не является просто продолжением линии Clipper. Хотя, конечно, при работе с VisualObjects можно использовать Clipper и включать разработанный раннее код в новую систему приложений.
Разработчику, использующему новую среду программирования, необходимо четко понимать особенности и преимущества объектно-ориентированного подхода, иметь представления о динамически компонуемых библиотеках (DLL) и принципах программирования в среде Windows.
Для работы систем VisualObjects требуется как минимум Intel 386 с 8 Мб оперативной памяти и Windows (с версией не менее, чем 3.1), а также примерно 40 МБ свободного дискового пространства. Но чтобы сделать работу более комфортной, лучше иметь 486-й (или более старший) процессор и 16 Мб памяти. Для создания приложений в среде GUI рекомендуется использовать сопроцессор. Такая конфигурация необходима именно для разработчиков, конечный же пользователь, применяющий готовые приложения, написанные в среде VisualObjects, не нуждается в таком мощном оборудовании. Это очень существенно для разработки коммерческих систем. При работе с VisualObjects не требуются дополнительные библиотеки, кроме библиотеки для работы с графикой.
В отличие от рассмотренных ранее сред программирования, при использовании VisualObjects простое изучение синтаксиса не позволяет сразу начинать работать. Необходимо освоить новые понятия. Прежде всего, это репозиторий (центральное хранилище объектов разработки). Это понятие чрезвычайно важно при разработке приложений в среде VisualObjects и непривычно для пользователей CA-Clipper. Вместо операций с PRG- и СН-файлами в VisualObjects используются модули, каждый из которых состоит, возможно, из нескольких функций, определений классов и методов.
Приложения, модули и компоненты хранятся в репозитории - своего рода глобальной базе данных. У репозитория есть еще одна важная функция - управление всеми частями приложения вплоть до компонентов самого низкого уровня. Автоматически поддерживаются связи между различными модулями и компонентами всех приложений. Репозиторию всегда "известно", был ли исходный код модифицирован или откомпилирован, так что отпадает необходимость в make-файлах и других файлах, так или иначе описывающих процесс компоновки.
Выбор опций в компиляции VisualObjects отличается от Clipper. По умолчанию устанавливается режим low (отображение самых серьезных ошибок). Однако можно выбрать опции none (предупреждения не выводятся), med (только важные предупреждения и серьезные ошибки), high (вывод всех предупреждений и ошибок). Существует режим, позволяющий предупреждать возникновение ошибок во время выполнения, при котором можно заказать отслеживание ситуаций переполнения, выхода за пределы указанного диапазона адресов (например, контроль доступа к элементам массива вне указанной размерности) и проверку корректности принадлежности объекта к тому или иному классу.
В VisualObjects реализован целый список переключателей компилятора, используемых для обеспечения совместимости с CA-Clipper. Так, можно "разрешить" применение переменных в стиле Clipper, объявить правила использования операторов присваивания "=" или "(=", а также обеспечить применение функции ProcName() и ProcLinep(). Кроме того, компилятор VisualObjects позволяет проводить оптимизацию кода по размеру и скорости выполнения, а также имеется возможность смешанной проверки, что очень полезно в процессе конвертирования Clipper-программы в VisualObjects. С VisualObjects пользователь получает большой выбор библиотек, интегрируемых в IDE. Каждая используемая библиотека должна быть связана с приложением. Наиболее интересна библиотека GUI Classes - совокупность почти 100 классов. Здесь описаны классы для формирования окон, списков, кнопок, линеек прокрутки и прочих атрибутов GUI. DBF-библиотека поддерживает стандартные для xBase-архитектуры команды и функции обработки данных. Средства ООП позволяет реализовывать библиотека DBF Classes.
Доступ через протокол ODBC к таблицам обслуживает библиотека SQL Classes, объектно-ориентированный интерфейс для генератора отчетов Report Classes, ввод/вывод в традиции xBase-Terminal, а функции прикладного программирования для Windows - Windows API.
Центральное место занимает библиотека System Library, содержащая все системные средства.
При работе с VisualObjects существует два варианта программирования в графическом интерфейсе - использование программы эмуляции терминала или применение библиотеки CommonView. В первом случае существует возможность использовать созданные раннее Clipper-приложения как программы Windows, хотя, конечно, это будет все то же DOS-приложение, просто работающее в окне Windows.
Переход к GUI создает для разработчика массу новых проблем, что, правда, окупается на порядок более качественным и гибким приложением, получаемым в итоге.
Поскольку программисту приходится учитывать событийный характер поведения тех или иных узлов приложения, инструментарий визуальной разработки оказывается ключевым. СА-VisualObjects дает возможность применять мощный набор средств визуального программирования. Так, доступны редакторы меню, окон, отчетов, исходных текстов программ и пиктограмм. Все это позволяет создавать качественные приложения.
Сложность освоения VisualObjects состоит в традиционной ломке представлений и привычек, происходящей на пути от процедурного программирования к ООП. В скором времени появится большое количество программных систем, созданных на базе VisualObjects и реализующих все достоинства информационных систем в архитектуре клиент-сервер. 3.3. Перенос файл-серверных приложений в среду клиент-сервер
Усложнение информационных приложений, их интеграция в корпоративные сети, создание распределенных БД коллективного пользования требуют новых инструментальных средств и "истинно реляционных" СУБД. Традиционно используемые "персональные" СУБД типа Clipper и FoxPro не могут обеспечить требуемый уровень надежности и достоверности информации, особенно при работе в сетях. Подобные СУБД не поддерживают целостность баз данных и не имеют механизмов управления транзакциями, что существенно затрудняет обеспечение логической непротиворечивости информации при сбоях оборудования и программ.
Возросшим требованиям удовлетворяет архитектура клиент-сервер, основанная на выделении одного узла сети под сервер БД с реляционной СУБД, поддерживающей максимальный уровень надежности хранения, ее актуальность и достоверность. До недавнего времени создание приложений для таких СУБД было делом непростым и требовало высокой квалификации, методика программирования на непроцедурном языке SQL не согласуется с опытом разработки приложений для СУБД на персональных компьютерах.
С другой стороны, накоплен большой опыт работы на системах семейства xBase, в частности, Clipper. Создано большое число прикладных программ, которые внедрены в эксплуатацию. При интеграции отдельных автоматизированных рабочих мест в корпоративные сети было бы желательно сохранить не только постановку задачи и применяемые алгоритмы, но и собственно программное обеспечение.
Существует несколько подходов к интеграции и адаптации файл-серверных приложений к архитектуре клиент-сервер:
использование библиотек доступа к серверам БД;
связь с сервером БД через открытый протокол ODBC;
укрупнение файл-серверных приложений.
Чтобы оценить возможности этих способов, рассмотрим их несколько подробнее. 3.3.1. Библиотеки доступа к базам данных
Библиотеки доступа к серверам приложений удобно применять для адаптации файл-серверных приложений, построенных на системах программирования типа Clipper или Clarion.
Система управления записями Clarion достаточно легко связывается с сервером баз данных Btrieve через библиотеку доступа. Нужно только заметить, что Btrieve не является SQL-сервером БД, что затрудняет программирование с использованием этого средства.
Приложения, построенные на Clipper, можно адаптировать с помощью программного интерфейса с выбранным сервером БД. Для примера рассмотрим библиотеку интерфейса Clipper-Oracle.
Интерфейс реализован в виде библиотеки функций, доступных для их использования в прикладных программах, написанных на языке Clipper, и выполняющих все необходимые операции над базой данных Oracle. Функции написаны на языках Clipper и Си.
С помощью функций этой библиотеки можно выполнять следующие операции над таблицами базы данных системы Oracle:
подключиться к системе Oracle;
вставить в базу данных новую строку;
удалить существующую строку;
произвести модификацию содержимого полей существующей строки;
выполнить поиск строк по заданному точному значению полей;
выполнить поиск строк по заданному шаблону значений полей;
выполнить поиск строк по их относительному номеру в заданной группе;
блокировать и разблокировать таблицы;
обрабатывать транзакции, в том числе с возможностью установки контрольных точек внутри одной транзакции.
В то же время для всех этих операций (кроме обработки транзакций) имеются соответствующие аналоги в системе Clipper, и все операции с базой данных системы Clipper могут быть реализованы с помощью функций предлагаемой библиотеки.
Кроме того, существует возможность прямого использования языка SQL, который является основным языком обработки данных не только в системе Oracle, но и в большинстве других развитых СУБД.
Версия языка SQL, реализованная в Oracle, ориентирована на стандарт этого языка и содержит ряд ограничений. Например, оператор Fetch позволяет перемещаться по результирующей таблице только в одном направлении, исключая возвраты назад. Функции библиотеки снимают эти ограничения.
С помощью функций библиотеки можно обрабатывать таблицы Oracle всех типов, в том числе виртуальные таблицы, кластеризованные таблицы, таблицы с индексами и без индексов. При этом обеспечивается преобразование форматов данных Oracle в форматы данных Clipper и наоборот.
Единицей обмена между прикладной программой и базой данных является строка таблицы, которая с точки зрения Clipper является массивом. Каждый элемент массива соответствует одному полю таблицы. Аналогично представляются ключи и поля поиска.
В состав библиотеки входят следующие функции:
INIT () подключение к Oracle;
OPEN () открытие таблицы;
INSERT () добавление строки;
UPDATE () корректировка строки;
DELETE () удаление строки;
SELECT () поиск строки;
NEXT () чтение следующей строки;
SET () чтение строки по относительному номеру;
SKIP () пропуск строк;
FILTER () выбор строк по условию;
GETIND () сохранение индекса;
SETIND () установка индекса;
COMMIT () конец транзакции;
SAVE () установка контрольной точки;
ROLL () откат транзакции;
LOCK () блокировка таблицы;
SQL () выполнение оператора SQL;
CLOSE () закрытие таблицы;
STOP () отключение от Oracle.
Предлагаемые функции не препятствуют использованию собственных средств управления данными Clipper, что позволяет совместно обрабатывать разнородные базы данных. Так, в качестве центральной может использоваться база данных Oracle на большой, мини- или персональной ЭВМ, а в качестве локальной может использоваться база данных Clipper на персональном компьютере пользователя.
В состав интерфейсных средств включен специальный модуль для автономной отладки прикладных программ без системы Oracle. Этот модуль выполняет все функции интерфейса на DBF-файлах, что позволяет разрабатывать и полностью отлаживать программы, используя только систему Clipper на обычном персональном компьютере. Кроме того, эта возможность позволяет разрабатывать прикладные программы сразу в двух вариантах - сетевом и автономном.
Такой подход позволяет сохранить ранее разработанное и внедренное программное обеспечение, обеспечить преемственность при разработке новых прикладных систем, поддержать единую технологию программирования. 3.3.2. Протокол ODBC и его реализации
Интерфейс прикладного программирования ODBC API предоставляет общие методы доступа на основе языка баз данных SQL как к реляционным, так и к нереляционным (ISAM) источникам данных.
Наиболее современный стандарт ANSI SQL (фактически, это часть разрабатываемого стандарта SQL-3) включает спецификацию интерфейса на уровне вызовов (CLI - Call-Level Interface), на которую опирается ODBC для обеспечения доступа и работы с данными во многих системах управления базами данных. Интерфейс CLI соответствует требованиям, установленным в 1996 году комитетом SQL Access Group и определяющим общий синтаксис SQL и интерфейса API. Иметь общий метод доступа к источникам данных удобно потому, что тогда база данных на сервере становится прозрачной для приложений, которые написаны в соответствии со специфицированным уровнем совместимости ODBC.
Интерфейс ODBC API реализован как набор расслоенных DLL-функций для Windows. Динамическая библиотека ODBC.DLL - это основная библиотека управления драйверами ODBC, которая содержит функции вызовов специализированных драйверов для разных поддерживаемых системой баз данных. Каждый драйвер совместим со своим уровнем CLI и относится к одной из двух категорий: одноуровневые или многоуровневые драйверы.
Одноуровневые драйверы предназначены для использования при работе с теми источниками данных, которые не могут быть прямо обработаны с использованием ANSI SQL. Обычно это локальные базы данных на персональных компьютерах, такие как dBase, Paradox, FoxPro и Excel. Драйверы, соответствующие этим базам данных, производят компиляцию ANSI SQL в наборы инструкций более низкого уровня, которые непосредственно обрабатывают составляющие базу данных файлы.
Многоуровневые драйверы используют сервер РСУБД для обработки SQL-предложений и предназначены для работы в среде клиент-сервер. Помимо обработки ANSI SQL, они также могут поддерживать и собственные конструкции конкретной РСУБД, поскольку ODBC может без трансляции передавать SQL-операторы источникам данных (механизм "passthrough"). Драйверы ODBC для баз данных, поддерживаемым в технологии клиент-сервер реализованы для Oracle V 6.0 и Oracle V 7, а также Informix, Microsoft и Sybase SQL Server, Rdb, DB2, Ingres, HP/Image и An SQL. Драйверы можно приобрести в фирмах Microsoft, Intersolv, Visigenic и Openlink, причем только Microsoft и Intersolv выпускают и 32-х, и 16-ти разрядные драйверы.
Существует 4 важных этапа (шага) процедуры запроса данных через ODBC API.
Шаг 1 - установление соединения. Первый шаг состоит в размещении указателей (handle) среды ODBC, которые выделяют оперативную память под ODBC драйверы и библиотеки. Затем происходит выделение памяти для указателей соединения, и соединение устанавливается.
Шаг 2 - выполнение оператора SQL. Выделяется указатель оператора, локальные переменные связываются со столбцами в SQL-выражении (это необязательное действие), и выражение представляется главному ODBC-драйверу для обработки.
Шаг 3 - извлечение данных. Перед извлечением данных возвращается информация о результирующем наборе, в частности, число столбцов в наборе. Исходя из этого числа, результирующий набор помещается в буфер записей, выполняется цикл его просмотра и содержимое каждого столбца помещается в соответствующую локальную переменную. Этот шаг необязателен, если используется связывание столбцов с локальными переменными.
Шаг 4 - освобождение ресурсов. После того, как данные получены, ресурсы освобождаются путем вызова функций освобождения указателей оператора, соединения и среды. Указатели оператора и соединения могут быть использованы в процессе обработки.
Технология ODBC разрабатывалась как общий, независимый от источников данных, способ доступа к данным. Применение технологии должно было также обеспечить переносимость приложений в среду различных баз данных без потребности переработки самих приложений. В этом смысле технология ODBC уже стала промышленным стандартом, ее поддерживают практически все производители СУБД и средств разработки.
Однако универсальность стоит дорого. Если при разработке приложений одним из основных критериев является переносимость на различные СУБД, то использование ODBC является оправданным. Для увеличения производительности и эффективности приложения активно применяют специфические для данной СУБД расширения языка SQL, используют хранимые на сервере процедуры и функции. В этом случае теряется роль ODBC как общего метода доступа к данным. Тем более, что для разных СУБД драйверы ODBC поддерживают разные уровни совместимости. Поэтому многие производители средств разработки, помимо поддержки ODBC, поставляют "прямые" драйверы к основным СУБД. 3.3.3. Укрупнение приложений (Upsigsing)
Пакет Microsoft Access Upsizing Tools позволяет автоматизировать процесс перехода от настольных баз данных к архитектуре клиент-сервер, в данном случае - от Microsoft Access к Microsoft SQL Server для Windows NT. Данный продукт добавляет к Access такие модули, как Upsizing Wizard и SQL Server Browser. Upsizing Wizard позволяет задать все параметры процесса переноса данных с помощью серии диалогов, а затем создает саму базу данных, журнал транзакций, таблицы, индексы, правила проверок значений данных, отношения между таблицами и поля типа timestamp (временная метка). Browser позволяет управлять объектами Access Server с помощью Access-подобного интерфейса. В комплект поставки также входит дискета с ODBC 2.0 и ODBC-драйвером для Microsoft SQL Server. База данных Access (файл с расширением .MDB) содержит таблицы данных и индексы, а также компоненты управления данными (запросы, макросы, модули, формы и отчеты).
Применение Microsoft Access Upsizing Tools основывается на концепции прозрачного для пользователя размещения данных: перенос информации в базу данных SQL Server при сохранении в исходном виде остальной части Access MDB. Access способен работать в качестве клиента в архитектуре клиент-сервер, поэтому разработчикам, переносящим приложения с помощью этого инструмента, не нужно отказываться от Access. Запросы, отчеты и прочие объекты остаются в неизменном виде, так как Upsizing Wizard перенаправляет их на экспортированные таблицы, переименовывая при этом локальные таблицы.
Upsizing Wizard учитывает при переносе ряд архитектурных различий между Microsoft Access и SQL Server для Windows NT. Он экспортирует таблицы и их свойства, такие как правила проверок, значения по умолчанию и индексы. Он выполняет такие операции, как добавление поля типа timestamp, преобразование отношений между таблицами Access в триггеры, поддерживающие ссылочную целостность, и даже создание INSERT-триггеров для аналогов автоинкрементируемых полей Access типа Counter. Upsizing Wizard не экспортирует из базы данных Access сведения о пользователях, группах и правах доступа, поэтому администратор базы данных должен устанавливать права доступа вручную. Upsizing Wizard создает подробный отчет, содержащий имена баз данных и размеры, параметры переноса, триггеры, таблицы (старые и новые), а также информацию об ошибках, возникших в процессе работы.
Модули Microsoft Wizard - это инструменты для автоматизации операций, направляющие действия пользователя в нужной последовательности. Access Upsizing Wizard не является примитивным продуктом, так как пользователю может понадобиться вручную конфигурировать систему для обеспечения нормальной работы, но, несмотря на это, покупка Microsoft Access Upsizing Tools будет оправдана для тех, кому необходимо перемещать данные из Access в SQL Server. Эта программа автоматизирует большинство рутинных моментов процесса, которые могут оказаться утомительными и нетривиальными, а документация включает специальный раздел по оптимизации использования Microsoft Access в качестве клиента в приложениях типа клиент-сервер. 3.4. Рекомендации по использованию инструментальных средств разработки файл-серверных приложений
Анализ инструментальных средств разработки файл-серверных приложений позволяет определить и рекомендовать их области применения. СУБД для персональных компьютеров в среде MS-Access могут быть использованы для создания масштабируемых одиночных и групповых информационных приложений и для разработки клиентской части приложений клиент-сервер, а также как средство автоматизации делопроизводства в составе MS-Office.
Систему программирования Visual Basic можно использовать для создания простых автономных приложений и компонентов VBX и OCX, для расширения и интеграции функциональных пакетов (Word, Excel, Access), а также как средство программирования для расширения возможностей систем документооборота и для создания утилит администрирования. В настоящее время Visual Basic является наиболее распространенным языком программирования: с сентября 1995г. по май 1996г. продано 800 тыс. копий Visual Basic 4.0. Общее число копий Visual Basic всех версий составило более 3 млн.
С момента выхода продано существенно меньше копий Delphi, чем Visual Basic. Поэтому решение вопроса об использовании Delphi для серьезных коммерческих приложений будет зависеть от перспектив распространения этого продукта на рынке. Применение продукта возможно для создания расчетно-аналитических программ, для разработки DLL, для сопровождения и развития разработок, выполненных на Turbo и Borland Pascal, а также для быстрого прототипирования будущих приложений. В ряде случаев решающим для выбора будут умеренные требования Delphi-приложения к системно-техническому обеспечению. Си++ применяется для расширения системного программного обеспечения, для разработки крупных проектов, специальных приложений, создания библиотек и классов для предметной области, разработки динамических библиотек DLL, создания программного обеспечения для серверов приложений, разработки ОСХ, использования совместно с CASE-системами, обеспечения многоплатформенности и переносимости (по стандарту ANSI).
Традиционные инструментальные средства класса xBase (такие, как FoxPro, Clipper, dBase и др.) теряют рынок (число их продаж значительно сокращается) из-за несоответствия современным требованиям. По мере того, как предприятия все шире используют СУБД MS Access и новые средства разработки, такие как Visual Basic и Delphi, популярность среды xBase уменьшается. Более того, Microsoft может прекратить поддержку FoxPro, так как эта СУБД с устаревшим языком и сокращающейся рыночной долей не вписывается в долговременную стратегию развития средств разработки, которую Microsoft строит вокруг Visual Basic и Access. Новые "визуальные" инструменты этого класса (Visual FoxPro, CA-Visual Objects, Visual dBase) пытаются сохранить и расширить прежний ареал. Они могут быть рекомендованы для сопровождения и развития прежних xBase-разработок, для создания масштабируемых одиночных и групповых файл-серверных приложений и для переноса и адаптации приложений в архитектуру "клиент-сервер" с использованием интерфейса ODBC. Но нужно четко осознавать, что при использовании нового инструментария для создания диалога и с переходом к использованию SQL-операторов применяемых xBase-приложений остается ничтожно мало, а, кроме того, существенно меняется подход к разработке и прежние навыки вряд ли будут востребованы.
Инструментальное средство MS Access хорошо зарекомендовало себя в разработке файл-серверных приложений с возможностью масштабирования, так как оно имеет удобные средства визуального конструирования, отладки и возможности использования как Access Basic, так и SQL. Интерфейс ODBC открывает широкие возможности интероперабельности с различными СУБД. В 1995г. на долю MS Access пришлось 57% рынка настольных баз данных, а FoxPro и dBase - 9% и 2% соответственно.
6 клиент-серверные приложения
Даже в нынешний век сложных многозвенных архитектур многие программы выполняются в простом клиент-серверном режиме, в особенности пакетные задания. Выделяя компонент приложения для тестирования, вы наверняка не откажете себе в такой роскоши. В подобной конфигурации любой сеанс Oracle создает единственный трассировочный файл, содержащий данные только этого сеанса (см. рис. 6.1).
Отсутствие межплатформенного стандарта именования трассировочных файлов вызвало у нашей компании затруднения при создании переносимого инструмента для поиска таких файлов. Мы рассматривали вариант с пополняемой таблицей шаблонов имен (т. е. регулярных выражений), которую можно было бы исправлять по мере переноса Oracle на новые платформы и выхода новых версий. Но мы пришли к выводу, что при поддержании актуальности такой таблицы неизбежно возникало бы множество ошибок. В результате мы остановились на таком алгоритме:
1. По заданным идентификатору и порядковому номеру выбранногосеанса (значения V$SESSION.SID и V$SESSION.SERIAL#) определить системный идентификатор (SPID) соответствующего серверного процесса. Этот идентификатор содержится в поле V$PROCESS.SPID, соответствующем выбранному сеансу, и может быть получен при помощи соединения, аналогичного приведенному в примере 6.3.
Рис. 6.1. В простых клиент-серверных конфигурациях сеансу соответствует один серверный процесс и, следовательно, один трассировочный файл
Найти, в каком каталоге располагаются файлы трассировки. Этот каталог определяется значением параметра USERDUMPDEST, если V$SESSION.TYPE='USER', или параметра BACKGROUNDDUMPDEST, если V$SESSION.TYPE='BACKGROUND'.
Отсортировать содержимое каталога по убыванию даты изменения файла (например, командой ls -lt в UNIX). Имейте в виду, что время изменения файла (атрибут mtime) обычно указывается с точностью до секунды. Поэтому, если несколько файлов были созданы в течение одной секунды, сравнение значений mtime не даст ответа на вопрос, какой из них был создан последним.
Для каждого файла из полученного списка, значение mtime которого превышает время начала сбора данных (можно задать и более точное условие, но сравнение времени изменения со временем начала сбора данных - это более консервативный подход):
Найти в файле последнюю преамбулу. В особенности это касается платформ Microsoft Windows, где ядро Oracle часто стремится повторно использовать трассировочные файлы, дописывая новые данные к уже существующим. (Поэтому в одном файле может быть несколько преамбул.)
Найти в преамбуле строку, содержащую подстроку «pid» (для Unix и OpenVMS) или «thread id» (для Windows). Преамбулу составляют все строки вплоть до той, которая начинается с подстроки «***».
Если число, следующее за подстрокой «pid» или «thread id», совпадает с идентификатором SPID выбранного сеанса, нужный файл найден, и поиск заканчивается.
Если в файлах из выбранного списка отсутствует подходящий идентификатор процесса, поиск также заканчивается: искомые файлы отсутствуют.
Для проекта Sparky, о котором можно прочитать на сайте http:// www.hotsos.com, мною был написан переносимый код на Perl, выполняющий действия, аналогичные описанным.
Такой метод просмотра содержимого файлов может показаться не очень элегантным, особенно если в данной организации используется только одна или две операционные системы. Однако достоинство приведенного алгоритма в его надежности для различных платформ и различных версий программного обеспечения Oracle. Алгоритм хорошо масштабируется в зависимости от количества файлов трассировки, находящихся в каталоге. Несколько хуже он масштабируется в случае, когда файлы трассировки имеют очень большие размеры и содержат по несколько преамбул.
Параллельное выполнение (Oracle PX)
При параллельном выполнении Oracle (Oracle Parallel eXecution - PX) серверный процесс Oracle порождает два или более дочерних процесса (называемых подчиненными процессами PX) для выполнения параллельного чтения и параллельной сортировки. Подчиненные процессы PX наследуют атрибуты трассировки от координатора запроса. Следовательно, включение расширенной трассировки SQL для сеанса, который использует функциональность PX, приведет к формированию нескольких файлов трассировки. Задача заключается в том, чтобы опознать и проанализировать все нужные файлы. Обычно она решается достаточно просто - необходимо оценить время изменения файлов трассировки, сформированных последними. Для запросов, использующих степень параллелизма p, количество n соответствующих файлов трассировки будет находиться в диапазоне 1 < n < 2p +1 для каждого вовлеченного экземпляра.
Многопоточный сервер Oracle
Применение многопоточного сервера Oracle (MTS) несколько усложняет поиск данных трассировки. MTS делает возможным использование коммутируемых соединений, что приводит к созданию отношения «один-ко-многим» между сеансом и серверными процессами Oracle, которые обслуживают вызовы базы данных, выполненные сеансом (рис. 6.2). Соответственно, данные трассировки для одного сеанса могут оказаться разбросанным по двум или более трассировочным файлам. Ядро Oracle предоставляет полные сведения по идентификации сеанса и временные метки каждый раз, когда сеанс мигрирует в новый серверный процесс (а следовательно, и в новый файл трассировки). Создать логический эквивалент единого файла трассировки для конкретного сеанса несложно. Рассмотренный ранее способ поиска файлов трассировки претерпевает следующие изменения:

Рис. 6.2. Многопоточный сервер Oracle использует отношение один-ко-многим для клиентского и серверных процессов, поэтому данные о сеансе могут направляться в несколько файлов трассировки
В зависимости от версии Oracle, совместно используемые серверные файлы трассировки могут храниться в параметре BACKGROUND_DUMP_DEST (мы с коллегами видели это на некоторых платформах для версий 7 и 8) или же в USERDUMPDEST (наблюдается в версии 9).
Вместо того чтобы завершать поиск, обнаружив один файл трассировки с нужной информацией, идентифицирующей сеанс, необходимо продолжить просмотр всех файлов трассировки с подходящим временем изменения.
Определив все файлы, которые содержат нужные данные трассировки, необходимо отбросить данные, относящиеся не к вашему сеансу, а затем объединить оставшиеся. Сначала избавляемся от сегментов данных трассировки, относящихся к сеансам, отличным от исследуемого. Чтобы определить, какие секции следует сохранить, достаточно просто просмотреть строки идентификации сеансов, которые начинаются с символов ***. Затем объединяем оставшиеся участки данных трассировки по возрастанию времени. Это тоже несложно, т. к. строки *** содержат и значения времени. В результате получаем «виртуальный файл трассировки», содержащий сведения только для исследуемого сеанса. Эту операцию можно выполнить вручную в многооконном текстовом редакторе, а можно приобрести специальное средство, которое все сделает за вас. Наша команда на hotsos.com создала подобный продукт и предлагает его на коммерческой основе.
Пул соединений
Как я уже говорил, организация пула соединений - это замечательная возможность, призванная уменьшить количество вызовов подключения к базе данных и отключения от нее. Степень сложности диагностики приложений, работающих с пулами соединений, полностью определяется реализованными в них возможностями. Если приложение позволяет идентифицировать вызовы базы данных, сделанные от имени пользовательской операции, то работа по сбору данных будет простой. К сожалению, многие приложения, работающие с пулами соединений, не обеспечивают такой возможности. Надеюсь, Oracle версии 10 упростит оснащение приложений такими средствами на несколько следующих лет.
Проблемы диагностики производительности для пулов соединений возникают тогда, когда сервер приложений «утаивает» личность конечного пользователя от базы данных. Один сеанс разделяют между собой несколько пользователей, из-за чего невозможно по одному лишь файлу трассировки определить, чьи действия вызвали появление некоторой строки в трассировочных данных (рис. 6.3).
Лучшим общим решением проблемы диагностики приложений, работающих с пулом соединений, является такая архитектура приложения, которая делает возможным включение расширенной трассировки SQL для действий каждого отдельного пользователя.
Если приложение ничем не может помочь в трассировке команд SQL отдельного пользователя, не отчаивайтесь. Конечно же, существуют идругие пути, ведущие к успеху. Рассмотрим такой пример: пользо-

Рис. 6.3. Архитектура, основанная на пуле соединений. Если среднее звено не отслеживает соответствие конечных пользователей вызовам базы данных, то нельзя определить, какой из пользователей вызвал появление той или иной строки данных трассировки
ватель Нэнси, имеющая IP-адрес 150.121.1.102, сообщила об ухудшении производительности приложения ввода заказов, основанного на пуле соединений (архитектура приложения приведена на рис. 6.3). Приложение никак не способствует выделению данных расширенной трассировки SQL для Нэнси.
Есть простой способ: временно запретить работу с системой всем пользователям, кроме Нэнси. Включить расширенную трассировку процесса, обслуживающего Нэнси, и позволить ей выполнить ее медленные операции. Когда Нэнси сделает все, что нужно, отключить трассировку и разрешить всем пользователям вернуться в систему. Этот способ весьма эффективен в отдельных случаях, но надо сказать, что в дополнение к очевидному вмешательству в ход процессов бизнеса, он имеет и серьезный диагностический недостаток. Если ухудшение производительности, о котором сообщила Нэнси, было вызвано конкуренцией с другими сеансами, то данные, собранные предложенным способом, никак не будут указывать на основной источник неприятностей.
Более эффективный обходной маневр - временное изменение архитектуры, которое бы изолировало сеанс Нэнси. Один из способов реализации такого изменения изображен на рис. 6.4, где изоляция сеанса Нэнси обеспечена за счет предоставления ей собственного процесса на сервере приложений и отдельного выделенного серверного процесса Oracle. Для того чтобы реализовать такой переход, можно, например, назначить Нэнси специальный «идентификатор службы» (аналог специального псевдонима TNS для уровня служб приложения), который

Рис. 6.4. Если изолировать действия пользователя так, чтобы в назначенный ему файл трассировки не попадали данные об операциях других пользователей, то сбор диагностических данных становится таким же простым, как в случае простого клиент-серверного приложения обеспечивает соединение со специальным диагностическим процессом сервера приложений.
Противники этого метода обычно отмечают, что изменение архитектуры может оказать влияние на производительность исследуемого сеанса Нэнси. Однако эти изменения имеют более локальный характер, чем в первом случае, т. к. мы не изменяем нагрузку, конкурирующую с действиями Нэнси. Конечно же, необходимо будет изучить сделанные изменения, особенно если окажется, что перемены в архитектуре повлияли на производительность. Например, если измененная архитектура, представленная на рис. 6.4, демонстрирует значительно более высокую производительность, чем архитектура на рис. 6.3, то следует задуматься, не является ли виновником низкой производительности процесс сервера приложений httpdO.
Последний предлагаемый способ возможен лишь в том случае, если все, кто совместно с Нэнси использует один или несколько серверных процессов, выполняют приблизительно те же операции, что и Нэнси. Если все соединения, которые задействуют серверные процессы, выполняют однотипные операции, то каждая из строк результирующего файла трассировки достаточно показательна для изучения действий Нэнси (рис. 6.5).
Конечно же, утверждение о том, что невозможно восстановить составляющие из усредненного значения, остается истинным. И поэтому рискованно рассматривать общий файл трассировки, стремясь полу-
7 Принципы работы архитектуры клиент-сервер
Клиент-сервер
По сети циркулируют только SQL-запросы/ответы (а не фрагменты или отдельные записи СУБД, как в архитектуре файл-сервер), благодаря чему резко снижается нагрузка на сеть. Обработка данных при этом более равномерно распределяется между клиентом и сервером.
{loadposition adsense2}
Обычно выделяются три модели взаимодействия клиента и сервера:
RDA (Remote Data Access), в которой компонента представления (пользовательский интерфейс) и прикладная компонента (логика работы программы) совмещены в клиентской части, а компонента доступа к информационным ресурсам (данным) размещена в серверной части.DBS (DataBase Server), в которой компонента представления размещена в клиентской части, а прикладная компонента и доступ к информационным ресурсам - в серверной;
AS (Application Server), в которой компонента представления находится в клиентской части, прикладная компонента - в "сервере приложения", а компонента доступа к информационным ресурсам - в "сервере базы данных".{loadposition adsense1}
1 одноранговые сети и сети с технологией клиент-сервер
Однора́нговая, децентрализо́ванная или пи́ринговая (от англ. peer-to-peer, P2P — равный к равному) сеть — это оверлейная компьютерная сеть, основанная на равноправии участников. В такой сети отсутствуют выделенные серверы, а каждый узел (peer) является как клиентом, так и сервером. В отличие от архитектуры клиент-сервера, такая организация позволяет сохранять работоспособность сети при любом количестве и любом сочетании доступных узлов. Участниками сети являются пиры. стройство одноранговой сети
Например, в сети есть 12 машин, при этом каждая может связаться с любой из них. Каждая из этих машин может посылать запросы на предоставление каких-либо ресурсов другим машинам в пределах этой сети и, таким образом, выступать в роли клиента. Будучи сервером, каждая машина должна быть способной обрабатывать запросы от других машин в сети, отсылать то, что было запрошено. Каждая машина также должна выполнять некоторые вспомогательные и административные функции (например, хранить список других известных машин-«соседей» и поддерживать его актуальность).
Любой член данной сети не гарантирует свое присутствие на постоянной основе. Он может появляться и исчезать в любой момент времени. Но при достижении определённого критического размера сети наступает такой момент, что в сети одновременно существует множество серверов с одинаковыми функциями.
Пример такой сети: I2P, Gnutella2.
Частично децентрализованные (гибридные) сети
Помимо чистых P2P-сетей, существуют так называемые гибридные сети, в которых существуют серверы, используемые для координации работы, поиска или предоставления информации о существующих машинах сети и их статусе (on-line, off-line и т. д.). Гибридные сети сочетают скорость централизованных сетей и надёжность децентрализованных благодаря гибридным схемам с независимыми индексационными серверами, синхронизирующими информацию между собой. При выходе из строя одного или нескольких серверов сеть продолжает функционировать. К частично децентрализованным файлообменным сетям относятся например EDonkey, BitTorrent.
Пиринговая файлообменная сеть
Основная статья: Файлообменная сетьОдна из областей применения технологии одноранговых сетей — это обмен файлами. Пользователи файлообменной сети выкладывают какие-либо файлы в т. н. «расшаренную» (англ. share — делиться) директорию, содержимое которой доступно для скачивания другим пользователям. Какой-нибудь другой пользователь сети посылает запрос на поиск какого-либо файла. Программа ищет у клиентов сети файлы, соответствующие запросу, и показывает результат. После этого пользователь может скачать файлы у найденных источников. В современных файлообменных сетях информация загружается сразу с нескольких источников. Ее целостность проверяется по контрольным суммам.
Многие распространяемые в таких сетях файлы, не являющиеся общественным достоянием, распространяются в них без разрешения правообладателей. Видеоиздательские и звукозаписывающие компании утверждают, что это приводит к значительной недополученной ими прибыли. Проблем им добавляет тот факт, что пресечь распространение файла в децентрализованной пиринговой сети технически невозможно — для этого потребуется физически отключить от сети все машины, на которых лежит этот файл, а таких машин (см. выше) может быть очень и очень много — в зависимости от популярности файла их число может достигать сотен тысяч. В последнее время видеоиздатели и звукозаписывающие компании начали подавать в суд на отдельных пользователей таких сетей, обвиняя их в незаконном распространении музыки и видео.
Такие организации, как RIAA, дискредитируют пиринговые сети, публикуя в них фальшивые файлы (содержание которых не соответствует названию, часто носит порнографический характер). Это привело к потере популярности сети KaZaA в пользу eDonkey, имеющей более совершенную архитектуру.
Несмотря на то, что в феврале 2006 прекратил работу самый популярный сервер сети eD2k — Razorback, и была прекращена разработка коммерческого клиента EDonkey2000, сама сеть ED2K продолжает функционировать, т. к. не завязана на конкретные серверы и существует большое количество свободно распространяемых клиентских программ типа eMule и mlDonkey.
Пиринговые сети распределённых вычислений
Технология пиринговых сетей (не подвергающихся квазисинхронному исчислению) применяется также для распределённых вычислений. Они позволяют в сравнительно короткие сроки выполнять поистине огромный объём вычислений, который даже на суперкомпьютерах потребовал бы, в зависимости от сложности задачи, многих лет и даже столетий работы. Такая производительность достигается благодаря тому, что некоторая глобальная задача разбивается на большое количество блоков, которые одновременно выполняются сотнями тысяч компьютеров, принимающими участие в проекте. Один из примеров такого использования пиринговых сетей использует компания Sony в игровых приставках Sony PlayStation [1].
Пиринговые финансовые сети
Разрабатываются и обкатываются на игровых моделях децентрализованных денежных систем. Основная идея в том, что современные деньги — несовершенный механизм расчетов, зависящий от воли высокопоставленных чиновников, а децентрализованные деньги, основанные на p2p технологиях, в теории являются более справедливым средством взаимных расчетов пользователей.
Сети клиент/сервер
Для получения доступа к ресурсу в сети клиент/сервер пользователь должен ввести свой уникальный идентификатор — имя пользователя (login — логин) и пароль (password). Логин пользователя является общедоступной информацией, и это правильно. Если кто-нибудь захочет отправить пользователю сообщение по электронной почте, то для этого ему достаточно знать его логин (естественно, и имя сервера электронной почты, который «знает» этого пользователя). Проверка имени пользователя называется идентификацией. Подтверждение (проверка подлинности) имени пользователя паролем — аутентификация. Идентификация + аутентификация = авторизация. Иногда понятие аутентификация просто воспринимается, как проверка подлинности в широком смысле этого слова.
После рассмотрения архитектуры одноранговой сети можно придти к выводу, что единственное ее преимущество — это ее простота и дешевизна. Сети клиент/сервер обеспечивают более высокий уровень производительности и безопасности. В отличие от одноранговой сети, в сети клиент/сервер существует один или несколько главных компьютеров — серверов. Все остальные компьютеры сети называются клиентами или рабочими станциями (workstations). Как я уже писал выше, сервер — это специальный компьютер, который предоставляет определенные услуги другим компьютерам. Существуют различные виды серверов (в зависимости от предоставляемых ими услуг): серверы баз данных, файловые серверы, серверы печати (принт-серверы),почтовые серверы, Web-серверы, и т.д.
Для экономии средств, как правило, один сервер сочетает в себе несколько функций, например, почтовик может быть также и Web-сервером. Услуги, которые может предоставлять сервер, ограничиваются только его физическими возможностями — чем мощнее сервер, тем больше услуг и с большим качеством он может предоставлять, поэтому в качестве сервера выбирается довольно мощный компьютер.
Сеть клиент/сервер более дорога в построении и обслуживании, чем простая одноранговая сеть. Так почему же Internet построен с использованием технологии клиент/сервер? Неужели никто не задумывался над экономией средств? Все дело в том, что Internet просто-напросто не может быть одноранговой сетью. Сейчас объясню почему. Можно привести множество примеров, но мы ограничимся только двумя.
По определению все компьютеры в одноранговой сети равны между собой. Теперь представьте себе такую одноранговую сеть, в которой сто-двести тысяч компьютеров (а в Internet узлов намного больше!). Ясное дело, что вы не можете запомнить IP-адреса всех компьютеров, вам легче запомнить их символьное имя — comp_vasya, comp_igor и т.п. Вы вводите в браузере адрес http://comp_vasya. Компьютер, в отличие от человека, «привык» оперировать с числами, а не символьными имбнами. То есть ему нужна программа, которая преобразует имя comp_vasya в IP-адрес. Написать такую программу очень просто, но сложность заключается в том, откуда эта программа будет брать сведения про имена компьютеров и соответствующие им IP-адреса? Раньше, когда Internet не было, а была сеть ARPAnet проблема разрешения имени решалась так: администратор редактировал файл hosts, в который вносил имя компьютера и IP-адрес. Потом этот файл нужно было скопировать на каждый (!) компьютер сети (а у нас их 200 тысяч). Программа преобразования имени просматривала этот файл и, если ей удавалось найти нужный IP-адрес, возвращала его. Ясное дело, что такая организация доставляла массу неудобств, как администраторам, так и пользователям — забыл обновить файл, ты уже не получишь доступ к компьютеру, не зная его IP. Поэтому было принято решение разработать службу доменных имен — DNS ( Domain Name System), которая и занималась решением данной проблемы. А служба DNS работает примерно так: к DNS-серверу обращается компьютер с просьбой преобразовать символьное имя в IP-адрес. Если DNS-сервер может разрешить имя компьютера, он возвращает его IP-адрес Все это делается незаметно для пользователя — ему нужно ввести толь ко имя компьютера, а все остально его не касается. Администратору тоже удобно: ему нужно всего один раз отредактировать базу данных сервера DNS. Как видите, служба DNS подразумевает использование технологии клиент/сервер — тут уж никак не отвертишься.
Второй пример связан с авторизацией. Представьте, что у нас есть те самые 200 тысяч пользователей. Один из них входит в сеть и пытается обратиться к компьютеру comp_igor. Ясное дело, что этот компьютер должен его авторизировать, то есть определить, кто вы такой. Для этогс на компьютере comp_igor должна быть база данных, содержащая все имена пользователей и пароли. Такая база данных должна быть на каждом из 200 тысяч компьютеров, а иначе сеть не сможет работать! Намного проще для авторизации использовать один какой-нибудь сервер (или несколько таких серверов). Во-первых, удобно — учетную запись пользователя нужно создать только на одном компьютере, а во-вторых, так намного безопаснее: ведь среди 200 тысяч компьютеров найдете как минимум десятка два-три незащищенных, которые проще взломать При этом, учитывая, что каждый компьютер содержит все имена пользователей и все пароли, в руках злоумышленников окажется вся сеть. С последствиях такого взлома, думаю, не трудно догадаться.
Помните, я говорил про экономию средств? Давайте посчитаем затраты на содержание двух баз данных — имен компьютеров и пользователей для 200 тысяч компьютеров. Договоримся, что максимально допустимое имя компьютера может состоять из 32 символов, имя пользователя — и; 16, а пароль — из 8. 32 (байта — имя компьютера) х 200000 (число записей в файле) х 20000С (этот файл должен быть на каждом компьютере) = 1280000000000 байт = 1220703,125 Мб дискового пространства; 16 + 8+1 (имя, пароль и разделитель) х 200000 х 200000 = 1ОООООООООО0 байт = 953674,32 Мб; Итого: 2174377,445 Мб. Представьте, что каждый день по сети будет «гулять» 2174377,445 Мб информации! Такое даже в страшном сне не приснится. Это ж какая пропускная способность должна быть! При использовании сети клиент/сервер затраты будут ровно в 200000 раз меньше — чуть больше 10 Мб.
10 Intranet приложения
Быстрая смена парадигм, методов и средств в области информационных технологий у части специалистов вызывает недоверие к новациям: "Возможно Intranet всего лишь очередной хит сезона или это хорошо продуманный маркетинговый ход?" Попробуем разобраться в этом вопросе.
Intranet - корпоративная , но не публичная сеть
Intranet - это прежде всего корпоративная - локальная или территориально распределенная сеть, закрытая от внешнего доступа из Internet. Такая сеть возможно использует публичные каналы связи, входящие в Internet, но при этом обеспечивается защита передаваемых данных и меры по пресечению проникновения извне на корпоративные узлы. Сейчас фирмы, занимающиеся электронным бизнесом в Internet имеют смешанную сеть, в которой подмножество внутренних узлов корпорации составляет Intranet, а для внешних узлов (как правило, Web-серверы) предложен термин Extranet. Но даже те, кто имеет только внешний информационный Web-сервер, а не сервер приложений или баз данных, вынуждены устанавливать firewall. В ряде случаев при жестких требования к безопасности эти сети приходится разграничивать физически. Intranet - это применение Web-технологии
Приложения в Intranet основаны на применении Internet-технологий и в особенности Web-технологии: гипертекст в формате HTML, протокол передачи гипертекста HTTP и интерфейс серверных приложений CGI. Составными частями Intranet являются Web-сервера для статической или динамической публикации информации и браузеры для просмотра и интерпретации гипертекста.
Феномен гипертекста
Гипертекстовая организация информации таит в себе огромные возможности. Это другая метафора диалогового интерфейса - электронная книга с автоматическими переходами по ссылкам. Простота этого интерфейса позволяет расширить контингент конечных пользователей, привлекая к активной работе с компьютером руководителей верхнего звена. Язык гипертекстовой разметки HTML имеет объектные свойства, позволяет помимо структуры, формы и содержания документа, определить диалоговые элементы. Вообще надо отметить, что HTML - в определенной мере универсальный стандарт описания диалога. До этого таким переносимым стандартом был телетайпный режим и виртуальные терминалы. Этот универсализм может быть распространен на внутренние форматы справочных систем, текстовых редакторов, текстовые и графические интерфейсы ОС и других системных программ, если только HTML не потонет в следующих волнах Webизации.
Intranet - это архитектура клиент-сервер
Много споров о том, к какой архитектуре относится Intranet. Пытаются даже противопоставить Intranet архитектуре клиент-сервер. Нужно четко понять, что все решения Intranet-приложений для взаимодействия с БД основаны на архитектуре клиент-сервер.
Наличие диалоговых свойств в HTML и интерфейса CGI позволяет строить Intranet-приложения с доступом к БД (рис.1). Наиболее распространена схема динамической публикации отчетов. При этом в качестве CGI-процедуры используется параметризуемый генератор отчетов. Однако это не единственная схема, возможно применять программы ввода и обновления информации в БД.
Если используются традиционные статичные страницы гипертекста, то в ответ на запрос клиента Web-сервер передает страницу в формате HTML. При работе с базой данных клиент указывает в форме программу или сценарий для запуска на сервере. Серверная процедура получает введенные пользователем данные, формирует и передает SQL-запрос (определяющий логику управления данными DL) и, возможно, данные к СУБД. Сервер БД по запросу выполняет обновление, вставку, удаление или выборку записей из БД. CGI-процедура полученные результаты преобразует в формат HTML или в формат диалоговых переменных. Затем Web-сервер посылает полученную HTML-cтраницу или значения диалоговых переменных браузеру для отображения.
Использование CGI-процедур имеет ряд недостатков - статичное представление информации, преобразование результата-отчета в HTML-файл, отсутствие динамического просмотра изменения информации в базе данных, процедура "не помнит состояний запросов" - каждое обращение к БД требует повторного установления соединения. Кроме того, такой принцип работы перегружает коммуникационную среду и имеет системные издержки при запуске серверных процессов.
Рассмотренная схема по существу является трехзвенной архитектурой клиент-сервер, где Web-сервер выступает в качестве сервера приложений. Для устранения недостатков CGI используют возможности специальных API для Web-серверов и включают дополнительное "релейное" звено в архитектуру. Все это только подталкивает к дальнейшему совершенствования архитектуры клиент-сервер.

Рис. 1. Схема Intranet-приложения с доступом к БД
Java - вторая волна Webизации
Предложенная фирмой Sun технология Java ориентирует взаимодействие между клиентом и сервером на поток команд, а не данных. В ходе сеанса обеспечивается фоновая подкачка через сеть на компьютер клиента программных агентов - апплетов, которые берут на себя функции обеспечения гибкого взаимодействия. Все, что нужно для этого - встроить в Web-браузер исполняющую систему для апплетов.
При построении информационных приложений с использованием Java-технологии получается классическая двух- или трехзвенная архитектура клиент-сервер (рис. 2), а гипертекст уходит на задний план и выполняет лишь роль инициатора апплетов. Существенным достоинством такой технологии является независимость приложения от аппаратной платформы. Но есть и немало недостатков: невысокое быстродействие вследствии интерпретации байт-кодов, возврат к оконной метафоре "рабочего стола", остаются те же проблемы организации связи с БД.

Рис. 2
Будет ли Intranet открытой системой?
Стандартные протоколы, языки и интерфейсы Web-технологии пришли в Intranet из мира открытых систем. И хотя от них веет архаикой, но именно это обеспечивает связность и согласованность в Internet. Ситуация со стандартами в Intranet иная: в пылу конкурентной борьбы и в погоне за эффективностью и расширением функциональности фирмы предлагают новые элементы технологии. Так возникли язык апплетов Java, множество языков сценариев JavaScript, VBScript, NetBasic и др., протоколы IIOP, WebNFS, интерфейсы WinCGI, ISAPI, NSAPI и др., компоненты расширения браузеров Plug-in и ActiveX. Но мало того уже заметна поляризация инфраструктур Internet и Intranet. И если в Intranet возобладает монополия Microsoft, то возможно внутренних проблем несовместимости и не будет, но тогда Intranet и Internet станут дальними родственниками, не находящими при встрече общего языка.
Унификация клиентов в Intranet
Однако значимость стандартизации достаточно велика, чтобы создавать унифицированного клиента, эдакий программируемый терминал. Только не надо при этом говорить о "тонком" клиенте: Web-браузер - клиент весьма "упитанный". Поэтому идея NetPC, основанная на унификации системного ПО и сокращении расходов на администрирование, кажется более жизнеспособной, чем идея "утонченного" сетевого компьютера, который ближе к "тупым" терминалам прошлых лет. Унификации клиентов способствовало бы в большей мере распространение формата HTML и стандартизация языков сценариев.
Интеграция Internet и офисных приложений
Именно в Intranet получат дальнейшее развитие офисные приложения, связанные с коллективной подготовкой и обработкой информации, управлением электронными документами и документооборотом.
Web-интерфейс станет привычным для многих приложений автоматизации учрежденческой деятельности. Почтовые, новостные и другие сервисы Internet встраиваются в приложения для коллективной работы. Можно ожидать сближения поисковых технологий Internet и офисных систем управления электронными документами. Интеграция Internet c корпоративными офисными приложениями - важное направление развития Intranet.
Intranet - не панацея от всех бед
Находясь в эпицентре бума Webизации, не надо переоценивать универсальность этой технологии, не поддавайтесь на призывы "все и везде изменить Weboбразно". У Web-технологии в корпоративных сетях своя, возможно, обширная ниша - время покажет. Уже сейчас для многих очевидны гибкость механизма, позволяющая подстраивать приложения под быстроменяющиеся нужды пользователей. Однако следует отметить, что многие инструменты разработки еще очень сырые или примитивные. Обратная сторона гибкости определенная "лоскутность" технологии, но возможно это то, к чему стремились: четко разделились описания диалога (HTML и скрипты или Java), логики управления данными (SQL) и логики приложений (традиционные языки и скрипты). При этом рекомендации по построению Intranet очень похожи на рецепты из поваренной книги: "Возьмите свежие Web-сервер и браузер, сделайте начинку из гипертекста, добавьте по вкусу разных скриптов, все тщательно перемешайте и варите в корпоративной сети до готовности. Гурманы могут для аромата прибавить Java, для остроты - Plug-in или ActiveX. Intranet подают в горячем виде с гарниром SQL ."
11 организация адресации в интернете
Для правильной доставки данных с одного компьютера на другой необходимо знать отправителя и получателя. Так, каждый компьютер, подключенный к сети Интернет, имеет свой собственный уникальный адрес. Т.к. в компьютерах вся информация представляется в цифровом виде, то и адрес, который используют компьютеры, является цифровым.
IP-адрес – это уникальный числовой адрес компьютера в сети, который имеет длину 32 бита и записывается в виде четырех частей по 8 бит каждая.
По формуле определения количества информации легко подсчитать, что общее количество различных IP-адресов составляет более 4 миллиардов: N=232=4294967296.
Поскольку двоичное представление IP-адреса для человека не удобно, то на практике используется десятичная форма записи IP-адреса. В данном представлении IP-адрес записывается в виде четырех десятичных чисел, называемых октетами, разделенными точками: W.X.Y.Z. Следовательно, каждая часть может быть числом от 0 до 255, а весь IP-адрес имеет вид 192.22.35.44 или 255.1.0.14.
IP-адрес содержит адрес сети и адрес компьютера в данной сети. Адрес читается справа налево.
Например:
IP-адрес 128.250.33.199.
128.250.33 – это адреса сетей и подсетей,
199 – это адрес компьютера пользователя.
В зависимости от количества компьютеров в сети, существует 5 классов IP-адресов: A, B, C, D, E. Принадлежность IP-адреса к тому или иному классу, определяется значением первого октета, а остальные разделяются на адрес сети и адрес компьютера.
Класс Диапазон
А 0.0.0.0 – 127.255.255.255
B 128.0.0.0 – 191.255.255.255
C 192.0.0.0 – 223.255.255.255
D 224.0.0.0 – 239.255.255.255
E 240.0.0.0 – 247.255.255.255
IP-адреса первых трех классов предназначены для адресации отдельных узлов и отдельных сетей. Адреса D используются для адресации групп компьютеров, а диапазон адресов Е зарегистрирован и в настоящее время не используется.
Например, IP-адрес 128.250.33.199 компьютера относится к сети класса В, адрес компьютера в сети 250.33.199, а 199 – это адрес компьютера пользователя.
IP-адреса могут быть статическими и динамическими. Для сервера, на котором хранится информация, необходим постоянный IP-адрес, иначе данные не будут найдены. Для пользователя, входящего в Интернет на несколько часов, IP-адрес может быть выделен динамически из некоторого количества имеющихся у провайдера свободных номеров. По желанию пользователь может иметь и постоянный IP-адрес.
Числовые адреса – единственно возможный метод идентификации для компьютеров, но для пользователей Интернет они неудобны, поскольку не несут смысловой нагрузки, а значит, практически не запоминаются. Поэтому в Интернете предусмотрена возможность использования их аналогов в текстовом представлении. Это так называемые доменные адреса DNS (Domain Name System).
Доменная система имен ставит в соответствие числовому IP-адресу каждого компьютера уникальное доменное имя.
Доменная система имен имеет иерархическую структуру:
домены верхнего уровня
   
домены второго уровня
   
домены третьего уровня
   
и так далее
В отличие от IP-адресов, мало говорящих пользователю, кому принадлежит и где находится ресурс Интернет, доменные имена несут много полезной информации.
Расшифровку доменного имени легко провести, читая его составляющие справа налево.
В любом имени справа записывается домен первого уровня, состоящий из двух, трех или четырех букв. Он означает страну или принадлежность к определенной деятельности. Количество имен первого уровня ограничено.
Сначала InterNIC – организация, ответственная за систему имен – ввела в обращение семь доменных имен первого уровня. Т.к. система доменных имен впервые появилась в США, то эти семь доменов по умолчанию означают, что хост расположен на территории США.
Слева от имени домена первого уровня записывается одно или несколько имен доменов второго, иногда третьего и более низких уровней.
Имя домена второго уровня выбирается компанией и несет информацию о ее названии или услугах, имя домена третьего уровня может означать подразделение этой компании.
И, наконец, слева в доменном имени стоит имя компьютера, на котором хранится информация.
Например, www.microsoft.com означает, что компьютер (сервер) с именем www находится в домене Microsoft, который входит в домен первого уровня .com.
Домены верхнего уровня бывают двух типов:
географические (двухбуквенные) – каждой стране соответствует двухбуквенный код;
административные (трехбуквенные) – позволяет определить профиль организации, владельца домена.
Вот некоторые имена доменов верхнего уровня
Административные Тип организации Географические Страна
com коммерческая ca Канада
edu образовательная de Германия
gov правительственная США jp Япония
int международная ru Россия
mil военная США su Бывший СССР
net компьютерная сеть uk Англия/Ирландия
org некоммерческая us США
В имени компьютера может быть любое число доменов, но, как правило, 2–4.
Компьютеры используют IP-адреса, для людей удобней и понятней доменные имена. Следовательно, должен существовать механизм преобразования вводимых пользователем доменных имен в IP-адреса. Этим занимается служба доменных имен Интернет – DNS (Domain Name Service).
Работа службы имен состоит в том чтобы, получив от пользователя доменное имя, отыскать соответствующую ему запись в таблице DNS – распределенной базе данных, хранящейся на тысячах компьютерах в сети. Найденный IP-адрес возвращается на компьютер пользователя, пославший запрос. И только после этого по IP-адресу запрашивается информация из Интернета. Система серверов DNS представляет собой тысячи компьютеров с определенной иерархией.
4. Практическая часть.
Определите IP-адрес вашего компьютера.
1. Зайдите в главное меню ПУСК – Все программы – Стандартные – Командная строка.
2. В появившемся окне введите команду [ipconfig]. В появившемся окне появятся настройки подключения вашего компьютера к сети Интернет: IP-адрес, Маска подсети, Основной шлюз.
13
Язык HTML . История развития.
Основой даже самых продвинутых Интернет - технологий в настоящий момент является уже давно используемый и все же самый дискутируемый язык HTML. Язык HTML предназначен для разметки и оформления документов в Интернете. Зарождение HTML следует отнести к далекому 1986 году, когда впервые усилиями Международной организации по стандартизации (ISO) был принят ISO-8879-стандарт, названный ими "Standard Generalized Markup Language" (SGML). Данный язык тогда описывался как язык для структурной (логической) разметки текста и не подразумевал наличия хоть сколько-нибудь малого описания внешнего вида документа. Так, задать описание кегля и размера шрифта в SGML считалось противоречащим стандартам того времени, т.к. не обеспечивало кросс - браузерности и кросс - платформенности представленного в таком виде документа. А ведь основной целью создания каких - либо стандартов было достижение именно этого.Однако нужно заметить, SGML не был готовой системой для разметки текста и не предполагал наличия того или иного списка структурных элементов языка, которые должны применяться в определенных обстоятельствах. Этот язык только подразумевал описание синтаксиса написания основных элементов разметки текста, которые в последующем были названы "тэгами". Для практической же разметки документов нужно было создать язык, который описывал бы в каких случаях и какой именно элемент языка необходимо применить и который давал перечень элементов языка, которые могут быть использованы для создания документа и которые должны читаться программами, работающими с этими документами. Язык SGML не получил сколько-нибудь значимого распространения, собственно как и его приложения. Впервые о данном языке вспомнили в глобальных масштабах 1991 году, когда Европейский институт физики частиц ощутил потребность в механизме передачи гипертекстовой информации через Интернет. Тогда они выбрали в качестве основы SGML, и на его базе был создан язык. Вряд ли сейчас кто-либо не знает его названия. HTML (Hyper Text Markup Language, "язык разметки гипертекста").
HTML версии 1.2 содержал около 40 тэгов и не подразумевал какого-либо описания физического представления документов. Все было приведено к логической и структурной разметке текста. Только несколько тэгов (кстати, не рекомендованных для использования) издали намекали на физические свойства представления страниц. В описании одного из этих тэгов было сказано: "При просмотре документа, созданного с использованием данного тэга текст может отображаться в графических браузерах полужирным курсивом".
В 1994 году был создан консорциум W3 (Ц3С), который унаследовал право главенствовать в мире Интернета от Европейского института физики частиц. Эта организация сразу же принялась за создание следующей спецификации HTML версии 2.0. но окончательный стандарт HTML 2.0 был принят только в 1995 году, когда уже полным ходом шло обсуждение и разработка HTML 3.0. Единственным существенным усовершенствованием HTML 2.0 было введение в язык форм - средств отправки информации от пользователя на сервер. Пожалуй, HTML версии 3.0 - самый большой прорыв в HTML-технологиях. Первоначальный вариант стандарта включал в себя много интересных нововведений - теги для создания таблиц, разметки математических формул, вставки обтекаемых текстом рисунков, примечаний и др. Но уже тогда в 1995 году появилась потребность в визуальном оформлении гипертекстовых страниц. Не нарушая основ HTML W3C решили создать отдельную систему для возможности описания визуального оформления HTML-документов. Так появились иерархические стилевые спецификации (Cascading Style Sheets, CSS), имеющие совершенно другую структуру, синтаксис и задачи. О нем будет сказано в следующей статье более подробно.
Вскоре (1995 год) появился первый коммерческий браузер Netscape Navigator, который привел к самому быстрому в истории человечества развитию корпорации Netscape Communications. Дабы привлечь еще и еще клиентов, которых было и так хоть отбавляй, корпорации начала вводить в HTML все новые и новые усовершенствования, которые не были отражены в стандартах W3C и поддерживались только Netscape Navigator. Вводимые все снова и снова тэги были ориентированы на улучшение внешнего вида документов и полностью нарушали изначальные принципы языка.
В 1996 году Microsoft перестал быть пассивным наблюдателем на рынке браузеров, в результате чего появился сначала Microsoft Internet Explorer 2.0, который, нужно сказать, не имел большой популярности. Позднее была создана 3-я версия этого браузера, что поделило рынок браузеров пополам между Navigator Communications и Microsoft. Microsoft взял под свою опеку W3C. В сжатые сроки был создан стандарт HTML версии 3.2, который был полностью ориентирован на Microsoft Internet Explorer.
HTML 3.2 до недавнего времени оставался единственным стандартом этого развивающегося языка WEB-строительства. Эта версия HTML навела относительный порядок в плане поддержки элементов разметки всеми браузерами.
В последние годы (2004 год) была принята последняя на настоящий момент версия HTML - HTML 4.01. Она также обеспечивает достаточно высокую кросс - браузерность и кросс - платформенность.
Нужно сказать, что в последние годы ясной становится еще одна проблема, связанная с HTML. Она заключается не столько в создании кросс - браузерности, сколько в другом. Язык HTML создавался для логической разметки гипертекста и не подразумевал какого-либо оформления документа. В нынешних условиях развития коммерческого Интернет, высокоскоростных выделенных линий и постоянного прогресса WEB-технологий необходимы новые решения, которые кроме логической разметки позволят вмешиваться в оформление документа, создавать яркие и запоминающиеся страницы в Интернет, что в корне противоречит принципам HTML. В этих условиях как никогда актуальным становится CSS, на который в настоящее время все больше и больше обращают свои взоры WEB-строители.
Видимо история HTML, полная борьбы и противоречий, по-видимому, близится к завершению. Точнее, близится к завершению история его развития, так как применяться в более или менее неизменном (и, по-видимому, близком к современному) виде он будет еще долго. В мире накоплено огромное количество ресурсов, жестко привязанных к этому языку, - а, кроме того, при всех его недостатках он сносно справляется с важнейшими из своих обязанностей. Основными же точками роста сейчас становятся другие Internet-технологии, к HTML имеющие довольно опосредованное отношение: Java, ActiveX, VRML, а в последнее время - разномастные push-технологии, которые позволят поставщикам "проталкивать" свою информацию на компьютеры пользователей на манер теле- или радиовещания.
14 html. гиперссылки, вставка картинок
Здравствуйте уважаемые читатели блога KtoNaNovenkogo.ru. В этой очередной статье из рубрики «HTML для чайников» мы продолжим рассматривать html теги. Раннее мы узнали что такое язык Html и тэги по версии валидатора W3C, поговорили об оформлении комментариев в Html и Doctype, а так же затронули тему символов пробела в Html коде и спецсимволов (мнемоник). Да, еще мы обсудили возможности задания цвета в Html.
Сегодня я хочу подробнее остановится на тех html тегах и их атрибутах, с которыми вы будете чаще всего сталкиваться в работе над своим веб-проектом. Это html тег изображений (картинок) Img и html тег ссылки A. Без знания html тегов, позволяющих вставить картинку или ссылку в HTML документ (вебстраницу), очень трудно будет продуктивно работать над дизайном сайта. Эти теги картинок и ссылок активно используются как при написании и оформлении статей, так и в оформлении шаблона, используемого на сайте.
HYPERLINK "http://ktonanovenkogo.ru/html/html-new/html-dlya-nachinayushhix-teg-Img-dlya-raboty-s-izobrazheniyami-teg-a-dlya-sozdaniya-ssylok.html" \o "HTML теги вставки картинки Img"


Допустим, что вы используете для написания статей визуальный редактор, позволяющий не задумываться, каким именно образом прописываются теги картинок и гиперссылок в html коде. Но дело в том, что не один визуальный редактор не является идеальным и зачастую, для исправления очередного бага в оформлении текста статьи, просто необходимо будет перейти в режим html редактора и внести изменения непосредственно в сами теги рисунков и гиперссылок.
Если вы будете знать, как устроены теги и атрибуты, позволяющие вставлять в HTML документ картинки и ссылки, то это может сильно упростить вам жизнь и сэкономить время. Тем более, что изучить десяток самых распространенных тегов и их атрибутов не составит труда. Реально используемых при современной блочной верстке (Html Div) тегов осталось не так уж и много, ну и конечно же, теги вставки ссылок и картинок, являются одними из самых распространенных и часто используемых.
С другой стороны, в оформлении используемого вами шаблона также активно применяются те же самые основные html теги — вставки ссылок, картинок, контейнеры, списки (UL, OL, LI, DL), различные формы html (Form, Input, Button, Checked, Value) и таблицы (Tr, Th, Td, Table). И следовательно, для того, что бы понимать структуру шаблона (шаблоны Joomla, темы WordPress) и при необходимости вносить в него изменения, опять же необходимо знание хотя бы небольшого количества html тегов и атрибутов. Поверьте, потраченное на это время с лихвой окупится в дальнейшем. Ну, будем считать, что я вас убедил в необходимости знакомства с языком html и пора переходить непосредственно к самим html тегам.
Как вставить картинку — html теги Img
Все объявленияЯндексДиректРаскрутка сайта в Казани!1 место в SEO-рейтингах. Более 1500 успешных проектов.Оптимизация в подарок
Адрес и телефон  ·  www.demis.ru  ·  Казань
Для вставки картинок на страницу служит html тег Img. Представленная ниже картинка вставлена с помощью следующего кода тега Img:
1 <Img src="https://ktonanovenkogo.ru/image/finik.jpg" Width="200"Height="150">
Атрибут Src html тега Img позволяет указать имя и место хранения файла изображения. При этом может быть указана относительная или абсолютная ссылка на файл с картинкой. Пути задаются с помощью символа '/', который служит разделителем между названиями папок, в которых хранятся файлы рисунков.
Абсолютный путь в html теге Img будет начинаться с http://vash_sait.ru (для моего блога — http://ktonanovenkogo.ru). Дальше, используя '/' для разделения имен папок, прописывается полный путь до файла картинки, заканчиваясь в конце именем и расширением самого файла картинки. Например,http://ktonanovenkogo.ru/image/finik.jpgОтносительный путь в html теге Img задается с помощью определения относительного пути от исходной папки, в которой лежит файл самого HTML документа, из которой вы пытаетесь открыть изображение, до файла картинки. Если файл картинки находится на сервере в той же папке, что и HTML документ, из которого к нему обращаются, то путь к нему указывать не нужно — требуется указать только имя файла с картинкой (сохраняя регистр букв).
Если файл изображения находится на том же сервере, но в другом каталоге, требуется указать путь к файлу от каталога, где находится HTML документ, из которого к нему обращаются (в примере, показанном выше, используется как раз относительный путь до файла картинки — image/finik.jpg).Html тег Img — задаем ширину и высоту изображения с помощью атрибутов Width и Height для ускорения загрузки сайта
Html атрибуты Width и Height позволяют задать размер области (ширину и высоту соответственно), которая будет отводиться на странице под данное изображение. Эти атрибуты вставляются внутри тега Img, например, так:
1 <Img src="https://ktonanovenkogo.ru/image/finik.jpg" Width="200"Height="150">
Если эта область будет не соответствовать реальному размеру картинки, которую вы хотите вставить, то рисунок будет соответственно растянут или сужен, до заданного в html теге Img размера. Тем не менее, не следует использовать это способ, скажем, для уменьшения размера вставляемого в Html документ рисунка. Ведь вес рисунка по-прежнему останется большой, а это будет замедлять загрузку страницы с этим рисунком.
Лучше предварительно изменить размер картинки в графическом редакторе, а уже затем вставлять картинки в Html документ через любой удобный вам Html редактор. Также, при сохранении рисунка в графическом редакторе следует обращать внимание на итоговый вес рисунка. Он не должен быть слишком большой. Иногда лучше немного пожертвовать качеством изображения (благо, что при небольших размерах картинки это будет практически не заметно в Html документе) для уменьшения итогового веса графического файла.
Используйте при сохранении рисунков компактные форматы типа GIF (для вставки схематических картинок) или JPG (для вставки фотографий). Html атрибуты Width и Height, в отличии от атрибута Srс (единственный обязательный атрибут тега Img), являются необязательными. Многие их просто не указывают, но они, тем не менее, позволяют незначительно ускорить загрузку документа с изображениями. Т.к. в комментариях появился вопрос от уважаемого Максима о том, как это происходит и с чем это связано, то я поясню.
Дело в том, что если браузер не находит атрибуты Width и Height внутри html тега Img, то ему потребуется время на то, чтобы узнать размер картинки, загрузить само изображение и только после этого продолжить загружать Html документ. В случае же когда вы прописали атрибуты Height и Width для тега Img, браузер автоматически резервирует место под картинку указанных в этих атрибутах размеров и продолжает загружать веб-страницу дальше.
Если изображения, выводимые на данную страницу очень тяжелые и их очень много, то вставка в html тег Img всех этих картинок атрибутов Height и Width позволит пользователям приступить к чтению текста сайта, в то время как изображения еще будут загружаться.
Также, если вы не укажете атрибуты Width и Height внутри html тега Img, то может возникнуть ситуация, когда при маленькой картинке и очень длинном альтернативном тексте (задается атрибутом Alt в теге Img, об этом речь пойдет ниже), до того как загрузится изображение, временно произойдет сдвиг дизайна сайта, т.к. длинный альтернативный текст из атрибута Alt будет занимать столько места, сколько ему понадобится.
В случае же использования атрибутов Width и Height внутри html тега Img, место для выведение альтернативного текста будет ограничено размерами, заданными в атрибутах размера изображения Width и Height. По большей части, именно из-за этого я стараюсь прописывать атрибуты Width и Height в теге Img.Атрибуты Alt и Title в html теге Img
Все объявленияЯндексДиректСоздай свой сайт самостоятельно!Бесплатные видеоуроки по созданию сайта. Эффективно и быстро! Узнай сейчас!
master-css.com
Очень полезными, с точки зрения внутренней поисковой оптимизации сайта, являются атрибуты Alt и Title для html тега Img. Более подробно об использовании подобранных в Яндексе ключевых слов вы можете прочитать в статье Продвижение и раскрутка сайта самостоятельно или в публикации Как раскрутить сайт. Первый из них задает, так называемый, альтернативный текст для изображения. Этот текст вы сможете увидеть, если отключите показ картинок в вашем браузере. Атрибут Alt для тега Img и предназначен для этого – рассказать поисковым системам о том, что за рисунок здесь должен был бы быть.Атрибут Title для тега Img предназначен для информирования пользователя о содержании картинки.
Содержимое атрибута Title для тега Img показывается во всплывающей строке, если пользователь подведет мышь к рисунку. Оба этих атрибута для html тега Img (если вы их прописали) позволяют включить изображения вашего веб-проекта впоиск по картинкам Яндекс и Google (а возможно и еще каких-то поисковиков). Поэтому не стоит пренебрегать этой возможность и в обязательном порядке прописывать атрибуты Alt и Title для html тега Img. Оформление ваших изображений должно быть примерно таким:
1 <Img src="https://ktonanovenkogo.ru/image/finik.jpg" Width="200"Height="150" Alt="Здесь нужно прописать ключевые слова, с помощью которых вы хотите привлечь целевых посетителей на ваш сайт с поиска по картинкам"Title=" Здесь нужно прописать ключевые слова, с помощью которых вы хотите привлечь целевых посетителей на ваш сайт с поиска по картинкам ">
На самом деле атрибутов, которые могут быть использованы в html теге Img, достаточно много и вы можете посмотреть их все хотя бы здесь. Но использовать на практике вы будете скорей всего лишь перечисленные мной в этой статье.
Еще раз напоминаю о правилах написания html тегов. После открывающейся треугольной скобки, обязательно без пробела, пишется название тега, затем, через пробел, пишет название атрибута, допустимого для этого html тега. После названия атрибута, без пробела, ставится знак равно и в кавычках пишется параметр атрибута (например, ширина в пикселях для атрибута Width). Следующий атрибут внутри html тега отделяется от предыдущего атрибута пробелом. В конце html тега ставится закрывающая треугольная скобка. Обращаю ваше внимание, что html тег Img не является парным, т.е. у него нет закрывающего тега.
В идеале, примерно так должны быть оформлены все картинки, используемые на вашем веб-проекте. Такого вида можно добиться и не правя для каждого изображения html код вручную. Визуальные редакторы различных CMS (Joomla, WordPress и др.) позволяют задать атрибуты для html тега Img в удобном для пользователя графическом интерфейсе, но после пробной настройки обязательно проверьте html код (в любом визуальном редакторе можно переключиться на показ html кода статьи). Действительно ли все прописывается именно так, как нужно, потому как не всегда сразу понятно, какое именно поле в визуальном редакторе соответствует тому или иному атрибуту html кода.Создаем гиперссылки с помощью html тега ссылки A
Ссылка — один из основных элементов организации Html документа. Без них вебстраница была бы просто страницей. Ссылки создаются при помощи html тега ссылки А. Обязательным атрибутом html тега ссылки А является атрибут Href. Он задает URL ресурса, куда должен перейти пользователь, щелкнув по данной гиперссылке.
Ссылка может вести как на внутреннюю страницу вашего же сайта (очень важный момент внутренней оптимизации сайта связан именно с внутренней перелинковкой страниц), так и на страницу другого проекта. Html тег ссылки A является парным и соответственно имеет закрывающий тег. Текст ссылки (анкор)размещается между открывающим и закрывающим html тегами ссылки A. Пример ссылки:
1 <a href="http://ktonanovenkogo.ru">Текст ссылки или анкор (если ссылка используется для внутренней перелинковки, то этот текст должен содержать ключевые слова, по которым вы хотите продвигать статью, на которую ведет эта ссылка) </a>
Поисковые системы анализируют не только сам текст ссылки (анкор ссылки), но и слова окружающие ссылку. Это следует учитывать при размещении ссылок на свой сайт (обратных ссылок на сайт) на других ресурсах (постовые, платные ссылки). Для того, чтобы ссылка выглядела более натурально, можно часть текста вынести за пределы ссылки, например:
1 <a href="http://ktonanovenkogo.ru">Текст ссылки</a> (если ссылка используется для внутренней перелинковки, то этот текст должен содержать ключевые слова, по которым вы хотите продвигать статью, на которую ведет эта ссылка)
Target _blank ( в новом окне) для html тега A
Все объявленияЯндексДиректРаскрутка сайтов в Казани!Раскрутка сайта в Яндекс и Google. Цены от 5000 руб. Офис в Казани!
Адрес и телефон  ·  goldexmedia.ru  ·  Казань
Ну, ладно, это мы опять отвлеклись на поисковую оптимизацию. Вернемся снова к тегам. Для html тега ссылки A имеется один очень нужный атрибут, который позволит открывать страницу, на которую ведет данная ссылка в новом окне. Это может понадобиться если вы с одной своей страницы ссылаетесь на множество внешних Html документов. В этом случае посетителю вашего сайта было бы удобнее, чтобы ваша страница оставалась всегда открытой.
Это атрибут html тега ссылки Target, а параметр этого атрибута, позволяющий открывать страницу в новом окне, называется _BLANK. Если атрибут Target не задан в html теге ссылки A, то ссылка будет открываться в этом же окне. Пример использования атрибута Target в теге ссылки A:
1 <a href="http://ktonanovenkogo.ru" Target="_blank">Текст ссылки (если ссылка используется для внутренней перелинковки, то этот текст должен содержать ключевые слова, по которым вы хотите продвигать статью, на которую ведет эта ссылка) </a>
Обратите внимание, что порядок следования атрибутов внутри html тегов никак не регламентирован. С таким же успехом можно написать:
1 <a Target="_blank" href="http://ktonanovenkogo.ru">Текст ссылки (если ссылка используется для внутренней перелинковки, то этот текст должен содержать ключевые слова, по которым вы хотите продвигать статью, на которую ведет эта ссылка) </a>
Ссылка с картинки (изображения) в html теге A
В качестве анкора для html тега ссылки, вместо текста, может использоватьсяизображение. В этом случае html тег Img заключается в открывающий и закрывающий теги ссылки A:1 <a href="http://ktonanovenkogo.ru" Target="_blank"><Img src="https://ktonanovenkogo.ru/image/finik.jpg" Width="200" Height="150"> </a>

Есть мнение, что поисковики выше ценят ссылки с картинки, а по некоторым данным выходит обратное. Но при использовании такого типа ссылки нет текста ссылки (анкора), в который можно было бы вставить нужные ключевые слова. В этом случае можно использовать атрибут Title для html тега ссылки A.
1 <a href="http://ktonanovenkogo.ru" Target="_blank" Title="Здесь нужно прописать ключевые слова, по которым вы хотите продвинуть статью, на которую ведет эта ссылка"><Img src="https://ktonanovenkogo.ru/image/finik.jpg" Width="200" Height="150"> </a>

Этот атрибут Title можно использовать и в случае использования обычного текстового анкора для Html тега ссылки. В этом случае, информация прописанная в атрибуте Title тега ссылки A будет видна, если подвести курсор мыши к гиперссылке.
1 <a href="http://ktonanovenkogo.ru" Target="_blank" Title="Здесь можно прописать фразу, которая будет подсказывать пользователям, куда они перейдут, щелкнув по этой ссылке" >Здесь нужно прописать ключевые слова, по которым вы хотите продвинуть статью, на которую ведет эта гиперссылка </a>Здесь нужно прописать ключевые слова, по которым вы хотите продвинуть статью, на которую ведет эта ссылкаСоздание якорей (атрибут NAME) и хеш-ссылок с помощью Html тега ссылки A
Все объявленияЯндексДиректЕсть свой бизнес, но нет сайта?Зарегистрируйтесь и получите сайт с каталогом товаров и услуг. Бесплатно!
tiu.ru
Еще один интересный атрибут html тега ссылки NAME, который довольно широко используется для создания так называемых якорей ссылок, на которые потом можно будет ссылаться с помощью так называемых хеш-ссылок. Немного запутанно, но сейчас попробую внести ясность. Допустим, что вам нужно сослаться на конкретное место в тексте, где идет обсуждение определенного вопроса.
Если поставить простую гиперссылку на эту статью, то после перехода по ней, статья откроется в самом ее начале и пользователю придется самому отыскивать в ней то место, на котором вы хотели сконцентрировать внимание. Так вот с помощью якорей и хеш-ссылок можно сделать так, чтобы статья открывалась именно на том месте (в этом месте текста нужно будет вставить якорь ссылки), где вы задумали и пользователю не придется перелопачивать лишний материал.
Для реализации описанного способа создания гиперссылок в Html документе, нужно предварительно вставить якорь html ссылки в ту статью, на которую будет вести хеш-ссылка. Якорь гиперссылки представляет из себя конструкцию напоминающую обычную ссылку, но при этом он остается невидимым для посетителя. Выглядит он так:
1 <a name=”imy_metki”></a>
Т.е. получается, что якорь состоит только из открывающего и закрывающего тега ссылки А, при этом якорь ссылки не содержит анкора и имеет один единственный обязательный атрибут NAME html тега ссылки A. Параметром этого атрибута будет служить метка, название которой вы задаете сами. Эта метка будет использоваться при создании хеш-ссылки.
Итак, после того, как мы расставили в тексте статьи все необходимые якоря гиперссылок, можно приступать к созданию хеш-ссылок, которые будут ссылаться на места в тексте статьи, заранее помеченные якорями ссылки. Гиперссылка создается стандартным для Html образом, за исключением того, что в конце URL, который прописывается в атрибуте Href, ставится знак решетки (знак диеза или хеш-символ), а после него имя метки того якоря ссылки, который стоит в требуемом месте текста статьи. Хеш-ссылка будет выглядеть примерно так:
1 <a Target="_blank" href="http://ktonanovenkogo.ru/vokrug-da-okolo/programs/kak-nastroit-dostup-k-sajtu-po-ftp-s-pomoshhyu-programmy-filezilla.html#redfaila">Лучший FTP клиент FileZilla</a>
Лучший FTP клиент FileZillaС помощью хеш-ссылки вы перейдете не только на страницу “Как настроить доступ к сайту по FTP с помощью программы FileZilla ”, но также браузер автоматически прокрутит окно до нужного месте в тексте (в данном случае до вопроса о редактировании файлов сайта с помощью FileZilla).
Если якорь ссылки находится в том же Html документе, что и хеш-ссылка, то можно не указывать в гиперссылке URL этой вебстранице, а указать только якорь ссылки.
1 <a Target="_blank" href="#11">Вопросы по верстке, html, CSS, PHP, MySql</a>
Пример использования хеш-ссылок вы можете посмотреть в действии на странице FAQ (Вопросы и Ответы) этого блога. Хеш-ссылки c этой вебстраницы ведут на различные места в текстах статей, где обсуждаются те или иные вопросы. Без использования хеш-ссылок создать такую вебстраницу было бы невозможно.
15 html. создание таблиц
Для создания таблицы служит тэг <TABLE>. Как известно таблица состоит из строк, а строки, в свою очередь состоят из ячеек. Для определения строк служит тэг <TR>, для создания ячеек - <TH>, <TD>.
Тэг <TH> используется для создания ячеек с заголовками.
Тэг <TD> - для обыкновенных ячеек с данными.
Содержание ячеек заголовков отображается полужирным шрифтом и выравнивается по центру.
В чем же "прелесть" таблиц и почему они нашли такое широкое применение в сайтостроении? Дело в том, что, используя таблицы, можно сделать аккуратную компоновку информации в пределах Вэб-страницы, добиться точного расположения того или иного фрагмента страницы, будь то текст, графика или гиперссылка. Например, используя таблицу, можно легко добиться отображения текста в нескольких колонках, подобно газетной публикации.
Пример:
HTML-код:
<table border="1">
 <tr>
  <td>1</td>
  <td>2</td>
 </tr>
 <tr>
  <td>3</td>
  <td>4</td>
 </tr>
 <tr>
  <td>5</td>
  <td>6</td>
 </tr>
</table> Отображение в браузере:
1 2
3 4
5 6
Обрамление таблицы документа html
Для того, чтобы сделать видимой границы таблицы, служит атрибут BORDER тэга <TABLE>.
Определяя рамку таблицы, надо указать толщину ее внешних линий в пикселях. Чтобы задать толщину разграничивающих линий внутри таблицы, необходимо воспользоваться атрибутом CELLSPACING.
По умолчанию браузер отображает рамку таблицы темно-серым цветом. Чтобы изменить цвет рамки надо применить атрибут BORDERCOLOR.
Пример:
HTML-код:
<table border="2" cellspacing="5" bordercolor="#0ff00f">
 <tr>
  <td>1</td>
  <td>2</td>
 </tr>
 <tr>
  <td>3</td>
  <td>4</td>
 </tr>
 <tr>
  <td>5</td>
  <td>6</td>
 </tr>
</table> Отображение в браузере:
1 2
3 4
5 6
Заголовок таблицы документа html
Для создания заголовка таблицы служит тэг <CAPTION>.
По умолчанию браузер располагает заголовок таблицы по центру над ней. При помощи атрибута ALIGN со значением bottom можно разместить заголовок под таблицей.
Следует сказать, что стандарт HTML не позволяет ставить одной таблице несколько заголовков.
Пример:
HTML-код:
<table border="1">
<caption> Заголовок таблицы </caption>
 <tr>
  <td>1</td>
  <td>2</td>
 </tr>
</table> Отображение в браузере:
Заголовок таблицы
1 2
Группирование столбцов документа html
Для группирования столбцов таблицы служат тэги <COLGROUP> и <COL>.
Дескриптор <COLGROUP> создает структурную группу столбцов, которая выделяет множество логически однородных ячеек. Так одна структурная группа может охватывать ячейки заголовков столбцов, а другая - ячейки, содержащие данные.
Дескриптор <COL> предназначен для формирования неструктурных групп столбцов, которые делят таблицу на разделы, не имеющих отношения к структуре. Это удобно в том случае, когда не все столбцы содержат информацию одного типа.
Пример:
HTML-код:
<table border="1">
<colgroup span="1" style="color:red"></colgroup>
<colgroup span="2">
 <tr>
  <th>Товар</th>
  <th>Цена</th>
  <th>Кол-во</th>
 </tr>
 <tr>
  <th>Гайка</th>
  <td>20р</td>
  <td>50</td>
 </tr>
 <tr>
  <th>Болт</th>
  <td>30р</td>
  <td>80</td>
 </tr>
</table>
<br>
<table border="1">
<col span="1" style="color:green">
<col span="2" style="color:red">
 <tr>
  <th>Товар</th>
  <th>Цена</th>
  <th>Кол-во</th>
 </tr>
 <tr>
  <th>Гайка</th>
  <td>20р</td>
  <td>50</td>
 </tr>
 <tr>
  <th>Болт</th>
  <td>30р</td>
  <td>80</td>
 </tr>
</table> Отображение в браузере:
Товар Цена Кол-во
Гайка 20р 50
Болт 30р 80
Товар Цена Кол-во
Гайка 20р 50
Болт 30р 80
Группирование строк документа html
Для группирования строк таблицы служат тэги <THEAD>, <TBODY>, <TFOOT>.
<THEAD> - нужен для создания группы заголовков для столбцов таблицы. Этот дескриптор допускается использовать в пределах таблицы только одни раз.
<TBODY> - применяется для создания одной или нескольких групп строк таблицы, содержащих основные данные.
<TFOOT> - позволяет создать группу строк для представления информации о суммах или итогах, располагаемую в нижней части таблицы. Этот дескриптор допускается использовать в пределах таблицы только одни раз. Вовсе не обязательно создавать группы строк таблицы всех трех типов.
Пример:
HTML-код:
<table border="1">
<thead style="color:green">
 <tr>
  <th>Товар</th>
  <th>Цена</th>
  <th>Кол-во</th>
 </tr>
</thead>
 <tr>
  <th>Гайка</th>
  <td>20р</td>
  <td>50</td>
 </tr>
 <tr>
  <th>Болт</th>
  <td>30р</td>
  <td>80</td>
 </tr>
<tfoot>
 <tr>
  <td colspan="3" align="center">Итоговая строка</td>
 </tr>
</tfoot>
</table> Отображение в браузере:
Товар Цена Кол-во
Гайка 20р 50
Болт 30р 80
Итоговая строка
16 MySQL.Установка и настройка серверной части
Пора заняться установкой MySQL-сервера, поскольку много чего будем хранить именно в этой базе данных.
Список необходимых опций сборки добавим в /etc/make.conf:
# Путь к коллекции портовPORTSDIR?= /usr/ports# Версия MySQL сервераDEFAULT_MYSQL_VER=50
# Oпции для сборки клиента.if ${.CURDIR} == ${PORTSDIR}/databases/mysql50-client
# Кодировка клиента по умолчанию.WITH_CHARSET=cp1251
# Коллэйшн или сравнение.WITH_COLLATION=cp1251_bin
# В общем, если эта опция действительно хоть что-то# оптимизирует, то странно что она по дефолту не включена,# а предлагается опционально.BUILD_OPTIMIZED=yes
.endif
# Oпции для сборки сервера.if ${.CURDIR} == ${PORTSDIR}/databases/mysql50-server
# Кодировка сервера по умолчанию.WITH_CHARSET=cp1251
# Какие кодировки компилить еще.WITH_XCHARSET=all
# Кодировка коллэйшн.WITH_COLLATION=cp1251_bin
# Вкомпилить ли SSL. Есть смысл, если к MySQL-серверу# разрешены коннекты откуда либо, кроме как с локалхоста.WITHOUT_OPENSSL=yes
# Если следующую опцию поставить в yes, то MySQL будет работать# в несколько потоков (только для i386)#WITH_LINUXTHREADS=yes# У меня amd64, соответственно:WITHOUT_LINUXTHREADS=yes
# Тоже че-то связано с многопоточностью сервера.# Чего не знаем - нетрогаем.#WITH_PROC_SCOPE_PTH=yes
# Как и с клиентом, типа "оптимизируемся".BUILD_OPTIMIZED=yes# Сборка статического варианта mysql демона. Я так понимаю, что# статический демон не станет подгружать дополнительные# библиотеки, потому что уже будет собран с ними же. Но где# тогда здесь выигрыш в производительности? Хоть в случае с# динамической версией - будут тратиться определенные ресурсы# на подгрузку библиотек; хоть в случае со статиком - он будет# эти библиотеки постоянно удерживать в памяти...# Эту опцию нельзя применять если у Вас WITH_OPENSSL=yesBUILD_STATIC=yes# Поддержка INNODB таблиц. Кому не надо, можете отключить.WITH_INNODB=yes
# Следущая опция - это для тех, кто использует кластера MySQL.WITHOUT_NDB=yes
.endif
Приступаем непосредственно к инсталляции серверной части (клиентскую часть подтянет автоматически).
# cd /usr/ports/databases/mysql50-server# make install clean# rehash
Добавляем в /etc/rc.conf строку о необходимости запуска MySQL-сервера:
# echo '# MySQL' >> /etc/rc.conf# echo 'mysql_enable="YES"' >> /etc/rc.conf
Запускаем сервер
# sh /usr/local/etc/rc.d/mysql-server start
Меняем пароль для пользователя root в MySQL (хотя, обычно, завожу пользователя с полными привилегиями, а запись пользователя root удаляю полностью):
# mysqladmin -u root password new_passwd_here
Теперь следует отредактировать конфигурационный файл mysql, который называется my.cnf. Положить его можно в любую из этих папок: /var/db/mysql/, /etc/, /usr/local/etc/. MySQL при запуске проверит его наличие во всех этих каталогах. Если конфигурациооный файл отсутствует – можно скопировать доступный пример и при необходимости отредактировать его (доступны примеры для нагруженного сервера, для сервера со средней нагрузкой и для ненагруженного сервера)
# cp /usr/local/share/mysql/my-medium.cnf /var/db/mysql/my.cnf
Для решения проблем с кодировкой кирилицы, добавим в секцию [client]:
default-character-set=cp1251
И, соответственно, в секцию [mysqld]:
default-character-set=cp1251character-set-server = cp1251collation-server = cp1251_general_ci
Также, для удобства, можете изменить параметры логгирования. Для этого в секцию [mysqld] файла /var/db/mysql/my.cnf добавляем строку log=/var/log/mysql.log
Также необходимо создать сам файл логов:
# touch /var/log/mysql.log# chown mysql:mysql /var/log/mysql.log
Перегружаем MySQL для того, чтобы новые настройки вступили в силу:
# sh /usr/local/etc/rc.d/mysql-server restart
Кстати... Если уж возьметесь писать логи MySQL - ОБЯЗАТЕЛЬНО настройте ротацию логов, а не то лог-файл очень скоро разрастется до неимоверных размеров (вплоть до того, что не останется свободного места на разделе. Например, будем архивировать лог раз в неделю. Для этого в /etc/newsyslog.conf необходимо добавить следующую строку:
/var/log/mysql.log      mysql:mysql     600  2     *    $W6D0   JB     /var/db/mysql/hostname.pid
Обратите внимание: pid-файл будет уникальный (зависит от от имени сервера).
Дальше создадим пользователя, с правами суперпользователя в БД MySQL:
GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost' IDENTIFIED BY 'user_pass' WITH GRANT OPTION;
Теперь еще осталось удалить остальных пользователей, которых mysql создает по-умолчанию.
# mysql -u username -pEnter password:Welcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 2Server version: 5.0.84-log FreeBSD port: mysql-server-5.0.84
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> USE mysql;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -A
Database changedmysql> DELETE FROM user WHERE NOT user='username';Query OK, 4 rows affected (0.00 sec)
mysql> quit
17 склады данных и система оперативно-аналитической обработки данных
Современный уровень развития аппаратных и программных средств с некоторых пор сделал возможным повсеместное ведение баз данных оперативной информации на разных уровнях управления. В процессе своей деятельности промышленные предприятия, корпорации, ведомственные структуры, органы государственной власти и управления накопили большие объемы данных. Они хранят в себе большие потенциальные возможности по извлечению полезной аналитической информации, на основе которой можно выявлять скрытые тенденции, строить стратегию развития, находить новые решения.
В последние годы в мире оформился ряд новых концепций хранения и анализа корпоративных данных:
1) Хранилища данных, или Склады данных (Data Warehouse) [15, 5];
2) Оперативная аналитическая обработка (On-Line Analytical Processing, OLAP) [11, 6, 10];
3) Интеллектуальный анализ данных - ИАД (Data Mining) [17, 19, 23, 3].
Технологии OLAP тесно связаны с технологиями построения Data Warehouse и методами интеллектуальной обработки - Data Mining. Поэтому наилучшим вариантом является комплексный подход к их внедрению.
Способы аналитической обработки данных
Для того чтобы существующие хранилища данных способствовали принятию управленческих решений, информация должна быть представлена аналитику в нужной форме, то есть он должен иметь развитые инструменты доступа к данным хранилища и их обработки.
Очень часто информационно-аналитические системы, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические системы называются в литературе Информационными системами руководителя (ИСР), или Executive Information Systems (EIS) [3]. Они содержат в себе предопределенные множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы к имеющимся данным, которые могут возникнуть при принятии решений. Результатом работы такой системы, как правило, являются многостраничные отчеты, после тщательного изучения которых у аналитика появляется новая серия вопросов. Однако каждый новый запрос, непредусмотренный при проектировании такой системы, должен быть сначала формально описан, закодирован программистом и только затем выполнен. Время ожидания в таком случае может составлять часы и дни, что не всегда приемлемо. Таким образом, внешняя простота статических СППР, за которую активно борется большинство заказчиков информационно-аналитических систем, оборачивается катастрофической потерей гибкости.
Динамические СППР, напротив, ориентированы на обработку нерегламентированных (ad hoc) запросов аналитиков к данным. Наиболее глубоко требования к таким системам рассмотрел E. F. Codd в статье [11], положившей начало концепции OLAP. Работа аналитиков с этими системами заключается в интерактивной последовательности формирования запросов и изучения их результатов.
Но динамические СППР могут действовать не только в области оперативной аналитической обработки (OLAP); поддержка принятия управленческих решений на основе накопленных данных может выполняться в трех базовых сферах [21].
Сфера детализированных данных. Это область действия большинства систем, нацеленных на поиск информации. В большинстве случаев реляционные СУБД отлично справляются с возникающими здесь задачами. Общепризнанным стандартом языка манипулирования реляционными данными является SQL. Информационно-поисковые системы, обеспечивающие интерфейс конечного пользователя в задачах поиска детализированной информации, могут использоваться в качестве надстроек как над отдельными базами данных транзакционных систем, так и над общим хранилищем данных.
Сфера агрегированных показателей. Комплексный взгляд на собранную в хранилище данных информацию, ее обобщение и агрегация, гиперкубическое представление и многомерный анализ являются задачами систем оперативной аналитической обработки данных (OLAP) [11, 10, 6]. Здесь можно или ориентироваться на специальные многомерные СУБД [6], или оставаться в рамках реляционных технологий. Во втором случае заранее агрегированные данные могут собираться в БД звездообразного вида, либо агрегация информации может производиться на лету в процессе сканирования детализированных таблиц реляционной БД.
Сфера закономерностей. Интеллектуальная обработка производится методами интеллектуального анализа данных (ИАД, Data Mining) [19, 25], главными задачами которых являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил, которые объясняют найденные аномалии и/или прогнозируют развитие некоторых процессов.
Некоторые авторы [21] выделяют в отдельную область анализ отклонений (например, в целях отслеживания колебаний биржевых курсов). В качестве примера может быть приведен статистический анализ рядов динамики. Чаще, однако, этот тип анализа относят к области закономерностей.
Полная структура информационно-аналитической системы, построенной на основе хранилища данных, показана на рис. 1. В конкретных реализациях отдельные компоненты этой схемы часто отсутствуют.

Рис. 1. Полная структура корпоративной информационно-аналитической системы (ИАС)
Оперативная аналитическая обработка данных
В основе концепции OLAP лежит принцип многомерного представления данных. В 1993 году в статье [11] E. F. Codd рассмотрел недостатки реляционной модели, в первую очередь указав на невозможность "объединять, просматривать и анализировать данные с точки зрения множественности измерений, то есть самым понятным для корпоративных аналитиков способом", и определил общие требования к системам OLAP, расширяющим функциональность реляционных СУБД и включающим многомерный анализ как одну из своих характеристик.
В большом числе публикаций аббревиатурой OLAP обозначается не только многомерный взгляд на данные, но и хранение самих данных в многомерной БД [6]. Вообще говоря, это неверно, поскольку сам Кодд отмечает, что "Реляционные БД были, есть и будут наиболее подходящей технологией для хранения корпоративных данных. Необходимость существует не в новой технологии БД, а, скорее, в средствах анализа, дополняющих функции существующих СУБД и достаточно гибких, чтобы предусмотреть и автоматизировать разные виды интеллектуального анализа, присущие OLAP". Такая путаница приводит к противопоставлениям наподобие "OLAP или ROLAP", что не совсем корректно, поскольку ROLAP (реляционный OLAP) на концептуальном уровне поддерживает всю определенную термином OLAP функциональность. Более предпочтительным кажется использование для OLAP на основе многомерных СУБД специального термина MOLAP, как это и сделано в [4, 9].
По Кодду, многомерное концептуальное представление (multi-dimensional conceptual view) представляет собой множественную перспективу, состоящую из нескольких независимых измерений, вдоль которых могут быть проанализированы определенные совокупности данных. Одновременный анализ по нескольким измерениям определяется как многомерный анализ. Каждое измерение включает направления консолидации данных, состоящие из серии последовательных уровней обобщения, где каждый вышестоящий уровень соответствует большей степени агрегации данных по соответствующему измерению. Так, измерение Исполнитель может определяться направлением консолидации, состоящим из уровней обобщения "предприятие - подразделение - отдел - служащий". Измерение Время может даже включать два направления консолидации - "год - квартал - месяц - день" и "неделя - день", поскольку счет времени по месяцам и по неделям несовместим. В этом случае становится возможным произвольный выбор желаемого уровня детализации информации по каждому из измерений. Операция спуска (drilling down) соответствует движению от высших ступеней консолидации к низшим; напротив, операция подъема (rolling up) означает движение от низших уровней к высшим (рис. 2).

Рис. 2. Измерения и направления консолидации данных
Требования к средствам оперативной аналитической обработки
Кодд определил 12 правил, которым должен удовлетворять программный продукт класса OLAP (табл. 1).
Таблица 1 Правила оценки программных продуктов класса OLAP
 
1. Многомерное концептуальное представление данных (Multi-Dimensional Conceptual View) Концептуальное представление модели данных в продукте OLAP должно быть многомерным по своей природе, то есть позволять аналитикам выполнять интуитивные операции "анализа вдоль и поперек" ("slice and dice"), вращения (rotate) и размещения (pivot) направлений консолидации.
2. Прозрачность (Transparency) Пользователь не должен знать о том, какие конкретные средства используются для хранения и обработки данных, как данные организованы и откуда берутся.
3. Доступность (Accessibility) Аналитик должен иметь возможность выполнять анализ в рамках общей концептуальной схемы, но при этом данные могут оставаться под управлением оставшихся от старого наследства СУБД, будучи при этом привязанными к общей аналитической модели. То есть инструментарий OLAP должен накладывать свою логическую схему на физические массивы данных, выполняя все преобразования, требующиеся для обеспечения единого, согласованного и целостного взгляда пользователя на информацию.
4. Устойчивая производительность (Consistent Reporting Performance) С увеличением числа измерений и размеров базы данных аналитики не должны столкнуться с каким бы то ни было уменьшением производительности. Устойчивая производительность необходима для поддержания простоты использования и свободы от усложнений, которые требуются для доведения OLAP до конечного пользователя.
5. Клиент - серверная архитектура (Client-Server Architecture) Большая часть данных, требующих оперативной аналитической обработки, хранится в мэйнфреймовых системах, а извлекается с персональных компьютеров. Поэтому одним из требований является способность продуктов OLAP работать в среде клиент-сервер. Главной идеей здесь является то, что серверный компонент инструмента OLAP должен быть достаточно интеллектуальным и обладать способностью строить общую концептуальную схему на основе обобщения и консолидации различных логических и физических схем корпоративных баз данных для обеспечения эффекта прозрачности.
6. Равноправие измерений (Generic Dimensionality) Все измерения данных должны быть равноправны. Дополнительные характеристики могут быть предоставлены отдельным измерениям, но поскольку все они симметричны, данная дополнительная функциональность может быть предоставлена любому измерению. Базовая структура данных, формулы и форматы отчетов не должны опираться на какое-то одно измерение.
7. Динамическая обработка разреженных матриц (Dynamic Sparse Matrix Handling) Инструмент OLAP должен обеспечивать оптимальную обработку разреженных матриц. Скорость доступа должна сохраняться вне зависимости от расположения ячеек данных и быть постоянной величиной для моделей, имеющих разное число измерений и различную разреженность данных.
8. Поддержка многопользовательского режима (Multi-User Support) Зачастую несколько аналитиков имеют необходимость работать одновременно с одной аналитической моделью или создавать различные модели на основе одних корпоративных данных. Инструмент OLAP должен предоставлять им конкурентный доступ, обеспечивать целостность и защиту данных.
9. Неограниченная поддержка кроссмерных операций (Unrestricted Cross-dimensional Operations) Вычисления и манипуляция данными по любому числу измерений не должны запрещать или ограничивать любые отношения между ячейками данных. Преобразования, требующие произвольного определения, должны задаваться на функционально полном формульном языке.
10. Интуитивное манипулирование данными (Intuitive Data Manipulation) Переориентация направлений консолидации, детализация данных в колонках и строках, агрегация и другие манипуляции, свойственные структуре иерархии направлений консолидации, должны выполняться в максимально удобном, естественном и комфортном пользовательском интерфейсе.
11. Гибкий механизм генерации отчетов (Flexible Reporting) Должны поддерживаться различные способы визуализации данных, то есть отчеты должны представляться в любой возможной ориентации.
12. Неограниченное количество измерений и уровней агрегации (Unlimited Dimensions and Aggregation Levels) Настоятельно рекомендуется допущение в каждом серьезном OLAP инструменте как минимум пятнадцати, а лучше двадцати, измерений в аналитической модели. Более того, каждое из этих измерений должно допускать практически неограниченное количество определенных пользователем уровней агрегации по любому направлению консолидации.
Набор этих требований, послуживших фактическим определением OLAP, следует рассматривать как рекомендательный, а конкретные продукты оценивать по степени приближения к идеально полному соответствию всем требованиям.
Классификация продуктов OLAP по способу представления данных
В настоящее время на рынке присутствует большое количество продуктов, которые в той или иной степени обеспечивают функциональность OLAP. Около 30 наиболее известных перечислены в списке обзорного Web-сервера http://www.olapreport.com/. Обеспечивая многомерное концептуальное представление со стороны пользовательского интерфейса к исходной базе данных, все продукты OLAP делятся на три класса по типу исходной БД.
Самые первые системы оперативной аналитической обработки (например, Essbase компании Arbor Software [11], Oracle Express Server компании Oracle [6]) относились к классу MOLAP, то есть могли работать только со своими собственными многомерными базами данных. Они основываются на патентованных технологиях для многомерных СУБД и являются наиболее дорогими. Эти системы обеспечивают полный цикл OLAP-обработки. Они либо включают в себя, помимо серверного компонента, собственный интегрированный клиентский интерфейс, либо используют для связи с пользователем внешние программы работы с электронными таблицами. Для обслуживания таких систем требуется специальный штат сотрудников, занимающихся установкой, сопровождением системы, формированием представлений данных для конечных пользователей.
Системы оперативной аналитической обработки реляционных данных (ROLAP) позволяют представлять данные, хранимые в реляционной базе, в многомерной форме [13, 14, 22], обеспечивая преобразование информации в многомерную модель через промежуточный слой метаданных. К этому классу относятся DSS Suite компании MicroStrategy, MetaCube компании Informix, DecisionSuite компании Information Advantage и другие. Программный комплекс ИнфоВизор [1], разработанный в России, в Ивановском государственном энергетическом университете, также является системой этого класса. ROLAP-системы хорошо приспособлены для работы с крупными хранилищами. Подобно системам MOLAP, они требуют значительных затрат на обслуживание специалистами по информационным технологиям и предусматривают многопользовательский режим работы.
Наконец, гибридные системы (Hybrid OLAP, HOLAP) разработаны с целью совмещения достоинств и минимизации недостатков, присущих предыдущим классам. К этому классу относится Media/MR компании Speedware [9]. По утверждению разработчиков, он объединяет аналитическую гибкость и скорость ответа MOLAP с постоянным доступом к реальным данным, свойственным ROLAP.
Помимо перечисленных средств существует еще один класс - инструменты генерации запросов и отчетов для настольных ПК, дополненные функциями OLAP или интегрированные с внешними средствами, выполняющими такие функции. Эти хорошо развитые системы осуществляют выборку данных из исходных источников, преобразуют их и помещают в динамическую многомерную БД, функционирующую на клиентской станции конечного пользователя. Основными представителями этого класса являются BusinessObjects одноименной компании [18], BrioQuery компании Brio Technology [7] и PowerPlay компании Cognos [7].
Многомерный OLAP (MOLAP)
В специализированных СУБД, основанных на многомерном представлении данных, данные организованы не в форме реляционных таблиц, а в виде упорядоченных многомерных массивов:
1) гиперкубов (все хранимые в БД ячейки должны иметь одинаковую мерность, то есть находиться в максимально полном базисе измерений) или
2) поликубов (каждая переменная хранится с собственным набором измерений, и все связанные с этим сложности обработки перекладываются на внутренние механизмы системы).
Использование многомерных БД в системах оперативной аналитической обработки имеет следующие достоинства.
В случае использования многомерных СУБД поиск и выборка данных осуществляется значительно быстрее, чем при многомерном концептуальном взгляде на реляционную базу данных, так как многомерная база данных денормализована, содержит заранее агрегированные показатели и обеспечивает оптимизированный доступ к запрашиваемым ячейкам.
Многомерные СУБД легко справляются с задачами включения в информационную модель разнообразных встроенных функций, тогда как объективно существующие ограничения языка SQL делают выполнение этих задач на основе реляционных СУБД достаточно сложным, а иногда и невозможным.
С другой стороны, имеются существенные ограничения.
Многомерные СУБД не позволяют работать с большими базами данных. К тому же за счет денормализации и предварительно выполненной агрегации объем данных в многомерной базе, как правило, соответствует (по оценке Кодда [11]) в 2.5-100 раз меньшему объему исходных детализированных данных.
Многомерные СУБД по сравнению с реляционными очень неэффективно используют внешнюю память. В подавляющем большинстве случаев информационный гиперкуб является сильно разреженным, а поскольку данные хранятся в упорядоченном виде, неопределенные значения удаётся удалить только за счет выбора оптимального порядка сортировки, позволяющего организовать данные в максимально большие непрерывные группы. Но даже в этом случае проблема решается только частично. Кроме того, оптимальный с точки зрения хранения разреженных данных порядок сортировки скорее всего не будет совпадать с порядком, который чаще всего используется в запросах. Поэтому в реальных системах приходится искать компромисс между быстродействием и избыточностью дискового пространства, занятого базой данных.
Следовательно, использование многомерных СУБД оправдано только при следующих условиях.
Объем исходных данных для анализа не слишком велик (не более нескольких гигабайт), то есть уровень агрегации данных достаточно высок.
Набор информационных измерений стабилен (поскольку любое изменение в их структуре почти всегда требует полной перестройки гиперкуба).
Время ответа системы на нерегламентированные запросы является наиболее критичным параметром.
Требуется широкое использование сложных встроенных функций для выполнения кроссмерных вычислений над ячейками гиперкуба, в том числе возможность написания пользовательских функций.
Реляционный OLAP (ROLAP)
Непосредственное использование реляционных БД в системах оперативной аналитической обработки имеет следующие достоинства.
В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.
В случае переменной размерности задачи, когда изменения в структуру измерений приходится вносить достаточно часто, ROLAP системы с динамическим представлением размерности являются оптимальным решением, так как в них такие модификации не требуют физической реорганизации БД.
Реляционные СУБД обеспечивают значительно более высокий уровень защиты данных и хорошие возможности разграничения прав доступа.
Главный недостаток ROLAP по сравнению с многомерными СУБД - меньшая производительность. Для обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработки схемы базы данных и настройки индексов, то есть больших усилий со стороны администраторов БД. Только при использовании звездообразных схем производительность хорошо настроенных реляционных систем может быть приближена к производительности систем на основе многомерных баз данных.
Описанию схемы звезды (star schema) и рекомендациям по ее применению полностью посвящены работы [14, 22, 16]. Ее идея заключается в том, что имеются таблицы для каждого измерения, а все факты помещаются в одну таблицу, индексируемую множественным ключом, составленным из ключей отдельных измерений (рис. 3). Каждый луч схемы звезды задает, в терминологии Кодда, направление консолидации данных по соответствующему измерению.

Рис. 3. Пример схемы "звезды"
В сложных задачах с многоуровневыми измерениями имеет смысл обратиться к расширениям схемы звезды - схеме созвездия (fact constellation schema) и схеме снежинки (snowflake schema) [22]. В этих случаях отдельные таблицы фактов создаются для возможных сочетаний уровней обобщения различных измерений (рис. 4). Это позволяет добиться лучшей производительности, но часто приводит к избыточности данных и к значительным усложнениям в структуре базы данных, в которой оказывается огромное количество таблиц фактов.

Рис. 4. Пример схемы "снежинки" (фрагмент для одного измерения)
Увеличение числа таблиц фактов в базе данных может проистекать не только из множественности уровней различных измерений, но и из того обстоятельства, что в общем случае факты имеют разные множества измерений. При абстрагировании от отдельных измерений пользователь должен получать проекцию максимально полного гиперкуба, причем далеко не всегда значения показателей в ней должны являться результатом элементарного суммирования. Таким образом, при большом числе независимых измерений необходимо поддерживать множество таблиц фактов, соответствующих каждому возможному сочетанию выбранных в запросе измерений, что также приводит к неэкономному использованию внешней памяти, увеличению времени загрузки данных в БД схемы звезды из внешних источников и сложностям администрирования. Частично решают эту проблему расширения языка SQL (операторы "GROUP BY CUBE", "GROUP BY ROLLUP" и "GROUP BY GROUPING SETS"); кроме того, авторы статей [14, 16] предлагают механизм поиска компромисса между избыточностью и быстродействием, рекомендуя создавать таблицы фактов не для всех возможных сочетаний измерений, а только для тех, значения ячеек которых не могут быть получены с помощью последующей агрегации более полных таблиц фактов (рис. 5).

Рис. 5. Таблицы фактов для разных сочетаний измерений в запросе
В любом случае, если многомерная модель реализуется в виде реляционной базы данных, следует создавать длинные и "узкие" таблицы фактов и сравнительно небольшие и "широкие" таблицы измерений. Таблицы фактов содержат численные значения ячеек гиперкуба, а остальные таблицы определяют содержащий их многомерный базис измерений. Часть информации можно получать с помощью динамической агрегации данных, распределенных по незвездообразным нормализованным структурам, хотя при этом следует помнить, что включающие агрегацию запросы при высоконормализованной структуре БД могут выполняться довольно медленно.
Ориентация на представление многомерной информации с помощью звездообразных реляционных моделей позволяет избавиться от проблемы оптимизации хранения разреженных матриц, остро стоящей перед многомерными СУБД (где проблема разреженности решается специальным выбором схемы). Хотя для хранения каждой ячейки используется целая запись, которая помимо самих значений включает вторичные ключи - ссылки на таблицы измерений, несуществующие значения просто не включаются в таблицу фактов.
Интеллектуальный анализ данных
ИАД (Data Mining) - это процесс поддержки принятия решений, основанный на поиске в данных скрытых закономерностей (шаблонов информации). При этом накопленные сведения автоматически обобщаются до информации, которая может быть охарактеризована как знания.
В общем случае процесс ИАД состоит из трёх стадий [19] (рис. 6):
1) выявление закономерностей (свободный поиск);
2) использование выявленных закономерностей для предсказания неизвестных значений (прогностическое моделирование);
3) анализ исключений, предназначенный для выявления и толкования аномалий в найденных закономерностях.
Иногда в явном виде выделяют промежуточную стадию проверки достоверности найденных закономерностей между их нахождением и использованием (стадия валидации).

Рис. 6. Стадии процесса интеллектуального анализа данных
Все методы ИАД подразделяются на две большие группы по принципу работы с исходными обучающими данными [19].
В первом случае исходные данные могут храниться в явном детализированном виде и непосредственно использоваться для прогностического моделирования и/или анализа исключений; это так называемые методы рассуждений на основе анализа прецедентов. Главной проблемой этой группы методов является затрудненность их использования на больших объемах данных, хотя именно при анализе больших хранилищ данных методы ИАД приносят наибольшую пользу.
Во втором случае информация вначале извлекается из первичных данных и преобразуется в некоторые формальные конструкции (их вид зависит от конкретного метода). Согласно предыдущей классификации, этот этап выполняется на стадии свободного поиска, которая у методов первой группы в принципе отсутствует. Таким образом, для прогностического моделирования и анализа исключений используются результаты этой стадии, которые гораздо более компактны, чем сами массивы исходных данных. При этом полученные конструкции могут быть либо "прозрачными" (интерпретируемыми), либо "черными ящиками" (нетрактуемыми).
Две эти группы и примеры входящих в них методов представлены на рис. 7.

Рис. 7. Классификация технологических методов ИАД
Интеграция OLAP и ИАД
Оперативная аналитическая обработка и интеллектуальный анализ данных - две составные части процесса поддержки принятия решений. Но сегодня большинство систем OLAP заостряет внимание только на обеспечении доступа к многомерным данным, а большинство средств ИАД, работающих в сфере закономерностей, имеют дело с одномерными перспективами данных. Эти два вида анализа должны быть тесно объединены, то есть системы OLAP должны фокусироваться не только на доступе, но и на поиске закономерностей. Как заметил N. Raden, "многие компании создали ... прекрасные хранилища данных, идеально разложив по полочкам горы неиспользуемой информации, которая сама по себе не обеспечивает ни быстрой, ни достаточно грамотной реакции на рыночные события".
K. Parsaye [20] вводит составной термин "OLAP Data Mining" (многомерный интеллектуальный анализ) для обозначения такого объединения (рис. 8). J. Han [65] предлагает еще более простое название - "OLAP Mining", и предлагает несколько вариантов интеграции двух технологий.
"Cubing then mining". Возможность выполнения интеллектуального анализа должна обеспечиваться над любым результатом запроса к многомерному концептуальному представлению, то есть над любым фрагментом любой проекции гиперкуба показателей.
"Mining then cubing". Подобно данным, извлечённым из хранилища, результаты интеллектуального анализа должны представляться в гиперкубической форме для последующего многомерного анализа.
"Cubing while mining". Этот гибкий способ интеграции позволяет автоматически активизировать однотипные механизмы интеллектуальной обработки над результатом каждого шага многомерного анализа (перехода между уровнями обобщения, извлечения нового фрагмента гиперкуба и т. д.).
К сожалению, очень немногие производители предоставляют сегодня достаточно мощные средства интеллектуального анализа многомерных данных в рамках систем OLAP. Проблема также заключается в том, что некоторые методы ИАД (байесовские сети, метод k-ближайшего соседа) неприменимы для задач многомерного интеллектуального анализа, так как основаны на определении сходства детализированных примеров и не способны работать с агрегированными данными [20].

Рис. 8. Архитектура системы многомерного интеллектуального анализа данных
Критерии оценки существующих продуктов
Как и в любой другой области, в сфере OLAP не может существовать однозначных рекомендаций по выбору инструментальных средств. Можно только заострить внимание на ряде ключевых моментов и сопоставить предлагаемые возможности программного обеспечения с потребностями организации.
Удобство и богатство возможностей средств администрирования. Работа администратора является самой важной и самой сложной частью эксплуатации OLAP-системы. Поэтому следует обращать внимание на удобство интерфейса администрирования, а более того - на спектр его функциональных возможностей. Как формируются новые измерения? Как модифицируется существующая модель? Требуется ли создание базы данных жестко заданной структуры, или можно анализировать данные, собранные в ранее созданных базах (в случае ROLAP)? На все эти вопросы необходимо получить ясный и четкий ответ.
Гибкость настройки и наглядность форм демонстрации результатов. Интуитивность представления информации - главная изюминка OLAP. Насколько качественно и удобно формируются отчёты? Наглядны ли графические возможности, существует ли связь с ГИС-технологиями? Налажены ли механизмы экспорта результатов в стандартные форматы?
Спектр методов постобработки данных, доступность средств интеллектуального анализа. Богаты ли аналитические возможности инструмента? Есть ли в нём элементы Data Mining, и если есть, какие преимущества они могут обеспечить при использовании?
Возможность обработки больших хранилищ данных с приемлемой производительностью. Если необходим планомерный непрерывный анализ большого хранилища данных организации, требуется выяснить объективные ограничения продукта с точки зрения предельных размеров исходных баз данных.
Возможность увязки OLAP-инструментария со всеми СУБД, используемыми в организации. Как показывает практика, интеграция разнородных продуктов в устойчиво работающую систему - один из наиболее важных вопросов, и его решение в ряде случаев может быть связано с большими проблемами. Необходимо разобраться, насколько просто и надёжно можно интегрировать средства OLAP с существующими в организации СУБД.
Кроме того, разумеется, одним из ключевых критериев выбора программных продуктов является цена. А продукты OLAP существенно отличаются друг от друга по этому показателю.
18,19 вызов удаленных процедур
Идея вызова удаленных процедур (Remote Procedure Call - RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.
Характерными чертами вызова локальных процедур являются:
Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
Синхронность, то есть выполнение вызывающей процедуры при останавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.
Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующим отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса - по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут "осиротевшими", а при аварийном завершении удаленных процедур станут "обездоленными родителями" вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.
Кроме того, существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.
Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем.
Базовые операции RPCЧтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов
count=read (fd,buf,nbytes);
где fd - целое число, buf - массив символов, nbytes - целое число.
Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.
Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.
Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.
Решение о том, какой механизм передачи параметров использовать, принимается разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке С, например, целые и другие скалярные данные всегда передаются по значению, а массивы - по ссылке.

Рис. 3.1. а) Стек до выполнения вызова read; б) Стек во время выполнения процедуры; в) Стек после возврата в вызывающую программу
Идея, положенная в основу RPC, состоит в том, чтобы сделать вызов удаленной процедуры выглядящим по возможности также, как и вызов локальной процедуры. Другими словами - сделать RPC прозрачным: вызывающей процедуре не требуется знать, что вызываемая процедура находится на другой машине, и наоборот.
RPC достигает прозрачности следующим путем. Когда вызываемая процедура действительно является удаленной, в библиотеку помещается вместо локальной процедуры другая версия процедуры, называемая клиентским стабом (stub - заглушка). Подобно оригинальной процедуре, стаб вызывается с использованием вызывающей последовательности (как на рисунке 3.1), так же происходит прерывание при обращении к ядру. Только в отличие от оригинальной процедуры он не помещает параметры в регистры и не запрашивает у ядра данные, вместо этого он формирует сообщение для отправки ядру удаленной машины.
Этапы выполнения RPCВзаимодействие программных компонентов при выполнении удаленного вызова процедуры иллюстрируется рисунком 3.2. После того, как клиентский стаб был вызван программой-клиентом, его первой задачей является заполнение буфера отправляемым сообщением. В некоторых системах клиентский стаб имеет единственный буфер фиксированной длины, заполняемый каждый раз с самого начала при поступлении каждого нового запроса. В других системах буфер сообщения представляет собой пул буферов для отдельных полей сообщения, причем некоторые из этих буферов уже заполнены. Этот метод особенно подходит для тех случаев, когда пакет имеет формат, состоящий из большого числа полей, но значения многих из этих полей не меняются от вызова к вызову.
Затем параметры должны быть преобразованы в соответствующий формат и вставлены в буфер сообщения. К этому моменту сообщение готово к передаче, поэтому выполняется прерывание по вызову ядра.

Рис. 3.2. Remote Procedure Call
Когда ядро получает управление, оно переключает контексты, сохраняет регистры процессора и карту памяти (дескрипторы страниц), устанавливает новую карту памяти, которая будет использоваться для работы в режиме ядра. Поскольку контексты ядра и пользователя различаются, ядро должно точно скопировать сообщение в свое собственное адресное пространство, так, чтобы иметь к нему доступ, запомнить адрес назначения (а, возможно, и другие поля заголовка), а также оно должно передать его сетевому интерфейсу. На этом завершается работа на клиентской стороне. Включается таймер передачи, и ядро может либо выполнять циклический опрос наличия ответа, либо передать управление планировщику, который выберет какой-либо другой процесс на выполнение. В первом случае ускоряется выполнение запроса, но отсутствует мультипрограммирование.
На стороне сервера поступающие биты помещаются принимающей аппаратурой либо во встроенный буфер, либо в оперативную память. Когда вся информация будет получена, генерируется прерывание. Обработчик прерывания проверяет правильность данных пакета и определяет, какому стабу следует их передать. Если ни один из стабов не ожидает этот пакет, обработчик должен либо поместить его в буфер, либо вообще отказаться от него. Если имеется ожидающий стаб, то сообщение копируется ему. Наконец, выполняется переключение контекстов, в результате чего восстанавливаются регистры и карта памяти, принимая те значения, которые они имели в момент, когда стаб сделал вызов receive.
Теперь начинает работу серверный стаб. Он распаковывает параметры и помещает их соответствующим образом в стек. Когда все готово, выполняется вызов сервера. После выполнения процедуры сервер передает результаты клиенту. Для этого выполняются все описанные выше этапы, только в обратном порядке.
Рисунок 3.3 показывает последовательность команд, которую необходимо выполнить для каждого RPC-вызова, а рисунок 3.4 - какая доля общего времени выполнения RPC тратится на выполнение каждого их описанных 14 этапов. Исследования были проведены на мультипроцессорной рабочей станции DEC Firefly, и, хотя наличие пяти процессоров обязательно повлияло на результаты измерений, приведенная на рисунке гистограмма дает общее представление о процессе выполнения RPC.

Рис. 3.3. Этапы выполнения процедуры RPC

Рис. 3.4. Распределение времени между 14 этапами выполнения RPC
1. Вызов стаба
2. Подготовить буфер
3. Упаковать параметры
4. Заполнить поле заголовка
5. Вычислить контрольную сумму в сообщении
6. Прерывание к ядру
7. Очередь пакета на выполнение
8. Передача сообщения контроллеру по шине QBUS
9. Время передачи по сети Ethernet
10. Получить пакет от контроллера
11. Процедура обработки прерывания
12. Вычисление контрольной суммы
13. Переключение контекста в пространство пользователя
14. Выполнение серверного стаба
Динамическое связываниеРассмотрим вопрос о том, как клиент задает месторасположение сервера. Одним из методов решения этой проблемы является непосредственное использование сетевого адреса сервера в клиентской программе. Недостаток такого подхода - его чрезвычайная негибкость: при перемещении сервера, или при увеличении числа серверов, или при изменении интерфейса во всех этих и многих других случаях необходимо перекомпилировать все программы, которые использовали жесткое задание адреса сервера. Для того, чтобы избежать всех этих проблем, в некоторых распределенных системах используется так называемое динамическое связывание.
Начальным моментом для динамического связывания является формальное определение (спецификация) сервера. Спецификация содержит имя файл-сервера, номер версии и список процедур-услуг, предоставляемых данным сервером для клиентов (рисунок 3.5). Для каждой процедуры дается описание ее параметров с указанием того, является ли данный параметр входным или выходным относительно сервера. Некоторые параметры могут быть одновременно входными и выходными - например, некоторый массив, который посылается клиентом на сервер, модифицируется там, а затем возвращается обратно клиенту (операция copy/ restore).
Рис. 3.5. Спецификация сервера RPC
Формальная спецификация сервера используется в качестве исходных данных для программы-генератора стабов, которая создает как клиентские, так и серверные стабы. Затем они помещаются в соответствующие библиотеки. Когда пользовательская (клиентская) программа вызывает любую процедуру, определенную в спецификации сервера, соответствующая стаб-процедура связывается с двоичным кодом программы. Аналогично, когда компилируется сервер, с ним связываются серверные стабы.
При запуске сервера самым первым его действием является передача своего серверного интерфейса специальной программе, называемой binder'ом. Этот процесс, известный как процесс регистрации сервера, включает передачу сервером своего имени, номера версии, уникального идентификатора и описателя местонахождения сервера. Описатель системно независим и может представлять собой IP, Ethernet, X.500 или еще какой-либо адрес. Кроме того, он может содержать и другую информацию, например, относящуюся к аутентификации.
Когда клиент вызывает одну из удаленных процедур первый раз, например, read, клиентский стаб видит, что он еще не подсоединен к серверу, и посылает сообщение binder-программе с просьбой об импорте интерфейса нужной версии нужного сервера. Если такой сервер существует, то binder передает описатель и уникальный идентификатор клиентскому стабу.
Клиентский стаб при посылке сообщения с запросом использует в качестве адреса описатель. В сообщении содержатся параметры и уникальный идентификатор, который ядро сервера использует для того, чтобы направить поступившее сообщение в нужный сервер в случае, если их несколько на этой машине.
Этот метод, заключающийся в импорте/экспорте интерфейсов, обладает высокой гибкостью. Например, может быть несколько серверов, поддерживающих один и тот же интерфейс, и клиенты распределяются по серверам случайным образом. В рамках этого метода становится возможным периодический опрос серверов, анализ их работоспособности и, в случае отказа, автоматическое отключение, что повышает общую отказоустойчивость системы. Этот метод может также поддерживать аутентификацию клиента. Например, сервер может определить, что он может быть использован только клиентами из определенного списка.
Однако у динамического связывания имеются недостатки, например, дополнительные накладные расходы (временные затраты) на экспорт и импорт интерфейсов. Величина этих затрат может быть значительна, так как многие клиентские процессы существуют короткое время, а при каждом старте процесса процедура импорта интерфейса должна быть снова выполнена. Кроме того, в больших распределенных системах может стать узким местом программа binder, а создание нескольких программ аналогичного назначения также увеличивает накладные расходы на создание и синхронизацию процессов.
Семантика RPC в случае отказовВ идеале RPC должен функционировать правильно и в случае отказов. Рассмотрим следующие классы отказов:
Клиент не может определить местонахождения сервера, например, в случае отказа нужного сервера, или из-за того, что программа клиента была скомпилирована давно и использовала старую версию интерфейса сервера. В этом случае в ответ на запрос клиента поступает сообщение, содержащее код ошибки.
Потерян запрос от клиента к серверу. Самое простое решение - через определенное время повторить запрос.
Потеряно ответное сообщение от сервера клиенту. Этот вариант сложнее предыдущего, так как некоторые процедуры не являются идемпотентными. Идемпотентной называется процедура, запрос на выполнение которой можно повторить несколько раз, и результат при этом не изменится. Примером такой процедуры может служить чтение файла. Но вот процедура снятия некоторой суммы с банковского счета не является идемпотентной, и в случае потери ответа повторный запрос может существенно изменить состояние счета клиента. Одним из возможных решений является приведение всех процедур к идемпотентному виду. Однако на практике это не всегда удается, поэтому может быть использован другой метод - последовательная нумерация всех запросов клиентским ядром. Ядро сервера запоминает номер самого последнего запроса от каждого из клиентов, и при получении каждого запроса выполняет анализ - является ли этот запрос первичным или повторным.
Сервер потерпел аварию после получения запроса. Здесь также важно свойство идемпотентности, но к сожалению не может быть применен подход с нумерацией запросов. В данном случае имеет значение, когда произошел отказ - до или после выполнения операции. Но клиентское ядро не может распознать эти ситуации, для него известно только то, что время ответа истекло. Существует три подхода к этой проблеме:
Ждать до тех пор, пока сервер не перезагрузится и пытаться выполнить операцию снова. Этот подход гарантирует, что RPC был выполнен до конца по крайней мере один раз, а возможно и более.
Сразу сообщить приложению об ошибке. Этот подход гарантирует, что RPC был выполнен не более одного раза.
Третий подход не гарантирует ничего. Когда сервер отказывает, клиенту не оказывается никакой поддержки. RPC может быть или не выполнен вообще, или выполнен много раз. Во всяком случае этот способ очень легко реализовать.
Ни один из этих подходов не является очень привлекательным. А идеальный вариант, который бы гарантировал ровно одно выполнение RPC, в общем случае не может быть реализован по принципиальным соображениям. Пусть, например, удаленной операцией является печать некоторого текста, которая включает загрузку буфера принтера и установку одного бита в некотором управляющем регистре принтера, в результате которой принтер стартует. Авария сервера может произойти как за микросекунду до, так и за микросекунду после установки управляющего бита. Момент сбоя целиком определяет процедуру восстановления, но клиент о моменте сбоя узнать не может. Короче говоря, возможность аварии сервера радикально меняет природу RPC и ясно отражает разницу между централизованной и распределенной системой. В первом случае крах сервера ведет к краху клиента, и восстановление невозможно. Во втором случае действия по восстановлению системы выполнить и возможно, и необходимо.
Клиент потерпел аварию после отсылки запроса. В этом случае выполняются вычисления результатов, которых никто не ожидает. Такие вычисления называют "сиротами". Наличие сирот может вызвать различные проблемы: непроизводительные затраты процессорного времени, блокирование ресурсов, подмена ответа на текущий запрос ответом на запрос, который был выдан клиентской машиной еще до перезапуска системы.
Как поступать с сиротами? Рассмотрим 4 возможных решения.
Уничтожение. До того, как клиентский стаб посылает RPC-сообщение, он делает отметку в журнале, оповещая о том, что он будет сейчас делать. Журнал хранится на диске или в другой памяти, устойчивой к сбоям. После аварии система перезагружается, журнал анализируется и сироты ликвидируются. К недостаткам такого подхода относятся, во-первых, повышенные затраты, связанные с записью о каждом RPC на диск, а, во-вторых, возможная неэффективность из-за появления сирот второго поколения, порожденных RPC-вызовами, выданными сиротами первого поколения.
Перевоплощение. В этом случае все проблемы решаются без использования записи на диск. Метод состоит в делении времени на последовательно пронумерованные периоды. Когда клиент перезагружается, он передает широковещательное сообщение всем машинам о начале нового периода. После приема этого сообщения все удаленные вычисления ликвидируются. Конечно, если сеть сегментированная, то некоторые сироты могут и уцелеть.
Мягкое перевоплощение аналогично предыдущему случаю, за исключением того, что отыскиваются и уничтожаются не все удаленные вычисления, а только вычисления перезагружающегося клиента.
Истечение срока. Каждому запросу отводится стандартный отрезок времени Т, в течение которого он должен быть выполнен. Если запрос не выполняется за отведенное время, то выделяется дополнительный квант. Хотя это и требует дополнительной работы, но если после аварии клиента сервер ждет в течение интервала Т до перезагрузки клиента, то все сироты обязательно уничтожаются.
На практике ни один из этих подходов не желателен, более того, уничтожение сирот может усугубить ситуацию. Например, пусть сирота заблокировал один или более файлов базы данных. Если сирота будет вдруг уничтожен, то эти блокировки останутся, кроме того уничтоженные сироты могут остаться стоять в различных системных очередях, в будущем они могут вызвать выполнение новых процессов и т.п.
20 Протоколы TCP/IP
TCP/IP - это два основных сетевых пpотокола Internet. Часто это название используют и для обозначения сетей, pаботающих на их основе. Пpотокол IP (Internet Protocol - IP v4) обеспечивает маpшpутизацию (доставку по адpесу) сетевых пакетов. Пpотокол TCP (Transfer Control Protocol) обеспечивает установление надежного соединения между двумя машинами и собственно пеpедачу данных, контpолиpуя оптимальный pазмеp пакета пеpедаваемых данных и осуществляя пеpепосылку в случае сбоя. Число одновpеменно устанавливаемых соединений между абонентами сети не огpаничивается, т. е. любая машина может в некоторый промежуток времени обмениваться данными с любым количеством дpугих машин по одной физической линии.
Дpугое важное пpеимущество сети с протоколами TCP/IP состоит в том, что по нему могут быть объединены машины с pазной аpхитектуpой и разными опеpационными системами, напpимеp Unix, VAX VMS, MacOS, MS-DOS, MS Windows и т.д. Пpичем машины одной системы пpи помощи сетевой файловой системы NFS (Net File System) могут подключать к себе диски с файловой системой совсем дpугой ОС и опеpиpовать "чужими" файлами как своими.
Протоколы TCP/IP (Transmission Control Protocol/Internet Protocol) являются базовыми транспортным и сетевым протоколами в OS UNIX. В заголовке TCP/IP пакета указывается:
IP-адрес отправителя
IP-адрес получателя
Номер порта (Фактически - номер прикладной программы, которой этот пакет предназначен)
Пакеты TCP/IP имеют уникальную особенность добраться до адресата, пройдя сквозь разнородные в том числе и локальные сети, используя разнообразные физические носители.Маршрутизацию IP-пакета (переброску его в требуемую сеть) осуществляют на добровольных началах компьютеры, входящие в TCP/IP сеть.
Протокол IP - это протокол, описывающий формат пакета данных, передаваемого по сети.
Следующий простой пример можетн прояснить, каким образом происходит передача данных и передача данных. Когда Вы получаете телеграмму, весь текст в ней (и адрес, и сообщение) написан на ленте подряд, но есть правила, позволяющие понять, где тут адрес, а где сообщение. Аналогично, пакет в компьютерной сети представляет собой поток битов, а протокол IP определяет, где адрес и прочая служебная информация, а где сами передаваемые данные. Таким образом, протокол IP в эталонной модели ISO/OSI является протоколомсетевого (3) уровня.
Протокол TCP - это протокол следующего уровня, предназначеный для контроля передачи и целостности передаваемой информации.
Когда Вы не расслышали, что сказал Вам собеседник в телефонном разговоре, Вы просите его повторить сказанное. Приблизительно этим занимается и протокол TCP применительно к компьютерным сетям. Компьютеры обмениваются пакетами протокола IP, контролируют их передачу по протоколу TCP и, объединяясь в глобальную сеть, образуют Интернет. Протокол TCP является протоколом транспортного (4) уровня21 создание канала связи между клиентом и сервером
Клиентом и сервером называются процессы, работающие одновременно на одном или разных компьютерах (объединенных в сеть) и взаимодействующие между собой определенным образом.
Клиент посылает серверу запрос на получение данных или выполнение какой-либо работы. Сервер, получив от клиента запрос, выполняет соответствующие действия и посылает клиенту ответ. Процесс передачи запроса серверу называется транзакцией.
Строго говоря, транзакция – это совокупность трех действий: посылки запроса, выполнение запроса, приема ответа.
Транзакция называется завершенной, если выполнены все три действия. Если же на одном из трех этапов произошел сбой, транзакция остается незавершенной. После восстановления незавершенная транзакция откатывается, что необходимо в ряде случаев для сохранения целостности данных (разумеется, за правильное выполнение отката транзакции отвечает сервер).
В системе, имеющей архитектуру “клиент – сервер”, может быть несколько клиентов, работающих с одним сервером, или несколько клиентов, работающих одновременно с несколькими серверами.
Приложения, использующие технологию динамического обмена данными DDE, выступают как клиенты или серверы (или одновременно как клиенты и серверы). При этом взаимодействие между ними – не что иное, как транзакция. Библиотека ddeml.dll позволяет создавать системы, имеющие различные топологии.
2.25.2. Инициализация и создание канала связиРассмотрим процесс создания канала связи между двумя одновременно работающими приложениями. Пусть одно приложение будет клиентом, а другое – сервером.
В процессе инициализации сервер должен выполнить следующие действия:
·         зарегистрировать себя в библиотеке DDEML;
·         зарегистрировать предоставляемый сервис, которым сможет воспользоваться приложение-клиент.
Клиент должен сделать следующее:
·         зарегистрировать себя в библиотеке DDEML;
·         создать канал связи с сервером, указав необходимый сервис.
Рассмотрим эти действия подробнее.
 
Регистрация в библиотеке DDEML. Если приложение собирается использовать DDEML, оно должно зарегистрировать себя в библиотеке DDEML, вызвав специально предназначенную для этого функцию с именем DdeInitialize.
Функция DdeInitialize используется в процессе инициализации и серверов, и клиентов. Сама по себе она не создает никаких каналов передачи данных между приложениями, однако процедура регистрации должна быть проведена до вызова любых других функций, имеющих отношение к DDEML.
Если приложение больше не собирается работать с библиотекой DDEML, оно должно вызвать функцию DdeUninitialize.
 
Регистрация сервиса. Следующий этап в инициализации сервера DDEML заключается в регистрации предоставляемого им сервиса.
Библиотека DDEML использует трехступенчатую схему адресации данных, передаваемых по каналу связи: сервис (service), раздел (topic) и элемент данных (data item). Приложение задает элементы адреса в виде текстовых строк размером не более 356 байт.
Сервер DDEML может предоставлять сервис одного или нескольких видов. Как правило, один сервер предоставляет только один сервис, причем текстовая строка, идентифицирующая сервис, часто совпадает с именем приложения, но можно выбрать любую другую строку.
Второй элемент адреса – раздел. В рамках одного сервиса можно определить несколько разделов. Когда клиент DDEML создает канал с сервером, он указывает сервис и раздел. Раздел объединяет группу элементов данных или выполняемых функций.
Канал DDEML служит для передачи блоков данных. В рамках одного раздела сервер может обмениваться с клиентом разными блоками данных, каждый из которых идентифицируется при передаче именем элемента данных. В процессе создания канала связи не требуется указывать элементы данных.
Регистрация сервиса выполняется сервером DDEML обычно сразу после вызова функции DdeInitialize и происходит в два этапа.
На первом этапе текстовая строка имени сервиса сохраняется в специальной системной таблице, для чего вызывается функция DdeCreateStringHandle.
Идентификатор текстовой строки, возвращенный функцией DdeCreateStringHandle и соответствующий регистрируемому сервису, следует передать функции DdeNameService.
Перед завершением работы сервер DDEML должен отменить весь зарегистированный им ранее сервис, вызвав функцию DdeInitialize с соответствующим флагом.
Одновременно с регистрацией сервиса сервер обычно создает идентификаторы текстовых строк, содержащих имена используемых разделов и элементов данных. Для этого вызывается все та же функция DdeCreateStringHandle.
Отметим, что регистрацию сервиса выполняет только сервер. Что же касается создания идентификаторов текстовых строк функцией DdeCreateStringHandle, то эта операция выполняется как сервером, так и клиентом. Полученные идентификаторы используются при создании канала и в процессе передачи данных.
Если идентификатор созданной строки используется в функции обратного вызова, то за освобождения ресурсов, связанных с текстовой строкой, отвечает система DDEML. В противном случае необходимо использовать функцию DdeFreeStringHandle.
 
Функция обратного вызова DDEML. Когда клиент или сервер регистрируется в библиотеке DDEML, он указывает адрес переходника, созданного для функции обратного вызова. Эта функция предназначена для обработки событий, возникающих в процессе создания каналов связи и передачи данных.
Простейшая функция обратного вызова сервера DDEML имеет вид
 
HDDEDATA EXPENTRY _export DdeServer(wType, wFmt, hConv ,hsz1, hsz2, hData, dwData1, dwData2)
WORD wType; // код транзакции
WORD wFmt; // формат данных
HCONV hConv; // идентификатор канала
HSZ hsz1; // первый идентификатор строки
HSZ hsz2; // второй идентификатор строки
HDDEDATA hData; // идентификатор глобальной области памяти
DWORD dwData1; // первое дополнительное двойное слово
DWORD dwData2; // второе дополнительное двойное слово
{
switch(wType)
{
case XTYP_CONNECT:
// создание канала передачи данных
. . .
return((HDDEDATA)TRUE);
case XTYP_CONNECT_CONFIRM:
// подтверждение создание канала
. . .
break;
case XTYP_DISCONNECT:
// завершение работы канала
. . .
break;
case XTYP_REQUEST: // запрос данных от сервера
. . .
return(hData);
case XTYP_EXECUTE:
// запрос на выполнение команды
. . .
break;
case XTYP_POKE: // передача данных серверу
. . .
return((HDDEDATA)DDE_FACK);
case XTYP_ERROR: // ошибка
. . .
break;
}
 return((HDDEDATA)NULL);
}
 
Функция обратного вызова для клиента DDEML выглядит точно также, отличаясь только составом обрабатываемых транзакций
 
HDDEDATA EXPENTRY _export DdeServer(wType, wFmt, hConv ,hsz1, hsz2, hData, dwData1, dwData2)
WORD wType; // код транзакции
WORD wFmt; // формат данных
HCONV hConv; // идентификатор канала
HSZ hsz1; // первый идентификатор строки
HSZ hsz2; // второй идентификатор строки
HDDEDATA hData; // идентификатор глобальной области памяти
DWORD dwData1; // первое дополнительное двойное слово
DWORD dwData2; // второе дополнительное двойное слово
{
switch(wType)
{
case XTYP_DISCONNECT: // завершение работы канала
return((HDDEDATA)NULL);
case XTYP_ERROR: // ошибка
break;
case XTYP_XACT_COMPLETE:
// завершение выполнения команды
break;
}
return((HDDEDATA)NULL);
}
 
Создание и уничтожение канала связи. Последнее, что нужно сделать перед началом передачи данных, – создать канал связи. Канал связи между клиентом и сервером создается всегда по инициативе клиента. После регистрации в библиотеке DDEML клиент вызывает функцию DdeConnect, создающую канал связи.
Рассмотрим, что происходит при создании канала при помощи функции DdeConnect.
Прежде всего библиотека DDEML посылает транзакцию с кодом XTYP_CONNECT всем активным серверам, которые зарегистрировали сервис, указанный в параметрах функции DdeConnect. Обработчик этого сообщения должен проверить сервис и раздел, если сервер их поддерживает, то можно создавать канал. В таком случае функция обратного вызова должна вернуть TRUE, в противном – FALSE.
В случае успешного создания канала сервер получает от системы DDEML транзакцию с кодом XTYPE_CONNECT_CONFIRM. При обработке этой транзакции сервер может сохранить идентификатор созданного канала для дальнейшего использования.
Если канал связи больше не нужен, клиент или сервер может уничтожить его, вызвав функцию DdeDisconnect. Партнер приложения, вызвавшего эту функцию, получит транзакцию XTYPE_DISCONNECT. Здесь можно освободить заказанные ранее ресурсы для работы с каналом связи.
22 передача и прием данных
int info = pvm_send( int tid, int msgtag)
call pvmfsend( tid, msgtag, info)
int info = pvm_mcast( int *tids, int ntask, int msgtag)
call pvmfmcast( ntask, tids, msgtag, info)
Подпрограмма pvm_send() помечает сообщение целочисленным идентификатором msgtag и передает его непосредственно процессу TID.
Подпрограмма pvm_mcast() помечает сообщение целочисленным идентификатором msgtag и широковещательно передает это сообщение всем задачам, указанным в целочисленном массиве tids (исключая себя). Массив tids имеет длину ntask.
int info = pvm_psend( int tid, int msgtag, void *vp,
    int cnt, int type)
call pvmfpsend( tid, msgtag, xp, cnt, type, info)
Подпрограмма pvm_psend() упаковывает и посылает массив данных указанного типа задаче, идентифицированной TID. Предопределенные типы данных на Фортране такие же, как и для pvmfpack(). В языке C аргумент type может иметь любое из следующих значений:
PVM_STR PVM_FLOAT
PVM_BYTE PVM_CPLX
PVM_SHORT PVM_DOUBLE
PVM_INT PVM_DCPLX
PVM_LONG PVM_UINT
PVM_USHORT PVM_ULONG
PVM поддерживает несколько методов приема сообщений в задаче. В PVM нет точного соответствия функций, например, применение pvm_send не обязательно требует примененияpvm_recv. Каждая из следующих подпрограмм может быть вызвана для любого из поступающих сообщений вне зависимости от того, как оно было передано (или передано широковещательно).
int bufid = pvm_recv( int tid, int msgtag)
call pvmfrecv( tid, msgtag, bufid)
Эта подпрограмма блокирующего приема будет ожидать до тех пор, пока от задачи с TID не поступит сообщение с меткой msgtag. Значение -1 в msgtid или TID означает ``все задачи'' (специальный символ). После поступления она помещает сообщение в новый создаваемый активный буфер приема. Предыдущий активный буфер приема очищается, если он не был сохранен вызовом pvm_setrbuf().
int bufid = pvm_nrecv(int tid, int msgtag)
call pvmfnrecv( tid, msgtag, bufid)
Если запрашиваемое сообщение не прибыло, то неблокирующий прием pvm_nrecv() при завершении вернет код, равный 0. Эта подпрограмма может вызываться сколько угодно раз для определенного сообщения - с целью проверки его прибытия - в промежутках выполнения работы программы. Если же возможной в данной ситуации работы не осталось, для того же сообщения можно воспользоваться блокирующим приемом pvm_recv(). Если сообщение с меткой msgtag поступило от задачи с TID, pvm_nrecv() помещает это сообщение в новый активный буфер (который она создает) и возвращает идентификатор данного буфера. Предыдущий активный буфер приема очищается, если он не был сохранен вызовомpvm_setrbuf(). Значение -1 в msgtid или TID означает ``все задачи'' (специальный символ).
int bufid = pvm_probe( int tid, int msgtag)
call pvmfprobe( tid, msgtag, bufid)
Если запрашиваемое сообщение не прибыло, то pvm_probe() возвращает bufid, равный 0. В противном случае она возвращает bufid сообщения, но не ``принимает'' его. Эта подпрограмма может вызываться сколько угодно раз для определенного сообщения - с целью проверки его прибытия - в промежутках выполнения работы. Дополнительно может быть вызвана pvmbufinfo() с возвращенным bufid - для получения информации о сообщении перед его непосредственным приемом.
int bufid = pvm_trecv( int tid, int msgtag,
    struct timeval *tmout)
call pvmftrecv( tid, msgtag, sec, usec, bufid)
PVM также поддерживает версию приема с тайм-аутом. Рассмотрим случай, при котором сообщение не прибывает никогда (из-за ошибки или сбоя): подпрограмма pvm_recv может заблокироваться навечно. Для избежания такой ситуации пользователь может захотеть ``прекратить'' ожидание после истечения фиксированного временного отрезка. Подпрограммаpvm_trecv() предоставляет пользователю возможность указать период тайм-аута. Если этот период очень велик, то pvm_trecv() действует подобно pvm_recv. Если же период тайм-аута установлен в ноль, то pvm_trecv() действует подобно pvm_nrecv. Так, pvm_trecv ``заполняет пробел'' между функциями блокирующего и неблокирующего приема.
Подпрограмма pvm_bufinfo() возвращает msgtag, TID источника и длину в байтах сообщения, идентифицированного с помощью bufid. Она может применяться для установления метки и источника сообщений, которые были приняты с использованием специальных символов.
int info = pvm_bufinfo( int bufid, int *bytes,
    int *msgtag, int *tid)
call pvmfbufinfo( bufid, bytes, msgtag, tid, info)
Подпрограмма pvm_precv() сочетает в себе функции блокирующего приема и распаковки буфера приема. Она не возвращает bufid. Вместо него она возвращает действительные значения TID, msgtag и cnt.
int info = pvm_precv( int tid, int msgtag, void *vp,
    int cnt, int type, int *rtid, int *rtag,
    int *rcnt)
call pvmfprecv( tid, msgtag, xp, cnt, type, rtid, rtag,
    rcnt, info)Подпрограмма pvm_recvf() модифицирует контекст работы принимающих функций и может быть использована для ``расширения'' PVM. Используемый по умолчанию контекст приема заключается в соответствии источника и тега сообщения. Он может быть модифицирован для любой определяемой пользователем функции сравнения. Подпрограммы, соответствующей pvm_recvf(), с интерфейсом на Фортране - нет.
23 интерфейс сетевой базовой системы ввода вывода
Историческая Справка
          Когда в 1984 году было впервые объявлено о Сети ПЭВМ IBM (IBM PC Network), возник вопрос: какое сетевое программное обеспечение реализовала фирма IBM ? Своеобразный ответ на него дали компаниипродавцы ЛВС: они предложили Сети MICROSOFT (Microsoft Networks), думая, что именно это программное обеспечение используется в Сети ПЭВМ (PC Network). Принятие такого решения было обусловлено, в частности, еще и тем, что операционная система MS-DOS фирмы Microsoft стала PC-DOS для компании IBM. (Сети Microsoft (Microsoft Networks) безусловно являются продуктом изготовителей комплексного оборудования. Они не реализованы ни в какой определенной ЛВС - это обусловлено только фирмой-изготовителем комплексного оборудования).          Та же история повторилась в апреле 1987 года, когда IBM объявила о создании OS/2 одновременно с фирмой Microsoft, которая заявила о своем новом продукте - Администраторе ЛВС (LAN Manager). В течение некоторого времени после этого события компания IBM не разглашала свою новинку - "стратегию спецпроцессора", пока не вышла на рынок с новым своим продуктом - Спецпроцессором ЛВС OS/2 IBM (IBM OS/2 LAN Server). И снова возникли затруднения - как же соотносятся эти два продукта - Спецпроцессор IBM и Администратор Microsoft?
          В настоящей главе рассказывается об эволюции Сетей Microsoft (Microsoft Networks) и Программы ЛВС ПЭВМ IBM (IBM PC LAN Program), начиная с оригинальной разработки и до их реализации в OS/2.
[начало] [оглавление] 
Сети Microsoft (Microsoft Networks)
          Только после выпуска Сети ПЭВМ (PC Network) с модулированной передачей фирмы-продавцы и пользователи стали осознавать, что сетевое программное обеспечение в Сети ПЭВМ (которое позднее стало известно как NETBIOS) является несовместимым с Сетями Microsoft (Microsoft Networks) и оно не было создано фирмой Microsoft. В результате, поток продуктов, совместимых с Сетями Micrsoft, о котором объявили многие фирмы-продывцы ЛВС, никогда не был реализован.
          После выпуска cети ПЭВМ (PC Network) фирма Microsoft действительно изменила структуру пользовательских команд в Сетях Microsoft (Microsoft Networks), чтобы достигнуть более тесного соответствия с командами, используемыми IBM. (К примеру, команда CONNECT стала командой NET USE). Фактически, команды Сетей Microsoft являются в значительной степени "подмножеством" команд, используемых в Программе ЛВС ПЭВМ IBM (IBM PC LAN Program).
          Один из компонентов реализации IBM NETBIOS был написан фирмой Microsoft: это непопулярный в настоящее время передресатор. Он тесто связан с PC/MS-DOS в том смысле, что используется протокол Блока сообщений спецпроцессора (SMB) (см. Главу 5), хотя остальная часть Сетей Microsoft и NETBIOS спроектирована таким образом, чтобы обеспечить независимость как от операционной системы, так и от ЛВС. Сети Microsoft (Microsoft Networks) доступны как для Xenix (реализация UNIX, System V фирмой Microsoft), так и для MS-DOS. Переадресатор предназначен для того, чтобы запросы на услуги (например, открытие или распечатка файлов), которые обычно обрабатываются в местном "режиме", были, при необходимости, перехвачены, преобразованы в сетевой запрос и направлены для исполнения спецпроцессору.          Подобно NETBIOS, Сети Microsoft (Microsoft Networks) предназначены для работы с MS-DOS 3.1 (на ней основан и спецпроцессор и рабочая станция) или же с более высокой версией этой операционной системы. Режимы коллективного использования файлов и режимы блокировки файлов идентичны. Аналогична и расширенная схема поименования: \\имя_спецпроцессора\каталог\файл(\\server_name\directory\file).
[начало] [оглавление] 
Сети Microsoft И NETBIOS
          Основное различие между ранней версией Сетей Мicrosoft (Microsoft Networks) и NETBIOS заключается в том, что Сети Microsoft предоставляют интерфейс транспортного уровня, в то время как интерфейс NETBIOS находится на сеансовом уровне. Сети Microsoft также включают специализированной программное обеспечение спецпроцессора и рабочей станции, тогда как Программа ЛВС IBM PC обеспечивает эти и другие функции, включая неспециализированный спецпроцессор.
          Транспортный уровень Сетей Microsoft используется для отправки сообщений через виртуальные каналы. По одному запросу может быть передано до 64 кбайт. Коммуникация (обмен данными) с транспортным уровнем осуществляется посредством прерывания 21H, функция 5BH (напомним, что NETBIOS использует прерывание 21H, функция 5CH). Коммуникация с транспортным уровнем производится посредством установки Блока управления транспортом (Transport Control Block, сокращенно TCB), а затем выполнения прерывания 21H. Блок управления транспортом аналогичен Блоку управления сообщениями (MCB) или Блоку управления сетью (NCB) в NETBIOS. Фактически, многие поля являются общими как для реализации TCB, так и для реализации NCB/MCB. На рис. 6-1 показана структура Блока управления транспортом (TCB).
ИМЯ ПОЛЯ ДЛИНА (байт) и ЗНАЧЕНИЕ-------------------------------------------------------------------! COMMAND ! 1 Поле команды !! ! !-------------------------------------------------------------------! CID ! 1 Идентификатор команды !! ! !-------------------------------------------------------------------! VCID ! 1 Идентификационный номер виртуального канала !! ! !-------------------------------------------------------------------! LENGTH ! 2 Размер буфера данных !! ! !-------------------------------------------------------------------! BADDR ! 4 Указаталь на адрес буфера сообщения !! ! (смещение:сегмент) !-------------------------------------------------------------------! RES1 ! 2 Зарезервированное !! ! !-------------------------------------------------------------------! LADDR ! 16 Местный адрес !! ! !-------------------------------------------------------------------! RADDR ! 16 Удаленный адрес !! ! !-------------------------------------------------------------------! ASYNC ! 4 Указатель на подпрограмму нотификации (объявления)!! ! адреса (смещение:сегмент) !-------------------------------------------------------------------! LNET ! 4 Местный номер ЛВС !! ! !-------------------------------------------------------------------! RNET ! 4 Удаленный номер ЛВС !! ! !-------------------------------------------------------------------! RTO ! 1 Тайм-аут получения (шаг равен 500 мсек) !! ! !-------------------------------------------------------------------! STO ! 1 Тайм-аут отправки (шаг равен 500 мсек) !! ! !-------------------------------------------------------------------! RES2 ! 8 Зарезервированное !! ! !-------------------------------------------------------------------
Рис. 6-1. Блок управления транспортом (TCB).
          Как и для оригинального NETBIOS в Сети ПЭВМ с модулированной передачей (PC Network), сетевой уровень в Сетях Microsoft реализован лишь в минимальной степени. Имеется поддержка для иерархического адреса, состоящего из 4-байтового адреса сети и 16-байтового адреса станции. Также имеется низкоуровневая поддержка для услуги дейтаграмм, позволяющая отправлять/принимать неквитированные пакеты длиной до 512 байт. Изготовитель комплексного оборудования должен решить, как отобразить адреса станций в адресах сети и как реализовать алгоритм маршрутизации, если будет разработан шлюз.
          К сожалению, между Сетями Microsofdt и NETBIOS существует много различий, что затрудняет совместимость этих продуктов. Кроме уже упромянутых различий, несовместимыми являются и две схемы поименования. NETBIOS позоляет иметь несколько имен, динамически переназначать имена и транслировать их; в то сремя как в Сетях Microsoft требуется, чтобы администратор присваивал только одно логическое имя каждому физическому адресу.
          Несмотря на различия в обеих реализациях, у них есть один общий недостаток: обе основываются на MS-DOS для выполнения услуг в файловом процессоре. Другими словами, на них влияют недостатки операционной системы - однопользовательской и "однозадачной". В первой редакции данной книги мы написали следующее: "Не совсем ясно, сможет ли 'многозадачная' версия DOS решить эту проблему, потому что для успешной своей работы она более чем вероятно НЕ будет совместима с предыдущими версиями DOS,что полностью обезоружит пять миллионов владельцев ПЭВМ". Как оказалось, OS/2 поддерживает только некоторые команды DOS и лежащую в основе DOS файловую структуру, что не устраняет трудности в работе для любого спецпроцессора ЛВС, действующего под управлением OS/2. (Метод, имеющийся в DOS, - метод использования таблицы размещения (записей) файла (FAT) потребует проведения интенсивного табличного поиска при открытии, закрытии и поддержании файла).
          Некоторые фирмы-продавцы, объявившие о поддержке Сетей Microsoft, выпустили на рынок промышленные версии для своих сетей. Многие из них предлагают также и NETBIOS, т.к. Сети Microsoft включают "образец" эмулятора NETBIOS, который фирмы-изготовители комплексного оборудования могут предлагать наряду со своими продуктами. Получилось так, что первоначальная полезность Сетей Microsoft в чистой среде MS-DOS была некоторым образом ограничена. Первоначально Сети Microsoft были для ЛВС с комбинацией операционных систем DOS и Xenix.
[начало] [оглавление] 
Администратор ЛВС
          С появлением Администратора ЛВС (LAN Manager) Microsoft (одновременно с PS/2 и OS/2), переадресатор стал называться Генератором запросов (Запросчиком), а NETBIOS стал интерфейсом прикладного программирования (API) для OS/2. Администратор ЛВС работает под управлением OS/2 на PC AT или PS/2 Модель 50 и выше с процессором 80286 или 80386. ПЭВМ рабочей стванции может действовать либо с МS-DOS и Программой ЛВС ПЭВМ (PC LAN Program), которая требует наличия NETBIOS, либо с OS/2 и новым интерфейсом прикладного программирования (API) NETBIOS. Администратор ЛВС OS/2 Microsoft (созданный совместно с 3Com) позволяет пользователям соединять системы ПЭВМ под управлением либо Microsoft OS/2, либо MS-DOS вместе в единую цепь. Системы под управлением Microsoft XENIX и XENIX Net могут быть также подсоединены к этой же сети.
          В подобной сети система на основе Microsoft OS/2 может работать одновременно и как рабочая станция и как спецпроцессор; Системы MS-DOS работающие в Сетях Microsoft, могут действовать как спецпроцессор или рабочая станция. Системы на основе XENIX могут работать и как спецпроцессор и как рабочая станция одновременно.
          Администратор ЛВС OS/2 Microsoft дает такие сетевые возможности, как прозрачное совместное использование файлов и печати, средства защиты пользователя и инструментальные средства управления сетью. Вследствие того, что Администратор ЛВС OS/2 Microsoft тесно связан с операционной системой MS OS/2, интерфейсы программирования работают во всей сети как прозрачные. Средство межпроцессовой коммуникации (IPC) облегчает процесс непосредственного обмена данными (коммуникации между прикладными программами, хотя они и находятся на разных машинах в сети. Разработчики прикладных программ смогут создать единую версию программного продукта, который может работать как на отдельной машине, так и на нескольких мамшинах, соединенных Администратором ЛВС OS/2 Microsoft. Такие фирмы как Novell и 3Com предложили свои собственные версии Средства межпроцессовой коммуникации (IPC) до OS/2.
          Администратор ЛВС OS/2 Microsoft полностью совместим с существующими продуктами Сетей Microsoft как для операционной системы MS-DOS, так и для XENIX. Это позволяет новым системам под управлением MS-DOS взаимодействовать с существующими сетями, поддерживающими Сети Microsoft.
          Большинство фирм-изготовителей комплексного оборудования, предлагающих Сети Microsoft (включая HEWLETT PACKARD, TandemTandem, DEC, Ungermann-Bass, 3Com/Bridge, AT&T, Nothern Telecom, AST Research, Apricot, Seimens, Bull, Intel, NEC Japan, XeroxXerox, SMT Goupil Research Machines и Digital Microsystems) также будут предлагать Администратор ЛВС Microsoft. Фирма IBM - заметное исключение из этого списка. Несмотря на то, что Сети Microsoft и Программа ЛВС ПЭВМ/NETBIOS имеют много общего, IBM не собирается поддерживвать Администратор ЛВС, планируя позже предложить программное обеспечение для Спецпроцессора ЛВС OS/2 (LAN Server). Еще одно различие между Microsoft и IBM - Расширенная версия OS/2 IBM (IBM OS/2 Extended Edition), которая стала собственной версией OS/2, созданной фирмой IBM. От изготовителей комплексного оборудования OS/2 Microsoft будет зависеть, оказать ли поддержку Расширенной версии IBM. Многие фирмы оснащают Стандартную версию дополнениями, например, пакетом APPC/PC.
[начало] [оглавление] 
Взаимодействие Администратора ЛВС И API NETBIOS
          Интерфейсы прикладного программирования (API) для OS/2 Microsoft предоставляют доступ к сетевым функциям и используются языками высокого уровня. API обеспечивает два вида функций:
1. Вызовы функций, ориентированных на прикладные программы. Эти функции предназначены для сетевых прикладных программ, которые выполняют сложные задачи, например, используют сетевые ресурсы, запрашивают или управляют удаленным печатающим устройством с буферизацией, посылают или получают сообщения и т.п.2. Вызовы функций, ориентированных на управление. Эти функции позволяют получать полный доступ к или управлять удаленным спецпроцессором, например, запускать, делать паузу или продолжать работу программ спецпроцессора, разделять и закрывать разделение ресурсов спецпроцессора, запрашивать/управлять сеансами спецпроцессора и т.п.
          Интерфейс прикладного программирования (API) Администратора ЛВС имеет те же ограничения, что и стандартный API DOS. API использует программную модель удаленного вызова процедуры, чтобы обеспечить управление удаленными спецпроцессорами и их ресурсами как местными. Такие вызовы принимают параметр имени спецпроцессора, который указывает цель операции. Для того, чтобы предотвратить несанкционированное использование, некоторые функции, вызванные удаленно, выполняются только, если запрашивающий пользователь имеет преимущество в управлении данным спецпроцессором.
          Управляющая программа (драйвер) NETBIOS - одна из категорий, определенная Интерфейсом прикладного программирования (API) Администратора ЛВС. Администратор ЛВС определяет и другие категории. Просто перечислим их.
Рабочая станция (WORKSTATION) - Информация о конфигурации рабочей станции.
Использование переназначения - Соединение удаленного (REDIRECT USE) устройства рабочей станции
Сообщения (MESSAGING) - Отправка и прием сообщений от пользователя к пользователю
Тревога (ALERT) - Управляет и поднимает тревогу в сети
Каналы (PIPES) - Двустроронняя коммуникация процессов
Почтовые участки (MAILSLOTS) - Односторонняя коммуникация процессов
Параметры пользователя - Сохраняет/восстанавливает (PROFILE) активное использование/совместное использование
Конфигурация (CONFIG) - Устанавливает элементы из файла LANMAN.INI
Спецпроцессор (SERVER) - Конфигурация спецпроцессора и статистические данные о нем
Совместное использование - Совместное использование файла (SHARES) и устройства спецпроцессора
Сеансы (SESSIONS) - Машинные сеансы спецпроцессора
Cоединения (CONNECTIONS) - Пользовательские соединения спецпроцессора
Файлы (FILES) - Открытые файлы спецпроцессора Регистрация (AUDITING) - Регистрация в контрольном журнале
Регистрация ошибок - Регистрация системных ошибок (ERROR LOGGING)
Символьные устройства - Соединения с удаленными (CHAR DEVICES) символьными устройствами
Очереди печати (PRINT QUEUES) - Очереди заданий системы буферизации потоков I/O
Задания печати (PRINT JOBS) - Задания печати системы буферизации
Назначения печати - Виртуальные устройства в (PRINT DESTINATIONS) системе буферизации
Разрешения на доступ - Разрешения на доступ к файлам (ACCESS PERMISSIONS) и другим ресурсам
Пользователи (USERS) - Разрешения на пользование файлами и групповое членство
Статистика (STATISTICS) - Статистические данные о работе рабочей станции и спецпроцессора
Удаленные (REMOTE) - Удаленные функции, такие как удаленное выполнение программы, копирование файлов и передвижение файлов
Смешанные (MISCELLANEOUS) - Время дня в сети и т.п.          Доступ к управляющей программе NETBIOS осуществляется вызовом Enum. Вызовы Enum перечисляют тип ресурса, является ли он именами пользователей, заданиями в очереди, очередями в спецпроцессоре и т.д. Вызовы всегда возвращают целое число частей ответа фиксированной длины. Если буфер пользователя слишком мал,некоторые данные переменной длины не возвращаются, вероятнее всего,для последнего элемента, хотя это и не обязательно. Кодом возврата является "больше данных", включая и данные переменной длины. Этот пераметр показывает количество возвращенных "порций" фиксированной длины. Некоторые или все из них могут иметь только часть соответствующих переменных данных, возвращаемых вместе с ними.
          Вызовы Enum помещают фиксированные структуры в передней части буфера, чтобы дать Вам возможность выполнять в них итерацию. Переменные данные помещаются с другого конца буфера. Вызов Enum в NETBIOS обеспечивает два уровня информации:
Уровень 0---------
struct netbios_info_0 {char nb_net_name [16] };/* nb_net_name is 16 character NETBIOS name */
Уровень 1---------
struct netbios_info_1 {char nb_ntet_name [16];char nb_driver_name [9]; /* OS/2 device driver name */unsigned byte nb_lana_num; /* lan adapter number */unsigned short nb_driver_type; /* 1 = ncb, 2 = mcb */unsigned short nb_net_status; /* bit 0 on = net started *//* bits 14/15 opcodes as follows: *//* 0 = net not opened *//* 1 = open in regular mode *//* 2 = open in privileged mode *//* 3 = open in exclusive mode */unsigned long nb_net_bandeidth; /* network bandwidth bits/s */unsigned short nb_max_sess; /* max number of sessions */unsigned short nb_max_ncbs; /* max number of outstanding ncbs */unsigned short nb_max_names; /* max number of names */
[начало] [оглавление]Вызовы Процедур
Вызов Процедуры NETBIOSENUM
Назначение: перечислить управляющие программы (драйверы) NETBIOS
Условие вызова
init far pascal NetBiosEnum(servername,level,buf,buflen,intritsread,totalentries)char far * servername; /* name of tart PC (null if local) */char far * buf; /* pointer to info buffer */unsigned short buflen; /* byte length of info buffer */unsigned short far * entriesread; /* # of entries supplied on return */unsigned short far * totalentries; /* total # of entries available */
Величина возврата
Содержимое буфера при возврате (формат для одного элемента) может быть одно из следующих:
Уровень 0 содержит "struct_netbios_info_0", Уровень 1 содержит "struct_netbios_info-1".
Возврат ошибки
Возврат функции 0 означает, что все нормально. Возможными возвратами ошибок могут быть следующие:
- сеть не начала работать;- устройство не найдено;- спецпроцессор не найден;- сбой в обмене данными с удаленным спецпроцессором.
Вызов Процедуры NETBIOSGETINFO
Назначение: Получение информации о данной управляющей программе (драйвере) NETBIOS.
Условие вызова
int far pascal netbiosgetinfo (servername,netdevname,level,buf,buflen)int far pascal netbiosgetinfo (servername,netbiosname,level,buf,buflen)char far * servername; /* name of target pc (null if local) */char far * netbiosname; /* netbios network name */short level; /* level of info requested */char far * buf; /* pointer to info buffer */unsigned short buflen; /* byte length of info buffer */
Уровень 1 содержит "struct netbios_info_1".
Возврат ошибки
Функция возвращает 0, если все нормально. Ниже возможны даны возможные возвраты онибок:
- слишком мал размер буфера для фиксированных полей;- устройство не найдено;- спецпроцессор не найден;- сбой в обмене данными с удаленным спецпроцессором.
Вызов Процедуры NETBIOSOPEN
Назначение: Получает handle для отправки управляющей программе NETBIOS.
Описание
          Вызов этой процедуры создает handle для отправки Блоков управления сетью (NCB) в управляющую программу (драйвер) NETBIOS. Программа может определить, какими эти имена являются, путем вызова NETBIOSENUM. Нулевая (пустая) строка может быть использована как имя устройства для скрытой ссылки на первую установленную управляющую программу NETBIOS.
NETBIOSOPT определяет открытые опции, которые включают в себя:
Режим доступа: 1. Обычный (регулярный)(mask 0x3) 2. Привилегированный3. Исключительный          Режим доступа определяет каким образом пользователь хочет разделить доступ к управляющей программе NETBIOS с другими процедурами. В регулярном режиме драйвер (управляющая программа) может быть открыт любым количеством процедур. Помимо этих процессов, еще один процесс может открывать драйвер в привилегированном режиме. Один и только один процесс может открывать драйвер в исключительном режиме. В зависимости от режима доступа операции Блока управления сетью (NCB) ограничены.
Режим Описание
          Регулярный Не позволяет переустанавливать, получать широковещательные дейтаграммы, получать "от любого к любому" Блоки управления сетью (NCB), или использовать постоянныеимена в любом Блоке управления сетью (NCB).
          Превилеги- Не позвроляет переустанавливать или полурованный чать NCB "от любого к любому".
Исключительный Позволяет выполнять любые операции NCB.
Условие вызова
int far pascal netbiosopen (netbiosname, netreserved,netopenopt, nethandle)char far * netbiosname; /* Name of NETBIOS network */char far * netreserved; /* reserved pointer; must be 0 */unsigned short netopenopt; /* open options */int far * nethandle; /* word for returned handle */
Возврат ошибки
Функция возвращает 0, если все нормально. Возможными возвратами ошибок являются:
- Управляющая программа (драйвер) NETBIOS не существует;- неверная опция;- открытый режим противоречит существующему;- недоступны ресурсы системы.
HANDLES NETBIOS являются связями процесс-драйвер. Только тот процесс, который создал данный драйвер, может его использовать.
Вызов Процедуры NETBIOSCLOSE
Назначение: Закрывает handle драйвера NETBIOS.
Описание
          Вызов этой процедуры завершает доступ к драйверу NETBIOS, делает "ошибочным" handle и отменяет все Блоки управления сетью, вызванные процессом, который создал данный идентификатор.
Условие вызова
int far pascal netbiosclose (nethandle, netreserved)int nethandle; /* handle to close */short netreserved; /* reserved, must be zero */
Возврат ошибки
Функция возвращает 0, если все нормально. Возможные возвратыошибок:
- неверный handle.
Вызов Процедуры NETBIOSSUBMIT
Назначение
          Передает Блок управления сетью (NCB) драйверу NETBIOS. handle 0 относится к первому установленному драйверу NETBIOS. Этот драйвер автоматически подвергнут действию процедуры NETBIOSOPEN при необходимости (в регулярном режиме) сразу же, как только вызов NETBIOS обратится к нему используя идентификатор 0.
          NETNCB указывает на Блок управления сетью (NCB), который должен быть выполнен (несцепленный NCB) или на слово-связку, предшествующее NCB (сцепленный NCB).
NETNCBOPT определяет опции обработки NCB, которые включают:
Сцепление: 0 отдельных NCB передается(mask 0x3) 1 отдельный NCB с повторением при ошибке2 NCB сцепливаются с продолжением при ошибке2 NCB сцепливаются с остановкой при ошибке
          Опции сцепления определяют, передается ли отдельный NCB или цепочка NCB. Отдельный Блок NCB может быть выполнен с опцией повторной передачи при ошибке, - в этом случае ядро сети выдает NCB установленное количество раз в ответ на следующие ошибки:
09H - нет доступных ресурсов;12H - отказано в открытии сеанса;21H - занят интерфейс.
          Сцепленные NCB должны быть в одном и том же сегменте и должны быть связаны 16-битовым указателем смещения, который предшествует NCB. Смещение 0xFFFF определяет конец сцепливания.
          Хотя может быть сцеплена любая последовательность команд NCB, не все возможности являются приемлимыми. Например, Вы не можете открыть сеанс и послать пакет данных по нему, связав команды SEND и CALL. Поле NCB_LSN, возвращенное по команде CALL NCB, должно быть скопировано в SEND NCB - ядро сети не поддерживает этого автоматически. Блоки управления сетью (NCB) в цепочке "с продолжением при ошибке" выполняются независимо один от другого, и вне зависимости от ошибок в цепочке; подобная цепочка просто обеспечивает быструю передачу набора Блоков NCB драйверу. Блоки, которые не были обработаны вследствие ошибки ранее в цепи, будут иметь свое поле NCB-CMD-CPLT установленное как 0xB (Команда отменена). Этот тип цепочки обычно должен иметь только режим ожидания. Неожидаемые Блоки NCB принимаются, но в этом случае именно немедленный (а не конечный) возврат определяет, продолжится или остановится процесс.
Условие вызова
int far pascal netbiossubmit (nethandle, netncbopt, netncb)int nethandle; /* handle to issue ncb against */unsigned short netncbopt; /* option flags */struct ncb far * netncb; /* Address of NCB */
Функция возвращает 0, если все нормально. Возможными возвратами ошибок являются:
- неверный handle;- неправильные опции;- отказано в доступе;- недоступны ресурсы драйвера;- определенные NETBIOS коды немедленного возврата(неожидаемый NCB);- определенные NETBIOS коды конечного возврата(режим ожидания NCB).
[начало] [оглавление]Функционирование
          Ядро Сетей Microsoft (Microsoft Networks), используемое Администратором ЛВС (LAN Manager), поддерживает несколько управляющих программ (драйверов) NETBIOS посредством рассмотрения каждой как поименованного устанавливаемого драйвера устройства, который может быть открыт и закрыт. Прикладные программы, использующие один и тот же драйвер NETBIOS, могут получать совместный доступ к именам и сеансам, которые они создали, просто путем передачи номера имени или сеанса другому процессу. Это позволяет другим процессам посылать и получать данные от имени процессов-"владельцев", или же высвобождать совместно используемые имена и сеансы.
          В защищенном режиме Блоки управления сетью (NCB) NETBIOS обрабатываются также, как и под управлением MS-DOS 3.X, посредством прерывания 5C и 2A, за исключением следующего:
1. Поле NCB_POST@ теперь содержит handle семафора системы, а не подпрограмму асинхронной нотификации (объявления). Ядро сети освободит этот семафор, когда завершится режим неожидания NCB.Иденhandle семафора, равный 0, считается пустым и не освобождается.
2. Поля NCB_POST@ и NCB_BUFFER@ временно изменены ядром сети во время обработки Блока управления сетью (NCB). Прикладные программы не должны зависеть от величин этих полей, пока не будет завершен NCB.
3. Некоторые функции NCB не разрешены, в зависимости от режима доступа, определенного вызовом NETBIOSOPEN.
4. Процессы могут коллективно использовать ресурсы NETBIOS, которыми они располагают, просто путем передачи номеров требуемых имен и сеансов другим процессам (как об этом сказамно выше). Получающие процессы просто используют номера общих имен или сеансов в Блоках управления сетью (NCB), которые они создают. Такие процессы должны, безусловно,послать Блоки NCB против handle, которые они сами создали (процедурой NETBIOSOPEN), в этот же драйвер.
[начало] [оглавление]Программа ЛВС ПЭВМ
          Программа ЛВС ПЭВМ IBM (IBM PC LAN Program), ранее носившая имя Программа Сети ПЭВМ IBM (IBM PC Network Program) была первоначально предназначена для работы с DOS 3.1 и Сетью ПЭВМ IBM (IBM PC Network) с модулированной передачей. Программа ЛВС ПЭВМ требует поддержки NETBIOS посредством Служебной Программы ЛВС ПЭВМ (PC LAN Support Program) и DOS 3.2 или выше, для работы в ЭКС Token-Ring.
          Программа ЛВС ПЭВМ (PC LAN Program) состоит из одного большого файла, который может быть вызван одним из четырех способов: пользователь выполняет команду NET START,а затем определяет переадресатор, получатель, отправитель или спецпроцессор. Первые три варианта (переадресатор,получатель, отправитель) предназначены для рабочих станций, а последний (спецпроцессор) является неспециализированным файловым процессором/процессором печати, который работает как фоновая задача на рабочей станции. На рис. 6-2 показан образец такой реализации, где одна ПЭВМ служит как файловый процессор, а другая - как процессор печати.
          Наиболее традиционный способ построения сети - с помощью переадресатора. Он перехватывает ввод/вывод диска и печатающего устройства рабочей станции и посылает его на спецпроцессор; пользователи также могут посылать сообщения на другие машины. Получатель, отправитель и спецпроцессор делают то же, что и переназначатель, но со следующими добавлениями: получатель получает и регистрирует сообщения на любом устройстве или файле; отправитель позволяет пользователю передавать файлы; спецпроцессор позволяет совместно использовать жесткие диски и печатающие устройства.
          Процедура установки управляется меню. Если установка произведена, с Программой Сети ПЭВМ (PC Network Program) можно работать либо набирая команды на клавиатуре по подсказке DOS, либо с помощью меню.
          Первоначальная версия программы ЛВС ПЭВМ подверглась жесткой критике - главным образом из-за проблем, связанных с производительностью. Эта проблема обусловлена тем, что, в отличие от NetWare фирмы Novell, Программа ЛВС ПЭВМ основывается на DOS для работы с файлами и печатью. Но с совершенствованием операционной системы и появлением OS/2, эта проблема потеряла свою остроту. Например, DOS 3.3 имеет дополнительно таблицу размещения записей файла (FAT) (команду FASTOPEN). Весия 1.3 Программы ЛВС ПЭВМ (PC LAN Program) имеет следующие свойства, которые облегчили по сравнению с первоначальной версией этой программы и проблему управления: контролируемый паролем доступ к спецпроцессору; централизированное определение ресурсов и управление ими, включая установку времени/даты на главном спецпроцессоре для синхронизации даты и времени на всех спецпроцессорах и рабочих станциях, для управления печатью, определения пользователей и привилегий, а также для управления меню выбора прикладных программ для отдельных пользователей; доступ администратора к ресурсам с любой рабочей станции, поддержка для удаленной загрузки программ и операционной системы (т.е. поддержка для рабочих станций, не имеющих дисков); возможность просматривать начавших сеанс пользователей, и, наконец, выбор печати, очередность и отображение состояния для удаленных рабочих станций. Версия 1.3 также обладает повышенной производительностью работы.
[начало] [оглавление] 
Спецпроцессор ЛВС
          Спецпроцессор ЛВС OS/2 IBM (LAN Server) использует NETBIOS для обмена данными (коммуникации) в ЛВС. Спецпроцессор обеспечивает, как для прикладных программ DOS (посредством Программы ЛВС ПЭВМ), так и для прикладных программ OS/2, совместное использование ресурсов - дисков, печатающих устройств и подсоединенных устройств, плюс средства для определения, управления и руководства доступом к ресурсам ЛВС, наряду с повышенной защитой и управлением печатью (до восьми печатающих устройств). Эти преимущества сходны с теми, которые обеспечиваются Программой ЛВС ПЭВМ (PC LAN Program), за исключением того, что защита файлов снижена до файлового уровня. Для работы Спецпроцессора ЛВС требуется Расширеная версия OS/2 (Extended Edition). Спецпроцессор ЛВС также обеспечивает удаленнрое выполнение программ.
          Часть программного обеспечения Спецпроцессора ЛВС бала создана фирмой Microsoft (в основном переадресатор). Фирма IBM не реализовала многие из Интерфейсов прикладного программирования (API) Microsoft в Администраторе ЛВС (LAN Manager), в частности, Средства межпроцессовой коммуникации, которые несовместимы с Прикладной архитектурой систем (Systems Application Architecture - SAA). Вместо этого, для разработки распределенных прикладных программ необходимо использовать APPC/PC (Перспективное межпрограммное взаимодействие/ПЭВМ), включенное вместе с Расширеной Версией OS/2, особенно в ЭКС Token-Ring со смешанными ЭВМ. Для ЛВС ПЭВМ эта проблема не столь остра - в них можно использовать Администратор ЛВС или другие продукты на основе спецпроцессора, чтобы обеспечить совместимость продуктов. Крупные фирмы, такие как 3Com, Banyan и Novell, предлагают, по меньшей мере, некоторый уровень совместимости (как, например, APPC) с Расширенной Версией OS/2 и Спецпроцессором ЛВС OS/2.
          Таким образом, создается впечатление, что компания IBM рассматривает Спецпроцессор ЛВС как средство перехода от DOS к OS/2. В этом убеждает и тот факт, что Спецпроцессор ЛВС работает под управлением OS/2 и обслуживает как Программу ЛВС ПЭВМ (PC LAN Program) на основе DOS, так и эмулятор NETBIOS OS/2.
25 внутренние механизмы сервера БД
Хотя данный материал предлагает некоторые рекомендации по конфигурированию систем, полезность этих рекомендаций в значительной степени зависит от анализа самого приложения. Важность такого анализа невозможно переоценить! Эффективность работы самого приложения и СУБД намного важнее, чем конфигурация хост-машины. Имеются буквально сотни примеров небольших изменений, проведенных в приложении или в схеме базы данных, которые обеспечивали 100- или 1000-кратное (или даже большее!) увеличение производительности системы. Например, в зависимости от того индексируется или нет таблица с помощью ключа просмотра (lookup key), выполнение оператора select, который запрашивает одну определенную запись, может приводить к тому, что СУБД будет читать из таблицы всего одну запись, либо каждую запись в таблице, содержащей 10 Гбайт данных. Часто для того чтобы оптимально обрабатывать несколько различных шаблонных обращений, генерируемых приложением, таблица должна индексироваться более чем одним ключом или набором ключей. Хорошо осмысленная индексация может иметь весьма существенное воздействие на общую производительность системы (см. разд. 2.2.6.1). После начальной инсталляции системы обязательно нужно произвести сбор статистики о ее работе, чтобы выяснить необходимость внесения изменений в базу данных, даже для приложений собственной разработки или приложений третьих фирм. Часто оказывается возможным улучшить производительность приложения путем реорганизации базы данных даже без обращения к исходному коду приложения.
Другим соображением, которому уделяется недостаточно внимания, но которое часто оказывает огромные воздействие на результирующую производительность системы, являются конфликты по внутренним блокировкам. СУБД должна блокировать доступ к данным при наличии конфликтующих одновременных обращений. Любой другой процесс, который требует доступа к этим данным должен быть отложен до тех пор, пока блокировка не будет снята. Если выбрана неоптимальная стратегия блокировок, то система может оказаться очень плохо работающей.
Каждая СУБД имеет огромное число настраиваемых параметров, некоторые из которых могут серьезно воздействовать на общую производительность системы. Приводимые здесь рекомендации предполагают разумную настройку приложений и СУБД.
Предпосылки выбораНиже перечислены вопросы, ответы на которые позволяют обобщить процесс достижения разумной точности конфигурации СУБД:
Какая используется СУБД? Это "2N" или многопотоковая реализация?
Какие используются мониторы транзакций (если таковые вообще применяются)?
Можно ли использовать систему в конфигурации клиент/сервер?
Сколько одновременно активных пользователей должна поддерживать система?
Можно ли выделить основной или доминирующий шаблон (образец) обращения к системе? Какие запросы доминируют в нагрузке?
Какова стратегия индексации? Какие запросы будут оптимизированы с помощью индексации (например, преобразуются для реализации произвольного доступа к данным вместо последовательного) и какие запросы должны быть реализованы с помощью полного или частичного сканирования таблицы?
Насколько велик чистый размер базы данных?
Имеется ли достаточное количество дисковых накопителей и главных адаптеров SCSI, сконфигурированных для обеспечения обработки предполагаемой нагрузки? Имеются ли отдельные диски для журналов СУБД и архивов?
Имеется ли достаточная емкость дисковой памяти для хранения необработанных данных, индексов, временных табличных пространств, а также место для возможного увеличения объема данных?
Достаточно ли число процессоров, сконфигурированных для работы с предполагаемым количеством пользователей?
Требуется ли специальная выделенная сеть для организации связи между клиентскими системами и сервером?
Если предполагаемая нагрузка ориентирована на интенсивное внесение обновлений в базу данных, имеется ли место в конфигурации для NVRAM?
Согласована ли предполагаемая стратегия резервного копирования с типом, числом и местом размещения устройств резервного копирования SCSI?
Выбор вычислительной моделиВ большинстве прикладных систем СУБД можно выделить три логических части: пользовательский интерфейс (средства представления), обеспечивающий функции ввода и отображения данных; некоторую прикладную обработку, характерную для данной предметной области; и собственно сервисы СУБД. Пользовательский интерфейс и прикладная обработка обычно объединены в одном двоичном коде, хотя некоторые из наиболее продвинутых приложений теперь обеспечивают многопотоковую фронтальную обработку, которая отделена от средств представления. Как правило, по мере роста базы данных сервер СУБД реализуется на выделенной системе, чтобы гарантировать минимизацию помех для его работы.

Рис. 2.3. Сравнение модели клиент/сервер с моделью разделения времени при работе прикладной системы Oracle*Financials.
Если в системе можно реализовать модель вычислений клиент/сервер, отделяющую фронтальную (прикладную) обработку и средства представления от поставщика услуг СУБД, ее использование обычно обеспечивает существенное улучшение общей производительности системы. Такая организация системы позволяет наиболее важному ресурсу (серверу СУБД) работать без помех на своей собственной хост-машине. Это в первую очередь справедливо для систем, в которых работа средств представления связана с управлением сотнями или тысячами терминалов в режиме cbreak. Большинство программ, базирующиеся на curses- (screen-), сегодня используют cbreak-поддержку терминалов.
Режим разделения времени, в отличие от режима клиент/сервер, обычно обеспечивает большую производительность только тогда, когда требования к компоненту представления оказываются очень легкими, или когда одновременная пользовательская нагрузка невелика. Существенно что приложения, в основе компонента представления которых лежат формы, никогда не бывают легковесными. Даже приложения, работающие в диалоговом режиме printf/get обычно значительно более тяжелые, что позволяет оправдать использование конфигураций клиент/сервер. Тест TPC-A определяет возможно наиболее легкое требование приложения/представления (он включает ровно по одному вызову scaf(n) и printf(n)). Следует отметить, что даже тест TPC-A работает только на 5% быстрее в режиме разделения времени. Некоторые сравнительно недавние исследования компании Sun с использованием Oracle*Financials и Oracle 7 показали, что 6-процессорный сервер СУБД на базе SPARCserver 1000 с фронтальной системой на базе SPARCstation 10 Model 512 может поддерживать почти на 40% пользователей больше, чем 8-процессорный SPARCserver 1000, работающий в режиме разделения времени (рис. 2.3).
Рекомендации:
Всегда, если это возможно, следует применять конфигурацию клиент/сервер, если только нагрузка по прикладной обработке и обработке представления являются необычно легкими.
Где это возможно, собственно сервер СУБД должен работать на выделенной системе.
Мониторы обработки транзакцийИспользование мониторов обработки транзакций является одним из методов достижения более высокой производительности для имеющейся конфигурации, особенно в режиме клиент/сервер. Иногда мониторы обработки транзакций оказываются очень полезными для создания гетерогенных баз данных, позволяющих хранить некоторые данные в одном формате (например, Oracle на Sun), а другие данные в другом (возможно Ingres на VAX или IMS на мейнфрейме IBM). Кроме того, некоторые TP-мониторы предоставляют сервис для легковесного компонента представления. Хорошо известен TP-монитор компании IBM - Customer Information Control System (CISC). Несколько реализаций CICS (MicroFocus, XDB, VI Systems, Integris) доступны в настоящее время на большинстве аппаратных платформ. Другими известными мониторами являются Tuxedo/T компании USL, TopEnd от NCR и Encina от Transarc.
TP-мониторы представляют собой промежуточный слой программного обеспечения, который располагается между приложением и системой или системами СУБД. При этом приложение должно быть модифицировано так, чтобы оно могло выдавать транзакции, написанные на языке монитора транзакций, а не обращаться прямо к базе данных посредством обычных механизмов (подобных различным формам встроенного SQL). Программисты прикладных систем являются также ответственными за составление файла описания, который отображает транзакции в определенные обращения к базе данных на родном языке обращений нижележащей СУБД (почти для всех СУБД под UNIX это SQL).
Гибкость доступа к даннымИспользование мониторов транзакций практически не накладывает каких-либо ограничений на многообразие или сложность запросов доступа к нижележащей СУБД. Например, вполне осмысленной оказывается транзакция, выдающая запрос на набор данных из базы данных DB2 на мейнфрейме IBM, работающей под управлением ОС MVS, а другой набор данных из локальной базы данных Sybase, и затем сливающая оба набора вместе для представления приложению. В результате создается иллюзия того, что данные хранятся в унифицированной базе данных, размещенной в одном и том же "хранилище данных" (data warehause).
В связи с тем, что во многих "старых" (legacy) системах используются мониторы обработки транзакций CICS, мигрирующая часть или все базы данных, связанные с этими системами, могут работать с небольшими изменениями существующих приложений. Все что требуется - это физический перенос данных на новую платформу и модификация описания транзакций для использования данных на новом месте. Однако сложность такого переноса не должна недооцениваться, поскольку он часто требует внесения изменений в представление данных (трансляцию COBOL "PIC 9(12)V99S" в C++ float) и организацию данных (например, из сетевой архитектуры IMS в реляционную архитектуру, используемую почти повсеместно СУБД на базе UNIX). Но возможность сохранить части, связанные с прикладной обработкой и представлением существующих приложений существенно сокращает сложность и риск, связанные с таким переносом.
Вопросы производительностиПомимо достижения определенной гибкости за счет использования TP-мониторов, такая организация оказывается выгодной и с точки зрения увеличения производительности системы. TP-монитор всегда представляет собой многопотоковую программу. Поскольку TP-монитор открывает свое собственное соединение с СУБД, одновременно устраняя необходимость выполнения каждым прикладным процессом прямых запросов к СУБД, число одновременно работающих пользователей СУБД существенно сокращается. В подавляющем большинстве случаев СУБД обслуживает только одного "пользователя" - TP-монитор. Это особенно важно, когда СУБД относится к классу "2N", поскольку в этом случае используется только один теневой процесс (для обеспечения соединения с TP-монитором), а не по одному процессу на каждый процесс конечного пользователя (рис. 2.4). Это может существенно сократить накладные расходы, связанные с переключением контекста на сервере СУБД.

Рис.2.4. Системы СУБД клиент/сервер сконфигурированные для работы с мониторами обработки транзакций. Теневой процесс на серверной системе появляется, когда СУБД использует архитектуру "2N".
TP-мониторы позволяют также улучшить производительность за счет сокращения объема информации, пересылаемой между СУБД и прикладным процессом. Поскольку определенную часть каждой транзакции составляют только минимально требуемые данные, общий объем пересылки данных обычно может быть сокращен. Это особенно важно, когда клиент и сервер соединены между собой посредством достаточно занятой сети и/или сети с низкой полосой пропускания, подобной глобальной сети на спутниковых каналах связи.
Рекомендации:
TP-мониторы могут рассматриваться как кандидаты для включения в состав системы, когда доступен исходный текст приложения.
TP-мониторы следует использовать для интеграции в корне отличных источников информации базы данных.
TP-мониторы особенно полезны для сокращения трафика клиент/сервер на сетях с низкой полосой пропускания или глобальных сетях.
Применение системе TP-монитора следует рассматривать, когда должно обслуживаться большое количество пользователей и используемая СУБД предпочитает или требует реализации архитектуры "2N".
Подсистема основной памятиСреди различных компонентов аппаратуры сервера СУБД конфигурация памяти системы обычно имеет самое большое воздействие на ее производительность. Хотя для многих людей память представляется только хранилищем выполняемых программ, большая часть основной памяти в системах СУБД используется в качестве буфера (кэша) данных, позволяющего во многих случаях устранить необходимость выполнения физического ввода/вывода с диска. Поскольку обращение к основной памяти выполняется примерно в 30000 раз быстрее, чем обращение к быстрому диску, минимизация дискового в/в является первостепенно важной задачей. (Обращение к памяти выполняется примерно за 500 нсек даже в самых худших условиях (при наличии промаха при обращении к кэш-памяти, требующего выталкивания модифицированной строки в основную память)). Возможно не будет преувеличением сказать, что "возня" с другими конфигурационными параметрами бесполезна, если в системе не хватает основной памяти. Если нужно создать конфигурацию системы без наличия достаточной информации (обычный случай при покупке новой системы), возможно лучше закупить избыточный объем памяти, чем недооценить его. К счастью, обычно ошибки по конфигурации памяти сравнительно легко исправляются.
Выбор размера буфера ввода/вывода СУБДКаждая СУБД называет свои буфера данных по разному, но все они выполняют одну и ту же функцию. Oracle называет эту память Глобальной Областью Системы (SGA - System Global Area), в то время как Sybase называет ее Кэшем Разделяемых Данных (Shared Data Cashe). Обычно буфер реализуется как большой массив разделяемой памяти, и его размер определяется специальным параметром в управляющем файле или таблицах СУБД. Размер памяти, необходимый для организации дискового кэша СУБД, меняется в широких пределах от приложения к приложению, но для примерной оценки размера буфера могут быть использованы следующие эмпирические правила.
Практические опыты различных компаний с СУБД Oracle и Sybase показали, что в зависимости от размера базы данных размер области памяти под буфера может варьироваться в очень широких пределах (от 4 Мбайт до более чем 1 Гбайт). Даже указанный больший размер буфера сегодня может быть превышен, поскольку начинают появляться реализованные на базе современных аппаратных платформ значительно большие по размеру базы данных (объемом 50 - 300 Гбайт). Однако следует иметь в виду, что как и при использовании любой кэш-памяти, увеличение размера буфера в конце концов достигает точки насыщения. Очень грубо размер кэша данных можно оценить, выделяя от 50 до 300 Кбайт на каждого пользователя. Каждая из известных систем СУБД имеет механизм сообщений об эффективности использования кэша разделяемых данных. Большинство систем могут также обеспечивать оценку того, какой эффект будет давать увеличение или уменьшение размера кэша.
Возможно самым простым и наиболее полезным является эмпирическое правило, которое называется "правилом пяти минут". Это правило широко используется при конфигурировании серверов баз данных, значительно большая сложность которых делает очень трудным точное определение размера кэша. Существующее в настоящее время соотношение между ценами подсистемы памяти и дисковой подсистемы показывает, что экономически целесообразно кэшировать данные, к которым осуществляются обращения более одного раза каждые пять минут.
Это означает, что данные, к которым обращения происходят более часто, чем один раз в пять минут, должны кэшироваться в памяти. Соответственно, чтобы оценить размер кэша данных необходимо просуммировать объемы всех данных, которые приложение предполагает использовать более часто, чем один раз в пять минут на уровне всей системы. Поэтому при определении необходимого объема памяти системы следует предусмотреть по крайней мере этот размер кэша данных. Дополнительно, следует зарезервировать еще 5-10% для хранения верхних уровней индексов B-деревьев, хранимых процедур и другой управляющей информации СУБД.
Не стоит волноваться из-за того, что чрезмерное увеличение размера кэша обычно не дает существенного эффекта. Указанные прогнозируемые объемы должны использоваться только для получения грубой оценки необходимой конфигурации системы. Каждая коммерческая СУБД обеспечивает механизм для определения стоимости или преимуществ изменения размера различных кэшей СУБД. Когда система инсталлирована и начинает работать, необходимо использовать эти механизмы для определения эффекта от изменения размеров кэша ввода/вывода СУБД. Следует отметить, что результаты часто могут оказаться удивительными. Например, выделение слишком большого объема памяти для кэша разделяемых данных может лишить пользовательское приложение (или, что еще хуже, сам сервер СУБД) требуемой для нормальной работы памяти. Память может также перераспределяться между кэшем разделяемых данных и пулом виртуальной памяти, используемой операционной системой для буферизации операций файловой системы UNIX (UFS).
Хотя основной целью СУБД на макроуровне является управление томами данных, которые по определению имеют очень большой объем и неизбежно во много раз превышают объем основной памяти, буквально десятки исследований многократно показали, что доступ к данным в общем случае подчиняется правилу "90/10": 90% всех обращений выполняются к 10% данных. Более того, совсем недавние исследования показали, что к "горячим" данным, обращения к которым составляют 90% всех обращений, снова применимо правило 90/10. Таким образом, примерно 80% всех обращений к данным связаны с доступом к примерно 1% агрегатированных данных. Следует отметить, что это отношение включает обращения к внутренним метаданным СУБД (включающих индексы B-деревьев и т.п.), обращения к которым обычно скрыты от прикладного программиста. Хотя желательно иметь коэффициент попаданий в кэш примерно на уровне 95%, по экономическим соображениям невозможно слепо обеспечить объем кэша в памяти, позволяющий разместить 10% всех данных: даже для скромных баз данных объемом 5 Гбайт это потребовало бы увеличения размера основной памяти до 500 Мбайт. Однако обычно всегда возможно обеспечить кэш объемом в 1% всех данных даже для очень больших баз данных. Те же самые 500 Мбайт основной памяти, таким образом, позволяют обслужить базу данных объемом 50 Гбайт, а максимальный размер памяти, например, SPARCcenter 2000 (5 Гбайт) компании Sun достаточен для поддержки баз данных объемом 400-500 Гбайт. (При наличии баз данных такого размера для поддержки неизбежно большого числа пользовательских приложений и т.д. очевидно также потребуется существенная часть этой памяти).
Рекомендации:
Размер кэша данных СУБД следует выбирать так, чтобы данные, обращения к которым выполняются чаще одного раза в пять минут, могли бы храниться в кэше. Дополнительно необходимо добавить 5-10%.
Если шаблон (образец) обращений не может быть определен, необходимо обеспечить кэш емкостью, соответствующей по крайней мере 1% от чистого объема данных СУБД (не считая индексов и накладных расходов).
В крайнем случае размер кэша данных конфигурируется исходя из выделения по 100-150 Кбайт на пользователя.
Дополнительные требования к памятиЕстественно конфигурация системы должна обеспечивать также пространство для традиционного использования памяти. В СУБД на базе UNIX всегда необходимо обеспечить по крайней мере 16 Мбайт для базовой операционной системы. Далее, необходимо предусмотреть пространство объемом 2-4 Мбайт для ряда программ СУБД (программ ведения журнала, проверки согласованного состояния, архиваторов и т.п.) и достаточно пространства для размещения в памяти двоичных кодов приложения. Объем двоичных кодов приложения составляет обычно 1-2 Мбайт, но иногда они могут достигать 16-20 Мбайт. Операционная система обеспечивает режим разделения двоичных кодов между множеством пользующихся ими процессов, поэтому необходимо резервировать пространство только для одной копии. Пространство для размещения самого кода сервера СУБД зависит от общей архитектуры сервера. Для архитектуры "2N" следует выделять по 100-500 Кбайт на пользователя. Многопотоковые архитектуры требуют только 60-150 Кбайт, поскольку они имеют намного меньше процессов и намного меньшие накладные расходы.
Существует также эмпирическое правило, которое гласит, что неразумно конфигурировать менее, чем примерно 64 Мбайт памяти на процессор. Обрабатываемая каждым ЦП дополнительная информация требует выделения некоторого пространства для того, чтобы обойти интенсивную фрагментацию памяти.
ПроцессорыПотребление процессорных ресурсов очень сильно варьируется в зависимости от используемого приложения, СУБД, индивидуальных пользователей и даже от времени дня. Например, результаты теста TPC-A показывают, что восьмипроцессорный SPARCserver 1000 способен обрабатывать запросы от 4000 пользователей, или от 500 пользователей на процессор. (Эти результаты были достигнуты на многопотоковом сервере Oracle Version 7, работающим в режиме клиент/сервер, причем в качестве фронтальной системы использовался монитор обработки транзакций Tuxedo/T.) Следует отметить, что этот результат был достигнут специалистами компании Sun и Oracle путем очень тщательной настройки ОС Solaris, СУБД Oracle и самого оценочного теста. Возможности этих специалистов по настройке системы, очевидно значительно превосходят возможности большинства пользователей. Более реалистическая верхняя граница числа пользователей на процессор возможно составляет порядка 100-200 пользователей на один процессор 50 МГц SuperSPARC, даже для легких транзакций типа TPC-A. Более крупные приложения естественно приводят к меньшему числу пользователей на процессор.
Работа прикладного пакета Oracle*Financials создает для системы значительно более тяжелую рабочую нагрузку, чем работа теста TPC-A. Это связано с несколькими причинами. Во-первых, по сравнению с одной транзакцией, выполняемой тестом TPC-A, пакет Financials генерирует множество различных транзакций. Во-вторых, после того как данные найдены, сама основная СУБД должна выполнить нетривиальный объем прикладной обработки. В-третьих, пакет Financials не может работать с монитором обработки транзакций. Эксперименты компании Sun с этим пакетом показали, что процессор 50 МГц SuperSPARC может обрабатывать примерно 15 полностью активных пользователей в режиме разделения времени и 40-60 полностью активных пользователей в режиме клиент/сервер, даже с минимальным временем обдумывания.
Таблица 2.3. Примерное число поддерживаемых пользователей на ЦП
Тип приложения Количество процессоров 50 Мгц SuperSPARC
124816
TP-монитор клиент/ сервер 200-300350-500550-850800+1000+
Легковесное клиент/ сервер 150-200250-350450-550725+800+
многопотоковое Разделение времени 50-8085-135150-225200-300250-300
Тяжеловесное Клиент/ сервер 50-10085-170150-250200-350350-600
многопотоковое Разделение времени 20-6035-10060-175100-300150-250
Тяжеловесное 2N клиент/ сервер 40-7570-125120-220200-600300-750
Разделение времени 15-4025-7045-12075-200110-230
Ни операционная система Solaris 2, ни СУБД не масштабируются линейно (то же самое происходит и с конкурирующими операционными системами). Поскольку как Solaris 2, так и версии СУБД под Solaris 2 являются относительно новыми, таблица 2.3 отражает коэффициент масштабирования на уровне 70% (т.е. дублирование процессоров дает 70% увеличение производительности). Ожидается, что эти цифры со временем будут улучшаться по мере дальнейшей настройки как Solaris 2, так и СУБД особенно в направлении достижения лучшей многопроцессорной масштабируемости.
Эти цифры заявлены компанией Sun исключительно для интерактивной пользовательской нагрузки. В действительности рабочие нагрузки, подобные показанным здесь, редко возникают (если вообще возникают) без пакетной обработки. В общем случае для обработки пакетных заданий в конфигурацию системы необходимо включить дополнительный процессор. До сих пор на этот счет доступно очень мало данных. Приведенное здесь эмпирическое правило должно использоваться только в качестве первой оценки.
Дисковые подсистемы ввода/выводаКак уже было отмечено при обсуждении требований к основной памяти, обращения к диску выполняются примерно в 30000 медленнее, чем к памяти. В результате, лучший способ оптимизации дискового ввода/вывода - вообще его не выполнять! Однако экономически это не оправдано. Таким образом, обеспечение достаточной пропускной способности (емкости доступа) подсистемы ввода/вывода, является решающим фактором для обеспечения высокой устойчивой производительности СУБД. Множество технических соображений приводят к некоторым удивительным результатам.
Соотношение запрос/индекс/дискБез понимания приложения заказчика, стратегии индексации, принятой администратором базы данных, а также механизмов поиска и хранения СУБД сложно сделать точное утверждение о том, какого типа доступ к диску данная транзакция будет навязывать системе. Особенно трудно количественно определить сложные транзакции, которые имеют место в приложениях третьих фирм, например, в продукте R/3 SAP, который надстроен над Oracle. Однако в отсутствие фирменной информации стоит предположить, что любая транзакция, которая находит небольшое число специально поименованных записей из индексированной таблицы "по индексному ключу" будет представлять собой операцию произвольного доступа к диску. Например, транзакция
select name, salary from employee
were phone-number = "555-1212" or
ssn = "111-111-1111";
почти наверняка будет осуществлять произвольное обращение к диску, если таблица служащих индексируется с помощью phone-number и ssn. Однако, если таблица индексируется только именем и номером служащего, то такая транзакция будет выполняться путем последовательного сканирования таблицы, вполне возможно затрагивая каждую ее запись.
Запросы, которые содержат целый ряд значений ключей, могут генерировать комбинацию произвольного и последовательного доступа, в зависимости от имеющей место индексации.
Рассмотрим запрос
select part_no, description, num-on-hand from stock
where (part_no > 2000 and part_no < 24000);
Если складская таблица индексируется с помощью part_no (что очень вероятно), этот запрос будет вероятно генерировать последовательное сканирование индексов (а возможно только частичное сканирование, если индексы физически хранятся в некотором способом отсортированном порядке), за которым последует произвольная выборка подходящих строк из таблицы данных. Однако, если по каким-то причинам эта таблица не индексировалась бы с помощью part_no, то запрос почти наверняка приводил бы к полному сканированию таблицы.
Напомним, что любое обновление базы данных связано и с обновлением всех затронутых индексов, а также с выполнением записи в журнал. К сожалению, вся эта техника уходит далеко за рамки данной части курса, требуя основательного понимания работы конкретной используемой СУБД, сложной природы запросов и методов оптимизации запросов. Оценка требований к выполнению дисковых операций оказывается неточной без детальной информации о том, как СУБД хранит данные, даже для показанных здесь простых транзакций. Вычисление количества и типа дисковых обращений для операции соединения пяти таблиц, ограниченной коррелирующим подзапросом был бы сложен даже для авторов приложения!
Замечание. В случаях, когда ожидается, что такие запросы будут определять общую производительностью прикладной системы, следует настаивать на консультациях экспертов. Диапазон ошибок для такого рода запросов часто составляет 1000:1!
Емкость и пропускная способность дисковой памятиОдной из наиболее общих проблем в СУБД является обеспечение большой емкости дисковой памяти для хранения данных при достаточной пропускной способности дисковой подсистемы. На большинстве серверов при выполнении обращений к диску доминируют операции произвольного доступа. Сегодня на рынке доступны множество дисков, но их производительность при выполнении операций произвольного доступа почти одна и та же:
Таблица 2.4.Временные параметры некоторых дисков
НМД Задержкавращения (мс) Среднее время поиска (мс) Скорость обращений к диску оп/с, Мб/с (объем блока данных - 8 Кб)
ПолностьюпроизвольныеПолностьюпоследовательные
424 Мб 6.8 14 50, 0.400323, 2.6
535 Мб 5.56 12 57, 0.456451, 3.6
1.05 Гб 5.56 11.5 67, 0.536480, 3.8
2.1 Гб 5.56 11.5 62, 0.496494, 4.0
Хотя диск 2.1 Гб имеет впятеро большую емкость, чем диск 424 Мб, он обеспечивает только на 24% лучшую скорость выполнения операций произвольного доступа. В действительности диск 1.05 Гб быстрее, чем диск 2.1 Гб. (Хотя их характеристики очень близки, диск 1.05 Гб имеет дополнительное фирменное обеспечение в своем встроенном контроллере. Главное отличие состоит в том, что контроллер диска 1.05 Гб способен соединяться и разъединяться с шиной SCSI намного быстрее, чем контроллер диска 2.1 Гб). По этим причинам наилучшие результаты почти всегда достигаются при использовании наименьшего по емкости диска, даже когда больший диск имеет превосходные спецификации по всем параметрам. Например, сервер SPARCserver 1000 может оснащаться дисками емкостью 535 Мб, 1.05 Гб и 2.1 Гб. Как видно из таблицы 2.5, для заданного объема дисковой памяти (16 Гбайт), общая пропускная способность дисковой подсистемы существенно выше при использовании дисков 535 Мб (больше чем в три раза).
Использование дисков такой малой емкости не всегда практично, поскольку общие требования к емкости дисковой подсистемы могут привести к использованию дисков большей емкости, или возможно в системе окажется недостаточно доступных слотов периферийной шины для конфигурирования необходимого числа главных адаптеров SCSI. Тем не менее, целесообразно рассмотреть возможность использования дисковых подсистем с большей пропускной способностью в таких системах, где о действительной нагрузке ввода/вывода известно, что она носит взрывной характер, либо полностью неизвестна, или где общий объем данных относительно невелик по сравнению с количеством имеющих к ним доступ пользователей.
Таблица 2.5. Пропускная способность ввода/вывода для дисковой памяти емкостью 16 Гб
НМД Требуемое количество Общаяскорость оп/сСтрок SCSIСтоимость (1994 г.)Цена заоперацию
535 Мб 32 1824 8$50360$27
1.05 Гб 16 1072 4$39580$37
2.1 Гб 8 496 2$37390$75
Было бы серьезной ошибкой подбирать для системы дисковые накопители исключительно исходя из требуемой общей емкости дисковой памяти. Хотя эта проблема не нова, со временем она становится все более серьезной, поскольку емкость дисковых накопителей и требования к общей емкости дисковой памяти начинают увеличиваться значительно более быстрыми темпами, чем пропускная способность дисков.
Рекомендации:
Чтобы добиться наибольшей общей производительности и пропускной способности дисковой подсистемы следует конфигурировать наименьшие по емкости дисковые накопители.
На одной шине Fast SCSI-2 (10 Мб/с) следует конфигурировать умеренное число (3-5) дисков. Для шины Fast-and-Wide SCSI (20 Мб/с) количество дисков может быть увеличено немного более чем в два раза (8-11 дисков).
Количество шин SCSI следует выбирать максимально возможным, естественно с учетом других ограничений.Для увеличения эффективной пропускной способности дисковой подсистемы следует использовать специальные программные средства типа On-line:DiskSuite и расщепление дисков.
Файловые системы по сравнению с "чистыми" (неструктурированными) дискамиБольшинство СУБД позволяют администратору системы выбрать способ размещения файлов СУБД (на "чистых" дисках или в стандартной файловой системе UNIX). Некоторые системы, наиболее известными из которых являются Ingres и Interbase, навязывают использование файловой системы UNIX. Для систем, которые допускают выбор указанных возможностей, приходится оценивать целый ряд разных критериев.
Хранение данных в файловой системе оказывается менее эффективным (отличие составляет по крайней мере 10%), поскольку при выполнении каждого обращения к диску со стороны СУБД в работу включается дополнительный слой системного ПО. Поскольку в больших СУБД часто одним из ограничивающих ресурсов является мощность процессора, использование "чистых" разделов (raw partition) улучшает производительность системы при пиковой нагрузке. Только по этой причине большинство администраторов баз данных обычно предпочитают хранение данных на "чистых" разделах дисков. Если ожидается, что система достигнет своих пределов производительности, особенно в части использования мощности ЦП, то это может быть наиболее подходящий выбор. Однако следует отметить, что эффективность процессора в действительности становится под вопрос только под пиковой нагрузкой. Большинство же систем испытывают эти пиковые нагрузки только в очень редких случаях.
Хранение данных в файловой системе имеет также определенную цену в терминах потери емкости памяти. Файловая система UNIX потребляет примерно 10% от форматированной емкости дисков для метаданных о файлах и файловой системе. Более того, файловая система резервирует 10% оставшегося пространства, чтобы обеспечить быстрый поиск свободного пространства в случае расширения файлов (этот дополнительный объем памяти в принципе может быть использован, но за счет потенциально значительных дополнительных задержек, которые возникнут при открывании или расширении файлов файловой системы). Если СУБД работает с данными через файловую систему, то по сравнению с "чистым" диском емкость дисковой памяти в целом уменьшается на 19%.
Если хранение данных в файловой системе обходится дороже как с точки зрения потребления мощности процессора, так и с точки зрения потерь емкости памяти, возникает вопрос: "А зачем все это нужно?". Имеется несколько важных причин, по которым в СУБД используется хранение данных в файловой системе. Большинство из них связано с обеспечением гибкости или относятся к разряду более знакомой для пользователя технологии.
Во-первых, и что возможно наиболее важно, использование файловой системы позволяет работать с памятью с помощью стандартных утилит UNIX. Например, стандартные утилиты UNIX ufsdump и ufsrestore могут использоваться для того, чтобы производить надежное резервное копирование и восстановление памяти СУБД. Для этого могут также использоваться не связанные с операционной системой инструментальные средства резервного копирования, подобные Online:Backup 2.0 компании Sun. Кроме того, гораздо проще осуществлять манипулирование отдельными частями базы данных. Например, можно осуществлять прямое перемещение таблицы с одного диска на другой, даже если используются диски разного размера и типа. Поскольку каждый из поставщиков СУБД предлагает свои собственные внутренние утилиты резервного копирования и восстановления, все они различны. Более того, некоторые из них выполняются настолько медленно, что заказчики часто прибегают к использованию копирования физических томов (т.е. используют команду dd(1)) со всеми присущими такому копированию сложностями. Хранение данных в файловой системе позволяет выполнять единообразные, надежные процедуры для того, чтобы работать через систему и сеть. При этом, если необходимо, могут также использоваться инструментальные средства поставщиков СУБД.
При некоторых обстоятельствах операции через файловую систему дают возможность оптимизации, которую сама СУБД не может реализовать. В частности, файловая система UNIX пытается кластеризовать данные в более крупные физические единицы, чем большинство СУБД. Поскольку дисковое пространство для таблиц часто заранее распределено, файловой системе обычно удается агрегатировать данные в блоки объемом по 56 Кб, в то время как менеджеры памяти СУБД обычно оперируют только страницами размером в 2 (или иногда 8) Кб. Последовательное сканирование таблиц или индексов, хранящихся таким образом часто может оказаться более эффективным, чем эквивалентных таблиц, хранящихся более традиционным способом. Если в операциях системы доминирует последовательное сканирование (или операции соединения (joins), которые часто подразумевают последовательное сканирование), хранение данных в файловой системе обеспечивает более высокую производительность.
Рекомендации:
Для обеспечения максимальной пиковой производительности следует конфигурировать "чистые" диски.
При размещении таблицы СУБД в файловой системе UNIX следует добавить 19% дополнительного дискового пространства на накладные расходы файловой системы.
Для обеспечения максимальной гибкости можно размещать таблицы СУБД в файловых системах.
Если СУБД хранит таблицы в файловой системе UNIX следует сконфигурировть 15% дополнительной памяти (или соответственно более маленький кэш разделяемых данных).
Метаданные СУБДОбычно пользователи рассматривают СУБД как средство хранения и последующего поиска своих данных и вовсе не задумываются о том, что же в действительности хранится на диске. На практике, программное обеспечение СУБД поддерживает значительное количество дополнительной информации. Было бы серьезной ошибкой предполагать, что для размещения заданного количества данных пользователя потребуется тот же самый объем дискового пространства. Схема базы данных, табличные индексы, B-деревья узлов каталогов, временные таблицы, заранее выделенное пространство для хеш-таблиц и индексов, пространство для сортировки, файлы журнала, архивы и мириады других функций - все это включается в дисковое пространство системы.
Если отсутствует более точная информация, то обычно разумно было бы предусмотреть примерно удвоенный объем дискового пространства по сравнению с объемом "чистых" данных. Это обеспечивает некоторую гибкость для создания индексов и т.п., и в итоге позволяет улучшить производительности приложения. Хотя коэффициент 2 на первый взгляд кажется чрезмерным, следует, например, иметь в виду, что индексация, навязываемая предложенным тестом TPC-D потребляет более 400 Мб. При этом объем "чистых" данных составляет примерно 650 Мб. При использовании устанавливаемых по умолчанию параметров памяти СУБД Oracle, объем "чистых" данных, необходимых для реализации теста TPC-C, увеличивается на 30% при хранении их в базе данных Oracle даже без индексации. Поэтому можно легко потребовать для системы даже гораздо больше, чем 100% дополнительного пространства.
Рекомендации:
Объем дискового пространства базы данных должен по крайней мере на 50% превышать требования по объему "чистых" данных (к этому необходимо добавить накладные расходы файловой системы, если таковая применяется). Более безопасная цифра - 100%.
Для размещения журналов транзакций и архивов необходимо выделить отдельное дисковое пространство. Его объем следует оценить отдельно, поскольку они должны размещаться на других физических дисках, чем сама база данных.
Распределение данныхДругим фактором, влияющим на конфигурацию подсистемы ввода/вывода, является предполагаемое распределение данных по дискам. Даже минимальная по объему система должна иметь по крайней мере четыре диска: один для операционной системы и области подкачки (swap), один для данных, один для журнала и один для индексов. Конфликты по этим ресурсам в системе с ограничениями ввода/вывода являются самым большим отдельным классом проблем обеспечения производительности в среде, в которой приложение в определенной степени было настроено (т.е. в наиболее продуктивных средах). Более крупные системы должны учитывать даже большее количество переменных, такие как зеркалирование дисков, расщепление дисков и перекрытие ресурсов. Вообще говоря, наиболее продуктивным и достаточно эффективным по стоимости способом распределения данных является обеспечение всех основных логических сущностей отдельным набором дисков.
Хотя технически возможно объединить по несколько логических функций на одних и тех же (физических или логических) дисках, для подсистемы ввода/вывода это оказывается очень разрушительным и почти всегда приводит к неудовлетворительной производительности. Например, рассмотрим базу данных, которая состоит из таблицы данных размером 1.5 Гбайт и индексов объемом 400 Мбайт, и которая требует 40 Мбайт для размещения журнального файла. Соблазнительно просуммировать эти объемы вместе и обнаружить, что вся эта информация может поместиться на одном диске емкостью 2.1 Гбайт. Если реализовать такую конфигурацию системы, то при выполнении приложением практически любого обновления базы данных, каретка диска все время будет сновать челноком по диску для каждой транзакции. В частности, процесс формирования журнала, который должен писаться синхронно и медленно, в действительности будет выполняться в режиме произвольного доступа, а не в режиме последовательного доступа к диску. Уже только это одно будет существенно задерживать каждую транзакцию обновления базы данных.
Кроме того, выполнение запросов, выбирающих записи из таблицы данных путем последовательного сканирования индекса, будет связано с сильно увеличенным временем ожидания ввода/вывода. Обычно сканирование индекса выполняется последовательно, но в данном случае каретка диска должна перемещаться для поиска каждой записи данных между выборками индексов. В результате происходит произвольный доступ к индексу, который предполагался последовательным! (В действительности индекс мог специально создаваться с целью последовательного сканирования). Если таблица данных, индекс и журнал находятся на отдельных дисках, то произвольный доступ к диску осуществляется только при выборке данных из таблицы и результирующая производительность увеличивается вдвое.
Последним пунктом обсуждения возможности объединения разных функций на одних и тех же физических ресурсах является то, что подобное объединение часто создает ситуации, в которых максимизируются времена подвода головок на диске. Хотя время позиционирования в спецификациях дисковых накопителей обычно приводится как одно число, в действительности длительность позиционирования сильно зависит от необходимого конкретного перемещения головок. Приводимое в спецификациях время позиционирования представляет собой сумму времен всех возможных позиционирований головок, деленное на количество возможных позиционирований. Это не то время, которое затрачивается при выполнении "типичного" позиционирования. Сама физика процесса перемещения дисковой каретки определяет, что позиционирование на короткое расстояние занимает гораздо меньше времени, чем на длинное. Позиционирование на смежный цилиндр занимает всего несколько миллисекунд, в то время как позиционирование на полный ход каретки длится значительно больше времени, чем приводимое в спецификациях среднее время позиционирования. Например, для диска 2.1 Гб позиционирование головки на соседний цилиндр обычно занимает 1.7 мс, но длится 23 мс для полного хода каретки (в 13 раз дольше). Поэтому длительное позиционирование головок, возникающее при последовательности обращений к двум разным частям диска, необходимо по возможности исключать.
Рекомендации:
Отдельные логические функции СУБД следует реализовывать на отдельных выделенных дисковых ресурсах.
Необходимо планировать размещение данных на дисках для минимизации количества и длительности позиционирования головок.
Использование ресурсов ввода/выводаПри разработке подсистемы ввода/вывода должно быть уделено внимание не только максимальной емкости ее компонентов, но также уровню использования (загруженности) каждого ресурса. Большинство параметров, используемых для описания емкости ресурсов, так или иначе связаны с пропускной способностью. Например, шина SCSI характеризуется пропускной способностью в 10 Мбайт/с. Это скорость пересылки битов по шине. Такой параметр не дает информации о том, насколько занята сама шина и, следовательно, не дает также информации о том, сколько времени будет потрачено на обслуживание данного запроса. Приводить в качестве параметра ресурса рейтинг максимальной пропускной способности - все равно, что говорить, что предел скорости автомагистрали равен 130 км в час: если въезды и съезды с нее так перегружены, что это занимает длительное время, то общая скорость вероятно будет намного ниже установленного предела.
Точно такие же принципы применимы к различным периферийным устройствам и периферийным шинам. В частности, это справедливо и для шин SCSI. Экспериментальные результаты показывают, что если должна поддерживаться пиковая производительность, то степень загруженности шины SCSI должна поддерживаться на уровне 40%. Аналогичным образом, степень загрузки дисков должна поддерживаться на уровне 60%. Диски могут выдерживать значительно большую степень загрузки чем шина SCSI, поскольку во встроенных дисковых контроллерах имеется интеллект и средства буферизации. Это позволяет координировать работу буферов дорожек, каретки диска и очереди запросов такими способами, которые не возможны на достаточно примитивных главных адаптерах шины SCSI.
Обычно невозможно оценить, какова будет средняя степень загрузки дисков или шины SCSI до тех пор, пока система не начнет работать. В результате, достаточно приемлемой оказывается такая конфигурация, которая позволяет распределить часто используемые данные и индексы по стольким дискам и шинам SCSI, сколько позволяют бюджет и технические ограничения. Для данных, доступ к которым происходит не очень часто, например, только во время ночной пакетной обработки (или других полуархивных данных подобных транзакциям годовой давности), можно рекомендовать как можно более плотную упаковку на накопителях.
Как только система начнет работать, можно измерить действительную степень загрузки дисков и соответствующим образом перераспределить данные. Как указывалось выше, перераспределение данных должно выполняться с учетом других параметров доступа к диску: везде надо поддерживать баланс.
В контексте СУБД имеется по крайней мере два механизма для распределения данных по дисковым накопителям. Для эффективного распределения доступа к данным все известные СУБД имеют возможность осуществлять конкатенацию нескольких дисковых накопителей или файлов UNIX. (В СУБД Ingres, например, реализовано истинное расщепление дисков, ограниченное стандартным размером чередования 16 Кбайт). Похожие возможности (помимо горячего резервирования и расщепления дисков) предлагают и специальные программные средства типа Online:DiskSuite. Если работа с таблицей ограничивается возможностями подсистемы ввода/вывода, следует исследовать запросы, которые вызывают ввод/вывод. Если эти запросы реализуют произвольный доступ к дискам, например, если многие пользователи независимо запрашивают индивидуальные записи, то имеющиеся возможности конкатенации дисков в СУБД полностью адекватны распределению нагрузки доступа по множеству дисков (при достаточно полном заполнении пространства таблицы). Если обращения по своей природе последовательны, например, если один или несколько пользователей должны просматривать каждую строку таблицы, то больше подходит механизм расщепления дисков.
Основное преимущество использования расщепления с помощью средств, подобных Online:DiskSuite, заключается в том, что задача распределения обращений к данным становится гораздо более простой для администратора базы данных. При действительном расщеплении эта задача тривиальна и почти всегда дает оптимальные результаты. Часто это не тот случай, когда логически разделение данных по пространствам таблицы использует внутренние механизмы СУБД. Задача заключается в том, чтобы распределить тяжело используемые таблицы по отдельным дисковым ресурсам, однако часто невозможно принять решение относительно конфликтующих комбинаций запросов при обращениях к этим таблицам, приводящих к неровной нагрузке. При использовании DiskSuite степень загруженности дисков сама будет стремиться к естественному уровню.
Обычно СУБД делят таблицу на несколько относительно больших сегментов и размещают данные равномерно по этим сегментам. Главное отличие между конкатенацией СУБД и функцией расщепления Online:DiskSuite заключается в размещении смежных данных. Когда диски конкатенируются друг с другом, последовательное сканирование представляет собой тяжелую нагрузку для каждого из дисков, но эта нагрузка носит последовательный характер (только один диск участвует в обслуживании запроса). Истинное расщепление дисков, реализованное в Online:DiskSuite, осуществляет деление данных по гораздо более мелким границам, позволяя тем самым всем дискам участвовать в обслуживании даже сравнительно небольшого запроса. Как результат, при использовании расщепления загрузка дисков при выполнении последовательного доступа существенно уменьшается. К архивным и журнальным файлам всегда осуществляется последовательный доступ и они являются хорошими кандидатами для расщепления, если реализация обращений к таким файлам ограничивает общую производительность системы.
По мере продолжения роста размеров и важности баз данных, процедуры резервного копирования, которые выполняются с блокировкой доступа к СУБД, становятся практически неприемлемыми. При реализации резервного копирования в оперативном режиме (режиме online) могут возникнуть достаточно сложные вопросы по конфигурированию соответствующих средств, поскольку резервное копирование больших томов данных, находящихся в базах данных, приводит к очень интенсивной работе подсистемы ввода/вывода. Резервное копирование в оперативном режиме часто вызывает очень высокий уровень загрузки дисков и шины SCSI, что приводит к низкой производительности приложений. Следует уделять особое внимание конфигурациям всех устройств, вовлеченных в процессы резервного копирования.
Рекомендации:
После начальной инсталляции необходимо наблюдать за работой системы и переразмещать данные до тех пор, пока каждый дисковый накопитель не будет загружен менее, чем на 60%.
Для распределения последовательных дисковых обращений по множеству дисков рекомендуется использовать программные продукты типа Online:DiskSuite.
Когда типовой доступ к диску носит характер произвольного обращения, для более равномерного распределения обращений к данным и уменьшения степени загрузки дисков следует использовать встроенную в СУБД функцию кокатенации.
Особое внимание следует уделять влиянию резервного копирования в режиме online на работу системы, особенно на загрузку шины SCSI.
Сетевая подсистема ввода/выводаСоображения по использованию режима клиент/серверЕсли СУБД работает в режиме клиент/сервер, то сеть или сети, соединяющие клиентов с сервером должны быть адекватно оборудованы. К счастью, большинство клиентов работают с вполне определенными фрагментами данных: индивидуальными счетами, единицами хранящихся на складе изделий, историей индивидуальных счетов и т.п. При этих обстоятельствах скорость сети, соединяющей клиентов и серверы редко оказывается проблемой. Отдельной сети Ethernet или Token Ring обычно достаточно для обслуживания 100-200 клиентов. На одном из тестов Sun конфигурация клиент/сервер, поддерживающая более 250 пользователей Oracle*Financial, генерировала трафик примерно 200 Кбайт/с между фронтальной системой и сервером базы данных. По очевидным причинам стоит более плотно наблюдать за загрузкой сети, особенно когда число клиентов превышает примерно 20 на один сегмент Ethernet. Сети Token Ring могут поддерживать несколько большую нагрузку, чем сети Ethernet, благодаря своим превосходным характеристикам по устойчивости к деградации под нагрузкой.
Даже если с пропускной способностью сети не возникает никаких вопросов, проблемы задержки часто приводят к тому, что более удобной и полезной оказывается установка отдельной, выделенной сети между фронтальной системой и сервером СУБД. В существующих в настоящее время конфигурациях серверов почти всегда используется большое количество главных адаптеров шины SCSI; поскольку как правило эти адаптеры спарены с портами Ethernet, обеспечение выделенного канала Ethernet между клиентом и сервером выполняется простым их подключением к дешевому хабу с помощью кабельных витых пар. Стоимость 4-портового хаба не превышает $250, поэтому причины, по которым не стоило бы обеспечить такое выделенное соединение, практически отсутствуют.
Большие объекты данныхОднако в ряде случаев возможностей сетей Ethernet или Token Ring может оказаться недостаточно. Чаще всего это случается, когда данные хранятся в базе в виде очень больших массивов. Например, в медицинских базах данных часто хранятся образы рентгеновских снимков, поскольку они могут быть легко быть объединены с другими данными истории болезни пациента; эти образы рентгеновских снимков часто бывают размером в 3-5 Мбайт. Другими примерами приложений с интенсивным использованием данных являются системы хранения/выборки документов, САПР в области механики и системы мультимедиа. В этих случаях наиболее подходящей сетевой средой является FDDI, хотя в сравнительно ближайшем будущем она может быть будет заменена на ATM или 100 Мбит Ethernet.
Для систем, требующих большей пропускной способности сети, чем обеспечивают Ethernet или Token Ring, по существу до конца 1994 года FDDI была единственным выбором. Хотя концентраторы FDDI имеют значительно большую стоимость по сравнению с хабами Ethernet, установка выделенной сети между фронтальной системой и сервером СУБД оказывается достаточно простой и недорогой. Как определено в стандарте FDDI, минимальная сеть FDDI состоит только из двух систем, соединенных между собой с помощью единственного кабеля. Никаких концентраторов не требуется, а цены на некоторые интерфейсы FDDI в настоящее время упали до уровня менее $1500.
Конфигурация клиент/сервер и региональные сетиВ последнее время резко увеличилось число приложений, в которых фронтальные системы и серверы СУБД могут или должны размещаться в географически разнесенных местах. Такие системы должны соединяться между собой с помощью глобальных сетей. Обычно средой передачи данных для таких сетей являются арендованные линии с синхронными последовательными интерфейсами. Эти линии обычно работают со скоростями 56-64 Кбит/с, 1.5-2.0 Мбит/с и 45 Мбит/с. Хотя скорость передачи данных в такой среде значительно ниже, чем обычные скорости локальных сетей, подобных Ethernet, природа последовательных линий такова, что они могут поддерживать очень высокий уровень загрузки. Линия T1 предлагает пропускную способность 1.544 Мб/с (2.048 Мбит/с за пределами США). По сравнению с 3.5 Мбит/с, обеспечиваемых Ethernet в обычном окружении, линия T1 предлагает пропускную способность, которая количественно практически не отличается от Ethernet. Неполные линии T3 часто доступны со скоростями 10-20 Мбит/с, очевидно соперничая с сетями Ethernet и Token Ring. В ряде случаев можно найти приложения, которые могут работать успешно в конфигурации клиент/сервер даже через сеть со скоростью 56 Кбит/с.
Для традиционных бизнес-приложений трафик конфигурации клиент/сервер обычно содержит сравнительно низкий объем данных, пересылаемых между фронтальной системой и сервером СУБД, и для них более низкая пропускная способность сети может оказаться достаточной. В большинстве случаев задержка сети не является большой проблемой, однако если глобальная сеть имеет особенно большую протяженность, или если сама среда передачи данных имеет очень большую задержку (например, спутниковые каналы связи), приложение должно быть протестировано для определения его чувствительности к задержкам пакетов.
Для сокращения трафика клиент/сервер до абсолютного минимума могут использоваться мониторы обработки транзакций.
Трафик символьного терминалаОбщей ошибкой пользователей является представление о том, что сетевой трафик, связанный с терминальными серверами, может перегрузить Ethernet. Это неправильно. Рассмотрим, например, 64-портовый сетевой терминальный сервер, который может управлять каждым портом, работающим со скоростью 38400 бод, или 38400 символов в секунду. (В каждом байте данных содержится 8 бит информации, но рейтинг бод включает биты старта и стопа). Если каждый порт работает на полной скорости 38400 бод, то всего за одну секунду по сети будет пересылаться 2457600 байт данных (или примерно 1.9 Мбит, т.е. около 20% максимальной загрузки Ethernet) с главной системы в терминальный сервер для дальнейшего распределения. Конечно имеются некоторые накладные расходы (дополнительные байты TCP/IP), связанные с этим уровнем трафика, но они составляют примерно 50 байт на пакет, т.е. примерно 4% для этого уровня трафика. Это сценарий наихудшего случая, например, когда на полной скорости работают 64 принтера. Типичный же уровень трафика намного ниже: один 2000-символьный экран может отображаться один раз в минуту. При этих условиях 64-портовый терминальный сервер обрабатывает примерно 35 байт в секунду на один порт или всего примерно 2 Кбайт/с.
Операции по вводу символов с клавиатуры терминала можно вообще не рассматривать, поскольку даже самая быстрая машинистка печатает только 20 символов в секунду (более типичный случай 1.0 - 1.5 символов в секунду). Даже если операции ввода обрабатываются в режиме cbreak, наибольшая нагрузка, которая будет генерироваться всеми пользователями, может составлять 1300 символов в секунду (по 20 символов в секунду на каждый порт при 64 портах). После учета максимальных накладных расходов TCP/IP это дает общий поток в 80 Кбайт/с . Типичные нагрузки (64 порта по 1.5 символа в секунду) будут составлять порядка 15 Кбайт/с с учетом накладных расходов.
Заключительные рекомендации по конфигурированию сетевого ввода/выводаДля конфигураций клиент/сервер, где клиенты работают на удаленных ПК или рабочих станциях, следует конфигурировать по 20-50 клиентов на одну сеть Ethernet. Количество клиентов в одной сети 16 Мбит/с Token Ring может достигать 100 благодаря прекрасной устойчивости к деградации под нагрузкой.
Если фронтальная система обслуживает большое количество клиентов, то между фронтальной системой и сервером СУБД следует предусмотреть специальную выделенную сеть. При этом если приходится манипулировать очень большими объектами данных (более 500 Кбайт на объект), то вместо сетей Ethernet или Token Ring следует применять FDDI.
Фронтальная система и сервер СУБД могут объединяться с помощью глобальных сетей, обеспечивающих "достаточную" полосу пропускания. В идеале это предполагает по крайней мере использование неполной линии T1. Такие приложения должны быть относительно малочувствительны к задержке сети.
При конфигурировании систем клиент/сервер с использованием глобальных сетей следует исследовать возможность применения мониторов обработки транзакций для снижения трафика клиент/сервер до минимума.
В частных сетях обычно нет никаких проблем с использованием терминальных серверов, если только сами разделяемые сети не загружены тяжело для других целей.
PrestoServe/NVSIMMПо определению семантики оператора SQL COMMIT_WORK любая СУБД должна гарантировать, что все обновления базы данных должны направляться и фиксироваться в стабильной памяти (т.е. любой памяти, которая обеспечивает устойчивое хранение данных даже в условиях сбоев системы или отказов питания). Чтобы СУБД могла дать такую гарантию, она должна выдавать для выполнения по крайней мере некоторые из своих операций записи синхронно. Во время выполнения таких записей операционная система блокируется и не возвращает управление вызвавшей программе до тех пор, пока данные не будут зафиксированы в стабильной памяти. Хотя эта стратегия очень надежна, вместе с тем она приводит к существенному замедлению операций, поскольку при выполнении синхронных записей обязательно требуется, чтобы данные были записаны непосредственно на дорожку диска. Синхронная запись на "чистый" диск занимает примерно 20 мс, а синхронная запись в файловую систему может занять в несколько раз больше времени (если должны быть выполнены обновления в косвенные блоки или блоки с двойной косвенностью).
Обычно СУБД осуществляют синхронную запись только в свои журналы - в случае отказа системы сама база данных может быть реконструирована из синхронно записанного журнала. Иногда система в целом становится узким местом в процессе заполнения журнала. Обычно это случается в среде тяжелой обработки транзакций, которая выполняет многочисленные обновления базы данных (приложения, выполняющие только чтение базы данных, подобные системам поддержки принятия решений, осуществляют немного записей в журнал). Этот эффект еще более усиливается при использовании для журнальных дисков зеркальных пар. В этих случаях для ускорения процесса журнализации часто полезно использовать PrestoServe или NVSIMM. Фиксация записей в немеханических NVRAM, устанавливаемых на PrestoServe или в NVSIMM может существенно расшить узкое горло в некоторых системах.
Рекомендации:
Если приложение связано с ведением журнала или если приложение жестко ориентировано на проведение обновлений, следует включить в конфигурацию системы NVSIMM или PrestoServe.
Для гарантии от потери данных следует размещать журналы СУБД на зеркальных дисковых парах.
Обеспечение резервного копированияПоскольку обычно базы данных бывают очень большими и в них хранится исключительно важная информация, правильная организация резервного копирования данных является очень важным вопросом. Объем вовлеченных в этот процесс данных обычно огромен, особенно по отношению к размеру и обычной скорости устройств резервного копирования. Просто непрактично осуществлять дамп базы данных объемом 20 Гбайт на 4 мм магнитную ленту, работающую со скоростью 500 Кбайт/с: это займет примерно 12 часов. В этой цифре не учтены даже такие важные для работы системы соображения, как обеспечение согласованного состояния базы данных и готовность системы.
Когда необходимо выполнять резервное копирование?Составить расписание для резервного копирования системы, которая используется главным образом в течение нормального рабочего времени, обычно сравнительно просто. Для выполнения процедур резервного копирования после завершения рабочего дня часто используются скрипты. В некоторых организациях эти процедуры выполняются автоматически даже без привлечения обслуживающего персонала, в других в неурочное время используют операторов. Для выполнения автоматического резервного копирования без привлечения обслуживающего персонала требуется возможность его проведения в рабочем режиме (режиме online).
Если система должна находиться в рабочем режиме 24 часа в сутки, или если время, необходимое для выполнения резервного копирования превышает размер доступного окна (временного интервала), то планирование операций резервного копирования и конфигурирование соответствующих средств значительно усложняются.
Резервное копирование в режиме onlineВ некоторых случаях необходимо выполнять "резервное копирование в режиме online", т.е. выполнять резервное копирование в то время, когда база данных находится в активном состоянии с подключенными и работающими пользователями.
При выполнении резервного копирования базы данных предполагается, что она находится в согласованном состоянии, т.е. все зафиксированные обновления базы данных не только занесены в журнал, но и записаны также в таблицы базы данных. При реализации резервного копирования в режиме online возникает проблема: чтобы резервные копии оказались согласованными, после того как достигнута точка согласованного состояния базы данных и начинается резервное копирование, все обновления базы данных должны выполняться без обновления таблиц самой базы до тех пор, пока не завершится ее полное копирование. Большинство основных СУБД обеспечивают возможность резервного копирования в режиме online.
Продолжительность резервного копированияПродолжительность процедур резервного копирования возможно является наиболее важным вопросом для организаций с большими базами данных (объемом более 10 Гбайт), и выбор методики резервного копирования может определяться именно этим. Резервное копирование небольших баз данных может легко осуществляться при наличии всего одного накопителя на магнитной ленте Exabyte или DAT. Хотя выпускаемые в настоящее время накопители на МЛ позволяют копировать данные со скоростью примерно 1.25 Гбайт в час, для больших баз данных это очевидно неприемлемо. Для увеличения пропускной способности несколько устройств могут работать параллельно, хотя конфликты по ресурсам делают этот способ недостаточно эффективным при использовании одновременно более трех-четырех НМЛ.
Некоторые НМЛ на 8 мм ленте с аппаратной компрессией способны обеспечивать скорость до 3 Гбайт/час, т.е. более чем вдвое превышают скорость стандартных устройств. Некоторые из этих устройств имеют емкость до 25 Гбайт, но более типичной является емкость 8-10 Гбайт. Совместимые с IBM 3480 устройства, например, Fujitsu Model 2480, могут обеспечивать скорость около 10 Гбайт в час, но ограниченный объем носителя (200-400 Мбайт до компрессии) означает, что для обеспечения эффективности они должны устанавливаться в механических стекерах. Некоторые относительно новые устройства используют носитель информации в формате VHS и предлагают исключительно высокую пропускную способность и емкость. В сообщении об одном из таких устройств (от Metrum) указана скорость передачи в установившемся режиме почти 15 Мбайт/с при подключении с помощью выделенных каналов fast/wide SCSI-2. Емкость этого устройства составляет 14 Гбайт на одну ленту без компрессии.
Если недоступно устройство, которое поддерживает аппаратную компрессию, возможно стоит рассмотреть возможность использования программной компрессии. Скорость резервного копирования обычно определяется скоростью физической ленты, поэтому любой метод сокращающий количество данных, которые должны быть записаны на ленту, должен исследоваться, особенно при использовании быстрых ЦП. Базы данных являются хорошими кандидатами для компрессии, поскольку большинство таблиц и строк включают значительную часть свободного пространства (обычно используются даже коэффициенты заполнения, обеспечивающие определенный процент свободного пространства с целью увеличения производительности). Некоторые таблицы могут содержать также текст или разбросанные поля двоичных данных и готовы для компрессии.
Использование зеркалирования дисков для облегчения резервного копированияПростым, но эффективным способом сокращения времени резервного копирования является выполнение копирования на отдельный зеркальный диск. ПО Online:DiskSuite предлагает зеркалирование с очень небольшими накладными системными расходами. Если зеркальная копия сделана непосредственно после контрольной точки, или после того как база данных выключена, она действительно становится онлайновой дисковой резервной копией, которая сама может быть скопирована в любое удобное время. Можно даже выполнить рестарт базы данных, чтобы продолжить нормальную обработку, хотя с меньшей избыточностью. Если доступно достаточное количество дисковых накопителей, то может быть использован и второй набор зеркальных дисков, что позволяет сохранить полное зеркалирование даже, когда один набор зеркальных дисков отключается (во время нормальных операций диски будут зеркалироваться по трем направлениям). В этом случае резервное копирование в режиме online может продолжаться после копирования на ленту, что обеспечивает в случае необходимости очень быстрое восстановление. Этот дополнительный набор зеркальных дисков мог бы быть заново подключен перед следующей контрольной точкой, обеспечив достаточно времени (примерно 30 минут), которое позволит этому набору зеркальных дисков синхронизоваться с зеркальными дисками, работавшими в режиме online.
Частота резервного копированияБольшинство пользователей выполняют полное резервное копирование ежедневно. Полагая, что резервное копирование выполняется на тот случай, когда понадобится восстановление, важно рассмотреть составляющие времени восстановления. Оно включает время перезаписи (обычно с ленты) и время, которое требуется для того, чтобы выполнить изменения, внесенные в базу данных с момента резервного копирования. Учитывая необходимость средств такой "прокрутки" вперед, очень важно зеркалировать журналы и журналы архивов, которые и делают этот процесс возможным.
В рабочей среде, где большое количество транзакций выполняют записи в базу данных, время, требуемое для выполнения "прокрутки" вперед от последней контрольной точки может существенно увеличить общее время восстановления. Это соображение само по себе может определить частоту резервного копирования.
Утилиты резервного копированияПри использовании "чистых" дисковых разделов, выбор прост: в действительности единственными командами UNIX, работающими с "чистыми" разделами, являются dd и compress. При хранении таблиц СУБД в файловых системах USF можно выбрать, например, команды tar, cpio и usfdump. Большинство пользователей предпочитают usfdump(1) (dump(1) для Solaris 1.X), или ее эквивалент в Online Backup (hsmdump для Solaris 2.X). Большинство СУБД имеют утилиты для выделения из базы данных "чистых" данных и их копирования на внешний носитель, но эти операции обычно выполняются намного медленнее, чем простое копирование "чистых" разделов диска.
Отслеживание и проверка резервных копийРезервные копии очень важны. Выполнение процедур резервного копирования должно соответствующим образом отслеживаться, чтобы гарантировать, что они завершились успешно. Также важно документировать и тестировать процедуры восстановления. Момент аварии не слишком удачное время для обнаружения того, что в стратегии резервного копирования пропущены некоторые ключевые элементы.
26 защита сервера от несанкционированного доступа
Отдельное место при обсуждении протокола занимают вопросы, связанные с обеспечением защиты ресурсов сервера от несанкционированного доступа. Как было отмечено в предыдущих разделах, первоначально разработка защищенных способов обмена данными в системе World Wide Web не предполагалась. Однако быстрое развитие популярности системы привело к тому, что многие коммерческие организации стали устанавливать серверы HTTP на свои машины. Кроме этого, конфиденциальной информации много и в научно-исследовательских государственных организациях. Таким образом, возникла необходимость в разработке механизмов защиты информации для системы WWW.Проблема защиты информации на Internet - это отдельная большая тема. В данном разделе мы рассмотрим только обеспечение безопасности при использовании серверов HTTP.При обсуждении этой проблемы полезно вспомнить схему WWW-технологии (рисунок 3.26). Из этой схемы видно, что в этой технологии имеется как минимум две потенциальные "дыры" .Первая связана с чтением защищенных текстовых файлов. Для решения этой задачи имеется достаточно много традиционных механизмов, встроенных в операционные системы. Проблема возникает, если администратор системы решит использовать для размещения WWW-файлов и FTP-архива одно и тоже дисковое пространство. В этом случае защищенные WWW-файлы окажутся доступными для "анонимного" FTP-доступа. Многие серверы разрешают создавать в дереве поддерживаемых ими документов "домашние" страницы пользователей с помощью методов POST и GET. Это значит, что пользователи могут изменять информацию на компьютере сервера. Данные, вводимые пользователем, передаются как тело ресурса при методе POST через стандартный ввод, а методе GET через переменные окружения. Естественно, что разрешение создания файлов на сервере протокола HTTP создает потенциальную опасность доступа к защищенной информации лиц, не имеющих права доступа к ней. Решается эта проблема путем создания специальных файлов прав пользователей сервера WWW.Рис. 3.28. Схема управления ресурсов сервером HTTPВторая возможность проникновения в компьютерную систему через сервер WWW связана с CGI-скриптами. CGI-скрипт - это программа, которую сервер HTTP может запускать для реализации механизмов, не предусмотренных в протоколе. Многие достаточно мощные информационные механизмы WWW реализованы посредством CGI-скриптов. К ним относятся: программы поиска по ключевым словам, программы реализации графических гипертекстовых ссылок - imagemap, программы сопряжения с системами управления базами данных и т.п. Естественно, что при этом появляется возможность получить доступ к системным ресурсам. Обычно внешняя программа запускается с идентификатором пользователя, отличным от идентификатора сервера. Данный идентификатор указывается при конфигурировании сервера. Наиболее безопасным здесь является идентификатор пользователя nobody (65534). Основная опасность скриптов заключена в том, что данные в скрипт посылаются программой-клиентом. Для того, чтобы в качестве параметров не передавали "подозрительных" данных, многие серверы производят проверку параметров на наличие допустимых символов. Особенно опасны скрипты для тех, кто использует сервер на персональном компьютере с MS-Windows 3.1. В этом случае файловая система практически не защищена. Одной из характерных для скриптов проблем является размер входных данных. Многие "умные" серверы обрезают слишком большие входные потоки и тем самым защищают скрипты от "поломки". Кроме перечисленных выше опасностей, порождаемых природой сети и системы WWW, существует еще одна, связанная с такой экзотикой, как мобильные коды. Мобильный код - это программа, которая может передаваться по сети для выполнения ее клиентом. Код встраивается в WWW-страницу при помощи тага <APP ...> - application. Например, Sun выпустила WWW-клиента HotJava, который позволяет интерпретировать язык Java. Существуют клиенты и для других языков, Safe-Tcl для Tcl, например. Главное назначение таких средств - реализация мультимедийных страниц и реализация работы в rеal-time. Опасность применения такого сорта страниц очевидна, так как повторяет способ распространения различного сорта вирусов. Однако пока речи о защите от такого сорта "взломов" не идет, видимо в силу довольно ограниченного применения данной возможности в сети.Практически любой сервер имеет механизм назначения паролей и прав доступа для различных пользователей, который базируется на схеме идентификации протокола HTTP 1.0. Данная схема предполагает, что программа-клиент посылает серверу идентификатор пользователя и пароль. Понятно, что такой механизм не обеспечивает защиты передаваемой по сети информации, и она может стать легкой добычей злоумышленников.Для того, чтобы этого не происходило, в рамках WWW ведется разработка других схем защиты. Они строятся на двух широко известных принципах: контроль доступа по IP-адресам и шифрация. Первый принцип реализован в программе типа "стена" (Firewall). Сервер разрешает обращаться к себе только с определенных IP-адресов и выполнять только определенные операции. Слабое место такого подхода с точки зрения WWW заключается в том, что обратиться могут через сервер-посредник, которому разрешен доступ к ресурсам защищенного первичного сервера. Поэтому применяют шифрование паролей и идентификаторов по аналогии с системой "Керберос". На принципе шифрования построен новый протокол SHTTP, который реализован в серверах Netsite (последние версии), Apachie и в новых серверах CERN и NCSA. Однако реально широкого применения это программное обеспечение еще не нашло и находится в стадии развития, а потому содержит достаточно большое количество ошибок.Завершая обсуждение протокола HTTP и способов его реализации, нужно отметить, что в качестве широко доступного информационного ресурса WWW уже состоялась, следующий шаг - серьезные коммерческие применения. Но для этого необходимо еще внедрить в практику защищенные протоколы обмена, базирующиеся на HTTP. В последнее время появилось много новых программ, реализующих протокол HTTP. Это серверы и клиенты, написанные как для новых компьютерных платформ, так и для возможностей SHTTP. Реальную возможность попробовать свои силы в разработке различных WWW-приложений имеют и отечественные программисты.
27 сетевое программное обеспечение
Сетевое программное обеспечение делится на три категории:
1. ПО управления сетевой платой;
2. ПО выполняющее правила (или протокол) общения в сети;
3. ПО сетевой операционной системы.
Первый компонент может состоять из одной или нескольких небольших программ. Он отвечает за наведение мостов между сетевой платой и стеком протокола.
ЛВС бывают двух основных типов: равноправные (или одноранговые) и с выделенным сервером. В равноправной локальной сети все узлы равноправны: любая РСТ может выступать по отношению к другой как клиент или как сервер. В сети с выделенным сервером все клиенты общаются с центральным сервером.
Одноранговые сети обычно легко устанавливать, и для их ОС не требуется выделять особый компьютер. С другой стороны, эти сети обладают меньшими функциональными возможностями по сравнению с сетями на основе выделенного сервера. В частности, проблемы централизованной защиты ресурсов и данных в таких сетях часто не разрешимы, так как каждый пользователь сам контролирует доступ к своей системе. По мере роста размеров таких сетей они быстро становятся неуправляемыми.
Равноправные СОС хороши для мелких сетей и идеальны в случае необходимости объединения лишь нескольких машин в целях коллективного применения специальных файлов и принтеров, когда не требуется централизованного администрирования. Но иногда доступ к некоторым ресурсам должен быть представлен лишь определенным пользователям и администратору требуется управлять такими ресурсами. Например, к определенному ресурсу должен быть организован централизованный доступ, в частности для организации "общего котла" модемов или принтеров. В этих случаях лучше обратиться к сети с выделенным сервером. В таких сетях один или несколько компьютеров организуют централизованный доступ к своим ресурсам. Все запросы от РСТ проходят через серверы. Компьютер, используемый в качестве сервера, должен быть как можно более мощным и надежным.
ПО сервера обеспечивает централизованное администрирование и защиту и управляет доступом к ресурсам при помощи реконфигурируемых бюджетов пользователей. Администратор сети контролирует эти бюджеты и определяет, что должен видеть и делать пользователь, зарегистрированный в сети. Локальные сети с выделенным сервером обычно сложнее в установке по сравнению с одноранговыми, но они мощнее, функционально многообразнее и поддерживают крупные сетевые системы.
Наиболее популярным сетевым ПО с выделенным сервером является ОС Novell NetWare, используемая, по некоторым оценкам, в 70% локальных сетей. К числу других широко известных СОС этого класса относятся Banyan Vines, IBM LAN Server для OC/2, DEC Pathworks для VAX и Windows NT, а также Microsoft Windows NT Server.
Сетевые операционные системы помогают осуществлять основные работы, проводимые в сети:
файловая поддержка (создание, поиск файлов);
коммуникации (взаимообмен данными);
услуги поддержки оборудования.
Сетевые операционные системы могут базироваться на операционных системах MS DOS, OS/2, Unix, Macintosh, Windows или на своих собственных операционных системах. Но вне зависимости от операционной системы, на которой базируется сетевая операционная система, они предоставляют средства обеспечения безопасности данных путем контроля прав доступа пользователей к рабочим программам, массивам данным и ресурсам сети.
Остальные компьютеры являются рабочими станциями, имеющими доступ к дискам файл-сервера и совместно используемым принтерам. С терминала каждой рабочей станции нельзя работать с дисками других рабочих станций. С одной стороны, это хорошо, так как пользователи изолированы друг от друга и не могут случайно повредить чужие данные, с другой стороны, для обмена данными пользователи вынуждены использовать диски файл-сервера, создавая для него дополнительную нагрузку.
Существуют, однако, специальные программы, работающие в сети с централизованным управлением и позволяющие передавать данные непосредственно от одной рабочей станции к другой, минуя файл-сервер, например NetLink. После ее запуска на двух рабочих станциях можно передавать файлы с диска одной станции на диск другой, аналогично тому, как копируются файлы из одного каталога в другой при помощи программы Norton Commander. На рабочих станциях должно быть установлено специальное программное обеспечение, часто называемое сетевой оболочкой. Это обеспечение работает в среде той ОС, которая используется на данной рабочей станции, — DOS, Windows, OS/2 и т. д.
Файл-серверы могут быть выделенными или невыделеннымиСуществуют различные сетевые операционные ситемы, ориентированные на сети с централизованным управлением. Самые известные из них — Windows NT, Novell NetWare, Microsoft Lan Manager (на базе OS/2), a также выполненная на базе UNIX System V сетевая OS VINES.Одноранговые сети не содержат в своем составе выделенных серверов. Функции управления сетью передаются по очереди от одной рабочей станции к другой. Как правило, рабочие станции имеют доступ к дискам (и принтерам) других рабочих станций. Такой подход облегчает совместную работу групп пользователей, но в целом производительность сети может понизиться.
Если сеть объединяет несколько рабочих станций, которые должны совместно использовать такие ресурсы, как лазерный принтер, файлы на дисках, и если требуется интенсивный обмен данными между рабочими станциями, рассматривают возможность применения недорогих одноранговых сетевых средств.
Одно из достоинств одноранговых сетей — простота обслуживания. Если для обслуживания сети на базе Novell NetWare, как правило, требуется системный администратор, то для поддержания работоспособности одноранговой сети не требуется специально выделенный для этого сотрудник.
Наиболее распространены такие одноранговые сети, как Artisoft LANtastic, LANsmart компании D-Link Systems, Invisible Software NET-30 и Web NOS компании Webcorp. Все эти сетевые средства реализованы как надстройки над OS MS-DOS. На основе ОС Windows 95 и Windows 98 также возможно построение одноранговой сети.
Фирма Novell предложила свое решение для организации работы групп пользователей. Сетевая оболочка Novell NetWare Lite напоминает одноранговые сетевые оболочки тем, что для организации сети не требуются выделенные файл-серверы, облегчено совместное использование дисков и принтеров. Novell NetWare Lite запускается как набор резидентных программ в среде MS-DOS. Однако Novell NetWare Lite не является одноранговой сетью. Скорее, это сеть с централизованным управлением, в которой может быть несколько невыделенных или выделенных серверов.
В целом Novell NetWare Lite представляет достаточно удачное решение для организации небольших сетей. Кроме того, Novell NetWare Lite хорошо уживается с Novell NetWare 3.11, что позволяет комбинировать возможности сетей с централизованным управлением на базе NetWare 3.11 с удобным разделением ресурсов отдельных рабочих станций.
Из всего разнообразия сетевых OS и оболочек самые распространенные изделия — Novell NetWare и Windows NT 4.0 (NT Server и NT Workstation). Сегодня Microsoft продает Windows 2000 Server и запускает Windows.NET Server (пока вышла бета-версия 3).
Сетевая операционная система необходима для управления потоками сообщений между рабочими станциями и серверами. Она может позволить любой рабочей станции работать с разделяемым сетевым диском или принтером, которые физически не подключены к этой станции.
Компоненты сетевой операционной системы на каждой рабочей станции и файловом сервере взаимодействуют друг с другом в рамках соглашений, называемых протоколом. Одним из общих протоколов является протокол фирмы IBM NetBIOS (Network Basic Input Output System —Сетевая операционная система ввода-вывода). Другим распространенным протоколом является IPX {Internet-work Packet Exchange — Межсетевой обмен пакетами) фирмы Novell.В таблице приведен список некоторых сетевых операционных систем с указанием их производителей.
Операционная система Производитель
Apple Talk Apple
LANtastic Arisoft
NetWare Novell
NetWare Lite Novell
Personal NetWare Novell
NFS Sun Microsystem
OS/2 LAN Manager Microsoft
OS/2 LAN Server IBM
Windows NT Advanced Server Microsoft
POWERtusion Perfomance Technology Рассмотрим некоторые из этих операционных систем.
Операционная система NetWare
ОС NetWare фирмы Novell. Novell была одной из первых компаний, которые начали создавать ЛВС.
Она производила как аппаратные средства, так и программные, однако в последнее время фирма Novell сконцентрировала усилия на программных средствах ЛВС.
Приведем некоторые характеристики программных продуктов NetWare.
В среде NetWare способно работать большее количество приложений, чем в любой другой ЛВС. ОС NetWare способна поддерживать рабочие станции, управляемые DOS, DOS и Windows, OS/2, UNIX, Windows NT, Mac System 7 и другими ОС. ЛВС NetWare может работать с большим количеством различных типов сетевых адаптеров, чем любая другая операционная система. Для достижения поставленных целей вы можете выбрать аппаратные средства от множества разных поставщиков. С NetWare можно использовать Arcnet, Ethernet, Token Ring или практически любой другой тип сетевого адаптера.
Средства защиты данных, предоставляемые NetWare, более чем достаточны для большинства ЛВС.
NetWare допускает использование более чем 200 типов сетевых адаптеров, более чем 100 типов дисковых подсистем для хранения данных, устройств дублирования данных и файловых серверов.
Фирма Novell имеет контракты о поддержке ОС NetWare с наиболее крупными и мощными из независимых организаций, таких как Bell Atlantic, DEC, Hewlett-Packard, Intel, Prime, Unisys и Xerox.
Операционные системы UNIX и LINUX
Операционные системы UNIX и LINUX имеют большую известность как сетевые операционные системы, чем Novell NetWare. Они реже используются как ОС локальных сетей. Основное их назначение — обеспечение доступа к глобальным сетям и их сервисам.
Независимо от версии общими для UNIX чертами являются:
многопользовательский режим со средствами защиты данных от несанкционированного доступа;
реализация мультипрограммной обработки в режиме разделения времени, основанная на использовании алгоритмов вытесняющей многозадачности (preemptive multitasking);
использование механизмов виртуальной памяти и свопинга для повышения уровня мультипрограммирования;
унификация операций ввода-вывода на основе расширенного использования понятия «файл»;
иерархическая файловая система, образующая единое дерево каталогов независимо от количества физических устройств, используемых для размещения файлов;
переносимость системы за счет написания ее основной части на языке Си;
разнообразные средства взаимодействия процессов, в том числе и через сеть;
кэширование диска для уменьшения среднего времени доступа к файлам.
Для глобальных сетей UNIX и UNIX-подобные системы (например, LINUX) являются основными. Здесь важно подчеркнуть, что UNIX прозрачным образом поддерживает не только работу с удаленного терминала (даже по телефонной линии), но и электронную почту, и набор протоколов TCP/IP. При этом детали обмена данными между компьютерами от пользователя системы скрыты, и он может, работая за любым компьютером сети или за удаленным терминалом, выполнять разнообразные операции и даже запускать процессы, не зная, где физически находится исполняющий компьютер.
В основе UNIX лежит концепция процесса — единицы управления и единицы потребления ресурсов. Процесс представляет собой программу в состоянии выполнения, причем в UNIX в рамках одного процесса не могут выполняться никакие параллельные действия.
Каждый процесс работает в своем виртуальном адресном пространстве. Совокупность участков физической памяти, отображаемых на виртуальные адреса процесса, называется образом процесса.
При управлении процессами операционная система использует два основных типа информационных структур:  HYPERLINK "http://professia.org/seti/251/2_5_1.%20HTML.html" \l "1" дескриптор процесса (структура ргос) и контекст процесса (структура user).
В UNIX реализован механизм виртуальной файловой системы VFS (Virtual File System), который позволяет ядру системы одновременно поддерживать несколько различных типов файловых систем. Механизм VFS поддерживает для ядра некоторое абстрактное представление о файловой системе, скрывая от него конкретные особенности каждой файловой системы.

Рис. 1 Традиционная файловая система s5
Необходимо отметить, что файловая система хорошо известных операционных систем DOS и Windows создавалась на основе идеологии традиционной файловой системы UNIX, поэтому у них можно обнаружить определенное сходство.
По функциональному назначению различают обычные файлы, каталоги и специальные файлы.В UNIX для файла существуют три типа имени:  HYPERLINK "http://professia.org/seti/251/2_5_1.%20HTML.html" \l "1" краткое имя, полное и относительное.Все пользователи по отношению к данному файлу делятся на три категории: владелец, член группы владельцев и все остальные.Кроме того, в системе существует администратор, обладающий абсолютными правами доступа ко всем файлам системы.
ОС UNIX остается сложной в освоении универсальной операционной системой, обладающей избыточными возможностями по отношении к использованию на персональных компьютерах, задачам поддержки локальной сети и обеспечению доступа к глобальным сетям. В связи с этим в появилась система Linux. Linux широко распространена на платформах Intel PC и завоевывает позиции на ряде других платформ (DEC, Apple и др.).
ОС Linux имеет следующие достоинства:
дает возможность бесплатно и легально иметь современную ОС для использования как на работе, так и дома;
обладает высоким быстродействием;
работает надежно, устойчиво, совершенно без зависаний;
не подвержена вирусам;
позволяет использовать полностью возможности современных ПК, снимая ограничения, присущие MS Windows по использованию памяти машины и ресурсов процессора(ов);
эффективно управляет многозадачностью и приоритетами, фоновые задачи (длительный расчет, передача электронной почты по модему, форматирование дискеты и т.д.) не мешают интерактивной работе;
позволяет легко интегрировать компьютер в локальные и глобальные сети, в том числе в Интернет; работает с сетями на базе Novell и MS Windows;
позволяет выполнять представленные в формате загрузки прикладные программы других ОС — различных версий UNIX и MS Windows;
обеспечивает использование огромного числа разнообразных программных пакетов, накопленных в мире UNIX и свободно распространяемых вместе с исходными текстами;
предоставляет богатый набор инструментальных средств для разработки прикладных программ любой степени сложности, в том числе системы класса клиент—сервер, объектно-ориентированные, с многооконным текстовым и/или графическим интерфейсом, пригодных для работы как в Linux, так и в других ОС;
дает пользователю и особенно разработчику замечательную учебную базу в виде богатой документации и исходных текстов всех компонент, включая ядро самой ОС;
дает всем желающим попробовать свои силы в разработке, организовать общение и совместную работу через Интернет с любыми из разработчиков ОС Linux и сделать свой вклад, став соавтором системы.
Операционная система Windows NT
При разработке структуры Windows NT по аналогии с NetWare и UNIX была использована концепция микроядра. В соответствии с этой идеей ОС разделена на несколько подсистем, каждая из которых выполняет отдельный набор сервисных функций, например сервис памяти, сервис по созданию процессов или сервис по планированию процессов. Каждая подсистема выполняется в пользовательском режиме, осуществляя цикл проверки запроса от клиента на одну из его сервисных функций. Клиент, которым может быть либо другая компонента ОС, либо прикладная программа, запрашивает сервис, посылая сообщение на сервер. Ядро ОС (или микроядро), работая в привилегированном режиме, доставляет сообщение нужному серверу, затем сервер выполняет операцию, после этого ядро возвращает результаты клиенту с помощью другого сообщения.Структурно Windows NT может быть представлена в виде двух частей: часть операционной системы, работающая в  HYPERLINK "http://professia.org/seti/251/2_5_1.%20HTML.html" \l "1" режиме пользователя, и часть операционной системы, работающая в режиме ядра (рис. 2).
Рис. 2 Структура Windows NT
Поддержку защищенных подсистем обеспечивает исполнительная часть Windows NT executive, которая работает в пространстве ядра и никогда не сбрасывается на диск. Ее составными частями являются:
менеджер объектов. Создает, удаляет и управляет объектами NT executive – абстрактными типами данных, используемых для представления ресурсов системы;
монитор безопасности. Устанавливает правила защиты на локальном компьютере. Охраняет ресурсы операционной системы, выполняет защиту и регистрацию исполняемых объектов;
менеджер процессов. Создает и завершает, приостанавливает и возобновляет процессы и нити, а также хранит о них информацию;
менеджер виртуальной памяти;
подсистема ввода-вывода. Включает в себя следующие компоненты:
1) менеджер ввода-вывода, предоставляющий средства ввода-вывода, независимые от устройств;
2) файловые системы — NT-драйверы, выполняющие файл-ориентированные запросы на ввод-вывод и транслирующие их в вызовы обычных устройств;
3) сетевой редиректор и сетевой сервер — драйверы файловых систем, передающие удаленные запросы на ввод-вывод на машины сети и получающие запросы от них;
4) драйверы устройств NT executive — низкоуровневые драйверы, которые непосредственно управляют устройством;
5) менеджер кэша, реализующий кэширование диска.
Исполнительная часть, в свою очередь, основывается на службах нижнего уровня, предоставляемых ядром (его можно назвать и микроядром) NT. В функции ядра входит:
планирование процессов;
обработка прерываний и исключительных ситуаций;
синхронизация процессоров для многопроцессорных систем;
восстановление системы после сбоев.
Windows NT использует защищенные подсистемы в следующих целях:
обеспечение нескольких программных интерфейсов (API), по возможности не усложняя при этом базовый программный код (NT executive);
изоляция базовой ОС от изменений или расширений в поддерживаемых API;
объединение части глобальных данных, требующихся всем API, и в то же время отделение данных, использующихся каждым отдельным API от данных, использующихся другими API;
защита окружения каждого API от приложений, а также от окружений других API, и защита базовой ОС от различных окружений;
расширение ОС в будущем благодаря новым API.
Микроядро NT служит, главным образом, средством поддержки для переносимой основной части ОС — набора пользовательских сред. Концентрация машинно-зависимых программ внутри микроядра делает перенос NT на разнообразные процессоры относительно легким.
В Windows NT реализована вытесняющая многозадачность, при которой операционная система не ждет, когда нить сама захочет освободить процессор, а принудительно снимает ее с выполнения — после того как та израсходовала отведенное ей время (квант) или если в очереди готовых появилась нить с более высоким приоритетом. При такой организации разделения процессора ни одна нить не займет процессор на очень долгое время.
Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто были рассчитаны на взаимодействие с определенным типом транспортного протокола. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были писать различные варианты одного и того же драйвера, рассчитанные на связь с разными протоколами транспортного уровня.
Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые «спецификация интерфейса сетевого драйвера» (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т.п.), используя один сетевой адаптер и один сетевой драйвер.Операционная система Windows 2000
Windows 2000, является потомком NT, обладает всеми ее достоинствами, а многие из ее ограничений при этом снимает. Windows 2000 — один из крупнейших программных продуктов, его код содержит около 30 млн. строк. В Windows 2000 появилась поддержка шины USB, РС-карт, шины AGP и DVD-устройств, а также технологии Plug and Play , которой славится Windows 98, — автоматического распознавания и установки устройств.
Для инсталляции Windows 2000 Professional нужно не менее 650 Мбайт свободного дискового пространства, но на некоторых машинах может потребоваться до 1 Гбайт. В установленном виде система занимает около 500 Мбайт — примерно вдвое больше, чем Windows 98.
Заметно расширены в Windows 2000 возможности работы с файловыми системами. Помимо используемых в Windows 9x файловых систем FAT16 и FAT32 (незащищенных), эта ОС работает с NTFS5 (NT File System 5), специально разработанной для Windows 2000 усовершенствованной версией файловых систем с добавлением шифрования и других новых возможностей. Она обеспечивает более эффективное использование дискового пространства и лучшую защиту информации.
Важным шагом вперед в защиту данных в Windows 2000 явилась технология Kerberos. Kerberos — это протокол аутентификации, обеспечивающий передачу данных по незащищенным сетям. Именно он наряду со службой каталогов Active Directory (AD) составляет важнейшую особенность Windows 2000, отличающую эту систему от Windows NT 4.0. Kerberos обеспечивает создание транзитивных доверительных отношений, тогда как NT 4.0 позволяет формировать лишь нетранзитивные. Эту идею можно пояснить на простом примере: если Х доверяет некоторому человеку У, а он, в свою очередь, доверяет Z, то, в соответствии с логикой формирования транзитивных отношений, этого уже достаточно, чтобы Х доверял Z. Эта особенность протокола Kerberos как раз и позволяет системе Windows 2000 формировать деревья и леса доменов. Другая сильная сторона протокола — функция взаимной аутентификации, т. е. возможность любого члена каждой пары «клиент-сервер» проверять полномочия своего партнера. Эта функция снимает такую характерную для Windows NT Workstation 4.0 проблему, как уязвимость для атак со стороны систем, выдающих себя за серверы.
ОС Windows 2000 оснащается средствами защиты информации на базе  HYPERLINK "http://professia.org/seti/251/2_5_1.%20HTML.html" \l "1" инфраструктуры открытых ключей (Public Key Infrastructure — PKI). Эта инфраструктура представляет собой систему цифровых сертификатов и организаций, удостоверяющих сертификаты (Certificate Authorities — CAs). Также, как и протокол Kerberos, она дает возможность обоим участникам транзакции проверять, действительно ли партнер является тем, за кого себя выдает, а также шифровать транзакции. Система защиты данных на базе PKI лучше всего подходит для использования в сети Интернет и потому представляет собой полезное средство для организации электронной коммерции между предприятиями.
В состав системы входит вполне добротный маршрутизатор с интерфейсом подключения по запросу (Demand-Dial Interface – DDI), так что при появлении на интерфейсе модема трафика автоматически устанавливается соединение с Интернетом. С помощью таких средств, как реализованные в Windows 2000 Server и в Windows 2000 Professional модуль Internet Connection Sharing, доступ к предоставляемому системой выходу в Интернет получают сразу несколько пользователей сети. Этот модуль реализует технологию трансляции сетевых адресов (Network Address Translation — NAT): маршрутизатор (т.е. сервер) транслирует трафик «локальная сеть — Интернет» в трафик между множеством локальных узлов и одним сетевым IP-адресом.
Службой Terminal Services сервера Windows 2000 Server можно пользоваться без какой-либо предварительной настройки. Эта функция обеспечивает доступ к удаленным серверам, причем пользователь получает такую же степень свободы, как если бы он зарегистрировался с консоли системы.
Windows 2000 оснащена усовершенствованными средствами симметричной многопроцессорной обработки, обеспечивающими более «гладкую», чем Windows NT 4.0, настройку операционной системы для работы с числом процессоров свыше четырех. Кроме того, надо иметь в виду, что сервер Windows 2000 Datacenter Server (Datacenter) выступает в качестве конкурента серверов UNIX с числом процессоров до 32 и оснащенных физической памятью емкостью 64 Гбайт.
Windows 2000 и ее предшественница Windows NT 4.0 не могли соперничать с мощными версиями UNIX. С появлением Datacenter Microsoft надеется выровнять положение, задействовав Windows на более крупных и мощных машинах, чем когда-либо до этого. Благодаря дополнительным возможностям повышается уровень масштабируемости, готовности и управляемости Windows 2000. Специальные требования к сертификации и техническому обслуживанию еще более выделяют эту операционную систему среди остальных серверов семейства Windows 2000. В таблице 1 приведены сравнительные характеристики Windows 2000 Server, Windows 2000 Advanced Server (AS) и Datacenter.
Таблица 1 Сравнительные характеристики Windows 2000 Server
Параметр Windows 2000 Server Windows 2000 AS Datacenter
Максимальное число процессов 4 8 32
Максимальная емкость памяти, Гбайт 4 8 64
Совместимость с WSD Нет Нет Да
Кластерная служба Нет да, 2 узла да, 4 узла
Совместимость с NLB (технологией балансировки нагрузки – трафика между серверами) Нет да, 32 узла да, 32 узла
Управление объектом задания Только API Только API API, встраиваемый модуль MMC Process Control, утилита Proccon
Joint Suppot Queue – служба технической поддержки Нет Нет Да
Сертификация приложений Сертификат Windows 2000 Server Сертификат Windows 2000 Serve, Windows AS Сертификат Windows 2000 Server, Windows 2000 AS и Datacenter
Продавец Microsoft Microsoft Уполномоченные OEM
Аппаратная совместимость Стандартный Windows 2000 HCL Стандартный Windows 2000 HCL Специальный Datacenter HCL
28 ПО общего назначения
«ПК Входящая-исходящая документация» (“InOutD”) 1. Назначение и условия функционирования
 
1.1 НазначениеПрограммное средство “ InOutD ” предназначено для автоматизации ведения журналов входящей и исходящей корреспонденции в учреждениях, в структуре которых  обязательно наличие отделов. Предоставляется возможность регистрации документов, их распределение для исполнения по отделам и контроль своевременного исполнения.  Осуществляется быстрый поиск нужных документов и возможность просмотра их электронных копий.
 
1.2 Функции Программное средство “InOutD” обеспечивает реализацию следующих функций:
    регистрация входящих документов секретарем учреждения, внесение резолюции руководителя и распределение документов по начальникам отделов;
    постановка документов на контроль и их снятие с контроля;
    наблюдение за своевременным исполнением документов и их распределением по отделам;
    создание ссылки на электронную копию документа для возможности его просмотра;
    печать журналов регистрации входящих и исходящих документов;
    поиск зарегистрированных документов по различным признакам;
    внесение резолюции начальником отдела;
    распределение документов среди сотрудников отдела и анализ их распределения  среди сотрудников;
    регистрация исходящих документов;
    регистрация приказов.
1.3 Условия функционированияПрограммное средство “InOutD”, далее просто ПС, функционирует под управлением СУБД VISUAL FOXPRO V 6.0 на ПК стандартной конфигурации с расширенной памятью в среде WINDOWS 98, 2000, XP в локальном или сетевом варианте.Разрешение рабочей области экрана монитора должно быть не менее 800х600 точек.В случае работы в сети необходимо программу и базу данных (БД) располагать на сервере и администратору сети обеспечить доступ пользователей к соответствующим каталогам.
29 ПО поиска неисправности в сети
Поиск неисправностей в сети. Поиск неисправностей в сети - это сочетание анализа (измерения, диагностика и локализация ошибок) и синтеза (принятие решения о том, какие изменения надо внести в работу сети, чтобы исправить ее работу). Анализ - определение значения критерия эффективности (или, что одно и то же, критерия оптимизации) системы для данного сочетания параметров сети. Из этого этапа выделяется подэтап мониторинга, на котором выполняется более простая процедура - процедура сбора первичных данных о работе сети: статистики о количестве циркулирующих в сети кадров и пакетов различных протоколов, состоянии портов концентраторов, коммутаторов и маршрутизаторов и т.п. Далее выполняется этап собственно анализа, под которым в этом случае понимается более сложный и интеллектуальный процесс осмысления собранной на этапе мониторинга информации, сопоставления ее с данными, полученными ранее, и выработки предположений о возможных причинах замедленной или ненадежной работы сети. Задача мониторинга решается программными и аппаратными измерителями, тестерами, сетевыми анализаторами и встроенными средствами мониторинга систем управления сетями и системами. Задача анализа требует более активного участия человека, а также использования таких сложных средств как экспертные системы, аккумулирующие практический опыт многих сетевых специалистов. Синтез - выбор значений варьируемых параметров, при которых показатель эффективности имеет наилучшее значение. Если задано пороговое значение показателя эффективности, то результатом синтеза должен быть один из вариантов сети, превосходящий заданный порог. Приведение сети в работоспособное состояние - это также синтез, при котором находится любой вариант сети, для которого значение показателя эффективности отличается от состояния "не работает". Синтез рационального варианта сети - процедура чаще всего неформальная, так как она связана с выбором слишком большого и очень разнородного множества параметров сети - типов применяемого коммуникационного оборудования, моделей этого оборудования, числа серверов, типов компьютеров, используемых в качестве серверов, типов операционных систем, параметров этих операционных систем, стеков коммуникационных протоколов, их параметров и т.д. и т.п. Очень часто мотивы, влияющие на выбор "в целом", то есть выбор типа или модели оборудования, стека протоколов или операционной системы, не носят технического характера, а принимаются из других соображений - коммерческих, "политических" и т.п. Поэтому формализовать постановку задачи оптимизации в таких случаях просто невозможно. В данной книге основное внимание уделяется этапам мониторинга и анализа сети, как более формальным и автоматизируемым процедурам. В тех случаях, когда это возможно, в книге даются рекомендации по выполнению некоторых последовательностей действий по нахождению рационального варианта сети или приводятся соображения, облегчающие его поиск.Обнаружение проблем в сетевом окружении. Основные проблемы, которые могут возникать в сетевом окружении: 
потеря или невозможность соединения компьютеров в подсети и/или в домене, 
уменьшение скорости обмена данными, 
невозможность получить доступ к общим ресурсам сети - папкам, каталогам, принтерам и т.д, 
невозможность получения IP-адреса от сервиса DHCP, 
невозможность установления связи с компьютерами других доменов, 
нарушение функционирования сетевого взаимодействия с использованием безопасности IP, 
недоступность со стороны компьютера-клиента серверных компонентов.
Проверить наличие или отсутствие соединений с другими компьютерами в сети можно в папке Cетевое окружение, открыв папку Вся сеть (дважды щелкнув соответствующий значок). В папке Вся сетьдоступна сеть Microsoft Windows Network. Открыв ее, можно увидеть значки с именами доступных доменов подсетей, и далее, значки компьютеров входящих в эти подсети. Отсутствие значков уже говорит об отсутствии соединений. Но если соединение с каким-либо компьютером внезапно пропадет, то попытка открыть этот компьютер вызовет задержку в работе проводника на период срабатывания тайм-аута и система выведет сообщение об отсутствии в сети ресурса. Аналогично обстоит дело с доступом к каталогу Active Directory, значок которого Каталог находится там же, в папке Вся сеть.Поиск неисправностей в сети. Утилиты TCP/IP. Windows XP предоставляет в ваше распоряжение широкий набор утилит для управления, конфигурирования и выявления неисправностей среды TCP/IP.Ping - диагностическая утилита, которая проверяет возможность соединения с удаленным компьютером. Pathping - усовершенствованная утилита ping, которая также отражает маршрут прохождения и предоставляет статистику потери пакетов на промежуточных маршрутизаторах. Route - показывает и позволяет изменять конфигурацию локальной таблицу маршрутизации. Tracert - отслеживает маршрут, по которому пакеты перемещаются на пути к пункту назначения. Netstat - показывает текущую информацию сетевого соединения TCP/IP. Например, информацию о подключенном хосте и номера используемых портов. Ipconfig - показывает текущую конфигурацию TCP/IP на локальном компьютере. Hostname - показывает локально настроенное имя узла TCP/IP .. Arp - показывает и позволяет изменять кэш протокола ARP (Address Resolution Protocol), где хранится информация о соответствии IP - адресов - MAC - адресам локальных узлов. Nslookup - утилита командной строки - распознаватель для запросов DNS сервера. Утилиты выполняются из командной строки. Чтобы открыть окно командной строки нажмите кнопку Пуск и выберите последовательно команды Все программы -> Стандартные -> Командная строка.Если не удается подключиться к другому компьютеру, могут иметь место неполадки с подключением или неполадки с именами.Применение утилит ping и ipconfig. Чтобы определить причину неполадок, попытайтесь выполнить обмен пакетами (утилита ping) с IP-адресом другого компьютера. Таким компьютером может быть компьютер, с которым вы пытаетесь соединиться, или основной шлюз. Чтобы определить IP-адрес основного шлюза: наберите в командной строке ipconfig и нажмите клавишу ENTER. Если требуемая информация уходит с экрана, то для просмотра экранов по очереди введите ipconfig | more и нажмите клавишу ENTER. В отображаемых результатах найдите строку Основной шлюз и запишите соответствующий IP-адрес. Чтобы выполнить обмен пакетами (ping) с другим компьютером: наберите в командной строке: ping адрес, где адрес представляет IP-адрес другого компьютера, и нажмите клавишу ENTER. Если обмен пакетами выполнен успешно, появляется отклик, аналогичный следующему:Ответ от <адрес> число байт=32:Ответ от <адрес>: число байт=32 время=75мс TTL=28Ответ от <адрес>: число байт=32 время=87мс TTL=28Если обмен пакетами выполнить не удается, появляется отклик, аналогичный следующему: Ответ от <адрес> число байт=32:Превышен интервал ожидания.Превышен интервал ожидания.Утилита Ipconfig показывает текущую конфигурацию TCP/IP на локальном компьютере.Ключи утилиты: /release - освобождает полученный от DHCP IP - адрес./renew - получает от DHCP новый IP - адрес./all - показывает всю информацию о TCP/IP конфигурации./flushdns - очищает кэш локального распознавателя DNS./regsiterdns - обновляет адрес в DHCP и перерегистрирует его в DNS./displaydns - показывает содержание кэша распознавателя DNS.
30 ПО поиска неисправности в сети
В данном руководстве содержатся советы по поиску и устранению сетевых проблем (локальная сеть), характерных для встроенных решений локальных сетей (LAN) на системных платах Intel® для настольных ПК.
Общая информация
Как определить версию сетевого драйвераГде найти последние версии сетевых драйверовКак обновить сетевые драйверыУстановка дополнительных сетевых платВключение среды сетевой загрузки PXEКонфигурирование Wake-on-LANИспользование технологии Intel® Active ManagementБольшие кадрыПоиск и устранение неисправностей
После обновления драйвера сетевого адаптера возникает сетевая ошибкаОшибка: “This connection has limited or no connectivity” (Соединение ограничено или отсутствует).Периодические ошибки сетевой подсистемы на системной плате Intel® DG31PR для настольных ПКПроблемы сетевого подключения
Общая информацияКак определить версию сетевого драйвера
Для Windows 7*:
Нажмите Пуск > правой кнопкой мыши нажмите Компьютер >Управление.
Выберите Диспетчер устройств.
Откройте раздел Сетевые адаптеры.
Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.
Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.
Для Windows Vista:
Нажмите Пуск > Настройки > Панель управления > Система >Диспетчер устройств.
Откройте раздел Сетевые адаптеры.
Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.
Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.
В Microsoft Windows XP*:
Нажмите Пуск (Start) > Панель управления (Control Panel) > Система и ее обслуживание (Performance and Maintenance) > Система(System).
Перейдите на вкладку Аппаратные средства и выберите Менеджер устройств.
Откройте раздел Сетевые адаптеры.
Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.
Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.
Для Microsoft Windows 98SE, ME или 2000*:
Нажмите Пуск (Start) > Настройки (Settings) > Панель управления(Control Panel).
Два раза нажмите Система (System).
Перейдите на вкладку Аппаратные средства и выберите Менеджер устройств.
Откройте раздел Сетевые адаптеры.
Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.
Перейдите на вкладку Драйвер (Driver), чтобы увидеть текущую версию драйвера.
Где найти последние версии сетевых драйверовВы можете скачать последние версии сетевых драйверов для Вашей системной платы Intel® в центре загрузки Intel.
Как обновить сетевые драйверы
Загрузите версию сетевого драйвера в центре загрузки Intel.
Дважды нажмите на загруженный файл, чтобы извлечь и установить обновленные драйверы.
Установка дополнительных сетевых платЕсли Вы хотите установить сетевую плату стороннего производителя вместо интегрированного сетевого решения, выполните следующие действия.
Отключение интегрированной сетевой платы:
Во время начальной загрузки нажмите F2, чтобы войти в режим конфигурирования BIOS.
Перейдите в меню Advanced (Дополнительно) > Peripherals Configuration (конфигурация периферийных устройств).
Отключение интегрированного сетевого решения.
Сохраните изменения, нажав F10, и выйдите из режима конфигурирования BIOS.
Установите карту дополнительную сетевую плату стороннего производителя в соответствии с инструкциями.
Включение среды сетевой загрузки PXEВ системных платах Intel® для настольных ПК с поддержкой предзагрузочной среды (PXE) можно выбрать сетевое устройство в качестве загрузочного. Это позволяет произвести загрузку с интегрированного сетевого решения.
Чтобы использовать сетевое устройство в качестве загрузочного, выполните следующее:
Во время начальной загрузки нажмите F2, чтобы войти в режим конфигурирования BIOS.
Перейдите в меню Boot.
Включите функцию Boot to Network.
Сохраните изменения, нажав F10, и выйдите из режима конфигурирования BIOS.
При нажатии клавиши <F12> во время процедуры POST форсируется загрузка с сетевого диска. Для использования этой клавиши во время процедуры POST, параметру User Access Level в программе настройки BIOS должно быть присвоено значение Full.
Конфигурирование Wake-on-LANWake-on-LAN - это аппаратно-программное решение, позволяющее удаленно пробудить компьютер. Компьютер, совместимый с интерфейсом управления конфигурацией и питанием (ACPI), можно включить удаленно из любой точки мира при условии, что он подключен к Интернету.
Вначале функция Wake-on-LAN должна быть включена в BIOS системной платы для настольных ПК, а затем настроена в операционной системе.
Чтобы включить функцию Wake-on-LAN, выполните следующие действия:
Во время начальной загрузки нажмите F2, чтобы войти в режим конфигурирования BIOS.
Перейдите к меню Power.
Установите параметр Wake-on-LAN в положение Power On (Включено).
Сохраните изменения, нажав F10, и выйдите из режима конфигурирования BIOS.
Чтобы настроить функцию Wake-on-LAN в операционной системе, выполните следующие действия:
Нажмите Пуск (Start) > Настройки (Settings) > Панель управления(Control Panel).
Два раза нажмите Система (System).
Перейдите на вкладку Аппаратные средства и выберите Менеджер устройств.
Откройте раздел Сетевые адаптеры.
Нажмите правой кнопкой мыши на адаптер и выберите вкладкуСвойства.
Откройте закладку Дополнительно.
Выберите Wake-on-LAN Options (Параметры Wake-on-LAN) и выберите вкладку Properties (Свойства). Установите следующее:
Включение PME: Установите Enabled
Настройки функции Wake on: выберите Wake on Magic Packet
Использование технологии Intel® Active ManagementТехнология Intel® Active Management (Intel® AMT) – это аппаратное решение, использующее коммуникации по внештатному каналу для управления клиентскими системами независимо от их состояния. Даже при отказе жесткого диска и заблокированной операционной системе Вы сможете получить доступ к клиентскому компьютеру для выполнения базовых управленческих задач.
Инструкции по базовой настройке системы и информация об использовании Web-браузера для доступа к клиентской системе посредством AMT доступны в Руководстве по быстрому запуску.
Дополнительные функции Intel® AMT реализованы разработчиками в виде программного обеспечения, поддерживающего эту новую технологию управления.
Большие кадрыВ некоторых гигабитных сетевых адаптерах Intel®, поддерживающих большие кадры, установлено ограничение на размер кадров до 9328 байт и соответствующее ограничение на максимальный размер пакета (MTU) до 9216 байт. Это ограничение оказывает влияние на следующие компоненты сетевого решения системных плат Intel® для настольных ПК:
Гигабитный сетевой контроллер Intel® 82547EI
Примечание Сетевой адаптер Intel PRO/1000 PL поддерживает большие кадры в ОС Microsoft* Windows* только, если установлено решение Intel® PROSet для программы Windows Device Manager.
Следующие гигабитные сетевые адаптеры, входящие в комплектацию системных плат Intel® для настольных ПК, не поддерживают большие кадры:
Гигабитный сетевой контроллер Intel® 82566DM
Гигабитный сетевой контроллер Intel® 82566DC
Гигабитный сетевой контроллер Intel® 82573E
Гигабитный сетевой контроллер Intel® 82573V
Гигабитный сетевой контроллер Intel® 82573L
Поиск и устранение неисправностей
Поиск и устранение неисправностейВ некоторых случаях, при использовании сетевого драйвера версии 14.7, 14.8 или 15.1 MAC-адрес системы меняется на 00.00.00.00.00.00, в результате чего происходит сбой сетевого соединения. Для решения данной проблемы обновите версию сетевого драйвера до версии 15.3 или выше.
Ошибка: “This connection has limited or no connectivity.” (Соединение ограничено или отсутствует).При использовании Microsoft Windows* XP Service Pack 2 возможно возникновение следующих проблем:
На панели задач возникает следующее сообщение: “This connection has limited or no connectivity (Соединение ограничено или отсутствует). You might not be able to access the Internet or some network resources” (Возможно, Вы не сможете получить доступ к Интернету или другим сетевым ресурсам).
Возникли проблемы при подключении к Интернету или локальной сети.
При попытке подключения система зависает на этапе «Acquiring IP Address» (Определение IP-адреса).
Загрузите и установите обновление для Windows XP* Service Pack 2 (KB884020)Периодические ошибки сетевой подсистемы на системной плате Intel® DG31PR для настольных ПКЕсли у вас возникают ошибки сетевого подключения на системной плате Intel® DG31PR для настольных ПК, попробуйте обновить драйвер сетевой платы до последней версии. Новейшую версию драйвера можно загрузить вцентре загрузки Intel.
Проблемы сетевого подключенияПроблемы сетевого подключения быть вызваны различными причинами. Информация по устранению возникших проблем с сетевым подключением содержится в следующих статьях:
Как выявить и устранить основные проблемы, связанные с Internet Explorer*Как выявить и устранить основные проблемы, связанные с TCP/IPКак выявить и устранить проблемы подключения TCP/IP к ОС Microsoft Windows XP*Как выявить и устранить проблемы в домашней сети на базе ОС Microsoft Windows XPКак выявить и устранить проблемы с сетевым подключением31 ПО анализа и оптимизации сети
Оптимизация сетей позволяет операторам сотовой связи решать такие актуальные на сегодняшний момент задачи, напрямую влияющие на доход оператора:
Максимально эффективно использовать существующие ресурсы сети, что позволяет экономить на необязательном расширении различных элементов сети.
Уменьшать потери трафика в сети: любой неуспешный звонок абонента (оборванные не по инициативе абонента или несостоявшийся вызов) уменьшает доход оператора.
Повышать лояльность абонентов за счет улучшения качества предоставления услуг. Затраты на привлечение нового абонента значительно превышают затраты на повышение лояльности. Более того, чем выше качества предоставляемых услуг, тем большее количество дополнительных услуг будет пользоваться среди абонентов спросом.
Безусловно, рассмотренные задачи оператор пытается решить самостоятельно – для этих целей практически каждый оператор имеет подразделение, основной целью которого является мониторинг и поддержание качества предоставляемых услуг на высоком уровне. Однако, как показывает практика, оператор не всегда располагает необходимым количеством персонала для выполнения такого рода работ во всех своих филиалах. Поэтому в ряде случаев для выполнения тех или иных работ в рамках процесса оптимизации в ряде случаев необходимо привлечение компаний, специализирующихся на такого рода работах.
С точки зрения предоставления услуги по оптимизации можно выделить 2 основных блока, каждый из которых состоит из нескольких модулей:
1. Первоначальная оценка текущего состояния сети (своего рода аудит сети) состоит из двух модулей: 
Оценка качества сети:
Анализ статистики BSS
Анализ статистики GPRS
Анализ статистики SSS
Анализ трассировок А-интерфейса
Анализ трассировок Gb-интерфейса
Оценка качества сети E2E тестами:
Проведение драйв-тестовАнализ качества передачи речи
Анализ качества передачи данных
Проведение benchmark драйв-тестов (сравнение с сетями конкурентов)
2. Оптимизация сети включает в себя следующие модули:
Оптимизация подсистемы базовых станций (как для голосовой услуги, так и для пакетной передачи трафика):
Анализ основных показателей качества
Оптимизация соотношений «по соседям»
Анализ параметров баз данных BSC и их корректировка
Предложения по активации новых опций
Выборочная проверка наиболее проблемных сайтов
Оптимизация подсистемы коммутации (как для голосовой услуги, так и для пакетной передачи трафика)
Анализ основных показателей качества
Определение трафик-моделиАнализ трассировок различных интерфейсов
Оптимизация баз данных MSC, SGSN
Выявление перегруженных направлений
2G/3G оптимизация:
Распределение трафика между 2G/3G иерархическими уровнями сети
Обеспечение эффективной работы между слоями 2G/3G
Ниже приводятся основные задачи, решаемые в процессе оптимизации подсистемы базовых станций:
Определение основных показателей качества (KPI):
Проводится согласование списка показателей качества, по которым проводится оценка сети, а также формул для вычисления KPI.
Оговариваются значения, которые предполагается достичь в результате оптимизации.
Мониторинг и анализ качества работы сети радиодоступа подсистемы BSS:
Мониторинг качества работы подсистемы BSS
Наблюдение за изменениями конфигурации при помощи специальных программных средств для анализа сети радиодоступа
Определение основных проблемных зон, разработка рекомендаций по улучшению качества работы сети
После проведенного анализа будут предоставлены результаты запланированных и реализованных изменений, а также указаны необходимые действия по улучшению ситуации в случае допущенных неточностей
Мониторинг и оптимизация соотношений «по соседям»
Проводится анализ имеющихся соотношений «по соседям»:
при помощи специального программного обеспечения
на основе статистических данных
на основе результатов драйв-тестовПредоставляются таблицы, в которых для сот будут определены необходимые «соседи».
Анализ параметров базы данных контроллеров и их корректировкаПроверка измененных параметров баз данных контроллеров и их уточнение
Разработка значений логических параметров БС и их последующая настройка
Анализ взаимосвязанных логических параметров (особенно соотношения таймеров)
Создание необходимых RC-скриптов для реализации предложенных значений логических параметров.
Предложения по внедрению новых опций
Разработка значений логических параметров для эффективной работы опций
Предложения по установке логических параметров в случае активации новых опций
Создание необходимых RC-скриптов для реализации предложенных значений логических параметров.
Поддержка 1-го уровня с выездом на сайты
Поддержка с выездом на сайт при проведении инспекции установленного оборудования, согласно техническим предписаниям и нормам по монтажу и эксплуатации оборудования.
При оптимизации подсистемы коммутации решаются следующие задачи:
Определение основных показателей качества (KPI)
Проводится согласование списка показателей качества, по которым проводится оценка сети, а также формул для вычисления KPI. 
Оговариваются значения, которые предполагается достичь в результате оптимизации.
Анализ качества работы подсистемы SSS на основе KPIАнализ емкости подсистемы SSS
Транкгруппы. Анализ позволяет получить представление о:
состоянииколичествестепени загруженности (utilisation rate, mErl)
ошибкахдля каждой из транкгрупп в ЧНН.
Нагрузка на LTG. Анализ позволяет получить представление о
статической нагрузке (мЕрл)
динамической нагрузке (попытки вызовов)
для каждой из LTG
Сигнальная сеть SSNC. Анализ MP и C7 линков позволяет получить представление о
нагрузке на линксет и каждый линк в частности (мЕрл)
рапределении нагрузки в пределах линксета
наличии ретранслированных октетов
динамической нагрузке МР
Анализ и корректировка баз данных коммутаторов
Соединения, маршрутизация и SDDPFC
Нумерация
Обработка глобальных заголовков (GTT)
Зависимые друг от друга команды
ODAGEN
Сравнение частей баз данных на разных сетевых элементах
Создание корректирующих баз данных
Установка корректирующих баз данных
31 краткое описание команд распространенных протоколов
Соединиться по какому-либо протоколу" - слышали такие слова? Кто они, вообще, эти протоколы передачи данных? Этой теме и посвящена данная статья (эта статья несколько сложней для восприятия, чем большинство статей на этом сайте).
Начнем с того, что протокол - это просто установленный "язык" общения программ. Вообще, что такое пересылка данных? По кабелю отправляется последовательность "битов" - нулей или единиц. Но почему этот поток доходит до целевого компьютера и что тот собирается с этим потоком делать? Естественно, должны существовать некоторые правила формирования данных, и эти правила описываются стандартными протоколами.
Про протоколы также обычно говорят, что имеются уровни вложенности сетевых протоколов. Что это означает? Во-первых, есть так называемый физический уровень. Это - просто список определений, каким должен быть сетевой кабель, толщину жил и так далее. Допустим, теперь, кабель исправен. Тогда по нему могут отправляться пакеты с данными. Но какой компьютер примет пакет? Здесь задействуется так называемый канальный уровень - в заголовке пакета указывается физический адрес компьютера - некоторое число, зашитое в сетевой карте (не IP-адрес, а MAC-адрес).

Канальный уровень = уровень Ethernet. Как вы видите (картинку я взял с википедии), пакет содержит некоторый параметр Ethertype, задающий тип пакета. Сами данные зависят от этого типа, и их содержание уже находится на сетевом уровне. Наиболее распространены два протокола: ARP, отвечающий за преобразование IP-адресов в MAC-адреса; и самый существенный протокол - IP. Приведем структуру пакета IP (детализация поля "Data" предудущего рисунка)

Все данные, переносимые по IP уже пересылаются на конкретный IP-адрес (это не мешает посылать широковещательных запросы всем компьютерам локальной сети - просто указывается специальный IP-адрес, например, 192.168.255.255). У протокола IP тоже есть разновидности - в пакете в установленном формате передается число, обозначающее тип протокола. Например, одним из типов протоколов, подчиненных IP, является ICMP, используемый командой ping для проверки, откликается ли компьютер.
Но наиболее распространены два следующих типа: TCP - Transmission Control Protocol и UDP - universal datagram protocol (кстати, мы уже поднялись на транспортный уровень). Отличие же между этими протоколами таково: про протокол TCP говорят, что он "надежный", то есть в процессе обмена данными производится постоянная проверка: а дошел ли пакет до цели? А протокол UDP не предусматривает никакого контроля - отправили дейтаграмму и забыли. Когда такое нужно? Очень просто, например, при прослушивании интернет-радио. Если был сбой и пакет до вас вовремя не дошел, он уже не нужен - просто проскользнули помехи - и вы слушаете дальше. Приведем структуру TCP-пакета (детализация поля "данные" с предудущего рисунка).

Как мы видим, в пакете указывается номер порта, на который отправлен пакет. Обычно номер порта определяет тип протокола на прикладном уровене - какому именно приложению отправлены эти данные. Однако ничего не запрещает использовать нестандартные порты для своих сервисов - просто менее удобно будет пользователям. Наиболее известные протоколы - http (просмотр страниц в интернете), pop3 (получение почты). Чтобы не повторяться, отошлю к списку стандартных портов. Сами данные, получаемые приложением вкладываются в TCP-пакет (поле "данные").
Таким образом, мы получили своеобразную иерархию вложенности пакетов. В Ethernet-пакет вложен IP-пакет, в него TPC или UDP-пакет, а в него - данные, предназначенные конкретному приложению. Просто смерть кащея какая-то.
Что еще интересно, протокол DHCP, отвечающий за получение IP-адреса по MAC-адресу, также находится на прикладном уровне (по умолчанию использует UDP порты 67 и 68) - хоть у компьютера еще нет IP-адреса, он может отсылать широковещательные запросы согласно сетевым настройкам. То же самое можно сказать про протокол DNS, выясняющий IP-адрес по доменному имени.32 формальные методы описание протоколов
Число эксплуатируемых в настоящее время протоколов обмена данными велико; при этом разрабатываются все новые протоколы, обеспечивающие лавинное развитие сетевых технологий (появилась новая область вычислительной техники, называемая ‘протокольной технологией’).
Классическое (неформально-словесное, например, ранее упомянутые RFC-документы) описание протокольных соглашений имеет ряд недостатков; важнейшие из них - не позволяющая однозначно согласовывать разрабатываемые стандарты субъективная природа восприятия словесных описаний (следствие - описания не имеют полноты и основы для анализа), возникают трудности и труднолокализируемые ошибки при создании реализующих эти протоколы программных и аппаратных средств. По сравнению со словесными формальные описания обладают существенными преимуществами - они строги и однозначны, лежащие в основе конкретного метода формального описания модели позволяют выполнить анализ (верификацию) описаний, а также автоматизировать процесс трансляции этих описаний непосредственно в машинную реализацию. Формальные методы описания протоколов могут быть разбиты на две группы - методы первой группы рассматривают объект как автомат (т.н. ‘автоматные методы’), методы второй группы - как ‘черный ящик’, характеризующийся только внешним поведением (т.н. ‘методы последовательностей’).
В качестве представителя первой группы может быть приведен язык ESTELLE (Extended State Transition Language), второй - язык LOTOS
(Language of Temporal Ordering Specification); оба языка разработаны Международной организацией стандартов (ISO) и служат базовыми средствами для описания разрабатывающих международных стандартов [8].
Язык ESTELLE (1983 г.) основан на объединении логики конечного ав-томата (при добавлении элементов описания архитектурных особенностей протокольных систем) и языка программирования Pascal; применяемые в
языке LOTOS (1984 г.) методы основаны на концепции временного упорядо-
чения примитивов взаимодействия.
В СССР для конкретного программно-аппаратного окружения был раз-
работан (в рамках инструментального комплекса ‘Архитектор’) реализую-
щий ‘автоматный метод’ язык ОСА (Описание Сетевых Архитектур, основы и принципы языка впервые опубликованы в 1983 г.), предназначенный для реализации протокольных архитектур на вычислительных комплексах ‘Эльбрус’. В комплект системы входят развитые средства анализа описаний на языке ОСА и средства тестирования и отладки (под конкретную аппаратную часть). С помощью языка OCA были разработаны специализированные протоколы канального и сетевого уровней, транспортный и сеансовый протокол, протоколы для передачи информации и файлов, удаленного диалога и протокол удаленного запуска заданий (некоторый функциональный аналог RPC в Windows’NT).
Кроме вышеприведенных, известны системы проектирования и описания протоколов FAPL (Format and Access Protocol Language, 1978), PANDORA (Protocol Analysis, Design and OpeRation Assesment, 1982), PDIL (Protocol Description and Implementation Language, 1982), ПРАНАС (Каунас-
ский политехнический институт, 1985) и др. Как и в случае традиционных языков программирования, исходный
текст на языке формального описания протоколов транслируется (после этапа отладки) в машинный код, исполняемый часто (специализированными) процессорами передачи сообщений (IMP - Interface Message Processor).
Введение в стандарты сетевых протоколов
Сетевой протокол – это стандарт, написанный на бумаге (или, более точно, в текстовом редакторе на компьютере). Стандарты, использующиеся в Интернете, называются Requests For Comment (RFC) – Запросы на комментарий. Стандарты RFC пронумерованы от 1 и далее. Сегодня существует более 4500 RFC. Большинство из них вышли из употребления, так что до сих пор используются лишь некоторые из первой тысячи.
Международная организация по стандартизации (International Standardization Office – ISO) разработала стандарты системы сетевых протоколов, называемой ISO OSI. Другой организацией, разрабатывающей стандарты коммуникаций, является Международный союз телекоммуникаций (International Telecommunication Union – ITU), который находится в Женеве. Раньше ITU назывался CCITT. Союз основан в 1865 году и является одной из самых старых всемирных организаций (для сравнения, Красный Крест был образован в 1863 году).
Некоторые стандарты разрабатываются Институтом инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers – IEEE). RFC, стандарты выпускаемые RIPE (Réseaux IP Européens – Европейская континентальная сеть TCP/IP), и PKCS (Public Key Cryptography Standard – Криптографический стандарт открытого ключа) свободно доступны в Интернете, их очень легко найти. Другие организации (ISO, ITU и т.д.) не дают стандарты бесплатно – за них нужно платить. Если это для вас проблема, вам придется потратить время на поиски в библиотеке.
В начале давайте посмотрим, почему сетевые связи разделены на несколько протоколов. Ответ прост, хотя он и рождает сложные проблемы в различных сферах деятельности. Большинство книг о сетевых протоколах объясняют проблему с помощью метафоры: два иностранца (философа, доктора и т.п.) пытаются общаться друг с другом. Каждый из них владеет только своим родным языком. Для того, чтобы они могли общаться, им нужен переводчик (Рисунок 2.1):

Рисунок 2.1: Трехуровневая архитектура общения
Два иностранца обмениваются идеями, т.е., они общаются. Но это происходит виртуально. В реальности они меняются информацией со своим переводчиками, которые затем передают ее путем вибраций, издаваемых голосовыми связками. Или, если собеседники находятся на большом расстоянии друг от друга, переводчики передают информацию по телефону, и информация физически передается по телефонным линиям. Мы можем говорить и о виртуальном общении в горизонтальном направлении (философский разговор, общий язык переводчиков и электронные сигналы, передаваемые по телефонной линии) и реальном общении в вертикальном направлении (иностранец-переводчик и переводчик-телефон). Таким образом, мы можем выделить три уровня общения:
Между двумя иностранцами
Между переводчиками
Физическая передача информации с помощью средств коммуникации (телефонная линия, голос и т.д.)
Общение между иностранцами и переводчиками виртуально. Фактически, реальное общение происходит между иностранцем и его переводчиком.
В компьютерной сети используется больше уровней. Количество уровней зависит от выбранной вами системы сетевых протоколов. Система сетевых протоколов иногда называется сетевой моделью. Обычно вы работаете с системой, которая используется в Интернете и называется семейством TCP/IP. Помимо TCP/IP мы рассмотрим модель ISO OSI, стандартизированную ISO.

Рисунок 2.2: Сравнение сетевых моделей TCP/IP и ISO OSI
Семейство TCP/IP использует четыре уровня, в то время как ISO OSI использует семь. Системы TCP/IP и ISO OSI значительно отличаются друг от друга, хотя и похожи на сетевом и транспортном уровне.
Лишь в некоторых исключительных случаях, таких как SLIP или PPP, семейство TCP/IP работает на канальном и физическом уровне. Поэтому даже в Интернете мы используем протоколы канального и физического уровня модели ISO OSI.
3. Структура стандартов IEEE 802.XВ 1980 году в институте IEEE был организован комитет 802 по стандартизации локальных сетей, в результате работы которого было принято семейство стандартов IEEE 802-х, которые содержат рекомендации по проектированию нижних уровней локальных сетей. Позже результаты работы этого комитета легли в основу комплекса международных стандартов ISO 8802-1...5. Эти стандарты были созданы на основе очень распространенных фирменных стандартов сетей Ethernet, ArcNet и Token Ring.
Помимо IEEE в работе по стандартизации протоколов локальных сетей принимали участие и другие организации. Так, для сетей, работающих на оптоволокне, американским институтом по стандартизации ANSI был разработан стандарт FDDI, обеспечивающий скорость передачи данных 100 Мб/с. Работы по стандартизации протоколов ведутся также ассоциацией ЕСМА, которой приняты стандарты ЕСМА-80, 81, 82 для локальной сети типа Ethernet и впоследствии стандарты ЕСМА-89,90 по методу передачи маркера.
Стандарты семейства IEEE 802.X охватывают только два нижних уровня семи-уровневой модели OSI - физический и канальный. Это связано с тем, что именно эти уровни в наибольшей степени отражают специфику локальных сетей. Старшие же уровни, начиная с сетевого, в значительной степени имеют общие черты как для локальных, так и для глобальных сетей.
Специфика локальных сетей также нашла свое отражение в разделении канального уровня на два подуровня, которые часто называют также уровнями. Канальный уровень (Data Link Layer) делится в локальных сетях на два подуровня:
логической передачи данных (Logical Link Control, LLC);
управления доступом к среде (Media Access Control, MAC).
Уровень MAC появился из-за существования в локальных сетях разделяемой среды передачи данных. Именно этот уровень обеспечивает корректное совместное использование общей среды, предоставляя ее в соответствии с определенным алгоритмом в распоряжение той или иной станции сети. После того как доступ к среде получен, ею может пользоваться более высокий уровень - уровень LLC, организующий передачу логических единиц данных, кадров информации, с различным уровнем качества транспортных услуг. В современных локальных сетях получили распространение несколько протоколов уровня MAC, реализующих различные алгоритмы доступа к разделяемой среде. Эти протоколы полностью определяют специфику таких технологий, как Ethernet, Fast Ethernet, Gigabit Ethernet, Token Ring, FDDI, l00VG-AnyLAN.
Уровень LLC отвечает за передачу кадров данных между узлами с различной степенью надежности, а также реализует функции интерфейса с прилегающим к нему сетевым уровнем. Именно через уровень LLC сетевой протокол запрашивает у канального уровня нужную ему транспортную операцию с нужным качеством. На уровне LLC существует несколько режимов работы, отличающихся наличием или отсутствием на этом уровне процедур восстановления кадров в случае их потери или искажения, то есть отличающихся качеством транспортных услуг этого уровня.
Протоколы уровней MAC и LLC взаимно независимы - каждый протокол уровня MAC может применяться с любым протоколом уровня LLC, и наоборот.
Стандарты IEEE 802 имеют достаточно четкую структуру, приведенную на рис. 3.1:

Рис. 3.1. Структура стандартов IEEE 802.X
Эта структура появилась в результате большой работы, проведенной комитетом 802 по выделению в разных фирменных технологиях общих подходов и общих функций, а также согласованию стилей их описания. В результате канальный уровень был разделен на два упомянутых подуровня. Описание каждой технологии разделено на две части: описание уровня MAC и описание физического уровня. Как видно из рисунка, практически у каждой технологии единственному протоколу уровня MAC соответствует несколько вариантов протоколов физического уровня (на рисунке в целях экономии места приведены только технологии Ethernet и Token Ring, но все сказанное справедливо также и для остальных технологий, таких как ArcNet, FDDI, l00VG-AnyLAN).
Над канальным уровнем всех технологий изображен общий для них протокол LLC, поддерживающий несколько режимов работы, но независимый от выбора конкретной технологии. Стандарт LLC курирует подкомитет 802.2. Даже технологии, стандартизованные не в рамках комитета 802, ориентируются на использование протокола LLC, определенного стандартом 802.2, например протокол FDDI, стандартизованный ANSI.
Особняком стоят стандарты, разрабатываемые подкомитетом 802.1. Эти стандарты носят общий для всех технологий характер. В подкомитете 802.1 были разработаны общие определения локальных сетей и их свойств, определена связь трех уровней модели IEEE 802 с моделью OSI. Но наиболее практически важными являются стандарты 802.1, которые описывают взаимодействие между собой различных технологий, а также стандарты по построению более сложных сетей на основе базовых топологий. Эта группа стандартов носит общее название стандартов межсетевого взаимодействия (internetworking). Сюда входят такие важные стандарты, как стандарт 802. ID, описывающий логику работы моста/коммутатора, стандарт 802.1Н, определяющий работу транслирующего моста, который может без маршрутизатора объединять сети Ethernet и FDDI, Ethernet и Token Ring и т. п. Сегодня набор стандартов, разработанных подкомитетом 802.1, продолжает расти. Например, недавно он пополнился важным стандартом 802.1Q, определяющим способ построения виртуальных локальных сетей VLAN в сетях на основе коммутаторов.
Стандарты 802.3,802.4,802.5 и 802.12 описывают технологии локальных сетей, которые появились в результате улучшений фирменных технологий, легших в их основу. Так, основу стандарта 802.3 составила технология Ethernet, разработанная компаниями Digital, Intel и Xerox (или Ethernet DIX), стандарт 802.4 появился | как обобщение технологии ArcNet компании Datapoint Corporation, а стандарт 802.5 в основном соответствует технологии Token Ring компании IBM.
Исходные фирменные технологии и их модифицированные варианты - стандарты 802.х в ряде случаев долгие годы существовали параллельно. Например, технология ArcNet так до конца не была приведена в соответствие со стандартом 802.4 (теперь это делать поздно, так как где-то примерно с 1993 года производство оборудования ArcNet было свернуто). Расхождения между технологией Token Ring и стандартом 802.5 тоже периодически возникают, так как компания IBM регулярно вносит усовершенствования в свою технологию и комитет 802.5 отражает эти усовершенствования в стандарте с некоторым запозданием. Исключение составляет технология Ethernet. Последний фирменный стандарт Ethernet DIX был принят в 1980 году, и с тех пор никто больше не предпринимал попыток фирменного развития Ethernet. Все новшества в семействе технологий Ethernet вносятся только в результате принятия открытых стандартов комитетом 802.3.
Более поздние стандарты изначально разрабатывались не одной компанией, а группой заинтересованных компаний, а потом передавались в соответствующий подкомитет IEEE 802 для утверждения. Так произошло с технологиями Fast Ethernet, l00VG-AnyLAN, Gigabit Ethernet. Группа заинтересованных компаний образовывала сначала небольшое объединение, а затем по мере развития работ к нему присоединялись другие компании, так что процесс принятия стандарта носил открытый характер.
Сегодня комитет 802 включает следующий ряд подкомитетов, в который входят как уже упомянутые, так и некоторые другие:
802.1 - Internetworking - объединение сетей;
802.2 - Logical Link Control, LLC - управление логической передачей данных;
802.3 - Ethernet с методом доступа CSMA/CD;
802.4 - Token Bus LAN - локальные сети с методом доступа Token Bus;
802.5 - Token Ring LAN - локальные сети с методом доступа Token Ring;
802.6 - Metropolitan Area Network, MAN - сети мегаполисов;
802.7 - Broadband Technical Advisory Group - техническая консультационная группа по широкополосной передаче;
802,8 - Fiber Optic Technical Advisory Group - техническая консультационная группа по волоконно-оптическим сетям;
802.9 - Integrated Voice and data Networks - интегрированные сети передачи голоса и данных;
802.10 - Network Security - сетевая безопасность;
802.11 - Wireless Networks - беспроводные сети;
802.12 - Demand Priority Access LAN, l00VG-AnyLAN - локальные сети с методом доступа по требованию с приоритетами.
33 Программное обеспечение анализа и оптимизации сети
В последние годы появился новый тип (сетевого) программного обеспечения, призванный обеспечивать эффективную работу сетей ЭВМ.
Дело в том, что современные компьютерные сети тяготеют к глобализации и усложнению топологии, при этом (стихийно) развивающаяся сеть часто становится неэффективной (а иногда и неработоспособной) вследствие неправильного выбора пропускных способностей и распределения потоков в сети; обычно деградация сети внешне (с точки зрения пользователя) проявляется в катастрофической задержке передачи сообщений (вплоть до полной блокировки сети).Пожалуй, впервые указанные проблемы проявились в 70-х годах в связи с постройкой и эксплуатацией сети принадлежащего Министерству обороны США Управления перспективных исследований (DARPA), принятое название - сеть ARPANET; в настоящее время данная сеть считается прообразом глобальной сети InterNet.
Сеть создавалась на случай ядерной войны и предполагала, что любой компьютер в сети может перестать функционировать в произвольный момент времени, равно как и линии связи между компьютерами. Именно такая постановка задачи привела к рождению сетевой технологии, которая впоследствии фактически стала технологией всемирной сети
ARPANET уже к 1975 году обеспечивала службу передачи сообщений между почти 100 ЭВМ, географически разнесенным по континентальной части США и подключенных спутниковой связью (через Гавайи) к нескольким точкам в Европе, причем соединенные сетью ARPANET вычислительные машины во многих отношениях являлись несовместимыми друг с другом по аппаратному и программному обеспечению. Именно тогда был обеспечен сетевой доступ к мощнейшей для того времени ЭВМ ILLIAC IV и были широко применены (с целью разгрузки вычислительных машин от выполнения задач обработки необходимых для функ1щонирования сети сообщений) вышеупомянутые IMP.Сеть ARPANET была спроектирована как для быстрой доставки коротких диалоговых сообщений, так и для обеспечения высокой скорости передачи длинных файлов, при этом стратегия выбора маршрута в сети принимается в каждом процессоре IMP на основе получаемой от соседних процессоров IMP информации и местной информации, включающей сведения о состоянии каналов данного IMP-процессора.
Заметим, что сети общего пользования сложной топологии с коммутацией пакетов появились не только в США (сети ARPANET и TELNET), но и в Канаде (DATAPAC), Англии (EPSS), Европе (EIN), Франции (TRANSPAC), Японии, Испании, Швеции и некоторых других странах.
В связи с проектированием и эксплуатацией сети ARPANET формулировались и решались задачи анализа и проектировании сетей нескольких типов. Базовой задачей является анализ задержки - определение средней задержки передачи сообщения по заданному пути в сети (от конкретного источника к конкретному получателю сообщений). Конечным результатом является зависимость задержки от интенсивности требований на обслуживание; обычно график этой зависимости имеет начальный малоизменяемый участок при изменении нагрузки от нуля до некоторой пороговой величины и экспоненциально возрастает при нагрузке выше пороговой (соответствующей нагрузке насыщения сети), нагрузка насыщения сети соответствует блокировке сети по данному маршруту.
31115410210На рис.1 приведен типовой график данных расчета времени задержки, ясно видно пороговое значение нагрузки сети.
Рисунок 1 — Зависимость средней времени задержки сообщения (ордината) от нагрузки в сети (абсцисса) по результатам моделирования (слева) и упрощенная пороговая модель (справа).
На основе базовой задачи формулируются (более сложные) задачи расчетов и оптимизации сети:
Задача выбора пропускных способностей (т.н. ВПС-задача) - оптимальный (обычно по критерию стоимости сети) выбор пропускных способностей из конечного набора их возможных значений (при этом топология и потоки в сети считаются заданными).
Задача распределения потоков (т.н. РП-задача) - фактически обратная вышеприведенной ВПС-задаче (заданными считаются пропускные способности, а определяются потоки из условия минимизации средней задержки).
Задача выбора пропускных способностей и распределения потоков - {комбинированная ВПС/РП-задача) - минимизация стоимости сети при заданной топологии и ограничениях на величину максимальной задержки.При постановке задач используются несколько способов представления сети - географическая и логическая карты сети и структура сети (рис.2).
На левой части рис.3 показана достаточно общая структурная схема сети ЭВМ; при этом прямоугольниками представлены вычислительные средства выполнения задач обработки и хранения, соединенные друг с другом с помощью подсети связи (состоящей из коммутационных ЭВМ и высокоскоростных каналов передачи данных). Правая часть рис.3.5 иллюстрирует последний (перед этапом численного моделирования) этап представления топологии сети.

Рисунок 2 — Географическая (слева) и логическая карта сети ARPANET (состояние на июнь 1975 года).
Вышеуказанные задачи трудоемки в постановке и разрешении, для получения решения необходимо применять компьютерное моделирование. При решении задач используются элементы теории графов и теории массового обслуживания, распределение потока поступления требований (на обслуживание связи) обычно принимается пуассоновским.

Рисунок 3 — Общая структурная схема сети ЭВМ (слева) и используемая при моделировании структурная схема (справа).
Наиболее сложной задачей является задача выбора оптимальных (в соответствие с определенным критерием оптимальности - обычно стоимости) параметров сети (в основном маршрутов передачи сообщений между узлами сети - при заданной топологии) при заданной максимальной средней задержке (ВТПС/РП-задача); часто используют ВМУР {Вогнутый Метод Устранения Ребер) и МЗР (Метод Замены Ребер) - алгоритмы решения задачи.Обычно предполагается, что 'хорошая' процедура выбора маршрута должна:
Обеспечивать быструю и надежную доставку сообщений.
Адаптироваться к изменениям топологии сети, происходящим в результате повреждений узлов и каналов.
Адаптироваться к меняющейся нагрузке между парами 'источник-получатель
Направлять пакеты в сторону от временно перегруженных узлов в сети.
Определять связность сети.
Допускать простое и автоматическое снятие и установку процессоров IMP.
Такую задачу можно решить лишь путем применения распределенного алгоритма управления. Это значит, что не существует центра, который принимал бы обязательные для всей сети решения, все узлы выносят местные решения относительно маршрутов динамическим образом. Основанное на подобных предпосылках программное обеспечение было протестировано применительно к сети ARPANET; было показано, что процедура выбора маршрутов является в основном стабильной и приводит к очень хорошим результатам, в разумной степени реагирует на повреждения узлов и каналов сети, автоматически 'узнает' о появлении нового узла (как только он присоединяется к сети или возвращается после исправления), эта особенность сети ARPANET является замечательной технической стороной данной сети. Заметим, что в дальнейшем многие из перечисленных разработок были использованы в сети InterNet.
Таким образом, логично предположить, что в состав сетевого ПО (даже для ЭВМ уровня персонального компьютера) все чаще будут включаться решающее вышеприведенные задачи программные компоненты. Например, для обслуживания баз данных фирмой Inprise Corp. в настоящее врет разрабатывается эффективная технология выбора сервера с учетом загрузки процессоров и сетевого трафика функционирующих в сети серверов, что позволит более равномерно распределять нагрузку между серверам!); в будущем они станут обязательными для системы распределенных вычислений (распределенной ОС). Представляет интерес также разработанная для сети InterNet технология (и соответствующий протокол) MPLS (Multiprotocol Label Switching - многопроцессорная коммутация с заменой меток), реализующая концепции известной ATM-технологии в обобщенном виде (Asynchronous Transfer Mode - поддерживаемая консорциумом известных компаний технология, основанная на использовании упаковки разнородных типов данных в ячейки - 'cells' и создании функционирующих определенное время виртуальных соединений в физическом канале связи с целью обеспечения гарантированной по времени доставки сообщений; в настоящее время ATN-технология считается перспективной для транспортировки чувствительных к временной задержке сообщений - например, цифровой телефонии, телевидения).
35 сокеты, датаграммы и каналы связи
В локальных и глобальных сетях существует два принципиально разных способа передачи данных.
Первый из них предполагает посылку пакетов данных от одного узла другому (или сразу нескольким узлам) без получения подтверждения о доставке и даже без гарантии того, что передаваемые пакеты будут получены в правильной последовательности. Примером такого протокола может служить протокол UDP (User Datagram Protocol ), который используется в сетяхTCP/IP, или протокол IPX , который является базовым в сетях Novell NetWare .
Основные преимущества датаграмных протоколов заключаются в высоком быстродействии и возможности широковещательной передачи данных, когда один узел отправляет сообщения, а другие их получают, причем все одновременно.
Второй способ передачи данных предполагает создание канала передачи данных между двумя различными узлами сети. При этом канал создается средствами датаграммных протоколов, однако доставка пакетов в канале является гарантированной. Пакеты всегда доходят в целостности и сохранности, причем в правильном порядке, хотя быстродействие получается в среднем ниже за счет посылки подтверждений. Примерами протоколов, использующих каналы связи, могут служить протоколы TCP и SPX (протоколNETBIOS допускает передачу данных с использованием как датаграмм, так и каналов связи).
Для передачи данных с использованием любого из перечисленных выше способов каждое приложение должно создать объект, который называется сокетом.
По своему назначению сокет больше всего похож на идентификатор файла (file handle), который нужен для выполнения над файлом операций чтения или записи. Прежде чем приложение, запущенное на узле сети сможет выполнять передачу или прием данных, оно должно создать сокет и проинициализировать его, указав некоторые параметры.
Для сокета необходимо указать три параметра. Это IP адрес, связанный с сокетом, номер порта, для которого будут выполняться операции передачи данных, а также тип сокета.
Что касается последнего параметра (тип сокета), то существуют сокеты двух типов. Первый тип предназначен для передачи данных в виде датаграмм, второй - с использованием каналов связи.
36 создание и инициализация сокета
После инициализации интерфейса Windows Sockets ваше приложение должно создать один или несколько сокетов, которые будут использованы для передачи данных.
Создание сокета
Сокет создается с помощью функции socket , имеющей следующий прототип:
SOCKET socket (int af, int type, int protocol);
Параметр af определяет формат адреса. Для этого параметра вы должны указывать значение AF_INET , что соответствует формату адреса, принятому в Internet.
Параметры type и protocol определяют, сооветственно, тип сокета и протокол, который будет использован для данного сокета.
Можно указывать сокеты следующих двух типов:
Тип сокета Описание
SOCK_STREAM Сокет будет использован для передачи данных через канал связи с использованием протокола TCP
SOCK_DGRAM Передача данных будет выполняться без создания каналов связи через датаграммный протокол UDP
Что же касается параметра protocol, то вы можете указать для него нулевое значение.
В случае успеха функция socket возвращает дескриптор, который нужно использовать для выполнения всех операций над данным сокетом. Если же произошла ошибка, эта функция возвращает значение INVALID_SOCKET . Для анализа причины ошибки вы должны вызвать функцию WSAGetLastError , которая в данном случае может вернуть один из следующих кодов ошибки:
Код ошибки Описание
WSANOTINITIALISED Интерфейс Windows Sockets не был проинициализирован функцией WSAStartup
WSAENETDOWN Сбой сетевого программного обеспечения
WSAEAFNOSUPPORT Указан неправильный тип адреса
WSAEINPROGRESS Выполняется блокирующая функция интерфейса Windows Sockets
WSAEMFILE Израсходован весь запас свободных дескрипторов
WSAENOBUFS Нет памяти для создания буфера
WSAEPROTONOSUPPORT Указан неправильный протокол
WSAEPROTOTYPE Указанный протокол несовместим с данным типом сокета
WSAESOCKTNOSUPPORT Указанный тип сокета несовместим с данным типом адреса
Ниже мы привели фрагмент кода, в котором создается сокет для передачи данных с использованием протокола TCP:
srv_socket = socket(AF_INET , SOCK_STREAM, 0);
if(srv_socket == INVALID_SOCKET)
{
MessageBox(NULL, "socket Error", "Error", MB_OK);
return;
}
Удаление сокета
Для освобождения ресурсов приложение должно закрывать сокеты, которые ему больше не нужны, вызывая функцию closesocket :int closesocket (SOCKET sock);
Ниже мы перечислили коды ошибок для этой функции :Код ошибки Описание
WSANOTINITIALISED Перед использованием функции closesocket необходимо вызвать функцию WSAStartup
WSAENETDOWN Сбой в сети
WSAENOTSOCK Указанный в параметре дескриптор не является сокетом
WSAEINPROGRESS Выполняется блокирующая функция интерфейсаWindows Sockets
WSAEINTR Работа функции была отменена при помощи функции WSACancelBlockingCall
Параметры сокета
Перед использованием вы должны задать параметры сокета.
Для этого вы должны подготовить структуру типа sockaddr , определение которой показано ниже:
struct sockaddr
{
u_short sa_family;
char sa_data[14];
};
typedef struct sockaddr SOCKADDR ;
typedef struct sockaddr *PSOCKADDR ;
typedef struct sockaddr FAR *LPSOCKADDR ;
Для работы с адресами в формате Internet используется другой вариант этой структуры, в котором детализируется формат поля sa_data:
struct sockaddr_in
{
short sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
typedef struct sockaddr_in SOCKADDR _IN;
typedef struct sockaddr_in *PSOCKADDR _IN;
typedef struct sockaddr_in FAR *LPSOCKADDR _IN;
Поле sin_family определяет тип адреса. Вы должны записать в это поле значение AF_INET , которое соответствует типу адреса, принятому в Internet:
srv_address.sin_family = AF_INET ;Поле sin_port определяет номер порта, который будет использоваться для передачи данных.
Порт - это просто идентификатор программы, выполняющей обмен на сети. На одном узле может одновременно работать несколько программ, использующих разные порты.
Особенностью поля sin_port является использование так называемого сетевого формата данных. Этот формат отличается от того, что принят в процессорах с архитектурой Intel, а именно, младшие байты данных хранятся по старшим адресам памяти. Напомним, что архитектура процессоров Intel подразумевает хранение старщих байтов данных по младшим адресам.
Универсальный сетевой формат данных удобен при организации глобальных сетей, так как в узлах такой сети могут использоваться компьютеры с различной архитектурой.
Для выполнения преобразований из обычного формат в сетевой и обратно в интерфейсе Windows Sockets предусмотрен специальный набор функций. В частности, для заполнения поля sin_port нужно использовать функцию htons, выполняющую преобразование 16-разрядных данных из формата Intel в сетевой формат.
Ниже мы показали, как инициализируется поле sin_port в приложении SERVER, описанном далее:
#define SERV_PORT 5000
srv_address.sin_port = htons(SERV_PORT);
Вернемся снова к структуре sockaddr_in .
Поле sin_addr этой структуры представляет собой структуру in_addr:
struct in_addr
{
union
{
struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b;
struct { u_short s_w1,s_w2; } S_un_w;
u_long S_addr;
} S_un;
};
#define s_addr S_un.S_addr
#define s_host S_un.S_un_b.s_b2
#define s_net S_un.S_un_b.s_b1
#define s_imp S_un.S_un_w.s_w2
#define s_impno S_un.S_un_b.s_b4
#define s_lh S_un.S_un_b.s_b3
При инициализации сокета в этой структуре вы должны указать адрес IP, с которым будет работать данный сокет.
Если сокет будет работать с любым адресом (например, вы создаете сервер, который будет доступен из узлов с любым адресом), адрес для сокета можно указать следующим образом:
srv_address.sin_addr .s_addr = INADDR_ANY ;В том случае, если сокет будет работать с определенным адресом IP (например, вы создаете приложение-клиент, которое будет обращаться к серверу с конкретным адресом IP), в указанную структуру необходимо записать реальный адрес.
Датаграммный протокол UDP позволяет посылать пакеты данных одновременно всем рабочим станциям в широковещательном режиме. Для этого вы должны указать адрес как INADDR_BROADCAST.
Если вам известен адрес в виде четырех десятичных чисел, разделенных точкой (именно так его вводит пользователь), то вы можете заполнить поле адреса при помощи функции inet_addr :dest_sin.sin_addr .s_addr = inet_addr ("200.200.200.201");
В случае ошибки функция возвращает значение INADDR_NONE , что можно использовать для проверки.
Обратное преобразование адреса IP в текстовую строку можно при необходимости легко выполнить с помощью функции inet_ntoa , имеющей следующий прототип:
char FAR * inet_ntoa (struct in_addr in);
При ошибке эта функция возвращает значение NULL.
Однако чаще всего пользователь работает с доменными именами, используя сервер DNS или файл HOSTS . В этом случае вначале вы должны воспользоваться функцией gethostbyname , возвращающей адрес IP, а затем записать полученный адрес в структуру sin_addr :PHOSTENT phe;
phe = gethostbyname ("ftp.microsoft.com");
if(phe == NULL)
{
closesocket (srv_socket);
MessageBox(NULL, "gethostbyname Error", "Error", MB_OK);
return;
}
memcpy((char FAR *)&(dest_sin.sin_addr ),
phe->h_addr , phe->h_length);
В случае ошибки функция gethostbyname возвращает NULL. При этом причину ошибки можно выяснить, проверив код возврата функции WSAGetLastError .
Если же указанный узел найден в базе DNS или в файле HOSTS , функция gethostbyname возвращает указатель на структуру hostent , описанную ниже:
struct hostent
{
char FAR * h_name; // имя узла
char FAR * FAR * h_aliases; // список альтернативных имен
short h_addr type; // тип адреса узла
short h_length; // длина адреса
char FAR * FAR * h_addr _list; // список адресов
#define h_addr h_addr_list[0] // адрес
};
typedef struct hostent *PHOSTENT ;typedef struct hostent FAR *LPHOSTENT ;
Искомый адрес находится в первом элемента списка h_addr _list[0], на который можно также ссылаться при помощи h_addr. Длина поля адреса находится в поле h_length.
Привязка адреса к сокету
После того как вы подготовили структуру SOCKADDR , записав в нее параметры сокета (в частности, адрес), следует выполнить привязку адреса к сокету при помощи функции bind :int bind (
SOCKET sock, const struct sockaddr FAR * addr, int namelen);
Параметр sock должен содержать дескриптор сокета, созданного функцией socket .
В поле addr следует записать указатель на подготовленную структуру SOCKADDR , а в поле namelen - размер этой структуры.
В случае ошибки функция bind возвращает значение SOCKET_ERROR . Дальнейший анализ причин ошибки следует выполнять при помощи функции WSAGetLastError . Возможные коды ошибок перечислены ниже: 
Код ошибки Описание
WSANOTINITIALISED Перед использованием функции необходимо вызвать функцию WSAStartup
WSAENETDOWN Сбой в сети
WSAEADDRINUSE Указанный адрес уже используется
WSAEFAULT Значение параметра namelen меньше размера структуры sockaddr
WSAEINPROGRESS Выполняется блокирующая функция интерфейсаWindows Sockets
WSAEAFNOSUPPORT Этот протокол не может работать с указанным семейством адресов
WSAEINVAL Сокет уже привязан к адресу
WSAENOBUFS Установлено слишком много соединений
WSAENOTSOCK Указанный в параметре дескриптор не является сокетом
Пример вызова функции bind показан ниже:
if(bind (srv_socket , (LPSOCKADDR )&srv_address,
sizeof(srv_address)) == SOCKET_ERROR )
{
closesocket (srv_socket);
MessageBox(NULL, "bind Error", "Error", MB_OK);
return;
}
37 удаление и параметры сокета
Сокет - устройство двунаправленной связи, которое может использоваться для взаимодействия с другим процессом на одной и той же машине или с процессом, запущенным на других машинах. Программы Интернета такие как Telnet, rlogin, FTP, talk , и World Wide Web используют сокеты.
Например, можно получить WWW-страницу от сервера Web, используя программу Telnet , так как они обе используют сокеты для сетевого взаимодействия. Для открытия подключения с сервером WWW на www.codesourcery.com, необходимо использовать telnet www.codesourcery.com 80. Константа 80 определяет подключение к Web серверу. Если после того, как подключение будет установлено, передать команду get /, то Web серверу через сокеты будет отправлено сообщение, на которое он ответит, передав исходный текст домашней HTML страницы и затем закроет подключение.
Пример:
% telnet www.codesourcery.com 80
Trying 206.168.99.1...
Connected to merlin.codesourcery.com (206.168.99.1).Escape character is '^]'.
GET /
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
...
Основы сокетов
При создании сокета, необходимо определить три параметра: стиль взаимодействия, пространство имен, и пртокол. Стиль взаимодействия контролирует, как сокет обрабатывает передаваемые данные, и определяет количество партнеров взаимодействия. Через сокеты данные передаются блоками (пакетами). Стиль взаимодействия определяет, как эти пакеты будут обработаны и как они передаются от отправителя к получателю.
Стили соединения гарантируют доставку всех пакетов в том порядке, в каком они были отправлены. Если во время передачи пакеты были потеряны или доставлены в неправильном порядке, получатель автоматически отправляет запрос на их повторную передачу. Стиль соединения напоминает телефонный звонок: адреса отправителя и получателя фиксируются в начале соединения, при установке подключения.
Стили датаграм не гарантирует доставки и правильного порядка прибытия. Пакеты могут быть потеряны или переупорядочены в пути из-за сетевых ошибок. Каждый пакет должен быть помечен его адресатом, и нет гарантии, что он будет доставлен. Система гарантирует только "максимальные усилия", поэтому пакеты могут исчезнуть или прибыть в различном порядке. Сокет стиля датаграмы ведет себя сходно с почтой. Отправитель определяет адрес получателя для каждого индивидуального сообщения.
Пространство имен определяет, как записаны адреса сокета ( socket addresses ). Адрес сокета идентифицирует один конец подключения сокета. Например, адреса сокета в локальном пространстве имен являются обычными именами файлов. В пространстве имен Интернет адрес сокета состоит из Интернет адреса ( IP адрес) главного компьютера, присоединенного к сети и номера порта, который идентифицирует сокет среди множества сокетов на том же главном компьютере.
Протокол определяет, как передаются данные. Существуют следующие виды протоколов: TCP/IP , первичные сетевые протоколы, используемые Интернетом; сетевой протокол AppleTalk ; локальный UNIX протокол взаимодействия. Не все комбинации стилей, пространств имен и протоколов поддерживаются.
Системные вызовы
Виды системных вызовов:
socket - создать сокет
closes - уничтожить сокет
connect - создать соединение между двумя сокетами
bind - привязать сокет к порту сервера
listen - настройка сокета для принятия подключений
accept - принять запрос на соединение и создать сокет для процесса взаимодействия
Сокеты представляются дескрипторами файлов.
Создание и уничтожение сокетов
С помощью функций socket и close создаются и уничтожаются сокеты. При создании сокета, необходимо определить три параметра сокета: пространство имен, стиль взаимодействия и протокол.
Для указания пространства имен используются константы, начинающиеся с PF_ (сокращение "семейство протокола"). Например, PF_LOCAL или PF_UNIX определяют локальное пространство имен, и PF_INET определяет Интернет пространство имен.
Второй параметр, стиль взаимодействия, представляет собой константу, начинающиюся с SOCK_ . SOCK_STREAM опеределяет стиль взаимодейтсвия соединение,SOCK_DGRAM - стиль датаграмы.
Третий параметр, протокол, определяет механизм нижнего уровня для передачи и получения данных. Для каждой комбинации пространство имен - стиль взаимоделйствия существует свой протокол.
Для каждой пары существует лучший протокол, поэтому можно указать 0, что соответсвует этому протоколу. Если команда socket выполнена успешно, в качестве результата возвращается дескриптор файла для сокета. С помощью команд read и write , можно читать и записывать данные в сокет.
Вызов connect
Для создания соединение между двумя сокетами, клиент вызывает connect , передавая адрес сокета сервера для подключения. Клиент - процесс, инициализирующий соединение, а сервер - процесс, ожидающий разрешения соединения. Клиент посылает запрос connect , чтобы инициализировать соединение между локальным сокетом и сокетом сервера, переданным в качестве второго параметра. В качестве третьего параметра передается длина, в байтах, адресной структуры, на которую указывает второй параметр.
Отправка данных
Любая техника записи в дескриптор файла, может использоваться при записи в сокет. Функция send , определенная для дескрипторов файлов сокета, аналогична функцииwrite с несколькими дополнительными параметрами.Серверы
Цикл жизни сервера состоит из создания сокета, привязки сокета к адресу, вызова listen , разрешающего соединение с сокетом, вызова accept , принимающего входящие соединения, и затем закрытия сокета. Данные не читаются и не записываются непосредственно через сокет сервера; вместо этого, каждый раз когда программа принимает новое соединение, Linux создает отдельный сокет, используется при передаче данных по этому соединению. В этом разделе рассматриваются вызовы bind, listen и accept .
С помощью команды bind адрес сервера должен быть привязан к сокету. Первый параметр команды - дескриптор файла сокета. Второй параметр - указатель на структуру адреса сервера; формат которого зависит от семейства адреса. Третий параметр - длина структуры адреса, в байтах.
Когда адрес связан с сокетом стиля соединение, необходимо вызвать listen , чтобы указать, что это - сервер. Первый параметр команды - дескриптор файла сокета. Второй параметр определяет, длину очереди ожидающих соединений. Если очередь заполнена, дополнительные соединения будут отвергнуты. Это не ограничивает общее количество соединений, которые сервер может обработать; это ограничивает только число клиентов, пытающихся соединиться и не получивших подтверждение.
С помощью команды accept сервер принимает запрос на соединение от клиента. Первый параметр вызова - дескриптор файла сокета. Второй параметр указывает на структуру адреса сокета, в которой хранится адрес клиентского сокета. Третий параметр - длина, в байтах, структуры адреса сокета. Сервер может использовать адрес клиента, чтобы определить, требуется ли действительно взаимодействовать с клиентом.
Вызов accept создает новый сокет для взаимодействия с клиентом и возвращает соответствующий дескриптор файла. Оригинальный сокет сервера продолжает принимать новые клиентские соединения.
Для чтения данных из сокета, без удаления их из входной очереди, используется команда recv . В качестве параметров передаются теже аргументы, что и в команде read, плюс дополнительный параметр FLAGS . Флаг MSG_PEEK указывает, что данные должны быть прочитаны, но не удалены из входной очереди.Локальные сокеты
Сокеты, подключающие процессы на одном компьютере могут использовать локальное пространство имен, представляющий собой синоним для PF_LOCAL и PF_UNIX . Они называются локальными сокетами или сокетами UNIX-домена. Адреса этих сокетов, определяемые именами файлов, используются только при создании соединения.
Имя сокета указывается в структуре sockaddr_un . Если в AF_LOCAL установлено поле sun_family , это указывает на то, что адрс в докальном пространстве имен. ПолеSun_path указывает, что используется имя файла; максимальная длина поля - 108 байт. Для вычисления длины struct sockaddr_un используется макрокоманда SUN_LEN . Может использоваться любое имя файла, но для процесса должно быть установлено право на запись в каталог. Чтоб соединениться с сокетом, процесса должен иметь право на чтения файла. Хотя различные компьютеры могут совместно использовать одну файловую систему, только процессы, запущенные на этом компьютере, могут взаимодействовать используя сокеты локального пространства имен.
Единственный допустимый протокол для локального пространства имен - 0. Поскольку он находится в файловой системе, локальный сокет представлен как файл.
Например, обратите внимание на начальную s:
% ls -l /tmp/socket
srwxrwx--x 1 user group 0 Nov 13 19:18 /tmp/socket
Вызов unlink удаляет локальный сокет, при завершении работы с ним.Пример использования локальных сокетов
В листинге 5.10 представлена программа сервера, в которой создается локальный сокет и слушает запросы на соединения с сервером. При получении запроса на соединение, сервер читает текстовые сообщения, передаваемые через соединение и печатает их. Если одно из этих сообщений - "выход", программа сервера удаляет сокет и завершается. Программа socket-server предполагает, что путь к сокету передается через параметр командной строки.
Листинг 5.10 (socket-server.c)
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
/* Чтение текста из сокета и вывод его на печать. Продолжение цикла до закрытия сокета.
*В качестве результата возвратит не ноль, если клиент передал сообщение "quit", иначе 0 */
int server (int client_socket)
{
while (1) {
int length;
char* text;
/* Сначала из сокета прочитать длину текстого сообщения. Если в качестве результата возвратиться 0,
то клиент закрыл соединение */
if (read (client_socket, &ength, sizeof (length)) == 0)
return 0;
/* выделить место в буфере для хранения текста */
text = (char*) malloc (length);
/* Чтение текста и распечатка */
read (client_socket, text, length);
printf ("%s\n", text);
/* Освободить буфер */
free (text);
/* Если от клиента поступило сообщение "quit", завершить работу */
if (!strcmp (text, "quit"))
return 1;
}
}
int main (int argc, char* const argv[])
{
const char* const socket_name = argv[1];
int socket_fd;
struct sockaddr_un name;
int client_sent_quit_message;
/* Создать сокет */
socket_fd = socket (PF_LOCAL, SOCK_STREAM, 0);
/* Определить что это сервер */
name.sun_family = AF_LOCAL;
strcpy (name.sun_path, socket_name);
bind (socket_fd, &name, SUN_LEN (&name));
/* Слушать (ожидать) соединения */
listen (socket_fd, 5);
/* Неоднократно принимать соединения, создавая для каждого клиента server().
Продолжать до получения от клиента сообщения "quit" */
do {
struct sockaddr_un client_name;
socklen_t client_name_len;
int client_socket_fd;
/* Принимать соединение */
client_socket_fd = accept (socket_fd, &client_name, &client_name_len);
client_sent_quit_message = server (client_socket_fd);
/* Закрыть соединение с нашей стороны */
close (client_socket_fd);
}
while (!client_sent_quit_message);
/* Удалить файл сокета */
close (socket_fd);
unlink (socket_name);
return 0;
}
Клиент-программа, представленная в листинге 5.11, соединяется с локальным сокетом и посылает сообщения. Путь к сокету и сообщения передаtтся через командную строку.
Листинг 5.11(socket-client.c)
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
/* Записать TEXT в сокет, переданный дескриптором файла SOCKET_FD */
void write_text (int socket_fd, const char* text)
{
/* Записать в строку количество байт, включая NUL-терминал */
int length = strlen (text) + 1;
write (socket_fd, &length, sizeof (length));
/* Записать строку */
write (socket_fd, text, length);
}
int main (int argc, char* const argv[])
{
const char* const socket_name = argv[1];
const char* const message = argv[2];
int socket_fd;
struct sockaddr_un name;
/* Создать сокет */
socket_fd = socket (PF_LOCAL, SOCK_STREAM, 0);
/* Сохранить имя сервера в адресе сокета */
name.sun_family = AF_LOCAL;
strcpy (name.sun_path, socket_name);
/* Соединиться с сокетом */
connect (socket_fd, &name, SUN_LEN (&name));
/* Записать текст командной строки в сокет */
write_text (socket_fd, message);
close (socket_fd);
return 0;
}
Перед передачей сообщения, посылается размер сообщения в байтах в качестве переменной length. Сервер сохраняет размер сообщения, для выделения памяти под сообщение. Чтобы выполнить этот пример, необходимо запустить сервер-программу в одном окне, определить путь к сокету.
Например, /tmp/socket .
% ./socket-server /tmp/socket
В другом окне запустить клиент-программу несколько раз, опеределяя один и тот же путь сокета и посылая клиенту сообщение:
% ./socket-client /tmp/socket "Hello, world."
% ./socket-client /tmp/socket "This is a test."
Сервер-программа получает и печатает эти сообщения. Для закрытия соединения, клиент посылает сообщение "quit":
% ./socket-client /tmp/socket "quit"
Сервер-программа завершена.Internet-Domain сокеты
Cокеты UNIX-domain использоваться только для взаимодействия двух процессов только на одном компьютере. Сокеты Internet, используются для соединения нескольких процессов на различных машинах, подключенных к сети.
Для соединения процессов через Интернет сокеты используют пространство имен Интернет указываемое с помощью PF_INET . Большинство протоколов являютсяTCP/IP . Интернет протокол ( IP), протокол нижнего уровня, отправляет пакеты через Интернет, разбивая на меньшие пакеты, в случае необходимости. Он гарантирует только доставку "лучшего усилия", так что пакеты могут быть потеряны или переупорядочены во время транспортировки. Каждый компьютер имеет IP адрес. Протокол управления передачей ( TCP ), который следует за IP протоколом, обеспечивает надежное подключение. Это позволяет установить между компьютерами соединение, наподобие телефонного и гарантирует доставку данных в парвильном порядке.
Интернет адрес сокета состоит из двух частей: номера компьютера и номера порта. Эта информация хранится в переменной структуры sockaddr_in . Для идентификации того, что это адрес Интернет пространства имен, необходимо установить поле sin_family в AF_INET . В поле Sin_addr хранится Интернет адрес компьютера, как 32-разрядное целое число IP . Каждому сокету на одном компьютере присваивается номер порта. Поскольку различные машины сохраняют многобайтовые значения в различном порядке байта, используют htons , чтобы преобразовать число порта к сетевому порядку байтов.
Команда gethostbyname преобразовывает удобочитаемые имена хоста, числа со стандартной точечной нотацией (типа 10.0.0.1) или DNS имена (такие как www.codesourcery.com) в 32-разрядные IP адреса. В качестве результата возвращается указатель на структуру struct hostent ; в поле h_addr хранится IP адрес главного компьютера.
Листинг 5.12 иллюстрирует использование Internet-domain сокетов. Программа получает домашнюю страницу от Web сервера, имя хоста которого определено в командной строке.
Листинг 5.12(socket-inet.c)
#include <stdlib.h>
#include <stdio.h>
#include <netinet/in.h>
#include <netdb.h>
#include <sys/socket.h>
#include <unistd.h>
#include <string.h>
/* Печать содержимого домашней страницы.
* В качестве результата передать флаг успешного завершения процесса.*/
void get_home_page (int socket_fd)
{
char buffer[10000];
ssize_t number_characters_read;
/* Передать команду HTTP GET для домашней страницы */
sprintf (buffer, "GET /\n");
write (socket_fd, buffer, strlen (buffer));
/* Читать данные из сокета. Не все данные могут быть возвращены одновременно,
* продолжать попытку до завершения процесса */
while (1) {
number_characters_read = read (socket_fd, buffer, 10000);
if (number_characters_read == 0)
return;
/* Записать данные в стандартный вывод */
fwrite (buffer, sizeof (char), number_characters_read, stdout);
}
}
int main (int argc, char* const argv[])
{
int socket_fd;
struct sockaddr_in name;
struct hostent* hostinfo;
/* Создать сокет */
socket_fd = socket (PF_INET, SOCK_STREAM, 0);
/* Сохранить адрес сервера в адрессе сокета */
name.sin_family = AF_INET;
/* Преобразовать строку в число */
hostinfo = gethostbyname (argv[1]);
if (hostinfo == NULL)
return 1;
elsename.sin_addr = *((struct in_addr *) hostinfo->h_addr);
/* Web сервер использует 80 порт */
name.sin_port = htons (80);
/* Установить соединение с Web сервером */
if (connect (socket_fd, &name, sizeof (struct sockaddr_in)) == -1) {
perror ("connect");
return 1;
}
/* Получить домашнюю страницу */
get_home_page (socket_fd);
return 0;
}
Имя хоста Web сервера задается в командно строке (без "http: //"). Команда gethostbyname преобразовывает имя хоста в числовой IP адрес и затем подключает поток (TCP) сокета к порту 80 на главном компьютере. Серверы используют Гипертекстовый Транспортный Протокол ( HTTP ), поэтому передается команда HTTP GET , сервер в качестве ответа передает текст домашней страницы.
Для отображения страницы www.codesourcery.com, необходимо задать следующуе команду
% ./socket-inet www.codesourcery.com
<html>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
...
Пары сокетов
Как упоминалось ранее, функция pipe , создает два дескриптора файлов для начала и конца канала. Каналы ограничены, потому что дескрипторы файлов используются только связанными процессами и потому что взаимодействие однонаправлено. Функция socketpair создает два дескриптора файлов для двух сокетов, подключенных на одном компьютере. Эти дескрипторы файлов разрешают двухстороннее взаимодействие двух связанных процессов. Первые три параметра команды - идентичны параметрам команды socket : они определяют домен, стиль подключения и протокол. Последний параметр - массив с двумя целыми числами, в котором хранятся характеристики файлов этих двух сокетов. При использовании команды socketpair , необходимо определить PF_LOCAL как пространство имен.
38 создание канала связи
Если вы собираетесь передавать датаграммные сообщения при помощи протокола негарантированной доставки UDP , канал связи не нужен. Сразу после создания сокетов и их инициализации можно приступать к передаче данных. Но для передачи данных с использованием протокола TCP необходимо создать канал связи.
Сторона сервера
Рассмотрим процедуру создания канала связи со стороны сервера.
Прежде всего вы должны переключить сокет в режим приема для выполнения ожидания соединения с клиентом при помощи функции listen:
int listen(SOCKET sock, int backlog);
Через параметр sock функции необходимо передать дескриптор сокета, который будет использован для создания канала. Параметр backlog задает максимальный размер очереди для ожидания соединения (можно указывать значения от 1 до 5). Очередь содержит запросы на установку соединений для каждой пары значений (адрес IP, порт).
Ниже мы привели список возможных кодов ошибок для функции listen. 
Код ошибки Описание
WSANOTINITIALISED Перед использованием функции необходимо вызвать функцию WSAStartup
WSAENETDOWN Сбой в сети
WSAEADDRINUSE Указанный адрес уже используется
WSAEINPROGRESS Выполняется блокирующая функция интерфейсаWindows Sockets
WSAEINVAL Сокет еще не был привязан к адресу или уже находится в подключенном состоянии
WSAEISCONN Сокет уже находится в подключенном состоянии
WSAEMFILE Недостаточно дескрипторов файлов
WSAENOBUFS Нет места для размещения буфера
WSAENOTSOCK Указанный в параметре дескриптор не является сокетом
WSAEOPNOTSUPP Функция listen не работает с сокетом указанного типа
Ниже мы привели пример вызов функции listen:
if(listen(srv_socket , 1) == SOCKET_ERROR )
{
closesocket (srv_socket);
MessageBox(NULL, "listen Error", "Error", MB_OK);
return;
}
Далее необходимо выполнить ожидание соединения. Это можно выполнить двумя различными способами.
Первый способ заключается в циклическом вызове функции accept до тех пор, пока не будет установлено соединение. Затем можно будет приступать к обмену данными.
Функция accept имеет следующий прототип:
SOCKET accept (SOCKET sock, struct sockaddr FAR * addr,
int FAR * addrlen);Через параметр sock необходимо указать дескриптор сокета, который находится в режиме приема для выполнения ожидания.
Параметр addr должен содержать адрес буфера, в который будет записан адрес узла, подключившегося к серверу. Размер этого буфера необходимо указать в переменной типа int, адрес которой передается через параметр addrlen.
Если ожидание соединения в цикле не вызывает у вас особого энтузиазма, можно предложить более удобный способ, основанный на использовании расширения программного интерфейса Windows Socket, предназначенного для выполнения асинхронных операций.
Приведем список возможных кодов ошибок для функции accept. 
Код ошибки Описание
WSANOTINITIALISED Перед использованием функции необходимо вызвать функцию WSAStartup
WSAENETDOWN Сбой в сети
WSAEFAULT Значение параметра addrlen меньше размера структуры адреса
WSAEINTR Работа функции была отменена при помощи функции WSACancelBlockingCall
WSAEINPROGRESS Выполняется блокирующая функция интерфейсаWindows Sockets
WSAEINVAL Перед вызовом функции accept не была вызывана функция listen
WSAEMFILE Нет доступных дескрипторов
WSAENOBUFS Установлено слишком много соединений
WSAENOTSOCK Указанный в параметре дескриптор не является сокетом
WSAEOPNOTSUPP Данный тип сокета нельзя использовать при вызове функций, ориентированных на работу с каналом связи
WSAEWOULDBLOCK Сокет отмечен как неблокирующий и в настоящее время нет каналов связи, которые нужно устанавливать
Вместо того чтобы ожидать соединение, вызывая в цикле функцию accept , ваше приложение может вызвать один раз функцию WSAAsyncSelect , указав ей, что при получении запроса на установку соединения функция окна вашего приложения должна получить сообщение:
#define WSA_ACCEPT (WM_USER + 1)
// При попытке установки соединения главное окно приложения
// получит сообщение WSA_ACCEPT
rc = WSAAsyncSelect (srv_socket , hWnd, WSA_ACCEPT, FD_ACCEPT );
if(rc > 0)
{
closesocket (srv_socket);
MessageBox(NULL, "WSAAsyncSelect Error", "Error", MB_OK);
return;
}
В данном случае ожидание соединения выполняется для сокета srv_socket . Последний параметр функции имеет значение FD_ACCEPT . Это означает, что при попытке создания канала связи функция окна с идентификатором hWnd получит сообщение WSA_ACCEPT, определенное в вашем приложении.
Обработчик этого сообщения может выглядеть, например, следующим образом:
void WndProc_OnWSAAccept(HWND hWnd, UINT msg,
WPARAM wParam, LPARAM lParam)
{
int rc;
// При ошибке отменяем поступление извещений
// в главное окно приложения
if(WSAGETSELECTERROR(lParam) != 0)
{
MessageBox(NULL, "accept Error", "Error", MB_OK);
WSAAsyncSelect (srv_socket , hWnd, 0, 0);
return;
}
// Определяем размер адреса сокета
acc_sin_len = sizeof(acc_sin);
// Разрешаем установку соединения
srv_socket = accept (srv_socket, (LPSOCKADDR )&acc_sin,
(int FAR *)&acc_sin_len);
if(srv_socket == INVALID_SOCKET)
{
MessageBox(NULL, "accept Error, invalid socket ",
"Error", MB_OK); return;
}
// Если на данном сокете начнется передача данных от
// клиента, в главное окно приложения поступит
// сообщение WSA_NETEVENT.
// Это же сообщение поступит при разрыве соединения
rc = WSAAsyncSelect (srv_socket , hWnd, WSA_NETEVENT,
FD_READ | FD_CLOSE );
if(rc > 0)
{
closesocket (srv_socket);
MessageBox(NULL, "WSAAsyncSelect Error", "Error", MB_OK);
return;
}
}
В данном случае обработчик сообщения вначале вызывает функцию accept , выполняющую создание канала передачи данных. После этого функция WSAAsyncSelect вызывается еще один раз для того чтобы установить асинхронную обработку приема данных от удаленного клиента, а также обработку ситуации разрыва канала связи.
Сторона клиента
Рассмотрим процедуру установки канала связи со стороны клиента, использованную нами в приложении CLIENT, исходные тексты которого будут приведены ниже.
Для установки соединения в приложении используется функция SetConnection:
SOCKADDR _IN dest_sin;
void SetConnection(HWND hWnd)
{
PHOSTENT phe;

// Создаем сокет
srv_socket = socket(AF_INET , SOCK_STREAM, 0);
if(srv_socket == INVALID_SOCKET)
{
MessageBox(NULL, "socket Error", "Error", MB_OK);
return;
}
// Устанавливаем адрес IP и номер порта
dest_sin.sin_family = AF_INET ; // Определяем адрес узла
phe = gethostbyname ("localhost ");
if(phe == NULL)
{
closesocket (srv_socket);
MessageBox(NULL, "gethostbyname Error", "Error", MB_OK);
return;
}
// Копируем адрес узла
memcpy((char FAR *)&(dest_sin.sin_addr ), phe->h_addr ,
phe->h_length); // Копируем номер порта
dest_sin.sin_port = htons(SERV_PORT);
// Устанавливаем соединение
if(connect(srv_socket , (PSOCKADDR )&dest_sin,
sizeof(dest_sin)) < 0)
{
closesocket (srv_socket);
MessageBox(NULL, "connect Error", "Error", MB_OK);
return;
}
}
Вначале с помощью функции socket эта функция создает сокет. Затем выполняется заполнение адресной информацией структуры dest_sin.
Обратите внимание, что для получения адреса IP мы воспользовались функцией gethostbyname , указав ей имя узла localhost .
Это имя отображается в файле HOSTS на адрес 127.0.0.1 :localhost
Адрес 127.0.0.1 является локальным. Вы можете использовать его для тестирования приложений, выполняющих обмен данными при помощи протокола TCP/IP, запуская сервер и клиент на одном и том же компьютере.
После заполнения структуры с адресной информацией функция connect создает канал связи с сервером.
39 передача и прием данных
int info = pvm_send( int tid, int msgtag)
call pvmfsend( tid, msgtag, info)
int info = pvm_mcast( int *tids, int ntask, int msgtag)
call pvmfmcast( ntask, tids, msgtag, info)
Подпрограмма pvm_send() помечает сообщение целочисленным идентификатором msgtag и передает его непосредственно процессу TID.
Подпрограмма pvm_mcast() помечает сообщение целочисленным идентификатором msgtag и широковещательно передает это сообщение всем задачам, указанным в целочисленном массиве tids (исключая себя). Массив tids имеет длину ntask.
int info = pvm_psend( int tid, int msgtag, void *vp,
    int cnt, int type)
call pvmfpsend( tid, msgtag, xp, cnt, type, info)
Подпрограмма pvm_psend() упаковывает и посылает массив данных указанного типа задаче, идентифицированной TID. Предопределенные типы данных на Фортране такие же, как и для pvmfpack(). В языке C аргумент type может иметь любое из следующих значений:
PVM_STR PVM_FLOAT
PVM_BYTE PVM_CPLX
PVM_SHORT PVM_DOUBLE
PVM_INT PVM_DCPLX
PVM_LONG PVM_UINT
PVM_USHORT PVM_ULONG
PVM поддерживает несколько методов приема сообщений в задаче. В PVM нет точного соответствия функций, например, применение pvm_send не обязательно требует примененияpvm_recv. Каждая из следующих подпрограмм может быть вызвана для любого из поступающих сообщений вне зависимости от того, как оно было передано (или передано широковещательно).
int bufid = pvm_recv( int tid, int msgtag)
call pvmfrecv( tid, msgtag, bufid)
Эта подпрограмма блокирующего приема будет ожидать до тех пор, пока от задачи с TID не поступит сообщение с меткой msgtag. Значение -1 в msgtid или TID означает ``все задачи'' (специальный символ). После поступления она помещает сообщение в новый создаваемый активный буфер приема. Предыдущий активный буфер приема очищается, если он не был сохранен вызовом pvm_setrbuf().
int bufid = pvm_nrecv(int tid, int msgtag)
call pvmfnrecv( tid, msgtag, bufid)
Если запрашиваемое сообщение не прибыло, то неблокирующий прием pvm_nrecv() при завершении вернет код, равный 0. Эта подпрограмма может вызываться сколько угодно раз для определенного сообщения - с целью проверки его прибытия - в промежутках выполнения работы программы. Если же возможной в данной ситуации работы не осталось, для того же сообщения можно воспользоваться блокирующим приемом pvm_recv(). Если сообщение с меткой msgtag поступило от задачи с TID, pvm_nrecv() помещает это сообщение в новый активный буфер (который она создает) и возвращает идентификатор данного буфера. Предыдущий активный буфер приема очищается, если он не был сохранен вызовомpvm_setrbuf(). Значение -1 в msgtid или TID означает ``все задачи'' (специальный символ).
int bufid = pvm_probe( int tid, int msgtag)
call pvmfprobe( tid, msgtag, bufid)
Если запрашиваемое сообщение не прибыло, то pvm_probe() возвращает bufid, равный 0. В противном случае она возвращает bufid сообщения, но не ``принимает'' его. Эта подпрограмма может вызываться сколько угодно раз для определенного сообщения - с целью проверки его прибытия - в промежутках выполнения работы. Дополнительно может быть вызвана pvmbufinfo() с возвращенным bufid - для получения информации о сообщении перед его непосредственным приемом.
int bufid = pvm_trecv( int tid, int msgtag,
    struct timeval *tmout)
call pvmftrecv( tid, msgtag, sec, usec, bufid)
PVM также поддерживает версию приема с тайм-аутом. Рассмотрим случай, при котором сообщение не прибывает никогда (из-за ошибки или сбоя): подпрограмма pvm_recv может заблокироваться навечно. Для избежания такой ситуации пользователь может захотеть ``прекратить'' ожидание после истечения фиксированного временного отрезка. Подпрограммаpvm_trecv() предоставляет пользователю возможность указать период тайм-аута. Если этот период очень велик, то pvm_trecv() действует подобно pvm_recv. Если же период тайм-аута установлен в ноль, то pvm_trecv() действует подобно pvm_nrecv. Так, pvm_trecv ``заполняет пробел'' между функциями блокирующего и неблокирующего приема.
Подпрограмма pvm_bufinfo() возвращает msgtag, TID источника и длину в байтах сообщения, идентифицированного с помощью bufid. Она может применяться для установления метки и источника сообщений, которые были приняты с использованием специальных символов.
int info = pvm_bufinfo( int bufid, int *bytes,
    int *msgtag, int *tid)call pvmfbufinfo( bufid, bytes, msgtag, tid, info)
Подпрограмма pvm_precv() сочетает в себе функции блокирующего приема и распаковки буфера приема. Она не возвращает bufid. Вместо него она возвращает действительные значения TID, msgtag и cnt.
int info = pvm_precv( int tid, int msgtag, void *vp,
    int cnt, int type, int *rtid, int *rtag,
    int *rcnt)
call pvmfprecv( tid, msgtag, xp, cnt, type, rtid, rtag,
    rcnt, info)Подпрограмма pvm_recvf() модифицирует контекст работы принимающих функций и может быть использована для ``расширения'' PVM. Используемый по умолчанию контекст приема заключается в соответствии источника и тега сообщения. Он может быть модифицирован для любой определяемой пользователем функции сравнения. Подпрограммы, соответствующей pvm_recvf(), с интерфейсом на Фортране - нет.
40 глобальная сеть Internet
Интернет представляет собой глобальную компьютерную сеть, соединяющую отдельные сети. Интернет обеспечивает обмен информацией между всеми компьютерами, которые входят в сети, подключенные к ней. Тип компьютера и используемая им операционная система значения не имеют.
Соединение сетей обладает громадными возможностями. Интернет предоставляет в распоряжение своих пользователей множество всевозможных ресурсов. Для того чтобы информация передавалась между компьютерами независимо от используемых линий связи, Шипа ЭВМ и программного обеспечения, разработаны специальные протоколы передачи данных. Они работают по Вринципу разбиения данных на блоки определенного размера (пакеты), которые последовательно отсылаются адресату. В Интернете используются два основных протокола: межсетевой протокол IP разделяет передаваемые июнные на отдельные пакеты и снабжает их заголовками и указанием адреса получателя, а протокол управления передачей TCP отвечает за правильную доставку пакета. Так как эти протоколы взаимосвязаны, обычно говорят о протоколе TCP/IP.
Основные ячейки Интернет — локальные вычислительные сети. Это означает, что Интернет не просто устанавливает связь между отдельными компьютерами, а . создает пути соединения для более крупных единиц — групп компьютеров. Если некоторая локальная сеть подключена к Интернету, то каждая рабочая станция этой сети также может подключаться к Интернету. Существуют также компьютеры, самостоятельно подключенные к Интернету. Они называются хост-компьютерами.
Каждый подключенный к сети компьютер имеет свой адрес, по которому его может найти абонент из любой точки света. К адресам станций предъявляются специальные требования. Адрес должен иметь формат, позволяющий вести его обработку автоматически, и должен нести информацию о своем владельце. С этой целью для каждого компьютера устанавливаются два адреса: цифровой IP-адрес и доменный адрес. Первый из них более понятен компьютеру, второй — человеку. Оба эти адреса могут применяться равноправно.
Цифровой адрес имеет длину 32 бита. Он разделяется точками на 4 блока по 8 бит каждый, которые можно записать в виде десятичного числа, не превышающего значение 255. Адрес содержит полную информацию, необходимую для идентификации компьютера. Два блока определяют адрес сети, третий — адрес подсети и четвертый — адрес компьютера внутри заданной сети.
Доменный адрес определяет область, представляющую ряд хост-компьютеров. Этот адрес читается в обратном порядке: вначале указывается имя компьютера, а затем имя сети, в которой он находится. Для упрощения связи абонентов сети все ее адресное пространство разбито на отдельные области — домены. В системе адресов Интернета приняты домены, представленные географическими регионами. Они имеют имя, состоящее из двух букв. Существуют домены, разделенные по тематическим признакам. Такие домены имеют трехбуквенное сокращенное название.
Компьютерное имя включает как минимум два уровня доменов. Уровни отделяются друг от друга точкой. Слева указывается домен верхнего уровня. Все имена, находящиеся слева, — поддомены общего домена. Для адресации отдельных пользователей в сети их регистрационные имена указываются слева от имени компьютера. После имени пользователя ставится знак @. В Интернете могут использоваться не только имена отдельных людей, но и имена групп.
Для обработки пути поиска в доменах имеются специальные серверы имен. Они преобразуют доменное имя в специальный цифровой адрес.
Использование технологий Интернета необязательно реализовывается в рамках всемирной информационной сети. Технологии, применяемые в глобальной сети, пригодны и для создания мощных корпоративных информационных систем и систем обеспечения коллективной работы. Интранет — это корпоративная сеть (возможно, сеть предприятия или офиса), использующая технологии и продукты Интернета для хранения, связи и доступ к информации.
41 стандартные приложения для работы с internet
Ранее были приведены основные компоненты сети InterNet, ниже будут рассмотрены программные приложения, позволяющие работать с Сетью конечным пользователям.
В большинстве случаев пользователь подключается к Сети через телефонную линию с помощью специального устройства - модема (сокращение терминов 'модулятор-демодулятор'), при этом скорость обмена данными определяется типом модема и (в большей степени) качеством телефонного канала и обычно составляет 14400 г 57600 бит в секунду (бод), сервер же 'общается' с Сетью через высокоскоростной канал (на рис.3 и 4 в качестве примера показан спутниковый, причем скорость обмена в этой части канала на порядки выше). Т.о. именно скорость передачи данных к конкретному компьютеру обычно лимитирует пропускную способность сети (т.н. 'проблема последней мили').
Повышенную скорость сетевого обмена обеспечивают выделенные линии связи (часто те же жилы телефонного кабеля, специально выделенные для передачи информации по Сети), при этом удается повысить скорость обмена не менее чем на порядок; технология DSL (Digital Subscrabe Line) подразумевает использование модулируемых ультразвуковых частот в обычном телефонном канале, обеспечивает скорость обмена до 7,5 Мбит/сек и не мешает обычным телефонным переговорам.Часто соединенные локальной сетью компьютеры одного учреждения подключаются к сети InterNet через выделенную ЭВМ со специализированным ПО, называемую в этом случае proxy-сервером (рис.4). Proxy-сервер (' доверенный компьютер') часто обеспечивает выполнение некоторых вспомогательных функций (например, ограничение на доступ к Сети определенных пользователей ЛВС, функции фильтрации сообщений и др. - т.е. выполняет функции брандмауэра).
В состав ОС Windows включены компоненты, поддерживающие связь по протоколу TCP/IP с использованием телефонного (или другого) канала связи, устанавливаемые опционально (по желанию); настройка этого ПО подробно описана, например, в работе .Одним из наиболее простых распространенных сетевых приложений сети InterNet являются программы обеспечения электронной почты (E-Mail). Для того, чтобы послать электронное письмо, необходимо иметь электронный адрес своего корреспондента; узнать его можно при личной встрече, по телефону, из рекламы (в том числе на WEB-страницах). Таким образом, любой пользователь имеет возможность послать (электронное) письмо по известному адресу, но только владелец почтового ящика имеет возможность просматривать и удалять письма (используется парольная система).
Электронные адреса E-Mail выглядят следующим образом
Адрес E-Mail Назначение
vep@oktava.msk.suВычислительный центр МГАПИ
e881@yahoo.comПочтовый ящик автора методического руководства
info@daidocomp.comФирма DaidoSeiko
frolov@glas.apc.orgЛичный почтовый ящик

При отправке письма по E-Mail адрес отправителя обычно добавляется автоматически. Большинство электронных писем представляет собой текстовые сообщения объемом не более нескольких килобайт, но современные программы допускают включение и двоичных файлов (изображения, программы, документы WinWord и др.). На рис.5 приведена копия экрана дисплея ПЭВМ при работе почтовой программы Microsoft News and Mail.
Сервер
I ■ |Спутниковая линия сязи

Рис.4. Подключение к InterNet через локальную сеть.
Для посылки письма следует ввести с клавиатуры адрес получателя в графе 'Кому' ('To' в английской транскрипции), тему письма в графе 'Тема' ('Subject') и набрать текст послания; дополнительно в графе 'Копия' ('Сс') можно указать адреса посылки копий письма и прикрепить к посланию двоичные файлы (для данной программы путем нажатия кнопки с символом ' скрепка' с последующим выбором нужного файла).Прием писем реально происходит при подсоединении программы электронной почты к почтовому серверу, список полученных писем изображается в таблице, владелец почтового ящика имеет возможность просмотреть письма, ответить на любое письмо или удалить его.
Среди других популярных почтовых программ можно отметить систему Eudora for Microsoft Windows, Microsoft Exchange и др.
Значительный интерес представляют т.н. электронные конференции (телеконференции), или сетевые новости. В Сети имеются серверы электронных конференций, которые хранят статьи (в виде текстовых документов), объединенные в группы. Имеющие доступ к такому серверу пользователи могут посылать в выбранные ими группы свои статьи и просматривать и получать статьи, записанные туда другими пользователями. Группы существуют по интересам (например, пользователи Borland Delphi, Interbase, Oracle и др.), постоянно появляются новые. Пользователи могут обсуждать проблемы конференции, задавать вопросы и оказывать помощь нуждающимся; большинство конференций транслируется по всей сети InterNet (существуют и локальные конференции); для работы с электронными конференциями пользователь обычно должен подписаться на интересующую его конференцию (или группу новостей). Одним из удобных приложений для работы с электронными конференциями является News Express, позволяющее легко выбирать нужную конференцию, просматривать список статей (с обеспечением сортировки по теме, дате, имени автора или размеру статьи).
$Ш Напоминание о встрече BI □1*1
Файл Правка Вид Сообщение 3ставка Формат ?т ш а и Кому: kocha@usa.netт Копия: [Щ] < получатели копни сообщения > Тема: Напоминание о встрече Алексей, не забудьте о сегодняшней встрече в 12.00 час в аудитории 347 - Вы обещали передать мне компонент TlrnageNew для DELPHI 3.0.
Баканов Валерий


С уважением littp://pilyer.mgapi.e{liiРис.5. Вид экрана ПЭВМ при работе с почтовой программой Microsoft News and Mail.
С помощью программы Telnet (Terminal Access to a remote host) имеется возможность подключения к консоли удаленной ЭВМ (что удобно, например, администратору сети и позволяет управлять работой сервера, не выходя из дома). Сетевое приложение HyperTerminal (фирма Hilgraeve Inc.) позволяет обмениваться файлами с удаленной ЭВМ по телефонной сети.
Возможность ' разговаривать' через InterNet путем набора и считывания с экрана текстовых посланий является уже привычным (и скучным) сервисом (для 'оживления' беседы программный продукт Microsoft Chat вводит в действие асоциируемых с конкретными пользователями типизированных персонажей, ' разговаривающих' на фоне определенного пейзажа). Популярная система ICQ (звуковое подражание фразе 'I Seek You' - 'Я ищу тебя', компания Mirabilis, Тель-Авив, 1996, бесплатная до 2000 г.) позволяет обмениваться персональными сообщениями с конкретным человеком в режиме реального времени ('двухсторонний пейджер', подробнее см. www.icq.com и www.dir.ru/internet/icq/russian/index.htm).
Существует ПО для обеспечения реального разговора через InterNet (т.н. IP-телефония), причем такой разговор обходится существенно дешевле, чем при использовании международного телефона; все чаще Сеть используется для передачи реальных видеоизображений. Большие размеры аувидео-файлов и ограничения полосы частот Сети для передачи реального аудио и видео вызвали появление технологии потоковой (streaming) передачи данных, для передачи голосовых сообщений в последнее время предлагается технология MPLS, позволяющая информационным пакетам 'обходить' перегруженные узлы Сети (тем самым минимизируя недопустимые при передаче голосовых сообщений задержки).
Получение файлов из сети InterNet обычно производится с помощью протокола FTP и специализированных приложений, например, FTP-32 Client for Windows (рис.6), соответствующие возможности включены во многие программные оболочки (например, Norton File Manager и Windows Commander).
Адрес целевого FTP-сервера (наряду с некоторыми дополнительными параметрами) вводится в окне, появляющемся сразу после загрузки приложения FTP-32 Client for Windows, при работе с программой пользователь на левой панели видит диски и каталоги собственного компьютера, на правой -удаленного; существуют возможности перемещения по каталогам файловой системы, выделения нужного файла и пересылки выбранного файла (кнопки со стрелками), причем посылка пользовательского файла на FTP-сервер разрешена лишь привилегированному пользователю (с целью устранения переполнения серверного набора дисковых томов ненужными файлами и предотвращения распространения компьютерных вирусов).
Рис.6. Вид экрана ПЭВМ при работе с приложением FTP-32 Client for Windows.
Наиболее мощные программные средства сети InterNet - программы обеспечения работы с серверами Word Wide Web (WWW), эти приложения часто называют броузерами (browser) или навигаторами (navigator).
Серверы WWW хранят информацию в виде гипертекстовых файлов (см. следующий подраздел), броузеры по сети получают (с использованием протокола HTTP) такой файл (соответствующий странице гипертекста или WEB-странице), специальным образом интерпретируют его и, при необходимости, отсылают введенную пользователем информацию назад серверу (например, запрос к базе данных); общая схема взаимодействия броузера с сервером WWW приведена на рис.7.Для просмотра страниц WEB-страниц первоначально были созданы броузеры Mosaic (разработка NCSA, National Center for Supercomputing Applications, Illinois University, 1993), Cello (LII, Legal Information Institute, Cornell Law School), Lynx и др., в настоящее время наиболее часто используются Microsoft Internet Explorer, Netscape Internet Navigator, Opera (Opera Software, www.opera.com) для эксплуатации в среде различных операционных систем; ниже будут рассмотрены наиболее распространенные броузеры фирм Netscape Communications Corp. и Microsoft Corp.
Программа-броузер,Адрес страницы WWW
запущенная на
Страница на языке HTML
Рис.7. Взаимодействие броузера и сервера WWW.
На рис.8 приведена копия экрана ПЭВМ во время функционирования приложения Netscape Communicator, на рис.7.9 - приложения Microsoft Internet Explorer (в обеих системах целевой WWW-адрес вводится в строке ввода, расположенной в верхней части окна броузера). Броузер фирмы Netscape Communications Corp. появился исторически первым, однако Microsoft Corp. включила свой броузер в состав ОС собственной разработки (что уже ряд лет служит причиной судебного разбирательства между указанными фирмами). Одними из последних нововведений фирмы Microsoft Corp. являются динамический HTML (DHTML, не поддерживаемый броузерами сторонних фирм) и новая компонентная модель разработки для WEB, под названием скриплеты (scriplets, понятие составлено из слов 'сценарии' и 'ап-плеты').
Оба приложения снабжены развитой системой навигации и кеширования WEB-страниц, поддерживают протоколы TCP/IP, HTTP, FTP, обеспечивают E-Mail и работу с FTP-серверами, содержат (встроенные) средства шифра-ции, однако только в последних версиях Microsoft Internet Explorer^ появилось средство публикации (пересылки с ЭВМ разработчика на WWW-сервер) файлов описания WEB-страниц, также первой фирма Netscape Communications Corp. выпустила средство для создания и редактирования HTML-страниц. Версии броузеров упомянутых фирм можно получить по адресам home.netscape.com и www.microsoft.com/ie соответственно. Представляющими интерес проектами являются Mozilla (термин является видоизмененным в сторону модной 'динозавровской' тематики названием легендарного броузера Mozaic, см. mozilla.ru) и BackOffice (backoffice.ru).
При проверке корректности настройки сети и протокола TCP/IP полезны программа PING (тестирование связи с любым InterNet-узлом), PM Ping (то же самое для операционной системы OS/2 Warp), NETSTAT (получение информации о установленных соединениях), ROUTE (работа с таблицей маршрутизации), FTP (утилита с командной строкой для загрузки файлов из Сети), FTP-PM (то же самое для OS/2 Warp), подробнее о эксплуатации этих приложений см. работу [13].
Виртуальная реальность в InterNet пока является новинкой (вследствие ограничений на объем передаваемой через Сеть информации предлагается хранить библиотеки описаний объектов виртуальной реальности на локальном компьютере, а из Сети получать лишь сценарии действий в виде текстовых файлов). При этом используется (интерпретируемый) предложенный в 1995 г. язык VRML (Virtual Reality Modeling Language) - язык моделирования виртуальной реальности; в настоящее время действует стандарт VRML97, практически идентичный языку VRML 2.0; на 2002 г. запланирована следующая версия VRML, получившая название X3D [22]. VRML предлагает способ создания трехмерных виртуальных миров (' аватаров') с возможностью 'путешествий' по ним в WEB; объекты VRML включают в себя текст, изображения, аудио, видео и Java-приложения (примеры VRML см. на InterNet-адресах www.webmaster.com/vrml, webspace.sgi.com, vrml.wired.com). Для общения InterNet-пользователей предлагаются поддерживающие VRML продукты Worlds Chat (фирма Worlds, Inc., www.worlds.net), Prospero's Global Chat (www.prospero.com), Internet Round Table Society's WebChat (www.irsociety.com) и др.
Для просмотра VRML-миров в настоящее время предлагаются несколько (бесплатных) расширений стандартных WEB-броузеров - модуль Live3D и CosmoPlayer (компания Cosmo Software, www.cosmosoftware.com) для броузера Nestcape Communicator, WorldView 2.0 (platunim.com) для MS Internet Explorer 5.0; удобным является VRML-клиент Cortona (фирма ParallelGraph-ics, www.paragraph.ru).
Рис.8. Вид экрана ПЭВМ при работе с приложением Netscape Communicator версии 4.5.
Так как описание VRML представляется обычным текстовым файлом (несложные примеры см. на адресе www.srcc.msu.su/vrml), создавать (и редактировать) исходные VRML-тексты можно с помощью простейших текстовых редакторов класса NotePad или WordPad; из специализированных редакторов VRML-кодов можно указать, например, VRMLPad фирмы Parallel-Graphics (выгрузка с узла www.paragraph.ru). Многие программы трехмерного моделирования (например, всем известный пакет 3D Studio Max) позволяют работать с данными в форме VRML.
43 язык java программирования в сети Internet
Язык Java [1] - это новый объектно-ориентированный язык программирования, созданный фирмой Sun для разработки программ, распространяемых по сети Internet [2]. Система программирования Java позволяет использовать World Wide Web (WWW) для распространения небольших интерактивных прикладных программ (апплетов), которые размещаются на серверах Internet, транспортируются клиенту по сети (точно так же, как картинки или звуковые файлы), автоматически устанавливаются и запускаются на месте, как часть документа WWW. При этом апплет имеет весьма ограниченный доступ к ресурсам компьютера клиента, так что он может предоставить произвольный мультимедийный интерфейс и выполнять сложные вычисления, не привнося при этом риска заражения вирусом или порчи данных.
Система программирования Java может служить основой для совместной разработки больших программных систем коллективом разработчиков, связанных между собой только через WWW (они и знакомы между собой могут быть лишь заочно, через e-mail, а когда они наконец повстречаются где-нибудь на международном симпозиуме, в их активе уже может быть совместно разработанная программная система). Java и WWW являются первыми системами, обеспечивающими такую возможность, поэтому их внедрение и распространение многие программисты справедливо называют революцией в разработке программного обеспечения. Ясно, что ведущую роль в обеспечении указанной возможности играет именно Java, так как именно Java позволяет распространять не просто тексты, а работающие программы и их фрагменты (апплеты) по WWW.
Отсюда большой интерес к языку и системе программирования Java со стороны буквально всех категорий разработчиков и пользователей программного обеспечения. Все ведущие фирмы, разрабатывающие компьютерную аппаратуру и программное обеспечение (и IBM, и DEC, и Microsoft, список можно продолжать очень долго) официально объявили о поддержке языка и системы программирования Java. Все распространенные инструментальные системы уже поддерживают программирование на Java. В WWW можно найти сотни тысяч публикаций и программной продукции, связанных с Java, в том числе свободно распространяемая система программирования Java, разработанная фирмой Sun-Soft (недавно из этой фирмы выделилась самостоятельная фирма Java-Soft), а также свободно распространяемая система программирования GNU-Java, разработанная FSF. Написаны десятки учебных пособий по Java (часть из них переведена на русский язык и издана в нашей стране), статьи и обзоры по языку Java и его применениям регулярно публикуются в серьезных и популярных программистских журналах и еженедельниках.
Цель данной публикации - ознакомить читателей с основными свойствами и особенностями системы программирования Java и показать, как можно использовать многочисленные Java-апплеты, доступные в среде Internet, и другие возможности языка и системы программирования Java в своей повседневной деятельности.
Сначала будет дано краткое описание особенностей синтаксиса и семантики конструкций языка Java, используя для сравнения всем хорошо известный объектно-ориенти-рованный язык C++. Внимание читателя будет обращено только на принципиальные моменты, с дальнейшими подробностями можно ознакомиться по описанию языка и другим основополагающим документам фирмы Sun [1,3,4], а также с помощью многочисленных учебных пособий и руководств по языку Java (см., например, [5]).
Затем будет описана система программирования языка Java. В ее состав входят следующие компоненты:
компилятор с языка Java на внутренний язык Java Byteсode (JavaBC): Java-программы и апплеты распространяются по WWW и интерпретируются на JavaBC;
загрузчик-верификатор программ на JavaBC;
интерпретатор JavaBC, называемый виртуальной машиной языка Java (JavaVM - Java Virtual Machine);
многочисленные библиотеки классов и утилиты, существенно упрощающие программирование на Java.
Возможности системы программирования языка Java (в частности, утилиты и некоторые библиотечные классы) будут продемонстрированы на примере разработки и использования нескольких простых апплетов, доступных по WWW.
Язык Java и его окружение непрерывно развиваются: постоянно появляются новые инструменты, многие системы интегрируются с системой Java. Развитием окружения Java занимаются группы во всех университетах, а также мощные компании (фирмы), разрабатывающие компьютерную аппаратуру и программное обеспечение. Поэтому основная часть данной публикации посвящена проблемам развития языка и системы программирования Java. На примере Java можно проследить как язык, первоначально ориентированный, в основном, на написание апплетов, постепенно превращается в мощный универсальный язык программирования. Развитие окружения Java нетрудно проследить по многочисленным публикациям в WWW, но именно их многочисленность делает эту задачу довольно трудной: ведь нужно не только успевать просмотреть все эти, порой противоречивые, а порой и просто ошибочные публикации, но и суметь сделать правильные выводы о тенденциях развития Java. Одна из попыток уловить такие тенденции и сформулировать их сделана в данной статье.
Основным свойством апплетов является возможность выполнять их на различных платформах и в различных окружениях, не оказывая вредного влияния на аппаратуру, программы и данные их пользователей. Язык, ориентированный на программирование апплетов должен прежде всего обеспечивать надежность и безопасность. Этого легче всего достичь в интерпретируемом языке, хотя интерпретация, как правило, ведет к существенной потере эффективности программы (она выполняется гораздо медленнее, чем могла бы), причем эти потери растут (нелинейно!) с ростом объема программы и объема обрабатываемых ею данных. Пока язык используется для разработки сравнительно небольших апплетов (например, апплета, выводящего на экран текущее состояние табло аэропорта, или биржи, или баскетбольного матча), эти потери просто не замечаются. Создается иллюзия, что скоро вообще можно будет решить проблему составления новых программ путем объединения ("сшивания") уже имеющихся в сети апплетов. Если стать на такую точку зрения, то интерпретируемый язык является наиболее естественным: ведь программа, состоящая из вызовов большого числа апплетов, все равно интерпретируется. К сожалению, с ростом объема такой программы она вообще перестанет выполняться ввиду нехватки ресурсов, или будет выполняться неприемлемо долго. Поэтому в окружении Java остро стоит проблема эффективности Java-программ. Авторы языка Java предчувствовали возникновение этой проблемы. Они ввели в язык легковесные процессы (трэды), обеспечив их параллельное выполнение на многопроцессорных компьютерах (которых становится все больше), они сконструировали интерпретатор языка (JavaVM) таким образом, что в Java-программу можно включать фрагменты, написанные на других языках и выполняемые в объектном коде (native code) соответствующей платформы. Но, как будет показано, эти средства языка Java не решают проблемы эффективности в полной мере, так как потери, связанные с интерпретацией намного больше. В данной статье будут рассмотрены основные пути решения проблемы эффективности системы Java.
Как уже было отмечено, Java - объектно-ориентированный язык. Это дало возможность зафиксировать достаточно компактное ядро языка, ограничив его сравнительно небольшим числом различных синтаксических конструкций, а большую часть возможностей языка вводить с помощью классов. Так, трэды включены в язык с помощью классов Thread и ThreadGroup. В виде классов реализованы и такие базовые языковые понятия, как функции обработки строк и обработка исключений. Развитие языка Java тоже ведется путем включения в него новых классов и пакетов (пакеты заменяют в системе программирования Java файлы-заголовки окружения C/C++, однако, в отличие от файлов-заголовков, пакеты содержат как спецификацию классов, так и их реализацию; подробнее о пакетах см. ниже). Такой способ расширения языка удобен тем, что старые компиляторы остаются пригодными и для расширенного языка. Многие новые свойства языка, введенные в него через новые классы и пакеты, будут рассмотрены (или хотя бы упомянуты) ниже. В частности, будут рассмотрены пакеты GJL и SJL, обеспечивающие некоторые удобные для приложений структуры объектов (контейнеры и итераторы)[6,7]. В языке C++ такие возможности поддерживаются широко известной библиотекой классов STL [8], в 1995 году включенной в его стандарт.
В заключение будут кратко рассмотрены и некоторые дополнительные средства окружения Java. Такими средствами являются, например, web'овский браузер HotJava [9] (именно этому браузеру система Java обязана своей эмблемой - чашечкой дымящегося кофе), а также небольшой объектно-ориентированный язык JavaScript [10], предназначенный для разработки CGI-скриптов [2, с. 189 - 199], используя конструкции языка Java. Netscape Navigator 2.0, или HotJava, интерпретирует операторы JavaScript, которые включаются непосредственно в страницу HTML. На языке JavaScript часто программируют текущую дату, различные "бегущие строки" и другие меняющиеся во времени объекты, встречающиеся на страницах HTML.
Основные конструкции языка Java
Авторы языка Java стремились сделать его внешне похожим на широко распространенный среди программистов язык C++. Поэтому синтаксис языка Java во многом совпадает с синтаксисом C и C++. И действительно в Java сохранена лексика и основные синтаксические конструкции C++. Как и в C++ в Java определены унарные и бинарные арифметические, логические и битовые операции, несколько операций присваивания, тренарная условная операция, явные и неявные операции приведения типов (причем все перечисленные операции имеют такие же обозначения и приоритеты, что и соответствующие операции C/C++). Как и в C++ в Java определены управляющие операторы if, if-else, break, switch, return, while, do-while, for, continue (все перечисленные операторы имеют семантику аналогичную семантике соответствующих операторов C/C++). Как и в C++ в Java определены классы, имеющие закрытую (private), ограниченно доступную (protected) и общедоступную (public) части, классы служат шаблонами для порождения объектов, для классов определено отношение наследования (правда в Java отменено множественное наследование), определены конструкторы и деструкторы, указатель this, абстрактные классы. На первый взгляд может показаться, что Java - просто еще одна версия C++.
Но это впечатление неверное. Язык Java существенно отличается от C++, так как при разработке Java из C++, который был взят за основу, были исключены почти все особенности C++, имеющие корни в языке C, из которого развился C++. В результате Java оказался не очередным диалектом C++, а новым языком, который лучше C++ в основном за счет того, чего в нем нет по сравнению с C++. В отличие от C++ Java позволяет писать надежные, безопасные, простые, удобные и легкие для понимания программы, хотя и более медленные, чем программы, написанные на C++.
Что же было исключено из C++ при разработке Java? Прежде всего были исключены указатели. Указатели или адреса в памяти - наиболее мощное средство написания высокоэффективных программ в окружении C/C++, но это и наиболее опасное средство этих языков. И дело даже не в том, что, как отмечают авторы языка Java, при недостаточно аккуратном обращении с указателями могут возникать трудно устранимые ошибки в C++-программе. Более существенные трудности в работе с указателями выявляются при разработке распределенных программ, когда требуется осуществить удаленный вызов функции (метода), среди параметров которой есть указатели. Еще более существенные трудности связаны с возможностью работы с произвольными адресами памяти через бестиповые указатели, так как это позволяет полностью игнорировать защиту памяти.
В языке Java нет указателей; все объекты программы расположены в куче (heap) и доступны по объектным ссылкам, которые представляют объекты во всех структурах, в которые могут входить объекты в качестве компонентов. Поскольку при работе с кучей программист не может пользоваться взаимным расположением объектов в памяти, это решение означает, что из языка Java исключена "кусочно-линейная" модель памяти системы C/C++, при которой массив - лишь точка (ячейка) памяти, на которую ссылается указатель этого массива; конечно, это решение исключило непосредственный доступ к памяти, но оно усложнило работу с элементами массивов и, естественно, является источником более низкой эффективности Java-программ по сравнению с C++-программами. Необходимо отметить, что объектные ссылки языка Java содержат информацию о классе объектов, на которые они ссылаются, так что объектные ссылки - это не указатели, а дескрипторы объектов. Наличие дескрипторов позволяет JavaVM выполнять проверку совместности типов на фазе интерпретации кода, возбуждая исключение в случае ошибки.
В Java пересмотрена и концепция C/C++ динамического распределения памяти. Исключена функция освобождения динамически выделенной памяти free(), так как работа с ней сочтена сложной и чреватой многими ошибками в программе, возможность которых уменьшает надежность C++-программ. Вместо этого в Java разработана и реализована система автоматического освобождения динамически выделенной памяти (сборщик мусора). Наличие механизма автоматической сборки мусора, естественное для интерпретируемого языка, усложняет разработку оптимизирующих компиляторов для такого языка. Тем не менее как показывает практика использования Java нужда в таких компиляторах имеется (см. ниже).
Стремление упростить Java-программы и сделать их более понятными привело к отказу от файлов-заголовков (h-файлов) и препроцессорной обработки. По мнению авторов Java файлы-заголовки, содержащие прототипы классов и распространяемые отдельно от двоичного кода этих классов, усложняют управление версиями, а механизм поддержки этой возможности в C/C++ помогает злонамеренным пользователям получать доступ к приватным данным объектов. В Java-программах спецификация класса и его реализация всегда содержатся в одном и том же файле. Препроцессор C/C++ с его возможностями условной компиляции дает возможность писать непонятные тексты программ, что, конечно, не очень хорошо. Но отказ от препроцессора привел к невозможности параметризации классов по типам (классам) их членов, что усложняет программирование простых вещей (например, на Java, в отличие от C++, нельзя иметь массив, элементами которого являются объекты произвольного класса). И, конечно, из Java исключен ненавидимый многими программистами-педантами оператор goto, замененный на continue и break с меткой.
Кроме того из Java исключены "дублирующие" понятия и конструкции языка C++, в частности, функции (в Java есть только методы классов), а также структуры (struct) и объединения (union) (в Java для этого используются атрибуты классов).
Необходимо также отметить, что в куче размещаются все данные Java-программы. Это означает, что хотя в Java и определены данные простых типов (byte, short, int, long, char, float, double, boolean) переменные этих типов могут быть лишь атрибутами объектов. Отсюда следует, что если нужно завести переменную, например, целого типа (int), то необходимо завести объект класса Int, который имеет один атрибут типа int и два метода - соответственно чтения значения этого атрибута и записи в него нового значения.
Таким образом, несмотря на внешнее сходство с C++, Java не просто является новым языком программирования, он настолько глубоко отличается от C++, что конвертировать разумным образом C++-программы на язык Java (или наоборот) - очень сложная задача.
Завершая краткий обзор языка Java, рассмотрим его конструкции, которых нет в C++. Это операторыpackage, import, interface и implements.
Оператор package, помещаемый в начале исходного программного файла определяет пакет, т.е. область в пространстве имен классов, в которой определяются имена классов, содержащихся в этом файле; внутри указанной области пространства имен можно выделить подобласти, используя все тот же оператор package; действие оператора package аналогично действию объявления директории на имена файлов. Для обеспечения возможности использования коротких имен классов, помещенных в другие пакеты, используется оператор import. Пакет, определяемый оператором package по существу является структурной частью проектируемой программной системы, в аспекте интерфейса во многом похожей на объект, но имеющей более сложную структуру (он играет роль подсистемы). Если ввести пакеты (подсистемы) в объектно-ориентированные методологии структурного проектирования программных систем (например, в известную методологию OMT [11]), они станут еще более мощным средством поддержки программных проектов.
Оператор interface, позаимствованный разработчиками Java из языка Objective_C (там аналогичное понятие называется протоколом), открывает определение интерфейса. Интерфейс - это набор сигнатур методов без из реализации. Каждый интерфейс может быть реализован одним или несколькими классами, при этом классы, реализующие один и тот же интерфейс, могут быть никак не связаны по иерархии наследования. Класс может реализовывать любое число интерфейсов (список интерфейсов, реализуемых некоторым классом указывается в операторе implements, дополняющим определение соответствующего класса). На множестве интерфейсов тоже определена иерархия по наследованию, но она не имеет отношения к иерархии классов. В языке Java интерфейсы обеспечивают большую часть той функциональности, которая в C++ обычно представляется с помощью механизма множественного наследования.
Библиотека классов языка Java
Системная библиотека классов языка Java содержит классы и пакеты, реализующие различные базовые возможности языка. Методы классов, включенных в эту библиотеку, вызываются из JavaVM во время интерпретации Java-программы. Идея реализовывать часть языковых возможностей с помощью системных библиотек была успешно осуществлена еще в языке C и его преемнике C/C++ (откуда Java и взяла эту идею). Но если в системе программирования C/C++ нужна была известная осторожность при развитии языка с помощью библиотек, так как библиотеки вносили в язык элемент интерпретации, снижая эффективность программного кода, то в системе Java и так вся программа интерпретируется на JavaVM, так что возможности расширять язык, вводя все новые и новые классы и пакеты в системную библиотеку, практически неограничены.Выше уже было упомянуто, что с помощью библиотечных классов Thread и ThreadGroup в Java введены легковесные процессы (трэды). Для синхронизации трэдов в Java используются мониторы Хоара, с помощью которых осуществляется синхронизация очередей (с приоритетами) к совместно используемым данным. Механизм наследования позволяет вводить в управление трэдами новые возможности: можно разработать "свои трэды", наследуясь от класса Thread.
Системная библиотека Java содержит также классы String и StringBuffer, поддерживающие работу со строками. Эти классы объявлены как final, что означает, что от этих классов нельзя производить подклассы. Класс String содержит основные операции для работы со строками (слияние строк, сравнение строк, поиск и извлечение символов и т.п.). Отметим, что операция (метод) конкатенации (слияния) строк обозначается символом "+", причем это единственный случай в языке Java, когда использована перегрузка знаков операций (в отличие от C++, широко использующем перегрузку операций+, * и др., что приводит к плохо понимаемым текстам программ, в Java запрещена перегрузка знаков операций). Класс StringBuffer является близнецом класса String, но, в отличие от класса String, объекты которого нельзя изменять (новая строка - это новый объект класса String), строки, являющиеся объектами класса StringBuffer, можно изменять.
Как и в системе программирования C/C++, в системную библиотеку Java включен пакет java.io, в котором реализованы потоки ввода-вывода. Возможности ввода-вывода в Java, в основном аналогичны реализации ввода-вывода в системе C/C++.
В системную библиотеку Java входят пакеты java.lang и java.util, которые содержат наборы вспомогательных классов, широко используемых в других встроенных пакетах Java и, естественно в прикладных пакетах и классах, разрабатываемых пользователями окружения Java. В частности, пакетjava.lang содержит абстрактный класс Number, представляющий собой интерфейс для работы со всеми скалярными типами, его подклассы Integer, Long, Float и Double, являющиеся классами-оболочками для значений соответствующих типов (каждый объект класса-оболочки содержит одно значение соответствующего типа и имеет методы, обеспечивающие доступ к указанному значению), а также классы-оболочки Character и Boolean. Из других классов этих пакетов можно отметить класс Math, который содержит функции с плавающей точкой, используемые в физических и технических расчетах, а также константы E (приблизительно 2.72) и PI (приблизительно 3.14).
Интеграция системы Java с сетью Internet обеспечивается пакетом java.lang, входящим в системную библиотеку Java. При этом адреса абонентов, принятые в Internet, поддерживаются классом InetAddress, для поддержки дейтаграмм (пакетов протокола UDP) используются классы DatagramPacket и DatagramSocket, класс Socket поддерживает сокеты TCP/IP, для создания серверов Internet используются объекты класса ServerSocket. Наконец, имеется класс URL для связи с WWW (пользователи WWW знают, что URL, или Uniform Resource Locators - наиболее фундаментальный компонент WWW, обеспечивающий доступ к ее содержимому; в списке литературы к данной статье URL использованы для указания источников, доступных по Internet). Сетевые классы Java представляют ясный и простой в использовании интерфейс для работы в Internet, существенно упрощая написание программ для Internet.
В системную библиотеку Java включены также классы, поддерживающие разработку апплетов и упрощающие работу с окнами. Эти классы рассматриваются в следующем разделе.
Библиотека классов Java постоянно расширяется за счет новых классов и пактов. Эти классы фактически расширяют язык Java, предоставляя программистам новые возможности. В качестве примера такого расширения Java рассмотрим два пакета, реализующие для окружения Java знаменитую библиотеку STL (Standard Template Library) [8], которая имеет большой успех у программистов, использующих C++.
Первый из этих пакетов - SJL (Simple Java Library) [7] представляет собой набор контейнерных классов и алгоритмов, параметризованных по типам (классам) содержащихся в них объектов и разработанных таким образом, чтобы программисты моли использовать их в различных сочетаниях в своих программах. Контейнерные классы определяют контейнерные объекты (или просто - контейнеры), т.е. объекты, которые содержат в себе наборы (множества) других объектов, обеспечивая доступ к этим объектам. Примерами контейнеров является список, массив, очередь и т.п. С каждым контейнером обычно бывает связано один или несколько итераторов - объектов, обеспечивающих доступ к содержимому соответствующего контейнера в некотором порядке. SJL обеспечивает возможности библиотеки STL для пользователей системы Java.
К сожалению, в системе Java в отличие от C++ не предусмотрено препроцессора (авторы Java являются принципиальными противниками препроцессора). Поэтому параметрические (generic) классы, реализованные в языке C++ через шаблоны (templates), обрабатываемые препроцессором, и широко используемые в библиотеке STL (ведь это библиотека шаблонов), в SJL реализованы через вызовы методов соответствующих классов. В результате во время выполнения программы приходится выполнять часть функций, которые в STL выполняются в процессе компиляции (дополнительная интерпретация!), что конечно же резко снижает производительность классов библиотеки SJL по сравнению с аналогичными классами STL.
В другой, более популярной, реализации библиотеки STL для окружения Java - пакете JGL (Java Generic Library) [6], разработанном под руководством самого автора STL А. Степанова, показано как в этом окружении можно интерпретировать параметрические (generic) классы. Для этого авторы JGL разработали наборы интерфейсов, по одному для каждого из одиннадцати видов контейнеров (Array, Deque, Dlist,Slist, HashSet, OrderedSet, Stack, Queue, PriorityQueue, HashMap, OrderedMap), и контейнерные классы, реализующие эти наборы интерфейсов. Каждый интерфейс контейнера соответствует одному из классов объектов, содержащихся в этом контейнере, так что как только появляется новый класс объектов, включаемых в контейнер, соответствующий набор интерфейсов должен быть пополнен еще одним интерфейсом. Обращение к контейнеру всегда производится через один из его интерфейсов. Конечно, по сравнению с шаблонами такой способ параметризации классов по типам содержащихся в них объектов выглядит несколько неуклюжим. Другим недостатком пакета JGL является возможность включать в его контейнеры только объекты, так что элементами контейнера "массив целых значений" будут не поля типаint, а соответствующие объекты класса Int из пакета java.lang.
Из описания двух способов реализации библиотеки STL для окружения Java (SJL и JGL) видно, что язык Java нуждается в более удобных средствах параметрического (generic) программирования. Предложения по расширению Java в этом направлении встречаются в публикациях (см., например, [12]). Однако пока эти предложения не встречают должного понимания у авторов Java.
44 языки javascript, vbscript и perlscript
ASP-страницы, почему-то, всегда связывают со скриптом VBScript. Хотя это, наверное, худший из возможных вариантов. ASP могут быть написаны на любом WSH (Windows Scription Host)-cовместимом скриптовом языке. Рассмотрим 3 варианта - VBScript, JScript, PerlScript. Первые два - VBScript & JScript поддерживаются Miscrosoft, и не требуют дополнительных инсталляций. PerlScript автоматически устанавливается при инсталляции
ActivePerl
. Сравним эти три варианта.
 
VBScript
    К немногим преимуществам (весьма неоднозначным) VBScript можно отнести то, что он прост для использования VisualBasic-программистами. Если объекты 2nd tier пишутся как COM-объекты на VisualBasic, это может служить оправданием использования VBScript. Т.к. образуется некий "корпоративный стандарт". Язык Basic, сам по себе, является прекрасным языком для обучения программированию, на котором выросло не одно поколение программистов. Однако, непосредственно VBScript, не способствует появлению хорошего стиля программирования и потому стимулирует крах проектов средней и большой сложности.  Наверное худшим ограничением является отсутствие возможности объектно-ориентированного программирования, что очень критично для крупных проектов.  Если, все-таки, решено использовать VBScript, следует уделить тщательное внимание аккуратности при написании кода, комментариям, отступам, понятным названиям процедур, функции и переменных, хорошему документированию. Это важно при любом программировании, но для VBScript это актуально вдвойне. Не следует также пользоваться независимостью от регистра языка VBScript.
JScript (javascript)
    Одним из новаторских изобретений фирмы Netscape стал скриптовый язык javascript. Его синтаксис официально основывается на чрезвычайно популярном сейчас языке Java. А это, в свою очередь, говорит о схожести с C и C++. Особый интерес в javascript представляет оригинальная система динамического создания объектов, что позволят применять объектно-ориентированный подход. Несмотря на отсутствие инкапсуляции, странное наследование и неограниченный полиморфизм (проверки типов в javascript нет), применение объектов выводит программирование ASP-страниц на более высокий уровень, позволяя использовать стандартные паттерны проектирования, упрощая код и делает его более логичным, расширяемым и переносимым. Можно, например, создавать  оболочки (которые еще называют адаптерами или врапперами) COM-объектов (того же ADODB), более удобные для применения, и абстрагирующие основной ASP-код от этого-самого COM-объекта (позволяя, при необходимости, легко заменить его на другой объект 2nd tier).    JScript является клоном языка javascript от Microsoft. Отличия javascript и JScript минимальны, однако их следует знать (отличия описаны в документации по JScript) и обходить (или абстрагировать), поскольку применение JScript в ASP открывает уникальную перспективу - возможность простого перевода Web-приложения, почти без переписывания основного кода, на технологию JSP (Java Server Pages). Это не означает, что мы собираемся бросать ASP и срочно переходить на JSP. Просто, в современных условиях, быть не привязанным к единственной платформе и/или технологии - очень ценное свойство проекта, которое, быть может, спасет его от гибели. Если грамотно абстрагировать ASP- и Windows-зависимый код в общие библиотеки,  то, переписав только эти библиотеки, мы, теоретически, получим JSP-сайт. (JSP страницы могут быть написаны на javascript, а конструкции <%...%>, <%=...%>  схожи и в ASP и в JSP). Это, однако, не относится к объектам 2nd tier, которые переводить придется отдельно.    Достоинством javascript можно считать  его применение на стороне клиента (DHTML в Web-броузере), что позволяет создать "корпоративный стандарт". Т.е. программист-разработчик может применять единую технологию на стороне клиента и сервера (VBScript также можно использовать на стороне клиента, для броузера Internet Explorer, но это, обычно, не практикуется). Если разработки в компании ведутся на Java, С или С++, то javascript весьма гармонично впишется в рабочую среду. Недостатком конкретной реализации JScript можно считать отсутствие аналога VBScript-функции chrB(), что ограничивает возможность работы с однобайтовыми потоками данных. Что, с другой стороны, стимулирует вынесение сложного кода в объекты 2-nd tier.
PerlScript (ActivePerl)
    Появившись как язык для написания UNIX-скриптов, Perl обрел новое призвание в Web-разработках благодаря своей простоте, уникальным возможностям для работы со строками, большому количеству библиотек и своей бесплатности. Использовать Perl как PerlScript в ASP несколько эффективнее, чем в качестве CGI или ISAPI, поскольку открывает доступ к стандартным и весьма полезным ASP-объектам (Server, Application, Session, etc.). Perl поддерживает объектно-ориентированное программирование, что дает ему преимущества, описанные выше для javascript. Недостатком (условным) использования PerlScript является необходимость его установки на сервер (усложнение deployment), а также то, что это свободно-распространяемый  продукт, безо всяких гарантий. С другой стороны, для стран СНГ эта характеристика присуща большинству программных продуктов, и потому этот недостаток неактуален. Решать, кто дольше просуществует и будет продолжать выпускать обновленные версии своих продуктов - Microsoft или ActiveState (разработчик ActivePerl) - тоже дело неблагодарное. Поэтому стоит изначально закладывать в проект возможность для перехода на конкурирующую технологию. Для ASP+PerlScript эта технология - PHP. Так же, как ASP+JScript можно перевести на JSP, так и  ASP+PerlScript можно перевести на PHP, поскольку скриптовый язык PHP по синтаксису близок к Perl. Этот переход видится немного более сложным, чем ASP+JScript->JSP, но вполне осуществимым.     К неоднозначным фактам можно отнести наличие у Perl большого количества библиотек. Несмотря на кажущееся явное преимущество, концентрация слишком большой функциональности в ASP-страницах (к чему склоняют Perl-библиотеки) приводит к нарушению баланса распределенной системы. Вместо того, чтобы выносить функциональность в 2nd tier объекты, разработчики размещают сложный и ресурсоемкий код в ASP-файлы, в результате система становится немасштабируемой, а IIS - перегруженным. Решением этой проблемы выглядит разработка 2nd tier COM-объектов на том же Perl (возможность писать COM-объекты на Perl  ActiveState предлагала, на момент написания статьи, за 110$). Опять же, мы имеем корпоративный стандарт - ASP+PerlScript & COM-объекты на Perl, со всеми преимуществами корпоративных стандартов.
Общие  сравнительные характеристики:
ASP Script: VBScript JScript PerlScript
Объктно-ориентированное программирование Нет Да Да
2nd tier на COM Да Да Да
2nd tier на CORBA Только через мосты Только через мосты Да
2nd tier на EJB Только через мосты Только через мосты Только через мосты
Схожие языки (для формирование корпоративного стандарта) MS Visual Basic, any Basic javascript, Java, C, C++  Perl, PHP
Проект может мигрировать на другую Web-технологию Нет Да, на JSP Да, на PHP или Perl CGI/ISAPI
Проект может мигрировать на другую платформу Нет Да, JSP на любой JSP-совместимой платформе Да, PHP/Perl на любой PHP/Perl-совместимой платформе
    Критериями выбора скрипта разработки для ASP могут стать:
возможности этого скрипта, как языка программирования
корпоративные стандарты компании 
возможности простой миграции проекта на конкурирующие технологии
простота поддержки
    В свете вышеописанных критериев, можно порекомендовать выбор в пользу JScript.
45 серверные расширения CGI и ISAPI
Как мы только что сказали, расширение ISAPI создается в виде библиотеки динамической компоновки DLL. Обращение к такой библиотеки выполняется в документах HTML аналогично обращению к программам CGI - из форм или ссылок, созданных, соответственно, при помощи операторов <FORM> и <A>.
Когда пользователь обращается к расширению ISAPI, соответствующая библиотека DLL загружается в адресное пространство сервера Microsoft Information Server и становится его составной частью. Так как расширение ISAPI работает в рамках процесса сервера Microsoft Information Server, а не в рамках отдельного процесса (как это происходит при запуске программы CGI), оно может пользоваться всеми ресурсами, доступными серверу. Это благоприятно сказывается на производительности.
Другой важный момент, влияющий на производительность, имеет особое значение в тех случаях, когда расширение сервера используется активно сразу многими пользователями.
Пусть, скажем, 20 пользователей обратятся одновременно к одной и той же программе CGI. В результате на сервере будет создано 20 процессов, по одному для каждого пользователя. Так как создание процесса отнимает достаточно много системных ресурсов, это приведет к потере производительности.
Если же 20 пользователей одновременно обратятся к одному и тому же расширению ISAPI, в память серверного процесса будет загружена одна копия библиотеки DLL расширения, которая будет работать в мультизадачном режиме. Очевидно, при таком подходе полностью исключаются накладные расходы системных ресурсов на запуск процессов.
Сравнивая программы CGI и расширения ISAPI, нужно заметить, что несмотря на существенное превосходство в быстродействии расширений ISAPI, программы CGI также имеют свои преимущества.
Так как расширения ISAPI работают в рамках серверного процесса, они должны отлаживаться особенно тщательно. Ошибка в расширении ISAPI может привести к аварийному завершению всего сервера Microsoft Information Server. Что же касается программы CGI, работающей как отдельный процесс в своем собственном адресном пространстве, то она едва ли способна вывести из строя сервер. Если в программе CGI будет допущена критическая ошибка, это приведет всего лишь к аварийному завершению самой программы, но не всего сервера.
Напомним, что расширение ISAPI работает в мультизадачном режиме, что приводит к дополнительным проблемам при отладке. Особенности программирования для мультизадачного режима мы описали в 26 и 27 томах “Библиотеки системного программиста”, которые называются “Программирование для Windows NT. Часть 1” и “Программирование для Windows NT. Часть 2”. Там же вы найдете информацию о том, как создавать библиотеки DLL, предназначенные для работы в среде Microsoft Windows NT и Microsoft windows 95.
Вызов расширения ISAPI сервером WWW
Структура расширения ISAPI очень проста. Библиотека DLL расширения должна экспортировать всего две функции с именами GetExtensionVersion и HttpExtensionProc. Первая из этих функций предназначена для того, чтобы расширение могло сообщить серверу версию спецификации, которой оно соответствует, и строку описания расширения. Функция HttpExtensionProc выполняет всю работу по передаче данных между расширением и сервером.
Дополнительно расширение ISAPI может экспортировать функцию TerminateExtension, которая вызывается сервером перед тем, как ненужное больше приложение ISAPI выгружается из памяти. Функция TerminateExtension должна освободить ресурсы, загруженные динамически при инициализации расширения ISAPI.
Функция GetExtensionVersion
Насколько проста реализация функции GetExtensionVersion вы можете судить по следующему фрагменту кода, взятому нами из исходных текстов приложения FILEUPL (это приложение будет полностью рассмотрено позже):
// =============================================================
// Функция GetExtensionVersion
// =============================================================
BOOL WINAPI GetExtensionVersion(HSE_VERSION_INFO *pVersion)
{
pVersion->dwExtensionVersion =
MAKELONG(HSE_VERSION_MINOR,HSE_VERSION_MAJOR);
lstrcpyn(pVersion->lpszExtensionDesc,
"Remote File Upload", HSE_MAX_EXT_DLL_NAME_LEN);
return TRUE;
}
При вызове функции GetExtensionVersion передается указатель на структуру типа HSE_VERSION_INFO. Эта структура и указатель на нее LPHSE_VERSION_INFO определены в файле httpext.h следующим образом:
#define HSE_MAX_EXT_DLL_NAME_LEN 256typedef struct _HSE_VERSION_INFO
{
DWORD dwExtensionVersion;
CHAR lpszExtensionDesc[HSE_MAX_EXT_DLL_NAME_LEN];
} HSE_VERSION_INFO, *LPHSE_VERSION_INFO;
Константы HSE_VERSION_MINOR и HSE_VERSION_MAJOR указывают текущую версию интерфейса расширения ISAPI и также определены в файле httpext.h:
#define HSE_VERSION_MAJOR 2 // верхний номер версии
#define HSE_VERSION_MINOR 0 // нижний номер версии
Функция HttpExtensionProc
Теперь рассмотрим вторую функцию, которую должна экспортировать библиотека DLL расширения ISAPI. Она называется HttpExtensionProc и имеет следующий прототип:
DWORD WINAPI HttpExtensionProc(EXTENSION_CONTROL_BLOCK *pECB);
Функция HttpExtensionProc получает единственный параметр - указатель на структуру типа EXTENSION_CONTROL_BLOCK, определенную в файле httpext.h:
typedef struct _EXTENSION_CONTROL_BLOCK
{
DWORD cbSize; // размер структуры в байтах
DWORD dwVersion; // версия спецификации ISAPI
HCONN ConnID; // идентификатор канала
DWORD dwHttpStatusCode; // код состояния HTTP
CHAR lpszLogData[HSE_LOG_BUFFER_LEN]; // текстовая строка,
// закрытая двоичным нулем, в которой находится информация
// протоколирования, специфичная для данного расширения
LPSTR lpszMethod; // переменная REQUEST_METHOD
LPSTR lpszQueryString; // переменная QUERY_STRING
LPSTR lpszPathInfo; // переменная PATH_INFO
LPSTR lpszPathTranslated; // переменная PATH_TRANSLATED
DWORD cbTotalBytes; // полный размер данных, полученных от
// навигатора
DWORD cbAvailable; // размер доступного блока данных
LPBYTE lpbData; // указатель на доступный блок данных
// размером cbAvailable байт
LPSTR lpszContentType; // тип принятых данных
// Функция GetServerVariable для получения значения переменных
BOOL (WINAPI * GetServerVariable)(HCONN hConn,
LPSTR lpszVariableName, LPVOID lpvBuffer, LPDWORD lpdwSize);
// Функция WriteClient для посылки данных удаленному пользователю
BOOL (WINAPI * WriteClient)(HCONN ConnID,
LPVOID Buffer, LPDWORD lpdwBytes, DWORD dwReserved);
// Функция ReadClient для получения данных от удаленного
// пользователя
BOOL (WINAPI * ReadClient) (HCONN ConnID,
LPVOID lpvBuffer, LPDWORD lpdwSize);
// Вспомогательная функция ServerSupportFunction
// для выполнения различных операций
BOOL (WINAPI * ServerSupportFunction)(HCONN hConn, DWORD dwHSERRequest, LPVOID lpvBuffer,
LPDWORD lpdwSize, LPDWORD lpdwDataType);
} EXTENSION_CONTROL_BLOCK, *LPEXTENSION_CONTROL_BLOCK;
Рассмотрим отдельные поля этой структуры.
·       cbSize
В самом начале структуры EXTENSION_CONTROL_BLOCK находится поле cbSize, в которое при вызове расширения сервер записывает размер структуры в байтах.
·       dwVersion
Поле dwVersion содержит номер версии расширения ISAPI. Верхнее и нижнее значения номера версии можно получить, соответственно, при помощи макрокоманд HIWORD и LOWORD.
·       ConnID
В поле ConnID сервер записывает идентификатор канала, созданного для расширения. Это поле вы не должны изменять.
·       dwHttpStatusCode
Поле dwHttpStatusCode должно заполняться расширением ISAPI. Вы должны записать сюда результат завершения операции (код состояния транзации). В случае успеха в это поле записывается значение 200 (как указано в спецификации HTTP).
·       lpszLogData
Поле lpszLogData предназначено для записи сообщения о выполнении транзакции в журнал сервера WWW. Это сообщение должно быть в виде текстовой строки, закрытой нулем. Размер строки в байтах не должен превышать значения HSE_LOG_BUFFER_LEN.
·       lpszMethod
Поле lpszMethod заполняется сервером и содержит название метода передачи данных от удаленного пользователя серверу в виде текстовой строки, закрытой двоичным нулем. Расширения ISAPI используют те же самые методы, что и программы CGI - метод GET и метод POST. Проводя аналогию с программами CGI дальше, скажем, что поле lpszMethod эквивалентно переменной среды с именем REQUEST_METHOD, создаваемой для программы CGI.
·       lpszQueryString
Аналогично, поле lpszQueryString соответствует переменной среды с именем QUERY_STRING. В это поле записываются данные, принятые от удаленного пользователя методом GET.
·       lpszPathInfo
В поле lpszPathInfo записывается виртуальный путь к программному файлу библиотеки DLL расширения ISAPI. Напомним, что аналогичная информация для программ CGI передавалась через переменную среды с именем PATH_INFO.
·       lpszPathTranslated
Это поле содержит физический путь к программному файлу библиотеки DLL расширения ISAPI. Оно соответствует переменной среды с именем PATH_TRANSLATED, создаваемой для программ CGI.
·       cbTotalBytes
В поле cbTotalBytes записывается общее количество байт данных, которое необходимо получить от удаленного пользователя. Часть этих данных (размером не более 48 Кбайт) считывается сервером автоматически и становится доступной сразу после того как функция HttpExtensionProc получит управление. Остальные данные необходимо дочитать в цикле при помощи функции ReadClient, о которой мы еще будем говорить.
·       cbAvailable
В поле cbAvailable записывается размер блока данных, полученных от удаленного пользователя автоматически. Как мы только что сказали, размер этого блока не может превышать 48 Кбайт. Этого, однако, вполне достаточно для обработки данных, полученных от форм обычного размера.
·       lpbData
Указатель на область памяти, в которую записан сервером полученный от удаленного пользователя блок данных размером cbAvailable байт.
·       lpszContentType
Поле lpszContentType содержит тип принятых данных, например, text/html.
·       GetServerVariable
Помимо полей данных, структура EXTENSION_CONTROL_BLOCK содержит указатели на функции. С помощью этих функций расширение ISAPI может выполнять различные операции, такие как прием данных от удаленного пользователя.
Поле GetServerVariable содержит указатель на функцию, с помощью которой расширение ISAPI может получить информацию, которая доступна программам CGI через переменные среды, описанные нами в предыдущей главе этой книги.
·       WriteClient
В поле WriteClient находится адрес функции, которую расширение ISAPI должно использовать для посылки данных удаленному пользователю. Таким образом, вместо того чтобы записывать данные в стандартный поток вывода STDOUT, как это делает программа CGI, приложение ISAPI посылает данные с помощью функции WriteClient.
·       ReadClient
С помощью функции, адрес которой передается в поле ReadClient, приложение может дочитать дополнительные данные, не поместившиеся в буфер предварительного чтения, имеющий адрес lpbData и размер, не превышающий 48 Кбайт. Аналогичную операцию приема данных от пользователя выполняет программа CGI в случае применения метода передачи данных POST. Отличие заключается в том, что программа CGI получает данные через стандартный поток ввода STDIN, а расширение ISAPI берет эти данные из буфера предварительного чтения и при необходимости дочитывает данные функцией ReadClient.
·       ServerSupportFunction
С помощью функции, адрес которой передается через поле ServerSupportFunction, расширение ISAPI может выполнять различные действия, такие как посылка стандартного заголовка протокола HTTP и некоторые другие.
При успешном завершении функция HttpExtensionProc должна вернуть значение HSE_STATUS_SUCCESS, а при ошибке - значение HSE_STATUS_ERROR. Соответствующие константы определены в файле httpext.h.
Получение данных расширением ISAPI
Программа CGI получает данные из переменных среды и стандартного потока ввода STDIN (в случае применения метода доступа POST). Расширение ISAPI делает это по-другому.
Функция HttpExtensionProc получает указатель на структуру типа EXTENSION_CONTROL_BLOCK, некоторые поля которой заполняются сервером и должны использоваться для получения входных данных. Прежде всего это поле lpszMethod, через которое передается метод, использованный для посылки данных (GET или POST), поле lpszQueryString, в котором передаются параметры запуска расширения или данные при использовании метода GET, а также другие поля, описанные выше.
Через структуру EXTENSION_CONTROL_BLOCK передаются адреса функций GetServerVariable и ReadClient, специально предназначенных для получения данных от навигатора удаленного пользователя.
Функция GetServerVariable
Прототип функции GetServerVariable определен в структуре EXTENSION_CONTROL_BLOCK, описанной нами ранее:
BOOL (WINAPI * GetServerVariable)(HCONN hConn,
LPSTR lpszVariableName, LPVOID lpvBuffer, LPDWORD lpdwSize);
Через параметр hConn вы должны передать этой функции идентификатор канала, полученный через поле ConnID структуры EXTENSION_CONTROL_BLOCK.
Параметр lpszVariableName должен содержать указатель на строку имени переменной, содержимое которой необходимо получить. Это содержимое будет записано функцией в буфер, адрес которого передается через параметр lpvBuffer, а размер - через параметр lpdwSize.
Ниже мы перечислили возможные значения строк, передаваемых через параметр lpszVariableName:
·       AUTH_TYPE
Переменная среды AUTH_TYPE содержит тип идентификации, который применяется сервером.
·       HTTP_ACCEPT
В этой переменной перечислены типы данных MIME, которые могут быть приняты навигатором от сервера WWW.
·       CONTENT_LENGTH
Количество байт данных, которые расширение ISAPI должно получить от навигатора.
·       CONTENT_TYPE
Тип данных, присланных навигатором.
·       PATH_INFO
Путь к виртуальному каталогу, в котором находится библиотека DLL расширения ISAPI.
·       PATH_TRANSLATED
Физический путь к библиотеки DLL расширения ISAPI.
·       QUERY_STRING
Строка параметров, указанная в форме или операторе ссылки <A>. Эта строка указывается после адреса URL библиотеки DLL расширения ISAPI вслед за разделительным символом “?”.
·       REMOTE_ADDR
Адрес IP узла, на котором работает навигатор удаленного пользователя.
·       REMOTE_HOST
Доменное имя узла, на котором работает навигатор удаленного пользователя. Если эта информация недоступна (например, для узла не определен доменный адрес), то вместо доменного имени указывается адрес IP, как в переменной REMOTE_ADDR.
·       REMOTE_USER
Имя пользователя, которое используется навигатором для аутентификации.
·       UNMAPPED_REMOTE_USER
Имя пользователя до обработки фильтром ISAPI, которое используется навигатором для аутентификации.
·       REQUEST_METHOD
Метод доступа, который используется для передачи данных от навигатора серверу WWW.
·       SCRIPT_NAME
В эту переменную записывается путь к виртуальному каталогу и имя библиотеки DLL расширения ISAPI. Анализируя эту переменную, расширение ISAPI может определить путь к своему загрузочному файлу.
·       SERVER_NAME
Доменное имя сервера WWW или адрес IP сервера WWW, если доменное имя недоступно или не определено.
·       SERVER_PROTOCOL
Имя и версия протокола, который применяется для выполнения запроса к расширению ISAPI.
·       SERVER_PORT
Номер порта, на котором навигатор посылает запросы серверу WWW.
·       SERVER_PORT_SECURE
Если обработка запроса выполняется через защищенный порт, в этой строке записано значение 1, а если через незащищенный - значение 0.
·       SERVER_SOFTWARE
Название и версия программного обеспечения сервера WWW. Версия следует после названия и отделяется от последнего символом “/”.
·       ALL_HTTP
Строка, закрытая двоичным нулем, в которую записаны значения всех переменных, имеющих отношение к протоколу HTTP. Это, например, такие переменные как HTTP_ACCEPT, HTTP_CONNECTION, HTTP_USER_AGENT и так далее.
Извлекать содержимое отдельных переменных ваша программа должна самостоятельно. При этом следует учесть, что названия переменных отделены от их значений символом двоеточия “:”, а поля переменных разделены символом перевода строки.
Обратите внимание, что названия этих строк почти совпадают с названиями переменных среды, создаваемых для программ CGI, однако совпадение все же не полное.
В случае успешного завершения функция GetServerVariable возвращает значение TRUE, а при возникновении ошибки - значение FALSE. Код ошибки можно определить с помощью функции GetLastError, вызвав ее сразу после функции GetServerVariable. Эта функция может вернуть в данном случае следующие коды ошибок:
Код ошибки Описание
ERROR_INVALID_INDEX Неправильное имя переменной, передаваемой через параметр lpszVariableName
ERROR_INVALID_PARAMETER Неправильное значение параметра hConn
ERROR_INSUFFICIENT_BUFFER Буфер, адрес которого указан с помощью параметра lpvBuffer, слишком мал. Необходимый размер буфера записывается по адресу, который был передан функции через параметр lpdwSize
ERROR_MORE_DATA Буфер, адрес которого указан с помощью параметра lpvBuffer, слишком мал. В результате данные были прочитаны частично, причем размер буфера, необходимый для чтения всех данных, неизвестен
ERROR_NO_DATA Данные не были получены
Ниже мы привели пример использования функции GetServerVariable для получения содержимого переменной с именем ALL_HTTP в буфер szTempBuf.
CHAR szTempBuf[4096];
DWORD dwSize;
dwSize = 4096;
lpECB->GetServerVariable(lpECB->ConnID,
(LPSTR)"ALL_HTTP", (LPVOID)szTempBuf, &dwSize);
strcat(szBuff, szTempBuf);
Функция ReadClient
Прототип функции ReadClient находится в определении структуры EXTENSION_CONTROL_BLOCK и выглядит следующим образом:
BOOL (WINAPI * ReadClient) (HCONN ConnID,
LPVOID lpvBuffer, LPDWORD lpdwSize);
Через параметр hConn этой функции надо передать идентификатор канала, полученный через поле ConnID структуры EXTENSION_CONTROL_BLOCK.
Функция ReadClient читает данные в буфер, адрес которого передается через параметр lpvBuffer, а размер - через параметр lpdwSize. В случае успеха функция возвращает значение TRUE, а при ошибке - значение FALSE. Код ошибки можно получить при помощи функции GetLastError.
Работа с функцией ReadClient имеет некоторые особенности.
Когда расширение ISAPI получает управление, через структуру типа EXTENSION_CONTROL_BLOCK передается адрес предварительно прочитанного блока данных, полученного от удаленного пользователя. Как вы знаете, адрес и размер этого блока данных указаны, соответственно, в полях lpbData и cbAvailable структуры EXTENSION_CONTROL_BLOCK.
Однако размер предварительно прочитанных данных не может превышать 48 Кбайт. Если все данные не поместились в буфер предварительного чтения, их необходимо дочитать функцией ReadClient. При этом следует использовать следующий алгоритм.
Прежде всего следует сравнить размер предварительно считанных данных с полным размером данных, которые нужно считать (этот размер передается в поле cbTotalBytes структуры EXTENSION_CONTROL_BLOCK).
Если все данные уже были считаны предварительно, функцию ReadClient вызывать не нужно. В том случае, когда значение, передаваемое через поле cbTotalBytes, превышает значение cbAvailable, вы должны воспользоваться функцией ReadClient для того чтобы прочесть (cbTotalBytes - cbAvailable) байт данных от пользователя.
Заметим, что функция ReadClient не будет читать заново данные, предварительно прочитанные в буфер lpbData. Она прочитает только оставшиеся данные, причем не исключено, что для чтения оставшихся данных эту функцию придется вызывать в цикле несколько раз. Причина этого заключается в том, что функция ReadClient не обязательно сможет прочитать все оставшиеся данные за один прием.
После успешного завершения чтения функция ReadClient записывает размер прочитанного блока данных в переменную, адрес которой передается через параметр lpdwSize. Если при первом вызове значение этого размера меньше величины (cbTotalBytes - cbAvailable), вы должны вызвать функцию ReadClient еще один или несколько раз для чтения оставшихся данных.
Пример использования функции ReadClient вы найдете в разделе “Приложение FILEUPL”. Там мы привели исходные тексты расширения ISAPI, позволяющее использовать сервер WWW довольно необычным способом - для получения файлов от удаленных пользователей и записи их на диск сервера. Так как размеры передаваемых файлов могут быть значительны, приложение FILEUPL вызывает функцию ReadClient в цикле.
Посылка данных расширением ISAPI
Вместо того чтобы записывать выходные данные в стандартный поток вывода STDOUT, как это делает программа CGI, расширение ISAPI пользуется для посылки данных функциями WriteCilent и ServerSupportFunction, указатели на которые передаются расширению ISAPI через структуру типа EXTENSION_CONTROL_BLOCK.
Функция WriteCilent
Прототип функции WriteClient, взятый из определения структуры EXTENSION_CONTROL_BLOCK, приведен ниже:
BOOL (WINAPI * WriteClient)(HCONN ConnID,
LPVOID Buffer, LPDWORD lpdwBytes, DWORD dwReserved);
Через параметр hConn функции WriteClient передается идентификатор канала, полученный через поле ConnID структуры EXTENSION_CONTROL_BLOCK.
Функция WriteClient посылает удаленному пользователю данные из буфера Buffer, причем размер передаваемого блока данных должен быть записан в переменную типа DWORD, адрес которой передается через параметр lpdwBytes. Параметр dwReserved зарезервирован для дальнейших расширений возможностей функции.
В случае успеха функция возвращает значение TRUE, а при ошибке - значение FALSE. Код ошибки можно получить при помощи функции GetLastError.
Заметим, что после посылки данных функция WriteClient записывает в переменную, адрес которой был ей передан через параметр lpdwBytes, количество успешно переданных байт данных. В отличие от функции ReadClient, функция WriteClient посылает данные за один прием, поэтому нет необходимости вызывать ее в цикле. Если же эта функция смогла передать только часть данных, то это означает, что произошла ошибка.
Функция ServerSupportFunction
Прототип функции ServerSupportFunction, определенный в структуре типа EXTENSION_CONTROL_BLOCK, приведен ниже:
BOOL (WINAPI * ServerSupportFunction)(HCONN hConn,
DWORD dwHSERRequest, LPVOID lpvBuffer,
LPDWORD lpdwSize, LPDWORD lpdwDataType);
Через параметр hConn функции ServerSupportFunction передается идентификатор канала, полученный через поле ConnID структуры EXTENSION_CONTROL_BLOCK.
С помощью параметра dwHSERRequest вы можете задать один из нескольких кодов запроса, определяющих операцию, выполняемую этой функцией.
Через параметр lpvBuffer передается размер буфера, который используется при выполнении операции. Размер этого буфера должен быть записан в переменной типа DWORD, адрес которой передается через параметр lpdwSize. После выполнения операции передачи данных в эту переменную будет записан размер успешно переданного блока данных.
Параметр lpdwDataType используется для указания дополнительной строки заголовка или дополнительных данных, которые будут добавлены к заголовку, передаваемому удаленному пользователю. Если для параметра lpdwDataType указать значение NULL (что допустимо), к заголовку будут добавлены символы конца строки “\r\n”.
Какие операции можно выполнять при помощи функции ServerSupportFunction?
Ниже мы привели список возможных значений параметра dwHSERRequest, определяющего код выполняемой операции:
·       HSE_REQ_SEND_RESPONSE_HEADER
Эта операция предназначена для посылки удаленному пользователю стандартного заголовка HTTP. При необходимости добавления других заголовков следует воспользоваться параметром lpdwDataType. В качестве дополнительного заголовка вы можете указать любую строку, закрытую символами конца строки “\r\n” и двоичным нулем.
Если ваше расширение ISAPI динамически формирует документ HTML и посылает его пользователю, то ей не нужно вызывать функцию WriteClient. Все необходимые для этого действия можно сделать при помощи одной только функции ServerSupportFunction. Ниже мы показали фрагмент кода, в котором эта функция используется для посылки документа HTML, подготовленного заранее в буфере szBuff:
CHAR szBuff[4096];
wsprintf(szBuff,
"Content-Type: text/html\r\n\r\n"
"<HTML><HEAD><TITLE>Simple ISAPI Extension</TITLE></HEAD>\n"
"<BODY BGCOLOR=#FFFFFF><H1>Hello from ISAPI Extension!</H1>\n");
strcat(szBuff, "<H1>Заголовок документа</H1>");
strcat(szBuff, "<HR>");
strcat(szBuff, "</BODY></HTML>");
lpECB->ServerSupportFunction(lpECB->ConnID,
HSE_REQ_SEND_RESPONSE_HEADER, NULL, NULL, (LPDWORD)szBuff);
Заметим, однако, что функция ServerSupportFunction не позволяет посылать двоичные данные. Для посылки двоичных данных вы обязательно должны использовать функцию WriteClient.
·       HSE_REQ_SEND_URL
Используя операцию HSE_REQ_SEND_URL, расширение ISAPI может послать удаленному пользователю данные, заданные адресом URL, как будто бы эти данные были запрошены непосредственно пользователем по этому адресу URL. Такая возможность удобна для посылки либо динамически созданных данных, либо для посылки предварительно подготовленных данных.
Адрес URL должен быть указан в виде текстовой строки, закрытой двоичным нулем, через параметр lpvBuffer. Размер строки вы должны указать в параметре lpdwSize. Что же касается параметра lpdwDataType, то при выполнении данной операции этот параметр игнорируется.
·       HSE_REQ_SEND_URL_REDIRECT_RESP
Посылка сообщения с номером 302 (URL Redirect). Адрес URL указывается аналогично тому, как это делается при выполнении операции HSE_REQ_SEND_URL.
·       HSE_REQ_MAP_URL_TO_PATH
Преобразование логического адреса URL в физический. Адрес логического пути передается через параметр lpvBuffer. По этому же адресу записывается результат преобразования. Размер буфера при вызове функции задается как обычно с помощью параметра lpdwSize. После преобразования переменная типа DWORD, адрес которой указан параметром lpdwSize, будет содержать длину строки результата преобразования.
·       HSE_REQ_DONE_WITH_SESSION
В том случае, когда расширение ISAPI оставляет канал открытым для выполнения длительной обработки данных, с помощью этой команды можно сообщить серверу о завершении обработки. Все параметры функции ServerSupportFunction при указании этой команды игнорируются.
46 поиск информации в сети интернет
Сеть Интернет растет очень быстрыми темпами, поэтому найти нужную информацию среди сотен миллиардов Web-страниц и сотен миллионов файлов становится все сложнее. Для поиска информации используются специальные поисковые системы, которые содержат постоянно обновляемую информацию о местонахождении Web-страниц и файлов на сотнях миллионов серверов Интернета.
Поисковые системы содержат тематически сгруппированную информацию об информационных ресурсах Всемирной паутины в базах данных. Специальные программы-роботы периодически "обходят" Web-серверы Интернета, читают все встречающиеся документы, выделяют в них ключевые слова и заносят в базу данных Интернет-адреса документов.
Большинство поисковых систем разрешают автору Web-сайта самому внести информацию в базу данных, заполнив регистрационную анкету. В процессе заполнения анкеты разработчик сайта вносит адрес сайта, его название, краткое описание содержания сайта, а также ключевые слова, по которым легче всего будет найти сайт.
Поиск по ключевым словам. Поиск документа в базе данных поисковой системы осуществляется с помощью введения запросов в поле поиска.
Запрос должен содержать одно или несколько ключевых слов, которые являются главными для этого документа. Например, для поиска самих систем поиска в Интернете можно в поле поиска ввести ключевые слова "российская система поиска информации Интернет" (рис. 6.21).

Рис. 6.21. Поиск по ключевым словам в системе Google

Через некоторое время после отправки запроса поисковая система вернет список Интернет-адресов документов, в которых были найдены заданные ключевые слова. Для просмотра этого документа в браузере достаточно активизировать указывающую на него ссылку (рис. 6.22).

Рис. 6.22. Результат поиска по ключевым словам

Если ключевые слова были выбраны неудачно, то список адресов документов может быть слишком большим (может содержать десятки и даже сотни тысяч ссылок). Для того чтобы уменьшить список, можно в поле поиска ввести дополнительные ключевые слова или воспользоваться каталогом поисковой системы.
Одной из наиболее полных и мощных поисковых систем является Google (www.google.ru), в базе данных которой хранятся 8 миллиардов Web-страниц и каждый месяц программы-роботы заносят в нее 5 миллионов новых страниц. В Рунете (российской части Интернета) обширные базы данных, содержащие по 200 миллионов документов, имеют поисковые системы Яndех (www.yandex.ru) и Rambler (www.rambler.ru).
Поиск в иерархической системе каталогов. В базе данных поисковой системы Web-сайты группируются в иерархические тематические каталоги, которые являются аналогами тематического каталога в библиотеке.
Тематические разделы верхнего уровня, например: Интернет, Компьютеры, Наука и образование и т. д., содержат вложенные каталоги. Например, каталог Интернет может содержать подкаталоги Поиск, Почта и др. (рис. 6.23).

Рис. 6.23. Тематические каталоги поисковой системы Апорт

Поиск информации в каталоге сводится к выбору определенного каталога, после чего пользователю будет представлен список ссылок на Интернет-адреса наиболее посещаемых и содержательных Web-сайтов. Каждая ссылка обычно аннотирована, т. е. содержит короткий комментарий к содержанию документа.
Наиболее полный многоуровневый иерархический тематический каталог русскоязычных Интернет-ресурсов имеет поисковая система Апорт (www.aport.ru). Каталог содержит подробную аннотацию содержания Web-сайтов и указание на их географическое положение.
Поиск файлов. Для поиска файлов на серверах файловых архивов существуют специализированные поисковые системы, в том числе поисковая система FileSearch (www.filesearch.ru). Для поиска файла необходимо ввести имя файла в поле поиска, и поисковая система выдаст Интернет-адреса серверов файловых архивов, на которых хранится файл с заданным именем.
Поиск информации в русскоязычной части Интернета с помощью наиболее поисковых систем: Google, Rambler, Апорт, Япс1ех и файловой поисковой системы Research можно производить с использованием интегрированной поисковой системы Gogle.ru (рис. 6.24). Для этого достаточно ввести ключевые слова в строку поиска, с помощью переключателей установить тип необходимой информации и щелкнуть по кнопке с названием поисковой системы Gogle.ru (рис. 6.24). Для этого достаточно ввести ключевые слова в строку поиска, с помощью переключателей установить тип необходимой информации и щелкнуть по кнопке с названием поисковой системы.

Рис. 6.24. Интегрированная поисковая система Gogle.ru

Способы поиска в Интернете
Три способа поиска в Интернете
Интернет в целом и Всемирная паутина, в частности, предоставляют абоненту доступ к тысячам серверов и миллионам Web-страниц, на которых хранится невообразимый объем информации. Как не потеряться в этом "информационном океане"? Для этого необходимо научиться искать и находить нужную информацию в сети.
Как уже было сказано, существуют три основных способа поиска информации в Интернете.
1. Указание адреса страницы. Это самый быстрый способ поиска, но его можно использовать только в том случае, если точно известен адрес документа.
2. Передвижение по гиперссылкам. Это наименее удобный способ, так как с его помошыо можно искать документы, только близкие по смыслу текущему документу. Если текущий документ посвящен, например, музыке, то, используя гиперссылки этого документа, вряд ли можно будет попасть на сайт, посвященный спорту.
3. Обращение к поисковому серверу (поисковой системе). Использование поисковых серверов - наиболее удобный способ поиска информации. В настоящее время в русскоязычной части Интернета популярны следующие поисковые серверы:
Yandex;Rambler;Апорт.
Существуют и другие поисковые системы. Например, эффективная система поиска реализована на сервере почтовой службы mail.ru.
Поисковые серверы
Наиболее доступным и удобным способом поиска информации во Всемирной паутине является использование поисковых систем. При этом поиск информации можно осуществлять по каталогам, а также по набору ключевых слов, характеризующих отыскиваемый текстовый документ.
Рассмотрим использование поисковых серверов более подробно. Поисковый сервер содержит большое количество ссылок на самые различные документы, и все эти ссылки систематизированы в тематические каталоги. Например: спорт, кино, автомобили, игры, наука и др. Причем эти ссылки устанавливаются сервером самостоятельно, в автоматическом режиме путем регулярного просмотра всех появляющихся во Всемирной паутине Web-страниц. Кроме того, поисковые серверы предоставляют пользователю возможность поиска информации по ключевым словам. После ввода ключевых слов поисковый сервер начинает просматривать документы на других Web-серверах и выводить на экран ссылки на те документы, в которых встретились указанные слова. Обычно результаты поиска сортируются по убыванию специального рейтинга документов, который показывает, насколько полно заданный документ отвечает условиям поиска или насколько часто он запрашивается в сети.
Язык запросов поисковой системы
Группа ключевых слов, сформированная по определенным правилам - с помощью языка запросов, называется запросом к поисковому серверу. Языки запросов к разным поисковым серверам очень похожи. Подробнее об этом можно узнать, посетив раздел "Помощь" нужного поискового сервера. Рассмотрим правила формирования запросов на примере поисковой системы Яndex.
Синтаксис оператора Что означает оператор Пример запроса
пробел или & Логическое И (в пределах предложения) лечебная физкультура
&& Логическое И (в пределах документа) рецепты && (плавленый сыр)
| Логическое ИЛИ фото | фотография | снимок | фотоизображение
+ Обязательное наличие слова в найденном документе +быть или +не быть
( ) Группирование слов (технология | изготовление) (сыра | творога)
~ Бинарный оператор И НЕ (в пределах предложения) банки ~ закон
~~или_ Бинарный оператор И НЕ (в пределах документа) путеводитель по Парижу ~~ (агентство | тур)
/(n m) Расстояние в словах (минус (-) - назад, плюс (+) - вперед) поставщики /2 кофе музыкальное /(-2 4) образование вакансии ~ /+1 студентов
" " Поиск фразы "красная шапочка" Эквивалентно: красная /+1 шапочка
&&/(n m) Расстояние в предложениях (минус (-) - назад, плюс (+) - вперед) банк && /1 налоги
Чтобы получить лучшие результаты поиска, необходимо запомнить несколько простых правил:
1. Не искать информацию только по одному ключевому слову.
2. Лучше не вводить ключевые слова с прописной буквы, так как это может привести к тому, что не будут найдены те же слова, написанные со строчной буквы.
3. Если в итоге поиска вы не получили никаких результатов, проверьте, нет ли в ключевых словах орфографических ошибок.
Современные поисковые системы предоставляют возможность подключения к сформированному запросу семантического анализатора. С его помощью можно, введя какое-либо слово, выбрать документы, в которых встречаются производные от этого слова в различных падежах, временах и пр.
48 защита информации в компьютерных сетях
Объекты защиты информации в сетиК объектам защиты информации в компьютерных сетях, подвергающихся наиболее интенсивному воздействию со стороны злоумышленников, относятся:сервера;рабочие станции;каналы связи;узлы коммутации сетей.Основными задачами серверов являются хранение и предоставление доступа к информации и некоторые виды сервисов. Следовательно, и все возможные цели злоумышленников можно классифицировать какполучение доступа к информации,получение несанкционированного доступа к услугам,попытка вывода из рабочего режима определенного класса услуг,попытка изменения информации или услуг, как вспомогательный этап какой-либо более крупной атаки.Попытки получения доступа к информации, находящейся на сервере, в принципе ничем не отличаются от подобных попыток для рабочих станций, и мы рассмотрим их позднее. Проблема получения несанкционированного доступа к услугам принимает чрезвычайно разнообразные формы и основывается в основном на ошибках или недокументированных возможностях самого программного обеспечения, предоставляющего подобные услуги.Основной целью атаки рабочей станции является, конечно, получение данных, обрабатываемых, либо локально хранимых на ней. А основным средством подобных атак до сих пор остаются «троянские» программы. Эти программы по своей структуре ничем не отличаются от компьютерных вирусов, однако при попадании на ЭВМ стараются вести себя как можно незаметнее. При этом они позволяют любому постороннему лицу, знающему протокол работы с данной троянской программой, производить удаленно с ЭВМ любые действия. То есть основной целью работы подобных программ является разрушение системы сетевой защиты станции изнутри – пробивание в ней огромной бреши.Для борьбы с троянскими программами используется как обычное антивирусное ПО, так и несколько специфичных методов, ориентированных исключительно на них. В отношении первого метода как и с компьютерными вирусами необходимо помнить, что антивирусное ПО обнаруживает огромное количество вирусов, но только таких, которые широко разошлись по стране и имели многочисленные преценденты заражения. В тех же случаях, когда вирус или троянская программа пишется с целью получения доступа именно к Вашей ЭВМ или корпоративной сети, то она практически с вероятностью 90% не будет обнаружена стандартным антивирусным ПО.Каналы связиЕстественно, основным видом атак на среду передачи информации является ее прослушивание. В отношении возможности прослушивания все линии связи делятся на:широковещательные с неограниченным доступомшироковещательные с ограниченным доступомканалы «точка-точка»Узлы коммутации сетейУзлы коммутации сетей представляют интерес для злоумышленников1) как инструмент маршрутизации сетевого трафика,2) как необходимый компонент работоспособности сети.Защита информации в сети InternetНаибольший риск подвергнуться атаке со стороны внешних злоумышленников возникает в случае, если ваш компьютер, или локальная, или корпоративная сеть предприятия подключена в публичную глобальную сеть. Самой большой публичной глобальной сетью является Internet. Многие корпоративные сети используют каналы Internet для объединения удаленных частей сети. Широкое распространение получили корпоративные intranet–сети, основанные на использование технологий Internet.От злоумышленников страдают в основном информационные ресурсы предприятий, которые имеют постоянные соединения с Интернет и используют постоянные IP-адреса, по которым можно атаковать внутренние корпоративные сайты. Пользователи же Интернет, соединяющиеся с Интернет по модему на небольшое время и использующие временный IP-адрес, предоставляемый провайдером на период сессии, могут пострадать только от почтовых вирусов или от «дырок» в системе мгновенных сообщений, такой как ICQ.С этой точки зрения представляют интерес механизмы защиты, используемые в Internet.
49 безопасность сетей
Обеспечение безопасности сети требует постоянной работы и пристального внимания к деталям. Пока "в Багдаде все спокойно", эта работа заключается в предсказании возможных действий злоумышленников, планировании мер защиты и постоянном обучении пользователей. Если же вторжение состоялось, то администратор безопасности должен обнаружить брешь в системе защиты, ее причину и метод вторжения
Формируя политику обеспечения безопасности, администратор прежде всего проводит инвентаризацию ресурсов, защита которых планируется; идентифицирует пользователей, которым требуется доступ к каждому из этих ресурсов, и выясняет наиболее вероятные источники опасности для каждого из этих ресурсов. Имея эту информацию, можно приступать к построению политики обеспечения безопасности, которую пользователи будут обязаны выполнять.
Политика обеспечения безопасности - это не обычные правила, которые и так всем понятны. Она должна быть представлена в форме серьезного печатного документа. А чтобы постоянно напоминать пользователям о важности обеспечения безопасности, можно разослать копии этого документа по всему офису, чтобы эти правила всегда были перед глазами сотрудников.
Хорошая политика обеспечения безопасности включает несколько элементов, в том числе следующие:
Оценка риска. Что именно мы защищаем и от кого? Нужно идентифицировать ценности, находящиеся в сети, и возможные источники проблем.
Ответственность. Необходимо указать ответственных за принятие тех или иных мер по обеспечению безопасности, начиная от утверждения новых учетных записей и заканчивая расследованием нарушений.
Правила использования сетевых ресурсов. В политике должно быть прямо сказано, что пользователи не имеют права употреблять информацию не по назначению, использовать сеть в личных целях, а также намеренно причинять ущерб сети или размещенной в ней информации.
Юридические аспекты. Необходимо проконсультироваться с юристом и выяснить все вопросы, которые могут иметь отношение к хранящейся или генерируемой в сети информации, и включить эти сведения в документы по обеспечению безопасности.
Процедуры по восстановлению системы защиты. Следует указать, что должно быть сделано в случае нарушения системы защиты и какие действия будут предприняты против тех, кто стал причиной такого нарушения.
Классификация вторжений
Список ресурсов, которые обычно являются целями вторжений, можно найти в документе RFC 1244.
Все вторжения можно разделить на пять классов, в зависимости от того что является их целью.
Аппаратные средства - рабочие станции и серверы, принтеры, дисковые накопители и сетевые кабели, а также такие межсетевые устройства, как мосты, маршрутизаторы и коммутаторы.
Программное обеспечение. Любое программное обеспечение, работающее на любом компьютере в сети, является потенциальной "дверью" для злоумышленника. Это могут быть программы, купленные у внешних разработчиков и программное обеспечение для внутреннего использования, созданное собственным отделом программистов. Именно поэтому операционные системы нуждаются в регулярной установке патчей.
Информация. Наиболее значительной ценностью, конечно же, являются данные, которые создаются или используются в сети. Программное обеспечение и операционные системы можно переустановить - а если подвергнутся разглашению важные данные, такие как списки клиентов, сведения о продажах или корпоративные секреты, то ущерб бизнесу может быть значительным.
Люди. В "группу риска" входят все пользователи, имеющие доступ к сети или к любому подключенному к ней устройству.
Документы. Об этом очень важном для хакеров ресурсе часто забывают. Пароли записываются на бумажках; отчеты, содержащие конфиденциальную информацию, распечатываются, а потом все это часто выбрасывается в мусорную корзину. Лучше измельчить эти бумаги на мелкие кусочки или сделать их нечитаемыми другим способом - и только потом выбросить.
Одной из величайших угроз компьютерной безопасности являются заметки-"липучки". Вспомните, сколько раз вам приходилось видеть такие липучки с именем пользователя и паролем, приклеенные сбоку монитора?
Хорошая политика обеспечения безопасности, понятная всем пользователям,- это нечто гораздо большее, чем просто средство предотвращения некоторых возможных проблем. Хорошей практикой является процедура регулярного повторного ознакомления пользователей с этой политикой, наравне с инструктажем по техника безопасности на рабочем месте. Это не должно быть пустой формальностью. Важно, чтобы пользователи сознавали, какую ответственность они берут на себя одновременно с правом доступа к корпоративной компьютерной сети.
Физическая безопасность
Предотвращение неавторизованного доступа к сетевым ресурсам означает, прежде всего, невозможность физического доступа к компонентам сети - рабочим станциям, серверам, сетевым кабелям и устройствам, и т.п. Когда сетевое соединение выходит за пределы вашей зоны влияния, например в точке подключения к внешнему провайдеру интернета, то контроль за физическими аспектами сети, разумеется, теряется - и остается полагаться на другие методы, такие как шифрование и туннелирование. Но оборудование в помещении компании должно находиться под пристальным наблюдением.
Как бы глупо это ни звучало, но от несанкционированного доступа часто спасает простой дверной замок. Серверы, на которых хранятся важные или уязвимые данные, не должны стоять открыто на столе или в незапертой комнате, куда может зайти кто угодно. Аналогичным образом должны защищаться маршрутизаторы, концентраторы, коммутаторы и другие устройства. Комнаты с компьютерами должны закрываться на замок или находиться под круглосуточным наблюдением. Если кто-то из сотрудников компании работает круглосуточно, то это комнату закрывать не обязательно - но только в том случае, если персонал не дежурит по одному. В идеале доступ в подобные помещения должен контролироваться, например, путем регистрации в журнале.
Резервные носители, такие как ленты или перезаписываемые компакт-диски, должны быть защищены так же, как и исходные данные. Недопустимо хранить резервные копии на сервере или рабочей станции, оставлять картриджи и CD на столе или в незапертом ящике.
Утилизация старых компьютеров
При обновлении сети и установке новых рабочих станций и серверов старое, ненужное оборудование часто передают сотрудникам компании или другим организациям, например школам. В политике обеспечения безопасности должно быть правило, согласно которому со всех жестких дисков, подлежащих списанию, должны быть удалены данные, а при необходимости - заново установлена легальная копия операционной системы. Там же должна быть описана процедура утилизации использованных дискет, компакт-дисков и картриджей с резервными копиями. При малейшем подозрении, что на них могла сохраниться важная информация, которую можно восстановить, лучше сначала разбить эти носители и только потом выбросить. Хорошим средством уничтожения информации с таких носителей является магнитное устройство "тотального" стирания.
Программный доступ
Кроме физического, следует ограничить и программный доступ к сети. И все равно, независимо от того насколько хорошо налажен контроль доступа, всегда найдется человек, который нарушит эту защиту. Поэтому необходимо иметь возможность проследить сетевые события и определить по ним, не пытался ли кто-то вторгнуться в сеть и насколько это удалось.
Существует несколько типовых механизмов управления доступом к сети:
пользовательские учетные записи и пароли;
физические идентификаторы;
защита ресурсов.
Во многих операционных системах важной частью этой схемы является концепция владения ресурсами. Например, в OpenVMS и Windows 2000/Server 2003 отслеживаются пользователи, создающие ресурсы (такие как файлы). Владельцы таких ресурсов имеют право изменять режим защиты файла и предоставлять другим пользователям полномочия, необходимые для работы с этим файлом. То же самое, хотя и в меньшей степени, можно сказать об операционных системах Unix/Linux.7
Идентификация пользователей
Если в сети не хранятся сверхсекретные данные, то для доступа к ресурсам обычно достаточно логина и пароля. Управление такими системами обычно не представляет сложностей. В Windows 2000/XP и Server 2003 можно создавать обособленные защищенные зоны управления - домены. Сетевой администратор может предоставить пользователям домена права доступа к ресурсам любого компьютера, будь то сервер или рабочая станция. Кроме того, при сотрудничестве администраторов между доменами могут быть установлены доверительные отношения, в результате чего пользователи получат доступ к сетевым ресурсам друг