Организация локальных сетей

1) Основные понятия

Локальная сеть – это множество узлов, соединенных дискретными каналами связи (ДКС) [16]. В качестве узла обычно выступает компьютер, но это может быть и любое другое устройство, способное передавать и принимать данные, например, сетевой принтер. В качестве ДКС между двумя узлами выступает структура “САК – ЛС – СУ – … – СУ– ЛС – САК”, где САК – сетевой адаптер компьютера, ЛС – линия связи (витая пара, оптоволоконный кабель), СУ – сетевое устройство (концентратор или хаб (hub), коммутатор или свитч (switch), мост (bridge), маршрутизатор (router) или шлюз (gateway)). Множество всех ЛС и СУ сети образует физическую среду передачи данных сети. В зависимости от того, равноправны или нет узлы локальной сети, различают одноранговые сети и сети с сервером.

В одноранговой сети (например, в рабочей группе Windows 2000/2003) все компьютеры равноправны в плане управления сетью и обслуживания пользователей. Здесь каждый компьютер ведет свою базу данных безопасности, где хранит учетные записи своих зарегистрированных пользователей, предоставляет этим пользователям доступ ко всем своим ресурсам (папки, файлы, приложения, принтеры и др.) согласно собственной политике безопасности, а также предоставляет доступ к строго ограниченной части своих ресурсов всем пользователям сети тоже согласно своей политике безопасности.

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

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

2) Топология локальной сети

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

Топология “шина”. Все компьютеры подключаются параллельно к одной линии связи. Информация от каждого компьютера одновременно передается всем остальным компьютерам (рис. 2.1).

Рис. 2.1. Топология “шина”

Рис. 2.2. Топология “звезда”

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

Рис. 2.3. Топология “кольцо”

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

3) Обмен данными между приложениями в сети

Информация от приложения в одном компьютере передается приложению в другом компьютере сети небольшими порциями, которые называют пакетами данных. Для создания пакета данных к блоку данных приложения-отправителя добавляются два блока служебных данных – спереди заголовок, а сзади концевик. Таким образом, пакет – это блок данных, “упакованный” в “конверт”, состоящий из заголовка и концевика. Этот первичный пакет не сразу поступает в физическую среду передачи данных (ФСПД) сети, а предварительно упаковывается в качестве нового блока данных в пакет смежного нижнего уровня, который, в свою очередь, упаковывается в качестве блока данных в пакет следующего нижнего уровня и так далее несколько раз в зависимости от топологии и архитектуры сети (рис. 2.4).

Рис. 2.4. Упаковка данных в пакеты

Пакет каждого уровня формируется определенным компонентом сетевого программного обеспечения (СПО), работающим в компьютере-передатчике.

СПО ­– составная часть всех современных операционных систем (Windows, Unix, Lnux). Пакет низшего уровня из компьютера-передатчика бит за битом поступает на вход ФСПД сети и затем бит за битом считывается с выхода ФСПД сети компьютером-приемником. В нем этот пакет проходит через компоненты СПО от низшего уровня до высшего, при этом каждый компонент СПО освобождает принятый пакет от заголовка и концевика своего уровня. В итоге на выходе СПО высшего уровня появляется блок данных приложения-отправителя, который и передается приложению-получателю (рис. 2.5).

Рис. 2.5. Передача данных между приложениями в сети

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

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

Типы и форматы пакетов каждого уровня определяются стандартом на сетевой протокол данного уровня. В общем случае заголовок пакета содержит адрес отправителя и адрес получателя. В качестве такого адреса в протоколе Ethernet (рис. 2.5, уровень 1), стандартном для ФСПД с топологией “шина” или “звезда”, используется физический адрес (MAC-адрес) “зашитый” в сетевой адаптер компьютера изготовителем; в стандартном протоколе IP (рис. 2.5, уровень 2) используется IP-адрес, назначаемый сетевому адаптеру компьютера вручную или сетевой службой, а в протоколе TCP или UDP (рис. 2.5, уровень 3) – номер порта (то есть логической точки подключения приложения к сети). Заметим, что в распределенных приложениях совокупность IP-адреса и номера порта рассматривается как сокет (socket), и соединение между отправителем и получателем однозначно определяется сокетами на его концах, а не парой IP-адресов или парой номеров портов. Кроме того, заголовок пакета содержит контрольную сумму для обнаружения ошибок передачи пакета и управляющую информацию (номер отправленного пакета, номер ожидаемого пакета и др.).

Пакет низшего уровня обычно называют кадром (frame). Концевик кадра содержит контрольную сумму кадра (Frame Check Sequence, FCS), вычисляемую на базе порождающего многочлена циклического кода [16].

4) Стандартная архитектура СПО

Международная организация по стандартизации (ISO) в 1984 г. предложила в качестве стандартной архитектуры СПО модель взаимодействия открытых систем (Open Systems Interconnection, OSI) (рис. 2.6), которая поддерживается сейчас многими изготовителями СПО и сетевых устройств.

Рис. 2.6. Модель OSI

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

Рис. 2.7. Обмен данными между двумя приложениями согласно модели OSI

Рассмотрим функции уровней модели OSI.

Физический уровень определяет физические свойства среды и сигналов передачи данных.

Канальный уровень обеспечивает перенос данных по ФСПД. Он разделен на два подуровня – управление логическим каналом (LLC) и управление доступом к среде (MAC). LLC-подуровень формирует из пакетов сетевого уровня LLC-кадры, а MAC-подуровень формирует из LLC-кадров кадры данных согласно методу доступа к ФСПД (например, Ethernet для топологии “шина” или Token Ring для топологии “кольцо”), добавляя к LLC-кадру MAC-адреса получателя и отправителя. Каждый подуровень управляет передачей и приемом своих кадров согласно своему протоколу.

Сетевой уровень работает с логическими адресами и управляет передачей пакетов данных через ФСПД по оптимальным маршрутам для каждой пары узлов сети. Обмен пакетами данных этого уровня между узлами происходит по протоколу IP, а обмен между маршрутизаторами информацией, нужной для создания и поддержки таблиц маршрутизации, – по протоколам ICMP, RIP , OSPF, ARP.

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

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

Представительный уровень “скрывает” синтаксис данных (например, код ASCII или Unicode) прикладного уровня в одном компьютере для прикладного уровня в другом компьютере и наоборот без изменения семантики. На этом уровне может выполняться шифрование в целях секретности обмена данными между компонентами прикладного уровня, например, посредством протокола SSL (Secure Socket Layer).

Прикладной уровень содержит объекты, реализующие протоколы, при помощи которых приложения получают доступ к совместно используемым ресурсам сети (папки, файлы, принтеры, Web-страницы, электронная почта). Такими протоколами являются, например, FTP (протокол передачи файлов), HTTP (протокол передачи гипертекста в Web), SMTP (протокол передачи электронной почты), Telnet (протокол эмуляции терминала, используемый клиентами для запуска удаленных приложений), SNMP (протокол управления узлами сети и сетевыми устройствами). Пакеты этих протоколов называют сообщениями.

2.3. Распределенные приложения

1) Общие сведения

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

Компоненты распределенного приложения (РП) могут находиться в симметричных и асимметричных отношениях. Если РП имеет симметричную модель, то ее компоненты равноправны, обладают одинаковым интеллектом и называются автономными агентами или интеллектуальными агентами, а само РП называется мультиагентной системой [18]. Такие РП создаются для решения сложных задач в Интернетe, отличаются множеством нерешенных проблем (координация, коммуникация, семантика знаний, обучение и др.) и тем не менее имеют большое будущее. Если РП имеет асимметричную модель, то один и более ее компонентов (серверы) имеют усиленный “интеллект” и предоставляют управленческие, информационные и прикладные услуги остальным компонентам (клиентам), причем серверы управления могут быть как равноправными, так и взаимно подчиненными, а серверы баз данных (БД) и серверы приложений реализуются как независимые программные объекты.

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

2) Удаленный вызов процедур

Удаленный вызов процедур (Remote Procedure Call, RPC) – самая ранняя технология связывания компонентов РП. Клиент вызывает метод удаленного сервера и блокируется до получения ответа (рис. 2.8).

Рис. 2.8. Архитектура РП на базе RPC

Для установления связи и передачи вызова метода сервера клиент вызывает локальную процедуру-заглушку (stub). Сервер для передачи ответа вызывает свою заглушку. Заглушки не решают никаких задач, кроме изоляции клиента и сервера от сетевого ПО. Код заглушки генерируется средой разработки. Привязка клиента к заглушкесервера происходит при компиляции и не может изменяться во время выполнения. В этом RPC уступает новым технологиям типа “ориентированное на сообщения промежуточное ПО (Message-Oriented Middleware, MOM)”, где возможен динамический выбор сервера по критерию оптимальной нагрузки серверов. Главный недостаток RPC – синхронный режим работы клиента и сервера, требующий высокой надежности и постоянной доступности дискретного канала связи.

3) Модель компонентных объектов

Модель компонентных объектов (Component Object Model, COM) создана Microsoft для платформы Windows. Она позволяет разбить приложение в одном компьютере на компоненты с четко описанными интерфейсами. Для разработки РП создана распределенная модель компонентных объектов (Distributed COM, DCOM). В ней удаленные объекты взаимодействуют согласно спецификации среды распределенных вычислений (Distributed Computing Environment, DCE) с применением RPC. Среда скрывает от клиента детали сетевой связи. DCOM позволяет связывать удаленные объекты динамически, т.е. клиент в фазе исполнения может обратиться к серверу-объекту, даже если его свойства и не были ему известны при компиляции. Информацию об объектах, доступных в сервере, клиент в фазе исполнения получает из библиотеки типов (type library) через OLE Automation, что позволяет изменять функции сервера без изменения кода клиентов. DCOM предоставляет разработчику язык описания интерфейсов (Interface Definition Language, IDL). Этот язык называется DCE IDL и не очень важен, так как объекты в DCOM связываются не через интерфейсы, а через двоичный код.

В Windows NT появилась служба Microsoft Transaction Server (MTS), позволяющая группировать объекты DCOM в рамках транзакций. MTS – это контейнер транзакционных компонентов или сервер приложений. Приложения, управляемые MTS, представляют собой наборы компонентов, оформленных в виде динамически подключаемых библиотек (DLL). В Windows 2000 служба MTS интегрирована в COM/DCOM в рамках новой технологии COM+ [9], доступной разработчику в форме набора служб компонентов (Component Services), которые повышают скорость и безопасность обработки транзакций, позволяют управлять транзакциями, объединять объекты в пулы, выстраивать компоненты в очереди, создавать и администрировать пакеты приложений.

Главный недостаток COM/DCOM и COM+ состоит в жесткой привязке к платформе Windows, что неприемлемо в корпоративных сетях.

4) Общая архитектура брокера объектных запросов

В 1990-х гг. международный консорциум OMG, включающий более 500 ведущих компьютерных компаний, разработал общую архитектуру брокера объектных запросов (Common Object Request Broker Architecture, CORBA), которая по-новому реализует идеи RPC и COM и определяет инфраструктуру взаимодействия клиентов с удаленными объектами (рис. 2.9).

Рис. 2.9. Архитектура РП на базе CORBA

В CORBA программисты описывают интерфейсы объектов на языке OMG IDL (стандарт ISO/IEC 14750). В описании интерфейса определяют операции и параметры объекта. Этот интерфейс согласуется с клиентом объекта, использующим его для создания вызова и управления вызовом объекта. Такой дизайн дает клиентам доступ к реализациям объектов, независимый от языка программирования, операционной системы, аппаратной платформы, представления данных, расположения в сети и протокола обмена данными. Клиенты и объекты CORBA могут разрабатываться на многих языках объектно-ориентированного программирования (ООП), например C++ или Java, так как для них OMG установил порядок перевода вызовов типов и методов с языка OMG IDL на язык ООП и созданы соответствующие компиляторы.

Передача запроса от клиента к реализации объекта и ответа от реализации объекта к клиенту через транспортную сеть осуществляется посредниками объектных запросов (Object Request Broker, ORB) с использованием протокола IIOP (Internet InterORB Object Protocol) или протокола GIOP (Generic Interoperable Object Protocol). Протокол IIOP работает поверх стандартного протокола TCP.

Клиент и реализация объекта изолированы от ORB своим IDL-интерфейсом, встроенным в заглушку (stub) на стороне клиента или в каркас (skeleton) на стороне реализации объекта. Поскольку клиенты видят только интерфейс объекта, а не детали реализации, архитектура гарантирует простую замену реализации объекта позади интерфейса. Экземплярами объектов в компьютере-сервере управляет блок Portable Object Adapter (POA). Каждый объект работает с момента создания до момента уничтожения. Клиенты могут вызывать любые действительные ссылки на объекты и рассчитывать на получение ответа, но не могут запускать или отключать объекты.

Множество не упомянутых выше спецификаций CORBA можно разбить на три категории: интеграция с Java и Интернетом, контроль качества сервиса и пакет компонентов CORBA.

CORBA изначально нацелена на кросс-платформенную поддержку и реализована для всех версий операционных систем UNIX и Windows. В этом — ее главное преимущество перед COM/DCOM и COM+. Но часто эти реализации сильно различаются, т. е. не полностью интероперабельны.

Стандарт определяет почти два десятка служб ORB, из которых в ORB фактически реализуются лишь несколько ключевых служб. Наиболее известные реализации ORB – продукты VisiBroker и Enterprise Server компании Borland, BEA Tuxedo и IONA Orbix.

НедостаткиCORBA – сложность реализации и синхронный режим связи клиентов и объектов.

5) Удаленный вызов методов Java

В язык программирования Java встроен механизм удаленного вызова методов (Remote Method Invocation, RMI). Для создания РП на базе RMI надо сначала создать сервер с методами для удаленного вызова. Сервер должен объявить себя доступным для обращения путем регистрации в сети с неким именем, тогда клиенты смогут, обращаясь к нему по этому имени, вызывать его методы. Для реализации RMI на компьютере-сервере запускается файл rmiregistry, поставляемый с пакетом JDK. В результате создается реестр, где содержится информация обо всех объектах, хранящихся на компьютере-сервере, к которым возможен доступ с удаленного компьютера-клиента. После этого сервер становится активным и начинает предоставлять клиентам услуги. Для обращения к серверу клиент должен указать его сетевое имя.

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

Итак, для создания РП на базе RMI надо выполнить следующие шаги.

1. Создать интерфейс, содержащий объявления методов, для которых будет осуществляться удаленный вызов.

2. Создать на компьютере-сервере класс, реализующий этот интерфейс. Этот класс должен расширять класс UnicastRemoteObject.

3. Запустить на компьютере-сервере программу rmi, создающую заглушки.

4. Запустить на компьютере-сервере программу rmiregistry.

5. Запустить сервер при помощи компилятора javac. Сервер связывает себя с созданным реестром, используя уникальное имя.

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

Анализ использования RMI позволяет сделать следующие выводы.

· RMI использует для обмена данными свой протокол JRMP, который обычно работает поверх протокола TCP.

· Имеются попытки слияния RMI и CORBA. Например, в Java 2, SE, v.1.3 встроен брокер CORBA v. 2.3.1, который поддерживает вызовы и по протоколу IIOP, и через RMI. Это позволяет связать две Java-платформы через IIOP, что выгоднее в плане “туннелирования” трафика через брандмауэр. Поддержка CORBA есть и в J2EE, а значит, и в корпоративных Web-серверах.

· Недостаток RMI – синхронный режим работы клиентов и сервера.

· На практике технология RMI вследствие ее низкого уровня слишком сложна для прямой реализации РП и де-факто вытеснена Java-технологией корпоративных объектов (Enterprise Java Beans, EJB).

6) Служба сообщений Java

Служба сообщений Java (Java Messaging Service, JMS) – технология связывания Java-приложений, включенная в J2EE, начиная с версии 1.3.

JMS предлагает модель и набор интерфейсов средств гарантированной доставки сообщений. Она позволяет связать в асинхронном режиме компоненты РП, исполняемые на разных Java-машинах. В качестве провайдера услуг JMS используется одна из существующих платформ MOM, например WebSphere MQ (IBM) или JES Message Queue Enterprise (Sun). Спецификация JMS позволяет разработчикам писать код Java-объектов без учета кода транспортного уровня. Благодаря асинхронному режиму, JMS менее чувствительна к обрывам канала связи. Спецификация JMS требует от провайдера услуг JMS поддержки многих функций, включая гарантированную доставку, временное хранение сообщений, передачу групп сообщений и др.

7) Архитектура .NET Remoting

Архитектура .NET Remoting создана недавно Microsoft для связывания компонентов РП. Она обеспечивает вызов методов удаленных объектов, размещенных на платформе Microsoft .NET. Здесь предоставляются услуги по активации удаленных объектов и контролю времени их жизни, поддерживается взаимодействие объектов через транспортные каналы (предоставляемые транспортным уровнем сети). Узлы сети делятся на узлы-клиенты и узлы-серверы по принципу, что первые отправляют запросы, а вторые отвечают на них. Это деление является нечетким, так как допускается, что в любой момент роль любого узла может смениться. В этом плане .NET Remoting похожа на Web-службs. В узле-клиенте выполняется приложение, называемое далее клиентом, а в узле-сервере находится объект, методы которого вызываются клиентом (рис. 2.10).

Рис. 2.10. Архитектура РП на базе .NET Remoting

Клиент работает с локальным с классом-посредником (proxy), генерируемом средой .NET на базе экземпляра кода удаленного класса, либо на базе класса, содержащего описания интерфейсов удаленного класса (но не код его логики), либо на базе Web-службы, получаемой с сервера. В сообщении, посылаемом клиентом серверу, класс-посредник кодирует имя и все входные параметры вызываемого метода удаленного объекта. На стороне сервера сообщение декодируется классом-посредником (dispatcher), и выполняется метод объекта. Для передачи данных серверу, клиент может вызвать метод класса-посредника с подстановкой этих данных в качестве параметров. Сервер может таким же образом передать возвращаемое значение метода объекта клиенту, и оно будет декодировано на стороне клиента классом-посредником. Несколько слоев посредников скрывают от клиента детали сетевого соединения с объектом. Первый посредник (TransparentProxy) упаковывает параметры вызова метода удаленного объекта в сообщение Imessage, которое передается второму посреднику (RealProxy), а тот уже передает его серверу. Классы этих посредников определены средой .NET, но пользователь может расширять класс RealProxy, например, чтобы включить в него средства безопасности. RealProxy взаимодействует с сетью через канал. В канале важны два элемента – форматер (formatter) и транспортер (transporter). В стандартном .NET форматер преобразует сообщение IMessage в двоичные пакеты данных или сообщения SOAP. Транспортеры доставляют их удаленному форматеру, используя протокол TCP или HTTP. Первый способ дает наибольшую скорость, но ценой утраты кросс-платформенности. Он подходит для локальной сети. Второй способ показывает методы удаленного объекта как Web-службы, к которым можно обращаться через брандмауэр и Интернет, и позволяет использовать любой протокол сетевого уровня, а не только IP, как первый способ. Однако он требует больших вычислительных и сетевых ресурсов.

В .NET различают объекты, активизируемые клиентом и активизируемые сервером. Первыми управляет менеджер контроля жизненного цикла, который по окончании срока аренды очищает память. Объекты, активизируемые сервером, делятся на объекты однократного вызова (single call) и единичные объекты (singleton). Объекты однократного вызова создаются в момент вызова их методов, а единичные объекты могут существовать долго и сохранять состояние между вызовами их методов. Все настройки свойств объектов (типы, каналы, номера портов) можно сохранить в конфигурационном XML-файле.

Технология .NET Remoting совместима с COM/DCOM и COM+, а также, благодаря поддержке открытых стандартов (XML, SOAP), теоретически совместима с Java и другими технологиями.

Важно, что .NET Remoting, кроме синхронного режима работы компонентов РП, реализует асинхронное взаимодействие в случае SOAP-транспорта. Это означает, что она может применяться вместе со средствами гарантированной доставки сообщений для обеспечения максимальной надежности РП.

Литература

1. Керниган Б., Ритчи Д. Язык программирования Си. М., Финансы и статистика, 1992. – 271 с.

2. Подбельский В.В. Язык Си ++. Учебное пособие, М.: Финансы и статистика, 1995. – 560 с.: ил.

3. Харви Дейтел, Пол Дейтел Как программировать на С++: Пер. с англ. М., ЗАО “Издательство БИНОМ”, 1999. – 1024 с.: ил.

4. Уильям Топп, Уильям Форд Структуры данных в С++: Пер. с англ. – М.: ЗАО «Издательство БИНОМ», 2000. – 816 с.: ил.

5. Арчер Т, Уайтчепел Э. Visual C++.NET. Библия пользователя: Пер. с англ. – М.: Издат. дом “Вильямс”, 2005. – 1216 с.

6. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. – СПб: Издат-во “Питер”, 1999. – 672 с.

7. Кульгин М. Технологии корпортаивных сетей. Энциклопедия. ­– СПб: Издат-во “Питер”, 1999. – 704 с.

8. Дилип Н. Стандарты и протоколы Интернета /Пер. с англ. – М.: Издат-кий отдел “Русская редакция”, Microsoft Press, 1999. – 384 с.

9. Оберг Р.Д. Технология COM+. Основы и программирование /Пер. с англ.: Учеб. поособие – М.: Издат. дом “Вильямс”, 2000. – 1480 с.

10. Седжвик Роберт Фундаментальные алгоритмы на С ++. Анализ / Структуры данных/ Сортировка / Поиск: Пер. с англ. – К.: Издательство «ДиаСофт», 2001. – 688 с.

11. Романов Е.Л. Практикум по программированию на С++: Учебное пособие. СПб: БХВ-Петербург; Новосибирск: Изд-во НГТУ, 2004. – 432 с.

12. Р.Г. Шахмаметов Технология программирования. Методические указания к курсовой работе. – Новосибирск: НГТУ, 2001. – 30 с.

13. Р.Г. Шахмаметов, О.В. Лауферман Программирование. Методические указания к практическим занятиям. – Новосибирск: НГТУ, 2003. – 20 с.

14. О.В. Лауферман, В.Г. Секаев Информатика. Методические указания к лабораторным работам. Часть 1. – Новосибирск: НГТУ, 2004. – 39 с.

15. О.В. Лауферман, Р.Г. Шахмаметов Информатика. Методические указания к лабораторным работам. Часть 2. – Новосибирск: НГТУ, 2004. – 23 с.

16. Р.Г. Шахмаметов, О.В. Лауферман Информатика. Учебное пособие. Часть 1. – Новосибирск: НГТУ, 2005. – 72 с.

17. О.В. Лауферман Информатика. Методические указания к курсовой работе. – Новосибирск: НГТУ, 2005. – 39 с.

18. Шахмаметов Р.Г. Сетевые вычисления на базе интеллектуальных агентов: Учеб. пособие. – Новосибирск: Изд-во НГТУ, 2004. – 68 с.

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

Дата добавления: 2014-11-14; просмотров: 440; Нарушение авторских прав

Мы поможем в написании ваших работ!