Автор работы: Пользователь скрыл имя, 14 Декабря 2014 в 00:10, курсовая работа
Операционная система в наибольшей степени определяет облик всей вычислительной системы в целом. Несмотря на это, пользователи, активно использующие вычислительную технику, зачастую испытывают затруднения при попытке дать определение операционной системе.
Может показаться странным, что сервер в соответствии с микроядерной концепцией не реализован как серверный процесс. Было бы логично ожидать, что сетевой сервер будет функционировать как защищенная подсистема - процесс, чьи нити ожидают поступления запросов по сети, выполняют их, а затем возвращают результаты по сети. Этот подход, как наиболее естественный, был тщательно рассмотрен при проектировании Windows NT, однако, учитывая опыт построения сетей VAX/VMS и опыт использования RPC, было решено выполнить сервер как драйвер файловой системы. Хотя сервер и не является драйвером в обычном смысле, и он не управляет файловой системой на самом деле, использование модели драйвера обеспечивает некоторые преимущества.
Главное из них состоит в том, что драйвер реализован в среде NT executive и может вызывать кэш-менеджер NT непосредственно, что оптимизирует передачу данных. Например, когда сервер получает запрос на чтение большого количества данных, он вызывает кэш-менеджер для определения места расположения этих данных в кэше (или для загрузки этих данных в кэш, если их там нет) и для фиксации данных в памяти. Затем сервер передает данные непосредственно из кэша в сеть, минуя доступ к диску. Аналогично, при запросе на запись данных сервер вызывает кэш-менеджер для резервирования места для поступающих данных. Затем сервер пишет данные непосредственно в кэш. Записывая данные в кэш, сервер возвращает управление клиенту гораздо быстрее; затем кэш-менеджер записывает данные на диск в фоновом режиме (используя страничные средства менеджера виртуальной памяти).
Будучи драйвером файловой системы, сервер несколько более гибок по сравнению с его реализацией в виде процесса. Например, он может регистрировать функции завершения ввода-вывода, что позволяет ему получать управление немедленно после завершения работы драйверов нижнего уровня. Хотя сервер Windows NT реализован как драйвер файловой системы, другие серверы могут быть реализованы и как драйверы, и как серверные процессы.
Асинхронные вызовы обрабатываются сервером аналогично, с использованием пула рабочих нитей.
И редиректоры, и серверы, и транспортные драйверы могут быть в любое время загружены и выгружены.
Открытая архитектура сетевых средств Windows NT обеспечивает работу своих рабочих станций (и серверов) в гетерогенных сетях не только путем предоставления возможности динамически загружать и выгружать сетевые средства, но и путем непосредственного переключения с программных сетевых средств, ориентированных на взаимодействие с одним типом сетей, на программные средства для другого типа сетей в ходе работы системы. Windows NT поддерживает переключение программных средств на трех уровнях:
Для доступа к другим типам сетей в Windows NT, помимо встроенного, могут загружаться дополнительные редиректоры. Специальные компоненты Windows NT решают, какой редиректор должен быть вызван для обслуживания запроса на удаленный ввод-вывод. За последние десятилетия получили распространение различные протоколы передачи информации по сети. И хотя Windows NT поддерживает не все эти протоколы, она, по крайней мере, разрешает включать их поддержку.
После того, как сетевой запрос достигает редиректора, он должен быть передан в сеть. В традиционной системе каждый редиректор жестко связан с определенным транспортным протоколом. В Windows NT поставлена задача гибкого подключения того или иного транспортного протокола, в зависимости от типа транспорта, используемого в другой сети. Для этого во всех редиректорах нижний уровень должен быть написан в соответствии с определенными соглашениями, которые и определяют единый программный интерфейс, называемый интерфейсом транспортных драйверов (TDI).
TDI позволяет
редиректорам оставаться
Сетевые адаптеры поставляются вместе с сетевыми драйверами, которые раньше часто были рассчитаны на взаимодействие с определенным типом транспортного протокола. Так как Windows NT позволяет загружать драйверы различных транспортных протоколов, то производители сетевых адаптеров, использующие такой подход, должны были писать различные варианты одного и того же драйвера, рассчитанные на связь с разными протоколами транспортного уровня.
Чтобы помочь производителям избежать этого, Windows NT обеспечивает интерфейс и программную среду, называемые "спецификация интерфейса сетевого драйвера" (NDIS), которые экранируют сетевые драйверы от деталей различных транспортных протоколов. Самый верхний уровень драйвера сетевого адаптера должен быть написан в соответствии с рекомендациями NDIS. В этом случае пользователь может работать с сетью TCP/IP и сетью NetBEUI (или DECnet, NetWare, VINES и т.п.), используя один сетевой адаптер и один сетевой драйвер. Среда NDIS использовалась в сетях LAN Manager, но для Windows NT она была обновлена.
Через свою нижнюю границу драйвер сетевого адаптера обычно взаимодействует непосредственно с адаптером или адаптерами, которые он обслуживает. Драйвер сетевого адаптера, реализованный для среды NDIS, управляет адаптером не непосредственно, а использует для этого функции, предоставляемые NDIS (например, для запуска ввода-вывода или обработки прерываний). Таким образом, среда NDIS образует некую оболочку, которая позволяет достаточно просто переносить драйверы сетевых адаптеров из одной ОС в другую. NDIS позволяет сетевым драйверам не содержать встроенных знаний о процессоре или операционной системе, на которых он работает.
Совместимость сетевых операционных систем предполагает использование одинакового стека коммуникационных протоколов, в том числе и верхнего прикладного уровня. Протоколы верхнего уровня (NCP, SMB, NFS, FTP, telnet) включают две части - клиентскую и серверную. При взаимодействии двух компьютеров на каждой стороне могут присутствовать как обе части прикладного протокола, так и по одной его части, в зависимости от этого образуется или одна, или две пары "клиент-сервер".
Для клиентской части протокола верхнего уровня, реализованного в виде модуля операционной системы, используются разные названия - редиректор (redirector), инициатор запросов или запросчик (requester). Эти компоненты получают запросы от приложений на доступ к удаленным ресурсам, расположенным на серверах, и ведут диалог с сервером в соответствии с каким-либо протоколом прикладного уровня. Совокупность функций, которая может использовать приложение для обращения к редиректору, называется прикладным интерфейсом (API) редиректора.
Существующая версия Windows NT 3.51 имеет встроенную поддержку стека протоколов Novell, а именно протоколов IPX/SPX и клиентской части NCP. При разработке первой версии Windows NT 3.1 между Microsoft и Novell существовало соглашение о том, что редиректор, реализующий клиентскую часть протокола NCP, будет написан силами сотрудников Novell и передан Microsoft в течение 60 дней после выпуска коммерческой версии Windows NT 3.1. Однако первая версия редиректора от Novell появилась только спустя четыре месяца и обладала существенными ограничениями: не поддерживался полностью API редиректора NetWare, в частности, поддерживались только 32-х разрядные вызовы, что означало невозможность работы старых 16 разрядных приложений клиента NetWare.
Через некоторое время Microsoft разработала свою собственную версию редиректора для NetWare, проведя большую работу по освоению NCP. Этот вариант оказался гораздо лучше, однако и он имеет недостатки: в нем отсутствует поддержка входных сценариев NetWare и службы каталогов NetWare Directory Services. Отсутствие поддержки входных сценариев означает, что администратору сети будет сложно автоматизировать создание индивидуальной операционной среды NetWare для пользователей, использующих Windows NT в качестве клиентской машины серверов NetWare.
Организация, использующая NetWare, может добавить Windows NT в качестве:
Сеть с файловыми серверами различных типов (NetWare и Windows NT) порождает сложные технические проблемы. Даже если серверы используют одинаковые транспортные протоколы, в данном случае протокол IPX (в реализации Microsoft имеющий название NWLink), клиентским рабочим станциям все равно придется загружать два разных инициатора запросов. У клиента, работающего в среде MS-DOS, для этого может просто не хватить памяти.
Для смягчения перехода от NetWare к Windows NT Server разработано несколько инструментальных программ, в том числе утилита Migration Tool, которая включена в комплект поставки Windows NT Server. Эта утилита переносит учетную информацию пользователей (имена пользователей, ограничения и права доступа) и данные с одного или нескольких файловых серверов NetWare на сервер Windows NT. Migration Tool подбирает наилучшее соответствие между возможностями NetWare и возможностями Windows NT. Однако имеется ряд существенных различий в том, как обрабатываются такие вещи, как ограничения. В NetWare подобная информация обрабатывается для каждого пользователя в отдельности, а в Windows NT она общая для целого сервера.
Компания Beame and Whiteside Software создала первый NFS сервер для Windows NT, а также продукт под названием BW-Multiconnect, который превращает сервер Windows NT в сервер NetWare. Системы Windows NT с установленным продуктом BW-Multiconnect посылают широковещательные сообщения по протоколу SAP (протокол объявления сервисов и серверов по сети - Service Advertising Protocol, с помощью которого клиенты NetWare узнают о наличии в сети серверов и о тех услугах, которые они предоставляют). BW-Multiconnect должен облегчить сосуществование и миграцию от NetWare к Windows NT. Хотя он и может работать как единственный NCP-сервер сети, он не предназначен для этой роли, так как предоставляет лишь ограниченный набор утилит под Windows и DOS, и не обрабатывает входных командных файлов NetWare. Но когда в сети есть "настоящий" файловый сервер NetWare, то пользователи могут войти в этот сервер, выполнить системный входной командный файл, а затем подсоединиться к серверу Windows NT. Этот продукт превращает в сервер NetWare как Windows NT Server, так и Windows NT Workstation.
Microsoft ведет работу над созданием своих собственных файл- и принт-серверов NetWare для Windows NT. Кроме этого, скоро должен появиться редиректор NetWare для Windows NT, поддерживающий NDS.
Рассмотренные способы организации взаимодействия сетей построены на использовании принципа мультиплексирования протоколов. Другим подходом является использование шлюза. Шлюз действует как транслятор, что позволяет получать доступ к файлам и ресурсам печати на файловом сервере NetWare, не пользуясь ничем, кроме загруженного редиректора Windows NT. Шлюз преобразовывает SMB-сообщения, посланные каким-либо Windows NT-клиентом, в NCP-сообщения, которые посылаются на серверы NetWare. В этом случае имеется экономия памяти на клиентских машинах, так как не требуется загружать дополнительные редиректоры.
Вариант шлюза подходит только для приложений, использующих для запросов к серверу NetWare только стандартный API, а при использовании специфического для NetWare API нельзя обойтись без установки дополнительного редиректора.
Если NetWare-шлюз загружен, Windows NT Server может подсоединиться к одному или нескольким файловым серверам NetWare и подключиться к любому дисковому тому, очереди на печать или каталогу. После того, как сервер подключился к ресурсам, их можно начинать использовать совместно с другими пользователями через File Manager или Print manager, как если бы они были локальными ресурсами. То есть пользователи, вошедшие в домен, на сервере которого установлен шлюз к NetWare, получают доступ к серверам NetWare.
Трансляция протоколов в шлюзе замедляет доступ к серверу NetWare по сравнению с доступом через редиректор клиента. При тестировании замедление в малозагруженном шлюзе составило от 10% до 15%.
Имя пользователя, используемое шлюзом для входа в сервер NetWare, должно входить в группу NTGateway на сервере Windows NT. Разрешение на доступ к ресурсам NetWare предоставляется пользователям сервером Windows NT точно так же, как если бы это были его локальные ресурсы.
Аналитики, занимающиеся 32-х битными операционными системами для персональных компьютеров, всегда концентрируют свое внимание на битве между Microsoft Windows и IBM OS/2, предполагая, что Microsoft имеет преимущество. Но не все согласны с такой точкой зрения. OS/2 v.2.0 была первой доступной и работающей 32-х битной операционной системой для персональных компьютеров. И она первой начала очередной круг состязаний - версия OS/2 Warp, предназначенная для клиентских машин сетей клиент-сервер и одноранговых сетей, появилась на рынке раньше Windows 95, позиционированной аналогичным образом. OS/2 Warp была также первой системой, включившей набор средств поддержки Internet, а также средств объектной ориентации.
Когда бета-тестеры получили Chicago, первую публичную версию Windows 95, те, кто уже использовал OS/2, отметили чрезвычайную схожесть двух систем. Например, обе начинают работу с показа красивой заставки, а затем приглашают пользователя к работе за вместительным рабочим столом; обе системы рассматривают иконки и программы как объекты; обе используют правую кнопку мыши для управления поведением объектов; обе используют более 20 дискет для инсталляции. Пользовательский интерфейс обеих систем имеет одинаковый уровень изощренности, требования к аппаратным ресурсам компьютера похожи, и они обе основаны на использовании одинакового набора лежащих в основе системы технологий. Эти технологии включают многозадачность и многонитевость, способность выполнять DOS-программы с помощью виртуальных машин процессоров Intel 80x86, полную 32-х битную организацию.