Новые книги

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

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

Цель этой книги — научить вас работать с DirectDraw, а не предоставить некоторую «структурную основу» или нестандартный API, который бы выполнял за вас всю работу. Демонстрационные программы написаны на C++ и используют MFC, но совсем не для того, чтобы скрыть все технические подробности. С++ и MFC — превосходные инструменты, потому что с их помощью любое приложение можно написать несколькими разными способами. Примеры для этой книги были написаны так, чтобы при этом получались структурированные и удобные для чтения проекты, которые наглядно показывают, что и почему происходит в программе.

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

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

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

Инкапсуляция на сетевом уровне: X.25 поверх TCP, IPX поверх IP



 

Инкапсуляция на сетевом уровне: X.25 поверх TCP, IPX поверх IP

Метод инкапсуляции часто применяется, когда двум сетям, использующим один и тот же сетевой протокол, нужно связаться через транзитную сеть, которая работает с другими сетевыми протоколами. Примером могут служить две сети Х.25, которым нужно связаться между собой через сеть TCP/IP.

В таких случаях сетевой протокол транзитной сети считается протоколом более низкого уровня, чем сетевой протокол объединяемых сетей (рисунок 3.2). Поэтому пакеты сетевого протокола сопрягаемых сетей Х.25 инкапсулируются в пакеты TCP транспортного уровня транзитной сети TCP/IP пограничным маршрутизатором М1, и переносятся в пакетах TCP по транзитной сети до следующего пограничного маршрутизатора М2. Для переноса по сети TCP/IP пакеты TCP в соответствии с технологией этой сети помещаются в пакеты IP, которые инкапсулируются в кадры протокола канального уровня, например, РРР. Пограничный маршрутизатор М2 извлекает пакет Х.25 из пакета TCP и отправляет его по сети Х.25 в соответствии с правилами этого протокола - то есть предварительно установив виртуальное соединение с узлом назначения по адресу Х.25_S1, а затем отправив по этому виртуальному соединению прибывший пакет.

Рис. 3.2. Соединение сетей X.25 через транзитную сеть TCP/IP методом инкапсуляции

Реализация такого подхода требует от протокола сетевого уровня объединяемых сетей разработанных процедур нахождения адреса пограничного маршрутизатора М2 в транзитной сети TCP/IP по адресу сети назначения протокола Х.25. Обычно такие протоколы называют протоколами разрешения адресов - Address Resolution Protocol, ARP. Если бы такой протокол был определен для сети Х.25, то он бы должен оперировать с ARP-таблицей, подобно той, которая приведена на рисунке 3.2. Эта таблица содержит для каждого адреса сети назначения Х.25 соответствующий IP-адрес пограничного маршрутизатора, через который эту сеть можно достичь.

К сожалению, многие сетевые протоколы разрабатывались или в расчете на работу только в сетях своего стека протоколов ( например, протокол Х.25), или в расчете на работу только через локальные сети (например, протокол IPX).

Наибольшую гибкость при инкапсуляции своих пакетов в пакеты других сетевых протоколов демонстрирует протокол IP. Для него разработано семейство протоколов ARP, каждый из которых предназначен для выполнения процедуры инкапсуляции пакетов IP в определенный протокол - Ethernet, Х.25, frame relay, ATM и т.п.

Протокол Х.25 рассчитан на инкапсуляцию только в кадры протокола LAP-B, который в свою очередь передает эти кадры между соседними коммутаторами, соединенными выделенными каналами "точка-точка". Процедуры и таблицы нахождения локальных адресов соседних коммутаторов при передачах пакетов Х.25 не предусмотрены, так как в них нет надобности, если трафик не выходит за пределы сети Х.25. Поэтому для передачи пакетов Х.25 через сети с другим стеком протоколов процедуры разрешения адресов и форматы инкапсуляции необходимо определять отельным стандартом.

Похожая ситуация возникает при необходимости передачи пакетов протокола IPX через сети TCP/IP. Процедуры передачи пакетов через составные локальные сети в протоколе IPX предусмотрены. Однако, из-за того, что в протоколе IPX на сетевом уровне для задания адреса узла просто дублируется аппаратный адрес сетевого адаптера, процедуры отображения сетевого адреса узла на локальные адреса транзитных сетей здесь отсутствуют. Поэтому, для протокола IPX, как и для протокола Х.25, необходимо разработать дополнительный протокол для того, чтобы этот протокол мог использовать сети TCP/IP как транзитные.

Спецификация "cisco Systems X.25 over TCP (XOT)"

Стандартный способ для передачи трафика сетей Х.25 через сети TCP/IP предусмотрен в спецификации RFC 1613, имеющей название "cisco Systems X.25 over TCP (XOT)", разработанный сотрудниками компании cisco Systems и организации JANET.

Эта спецификация определяет способ инкапсуляции пакетов Х.25 в сообщения TCP для переноса их по магистральной сети TCP/IP.

Так как протокол Х.25 работает на основе установления соединения, то спецификация использует для инкапсуляции протокол TCP, который также работает с установлением соединения. Для каждого виртуального соединения Х.25 маршрутизатор, который поддерживает стандарт XOT, устанавливает отдельное TCP-соединение с другим пограничным маршрутизатором. Новое TCP-соединение устанавливается при поступлении из сети Х.25 служебного кадра Call Request, запрашивающего новое соединение и несущего Х.25-адрес узла назначения. Спецификация XOT не предусматривает какого-либо способа определения IP-адреса маршрутизатора-партнера по сети IP, поэтому наиболее целесообразно использовать ее для случая, когда такой партнер один, или же маршрутизатор должен иметь таблицу соответствия адресов Х.25 и IP-адресов маршрутизаторов-партнеров, сформированную вручную.

После установления TCP-соединения все пакеты Х.25, принадлежащие данному виртуальному соединению сети Х.25, передаются в сообщениях TCP, принадлежащих этому TCP-соединению. Так как протокол TCP ориентирован на передачу неструктурированного потока байт, то стандарт ХОТ имеет небольшой заголовок, состоящий из 4-х байт, для выделения пакетов Х.25 в потоке байт сообщений TCP.

Спецификация "Tunneling IPX Traffic through IP Networks"

Для туннелирования пакетов IPX через магистрали TCP/IP компания Novell предложила спецификацию "Tunneling IPX Traffic through IP Networks", которая была утверждена в качестве стандарта RFC 1234.

Спецификация использует инкапсуляцию пакетов IPX в пакеты протокола UDP. Это объясняется тем, что протокол IPX является дейтаграммным протоколом, поэтому удобнее для его транспортировки использовать также дейтаграммный протокол UDP.

Транзитная IP-сеть вместе с объединяемыми IPX сетями рассматривается в этой спецификации как одна IPX-сеть, поэтому узлы по разные стороны IP-сети должны иметь один и тот же сетевой IPХ-адрес.

Спецификация RFC 1234 предлагает автоматизировать процесс поиска маршрутизатора-партнера в сети IP за счет прямого преобразования МАС-адреса узла на фиктивный IP-адрес этого же узла. Адрес узла в приходящем для транзитной передачи IPX-пакете состоит из 6 байт. Для получения IP-адреса назначения пакета, который будет переносить данный IPX-пакет, старшие два байта адреса узла отбрасываются, а оставшиеся 4 рассматриваются как IP-адрес.

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

Широковещательные пакеты сервиса SAP предлагается распространять на индивидуальной основе, то есть путем дублирования пакета всем узлам сети IPX через сеть IP.

Предыдущая глава | Оглавление | Следующая глава