Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Прогнозы — дело неблагодарное?Содержание книги Поиск на нашем сайте
«Потенциальный мировой рынок копировальных машин — 5000 штук, в крайнем случае.» Из письма руководителей IBM к будущим учредителям Xerox, 1959 год. «Нет никаких оснований предполагать, что кто-либо захочет иметь компьютер в своем доме.» Кен Олсен, основатель Digital Equipment Corp, 1977 год. «Никому не понадобится больше, чем 637 кб памяти для персональных компьютеров — 640 кб будет достаточно для любого", Билл Гейтс, Microsoft, 1981 год. «К следующему рождеству IPod будет мертв, закончится, уйдет, ему капут.» Сэр Алан Шугар, британский бизнесмен, 2005 год. Ложка дегтя Как бы радужные перспективы в развитии сетевых технологий нас не ожидали, но платить приходится за все. И не всегда деньгами. Самая высокая цена, которую выставит пользователям Сеть будущего — потеря приватности. Прикрываясь борьбой с терроризмом, защитой авторских прав, политическим и религиозным экстремизмом и прочими бутафорскими опасностями, правительства доведут до совершенства автоматизированные системы тотального контроля за пользователями. Вплоть до ведения пожизненного лога всех действий в интернете. Вживленные чипы постоянно подключенных к Сети интернет-гаджетов позволят Большому Брату следить за каждым шагом гражданина и манипулировать его поведением. Реализовать это будет легко — путем отключения повседневных в будущем сервисов или, напротив, тайным подключением специализированных сетевых служб. Приватность, если сохранится, станет привилегией небольшого числа «толстых кошельков». Веб-сервисы как средство интеграции приложений в WWW Что есть веб-сервис? Всемирная паутина является готовой платформой для создания и использования распределенных машинно-ориентированных систем на основе веб-сервисов. Веб-сервер выступает в качестве сервера приложений, к которым обращаются не конечные пользователи, а сторонние приложения. Это позволяет многократно использовать функциональные элементы, устранить дублирование кода, упростить решение задач интеграции приложений. Веб-служба, веб-сервис (англ. web-service) — это сетевая технология, обеспечивающая межпрограммное взаимодействие на основе веб-стандартов. Консорциум W3C определяет веб-сервис, как «программную систему, разработанную для поддержки интероперабельного межкомпьютерного (machine-to-machine) взаимодействия через сеть»
Веб-службы: концепции и протоколы Веб-сервис идентифицируется строкой URI. Веб-сервис имеет программный интерфейс, представленный в машинно-обрабатываемом формате WSDL. Другие системы взаимодействуют с этим веб-сервисом путем обмена сообщениями протокола SOAP. В качестве транспорта для сообщений используется протокол HTTP. Описание веб-сервисов и их API могут быть найдены средствами UDDI. Концептуальная схема технологии приведена на рис. 1., а связь между протоколами — на рис. 2.
Рис. 1. Концепция веб-сервиса
Рис. 2. Протоколы веб-сервисов Все спецификации, используемые в технологии, основаны на XML и, соответственно, наследуют его преимущества (структурированность, гибкость и т.д.) и недостатки (громоздкость, медлительность). SOAP SOAP (изначально Simple Object Access Protocol, а в версии 1.2 официальная расшифровка аббревиатуры отсутствует) — простой протокол доступа к объектам (компонентам распределенной вычислительной системы), основанный на обмене структурированными сообщениями. Как любой текстовый протокол, SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но чаще всего SOAP используется поверх HTTP. Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы:
Развернутый список элементов сообщения SOAP приведен в схеме данных (для SOAP версии 1.2). Пример сообщения SOAP: <env: Envelope xmlns:env=" http://www.w3.org/2003/05/soap-envelope "> <env: Header > <n:alertcontrol xmlns:n=" http://example.org/alertcontrol ">
<n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env: Header > <env: Body > <m:alert xmlns:m="http://example.org/alert"> <m:msg>Get up at 6:30 AM</m:msg> </m:alert> </env: Body > </env: Envelope > XML-RPC: Не конкурент, а альтернатива SOAP XML-RPC — очень простой и эффективный протокол взаимодействия веб-сервисов. Он не предназначен для решения глобальных задач, как SOAP, но широко используется во многих веб-разработках. XML-RPC — это "... спецификация и набор реализаций, которые позволяют программному обеспечению, работающему на разных операционных системах и в различных условиях, вызывать процедуры через Интернет. Это удаленный вызов процедуры с использованием HTTP как транспорта и XML как способа кодирования. XML-RPC разработан настолько простым, насколько это возможно для сложных структур данных, подлежащих передаче, обработке и приему". — [хmlrpc.com] "Мы хотели, чистый, расширяемый и очень простой формат. Он должен представлять HTML-кодеру возможность заглянуть в файл, содержащий описание XML-RPC вызова, понять, что тот делает и быть в состоянии изменить его, чтоб он заработал с первой или второй попытки... Мы также хотели, чтобы это был легко реализуемый протокол, который может быть быстро адаптирован для работы в другой среде или на других операционных системах."- [xmlrpc.com] WSDL Язык описания веб-сервисов (Web services Description Language, WSDL) предназначен для унифицированного представления внешних интерфейсов веб-службы. Текущая версия протокола (на момент написания этой лекции) WSDL 2.0 и она имеет некоторые отличия от предыдущих версий (см.табл. 1 и рис. 3). Таблица 1. Основные элементы протокола WSDL.
Рис. 3. Структура протокола WSDL В спецификации WSDL 1.1 было определено 4 шаблона обмена сообщениями (типы операций):
В версии WSDL 2.0 эти шаблоны изменены и расширены в сторону поддержки сообщений об ошибках (например, шаблон Robust-in-only), но для обратной совместимости поддерживаются типы WSDL 1.1 Пример описания веб-сервиса на языке WSDL (версия 2.0). UDDI Universal Description, Discovery and Integration (UDDI, универсальный интерфейс распознавания, описания и интеграции) — открытый стандарт, утвержденный OASIS, определяющий методы публикации и обнаружения сетевых программных компонентов сервис-ориентированной архитектуры (SOA). В практической реализации UDDI представляет собой сетевой реестр (службу каталогов), представляющий данные и метаданные о веб-сервисах и доступный по адресу http://uddi.xml.org/services.
UDDI опирается на отраслевые стандарты HTTP, XML, XML Schema (XSD), SOAP и WSDL. Концептуальная связь между UDDI и другими протоколами стека веб-сервисов показана на рисунке 4.
Рис. 4. Место UDDI в стеке протоколов веб-служб Функциональное назначение реестра UDDI — представление данных и метаданных о веб-службах. Он может использоваться как в сети общего пользования, так и в пределах внутренней инфраструктуры организации. Реестр UDDI предлагает основанный на стандартах механизм классификации, каталогизации и управления веб-службами, позволяющий применять их (веб-сервисы) другими приложениями. Этот механизм включает средства для поиска сервиса, вызова этой службы, а также для управления метаданными об этой службе. Ключевыми функциями UDDI являются публикация информации о службе в реестре и поиск этой информации сторонними приложениями. Наряду с этими, реализованы и типовые для службы каталогов функции: представление модели хранимых данных и структуры информационной базы, отношения между объектами реестра, репликация, обеспечение безопасности и т.д. —Все основные функции реестра представлены в виде веб-сервисов и доступны через API UDDI. Веб-сервисы: Pro et Contra Достоинства
Недостатки
Серверы приложений Вынесение прикладной логики в отдельный уровень представляет разработчикам дополнительную гибкость в создании распределенных информационных систем. Размещение и выполнение программ на стороне сервера снижает требования к аппаратному обеспечению клиентов и уменьшает проблемы обеспечения совместимости в гетерогенной сетевой среде. Сервер приложений — это сервисная программа, которая обеспечивает доступ клиентов к прикладным программам, выполняющимся на сервере. Сервер приложений обычно выделяется как среднее звено (рис. 1) в трехуровневой клиент-серверной архитектуре (3-tier):
Модель "сервер приложений"
1. Первый уровень, интерфейсный, как правило, графический (GUI). 2. Средний уровень, исполнимый программный код, размещенный обычно на выделенном сервере. 3. Третий уровень, фоновый — базы данных. Сюда же относятся, унаследованные средства доступа к данным и управления транзакциями. В сетевой среде сервер приложений является посредником между фронт-эндами клиентов и серверами баз данных. Бизнес-логика может быть реализована на стороне сервера как целиком (удаленный код), так и частично (распределенный код). В первом случае к серверу могут обращаться терминалы и «тонкие» клиенты и такое взаимодействие соответствует модели «сервер терминалов». «Толстые» и rich-клиенты могут получать компоненты серверного приложения и выполнять их на своей стороне (например javascript, апплеты, flash). Мобильный софт Задачи, решаемые серверами приложений хорошо иллюстрируются на примере мобильных сервисов. Возможности мобильных устройств изначально ограничены физическими размерами и временем автономной работы (остальные ограничения, в основном, вытекают из этих двух). Мобильное приложение разрабатывается с учетом этих ограничений, но так как софт для телефона должен быть адаптирован для использования на конкретной модели, то процесс разработки усложняется. Разделив мобильное приложение на клиентскую (представление данных) и серверную (прикладная логика) части, разработчик получает следующие возможности: · урезанная по функционалу клиентская часть получается менее требовательной к ресурсам; · для поддержки новых устройств нужно адаптировать только фронт-энд, не затрагивая прикладную логику; · изменения в программе (расширение функциональности, исправление ошибок и т. п.) выполняются на сервере приложений и распространяются на всех клиентов. Клиенты могут взаимодействовать с приложениями через API сервера (Java-клиент <—> контейнер сервлетов <—> сервлет). Большую гибкость и универсальность представляет взаимодействие через сторонние сервисы, в первую очередь — через веб-сервер. Понятие сервера приложений традиционно связывают с платформой Java, указывая на то, что сервер Java-приложений представляет реализацию спецификации сервлетов, возможно в виде JSP, и еще некоторые сервисные услуги, в первую очередь соединение с базой данных. Но это нечто большее и меньшее одновременно: сервер приложений предоставляет среду, в которой прикладные программы могут работать, независимо от того, что и как именно они делают. Поэтому, чтобы ответить на вопрос, является ли (и в какой степени) некое сервисное ПО сервером приложений, стоит сравнить его заявленные функции со списком атрибутов, присущих этой категории:
Реализации По приведенным признакам в рассматриваемую категорию попадают, например, традиционные терминал-серверные системы, технология CGI, контейнеры Java-сервлетов и др.
Унаследованные решения Серверы терминалов представляют среду для удаленного выполнения программ, в качестве которой выступает сама операционная система. Доступ к ним осуществляется по протоколам удаленного управления (telnet, ssh, RDP, VNC и т. п.) из клиентского ПО (эмулятор терминала, средства управления удаленным рабочим столом и т.п.). Управление запущенной программой выполняется через эмулируемый на клиенте пользовательский интерфейс (текстовый или графический) операционной системы. На серверной стороне взаимодействие программ с ОС реализуется через системные вызовы. Управление также осуществляется средствами операционной системы. Разработка может вестись на любом языке, доступном в конкретной ОС. Общий шлюзовый интерфейс (CGI) — технология доступа к приложениям через веб-сервер. Отличия от сервера терминалов здесь в том, что пользовательский интерфейс предоставляется в виде веб-страниц. Запросы веб-клиентов, обращенные к программам, размещенным в выделенном каталоге (как правило cgi или cgi-bin) перенаправляются на их вход через стандартный поток ввода (stdin). Результаты выполнения в виде гипертекста приложение возвращает веб-серверу через stdout. Серверы Java-приложений Платформа Java является индустриальным стандартом, позволяющим создавать из унифицированных компонентов интероперабельные программные решения для самых разных систем, в которых может быть запущена виртуальная машина Java (JVM). Контейнер сервлетов — один из архитектурных компонентов J2EE, представляющий окружение для выполнения сервлетов. Сервлет — это Java-приложение, выполняющееся на стороне сервера (в отличие от апплета). Контейнер сервлетов может работать как полноценный самостоятельный сервер, но чаще используется (интегрируется) совместно с другим серверным ПО. Обеспечивает обмен данными между сервлетом и клиентами, берёт на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них. Концепция сервлет-контейнера позволяет создавать как универсальные, так и специализированные серверы приложений (например, для мобильных сервисов). Примером реализации контейнера сервлетов является Apache TomCat, который используется в таких серверах приложений как Apache Geronimo, JBoss, GlassFish, IBM WebSphere Application Server (WAS). Другие решения Компания Microsoft представляет собственные решения для поддержки бизнес-логики и сервисной инфрастуктуры на основе ОС Windows Server и технологии.NET Framework. Основным средством разработки является язык C#. Язык python, получивший популярность во многом благодаря Google, является основным средством разработки для сервера веб-приложений Zope. Для сценариев на языке PHP, широко используемом для создания веб-сайтов, компания Zend Technologies (разработчик самого языка PHP) создала сервер приложений Zend Server. Серверы приложений: плюсы и минусы Преимущества Целостность кода и данных Размещение бизнес-логики на выделенном сервере или ограниченном числе серверных компьютеров гарантирует доступ к обновленному и модернизированному ПО для всех клиентов. Это исключает риск доступа и управления данными из устаревших и, возможно, несовместимых программ. Централизованное управление Изменения в конфигурации прикладных программ, такие как, например, смена сервера баз данных, выполняются централизованно. Безопасность Централизованные средства, через которые поставщик услуг (сервис-провайдер) может управлять доступом к данным и компонентам приложения, позволяют выполнять проверку подлинности потенциально ненадежных клиентов в среднем слое и не затрагивать уровень базы данных. Производительность Сервер приложений может решать задачи балансировки сетевого трафика и распределения нагрузки между другими физическими серверами системы. Общая стоимость владения Совокупность перечисленных выше преимуществ, а в дополнение к ним перераспределение затрат на оборудование с клиентской на серверную сторону, может привести к экономии средств для организации. Так же на снижении общей стоимости владения может отразиться практика аренды программного обеспечения. Справедливости ради нужно отметить, что стоимость самого серверного ПО, а также затраты на его внедрение и сопровождение могут быть весьма высокими. Недостатки Централизация Системы, построенные на основе сервера приложений, имеют один основной недостаток, присущий всем централизованным решениям — «падение» сервера приведет к недоступности программ для всех клиентов. К тому же эффекту приведут и неполадки в сетевом подключении. Защита информации Эта проблема, в принципе, актуальна для любых сетевых решений, использующих для передачи данных инфраструктуру публичных сетей. Общий доступ к сетевым ресурсам. 1. Служба общего доступа (sharing) 2. Протоколы общего доступа o SMB/CIFS o NFS o DFS 3. Низкоуровневые средства общего доступа. Протокол DAFS Служба общего доступа (sharing) Компьютерная сеть по определению представляет собой распределенную систему. Ее предназначение — совместная работа пользователей. Такая работа подразумевает доступ к сетевым ресурсам, как то файлы и каталоги, принтеры и т.д. Для пользователя обращение к сетевым ресурсам должно быть прозрачным, т.е.: 1. Удаленные ресурсы должны выглядеть так, словно они являются локальными и обращение к ним из приложений происходит единообразно. 2. Клиенту должно быть безразлично, какая платформа используется в качестве сервера общего доступа. При этом нужно учитывать и то, что не всякий пользователь должен иметь доступ к конкретному ресурсу, и не всякий ресурс олжен быть доступен всем. Т.е. необходимо обеспечить возможности управления общим доступом как на уровне пользователей, так и на уровне отдельных ресурсов. Указанные возможности предоставляют специальные протоколы общего доступа. Наиболее распространенными из них являются SMB/CIFS для ОС Windows и NFS, используемый в UNIX-подобных системах. Протоколы общего доступа SMB/CIFS SMB (Server Message Block) — это протокол, предложенный IBM для организации общего доступа к файлам, принтерам, последовательным портам, почтовым ячейкам (mail slots), именованным каналам (named pipes) и API сетевых компьютеров. Протокол SMB может быть использован поверх сетевых протоколов стека TCP/IP, а также поверх ряда других сетевых протоколов. SMB — это типичный клиент-серверный протокол, который позволяет клиентскому приложению выполнять операции доступа к общему ресурсу (чтение, запись и т.п.) через запросы к серверу. SMB требует установления и поддержания соединения, но может работать и в датаграммном режиме. В 1992 году появилась Samba — свободная реализация протокола SMB для UNIX-подобных операционных систем. Поскольку Microsoft не публиковала спецификации SMB и дополнений к нему, создателю Samba Эндрю Триджеллу (Andrew Tridgell) пришлось провести обратную разработку протокола на основе анализа пакетов. Продвижение протокола SMB обеспечила корпорация Microsoft, включив его поддержку в свои продукты. В сетевой среде Microsoft Windows SMB являлся основным протоколом прикладного уровня для работы с ресурсами ЛВС. Он предназначен для выполнения функций общего доступа к файлам и принтерам, авторизации пользователей и обмена сообщениями. Протокол SMB представляет четыре вида севисов:
Если режим управления сеансами в SMB прозрачен для пользователя, то остальными сервисами пользователь может управлять непосредственно с помощью команды net (см. net /? в консоли ОС Windows).
Рис. 1. NetBIOS/SMB Для управления сессиями протокол SMB изначально использовал NetBIOS в реализации NetBEUI (NetBIOS Extended User Interface) — расширенный пользовательский интерфейс дейтаграммной передачи NetBIOS, рассчитанный на сети порядка 20-200 рабочих станций. Сети, основанные на протоколе NetBEUI, легко реализуются, но их трудно расширять, так как протокол NetBEUI не маршрутизируемый. Для использования SMB в сетях с более сложной топологией в NetBIOS была добавлена поддержка транспортных протоколов TCP (NBT, NetBIOS over TCP), IPX, DECNet и Xerox Networking (XNS) (рис. 1) Сервисы SMB, работающие в среде TCP/IP, используют различные порты (стандартные названия портов подчеркивают тесную связь SMB с NetBIOS):
netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp netbios-dgm 138/tcp # NETBIOS Datagram Service netbios-dgm 138/udp netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp В SMB первых версий отсутствовала аутентификация — то есть любой пользователь мог использовать любые ресурсы, что, конечно, ограничивало область применения малыми локальными сетями. Современные версии SMB поддерживают два уровня доступа: 1. Доступ на уровне ресурсов. Ограничения накладываются серверной стороной на каталоги общего доступа. Каждый сетевой каталог может быть защищен паролем и клиент должен указать этот пароль для получения доступа к файлам из общего каталога. 2. Доступ на уровне пользователей. Ограничения налагаются на каждый файл в каждом общем каталоге и они основаны на пользовательских правах. Каждый пользователь (клиент) должен войти на сервер под своей учетной записью и пройти аутентификацию. После завершения проверки подлинности клиент получает соответствующий идентификатор пользователя (user ID), который он должен предъявлять для получения доступа к ресурсам сервера. Привязка к NetBIOS ограничивало использование SMB небольшими локальными сетями. Первая причина — отсутствие в NetBIOS понятия сети как такового и средств перенаправления трафика (маршрутизации). Вторая — в принятой схеме адресации: имя ресурса, по сути, строка из 15 символов, плюс байт типа ресурса: сервер, контроллер домена и т.д. Естественно, такая одноранговая система именования не годится для интернета. Для устранения этих ограничений в последних версиях SMB использовался протокол NBT (NetBIOS over TCP), работавший поверх стека TCP/IP. CIFS создавался совместно разработчиками Samba Team, независимым сообществом и Microsoft. После того как протокол CIFS был представлен как открытый стандарт, Microsoft прекратила финансирование проекта и сотрудничество с Samba Team, а поддержка CIFS в переработке Microsoft для совместимости с прежними версиями SMB была включена в ОС Windows 2000. CIFS (Common Internet File System) — это открытый стандартный протокол (см. CIFS) на основе SMB, который обеспечивает доступ к файлам и сервисам на удаленных компьютерах в сетях TCP/IP. В отличие от SMB, основным транспортом для CIFS является протокол TCP. Для серверов CIFS зарегистрированы порты 445/TCP и 445/UDP (microsoft-ds # Microsoft Naked CIFS, см. /etc/services) CIFS обеспечивает функциональность похожую на FTP (File Transfer Protocol), но предоставляет клиентам улучшенный (похожий на прямой) контроль над файлами. Основные возможности CIFS приведены втаблице 1. Табл. 1. Возможности протокола CIFS
Сетевая файловая система NFS NFS (Network File System, сетевая файловая система) — это стандарт, который включает описание распределенной файловой системы и сетевого протокола для работы с ней. Первая спецификация NFS была разработана компанией Sun в 1989 году и предназначалась для использования только в UNIX. Позже реализации клиентской и серверной частей стали распространенными и в других системах. Текущая версия (на момент написания этого материала) имеет название NFS v4 и является открытым стандартом (RFC 3010). Эта система позволяет пользователю работать с удаленными данными так же, как с локальными — то есть абсолютно прозрачно. Не считая, естественно, временных задержек. Протокол NFS, как и SMB/CIFS, использует клиент-серверную модель взаимодействия. В ранних версиях NFS для транспортирования данных использовался UDP-протокол, в современных — используется TCP. Сервис NFS работает на следующих зарегистрированных портах: nfs 2049/tcp # Network File System - Sun Microsystems nfs 2049/udp # Network File System - Sun Microsystems Применение протокола TCP в качестве транспорта позволило решить вопросы совместного доступа прямолинейно, без обходных маневров, однако ценой этому является некоторое снижение производительности по сравнению с UDP. NFS является «родной» файловой системой для UNIX и соответствует логике файловых операций этой операционной системы. Это относится как к пространству имен файлов, так и к поддерживаемым файловым атрибутам. Поддержка NFS имеется у всех популярных систем на основе UNIX.
Рис. 2. Организация NFS в соответствии с сетевой моделью OSI. Структура NFS включает три компонента разного уровня:
Процедура подключения сетевого ресурса средствами NFS называется «экспортированием». Клиент может запросить у сервера список представляемых им экспортируемых ресурсов. Сам сервер NFS, в отличие от, например, сервера SMB, не занимается широковещательной рассылкой списка своих экспортируемых ресурсов. В зависимости от заданных опций, экспортируемый ресурс может быть смонтирован «только для чтения», можно определить список хостов, которым разрешено монтирование, указать использование защищенного RPC (secureRPC) и пр. Одна из опций определяет способ монтирования: «жесткое» (hard) или «мягкое» (soft).
На вопрос, какой из режимов, «мягкий» или «жесткий», лучше, однозначно ответить невозможно. Если данные на клиенте и сервере должны быть синхронизированы при временном отказе сервиса, то «жесткое» монтирование оказывается предпочтительнее. Этот режим незаменим также в случаях, когда монтируемые файловые системы содержат в своем составе программы и файлы, жизненно важные для работы клиента, в частности для бездисковых машин. В других случаях, особенно когда речь идет о системах «только для чтения», режим «мягкого» монтирования представляется более удобным. С точки зрения безопасности первые реализации NFS были крайне слабы: аутентификация выполнялась, по сути, только по ip-адресу клиента. Использование NIS не намного увеличивало защищенность системы. В версиях NFS 3 и 4 эти вопросы были переработаны путем добавления поддержки списков доступа (ACL), защищенного rpc и ряда других решений, которые позволили сертифицировать NFS в минобороны США. Общий доступ в смешанной сети Сервис NFS идеально подходит для сетей на основе UNIX, так как поставляется практически со всеми версиями этой операционной системы. Более того, поддержка NFS реализована на уровне ядра UNIX. К сожалению, использование NFS на клиентских компьютерах с Windows создает определенные проблемы, связанные с необходимостью установки специализированного и довольно дорогого клиентского ПО. В таких сетях использование средств разделения ресурсов на основе протокола SMB/CIFS, в частности ПО Samba, выглядит более предпочтительным. Низкоуровневые средства общего доступа. Протокол DAFS
|
||||||||||||||||||||||||||||||||||||||||||||||||||||
Последнее изменение этой страницы: 2016-04-18; просмотров: 310; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.117.156.153 (0.018 с.) |