Внутренний протокол маршрутизации RIP
4.4.11.1 Внутренний протокол маршрутизации RIP
Семенов Ю.А. (ГНЦ ИТЭФ)
IP-адрес места назначения.
Метрика маршрута (от 1 до 15; число шагов до места назначения).
IP-адрес ближайшего маршрутизатора (gateway) по пути к месту назначения.
Таймеры маршрута.
Первым двум полям записи мы обязаны появлению термина вектор расстояния (место назначение – направление; метрика – модуль вектора). Периодически (раз в 30 сек) каждый маршрутизатор посылает широковещательно копию своей маршрутной таблицы всем соседям-маршрутизаторам, с которыми связан непосредственно. Маршрутизатор-получатель просматривает таблицу. Если в таблице присутствует новый путь или сообщение о более коротком маршруте, или произошли изменения длин пути, эти изменения фиксируются получателем в своей маршрутной таблице. Протокол RIP должен быть способен обрабатывать три типа ошибок:
Циклические маршруты. Так как в протоколе нет механизмов выявления замкнутых маршрутов, необходимо либо слепо верить партнерам, либо принимать меры для блокировки такой возможности.
Для подавления нестабильностей RIP должен использовать малое значение максимально возможного числа шагов (
Медленное распространение маршрутной информации по сети создает проблемы при динамичном изменении маршрутной ситуации (система не поспевает за изменениями). Малое предельное значение метрики улучшает сходимость, но не устраняет проблему.
Несоответствие маршрутной таблицы реальной ситуации типично не только для RIP, но характерно для всех протоколов, базирующихся на векторе расстояния, где информационные сообщения актуализации несут в себе только пары кодов: адрес места назначение и расстояние до него. Пояснение проблемы дано на рис. 4.4.1.11.1 ниже.
Рис. 4.4.11.1. Иллюстрация, поясняющее возникновение циклических маршрутов при использовании вектора расстояния.
На верхней части рисунка показана ситуация, когда маршрутизаторы указывают маршрут до сети в соответствии со стрелками. На нижней части связь на участке GW1 оборвана, а GW2 по-прежнему продолжает оповещать о ее доступности с числом шагов, равным 2. При этом GW1, восприняв эту информацию (если GW2 успел передать свою маршрутную информацию раньше GW1), может перенаправить пакеты, адресованные сети А, на GW2, а в своей маршрутной таблице будет характеризовать путь до сети А метрикой 3. При этом формируется замкнутая петля маршрутов. Последующая широковещательная передача маршрутных данных GW1 и GW2 не решит эту проблему быстро. Так после очередного обмена путь от gw2 до сети А будет характеризоваться метрикой 5. Этот процесс будет продолжаться до тех пор, пока метрика не станет равной 16, а это займет слишком много циклов обмена маршрутной информацией.
Проблема может быть решена следующим образом. Маршрутизатор запоминает, через какой интерфейс получена маршрутная информация, и через этот интерфейс эту информацию уже не передает. В рассмотренном выше примере GW2 не станет посылать информацию о пути к сети А маршрутизатору GW1, от которого он получил эти данные. В этом случае в маршрутной таблице GW1 путь до А исчезнет сразу. Остальные маршрутизаторы узнают о недостижимости сети А через несколько циклов. Существуют и другие пути преодоления медленных переходных процессов. Если производится оповещение о коротком пути, все узлы-получатели воспринимают эти данные немедленно. Если же маршрутизатор закрывает какой-то путь, его отмена фиксируется остальными лишь по тайм-ауту. Универсальным методом исключения ошибок при маршрутизации является использование достаточно большой выдержки, перед тем как использовать информацию об изменении маршрутов. В этом случае к моменту изменения маршрута эта информация станет доступной всем участникам процесса маршрутизации. Но все перечисленные методы и некоторые другие известные алгоритмы, решая одну проблему, часто вносят другие. Многие из этих методов могут при определенных условиях вызвать лавину широковещательных сообщений, что также дезорганизует сеть. Именно малая скорость установления маршрутов в RIP (и других протоколах, ориентированных на вектор расстояния) и является причиной их постепенного вытеснения другими протоколами.
Но даже усовершенствование, изложенное выше, не всегда срабатывает. На рис. 4.4.11.1а приведен пример, когда переходной процесс, несмотря на усовершенствование будет идти долго. При обрыве связи В-Г узлы А и Б сообщают узлу В, что они потеряли связь с узлом Г. Узел В делает вывод, что Г не достижим, о чем и сообщает узлам А и Б. К сожалению А знает, что Б имеет проход к Г длиной 2, из чего он делает вывод о достижимости Г за три шага. Аналогично рассуждает Б о возможности достижимости Г через А. Далее при последующих рассылках метрика доступности Г, характеризуется все большими значениями, до тех пор пока не станет равной "бесконечности".
Рис. 4.4.11.1а. Пример топологии, где переходной процесс осуществляется медленно, даже при усовершенствовании алгоритма.
В RIP сообщения инкапсулируются в udp-дейтограммы, при этом передача осуществляется через порт 520. В качестве метрики RIP использует число шагов до цели. Если между отправителем и приемником расположено три маршрутизатора (gateway), считается, что между ними 4 шага. Такой вид метрики не учитывает различий в пропускной способности или загруженности отдельных сегментов сети. Применение вектора расстояния не может гарантировать оптимальность выбора маршрута, ведь, например, два шага по сегментам сети ethernet обеспечат большую пропускную способность, чем один шаг через последовательный канал на основе интерфейса RS-232.
Маршрут по умолчанию имеет адрес 0.0.0.0 (это верно и для других протоколов маршрутизации). Каждому маршруту ставится в соответствие таймер тайм-аута и "сборщика мусора". Тайм-аут-таймер сбрасывается каждый раз, когда маршрут инициализируется или корректируется. Если со времени последней коррекции прошло 3 минуты или получено сообщение о том, что вектор расстояния равен 16, маршрут считается закрытым. Но запись о нем не стирается, пока не истечет время "уборки мусора" (2мин). При появлении эквивалентного маршрута переключения на него не происходит, таким образом, блокируется возможность осцилляции между двумя или более равноценными маршрутами. Формат сообщения протокола RIP имеет вид, показанный на рис. 4.4.11.2. Поле команда определяет выбор согласно следующей таблице:
Таблица 4.4.11.1. Значения кодов поля команда
Команда
Значение
Инициализация
, определение всех "живых" интерфейсов путем посылки запросов, получение таблиц маршрутизации от других маршрутизаторов. Часто используются широковещательные запросы.
Получен запрос. В зависимости от типа запроса высылается адресату полная таблица маршрутизации, или проводится индивидуальная обработка.
Получен отклик. Проводится коррекция таблицы маршрутизации (удаление, исправление, добавление).
Рис. 4.4.11.2. Формат сообщения RIP.
Регулярные коррекции. Каждые 30 секунд вся или часть таблицы маршрутизации посылается всем соседним маршрутизаторам. Могут посылаться и специальные запросы при локальном изменении таблицы. RIP достаточно простой протокол, но, к сожалению не лишенный недостатков:
RIP не работает с адресами субсетей. Если нормальный 16-бит идентификатор ЭВМ класса B не равен 0, RIP не может определить является ли не нулевая часть cубсетевым ID, или полным IP-адресом.
RIP требует много времени для восстановления связи после сбоя в маршрутизаторе (минуты). В процессе установления режима возможны циклы.
Число шагов важный, но не единственный параметр маршрута, да и 15 шагов не предел для современных сетей.
Протокол RIP-2 (RFC-1388, 1993 год) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг; позволяет работать с масками субсетей. На рис. 4.4.11.3 представлен формат сообщения для протокола RIP-2. Поле маршрутный демон является идентификатором резидентной программы-маршрутизатора. Поле метка маршрута используется для поддержки внешних протоколов маршрутизации, сюда записываются коды автономных систем. При необходимости управления доступом можно использовать первые 20 байт с кодом набора протоколов сети 0xFFFF и меткой маршрута =2. Тогда в остальные 16 байт можно записать пароль.
Рис. 4.4.11.3 Формат сообщений протокола RIP-2
Проблемы аутентификации в протоколе RIP-2 c использованием дайджестов MD5 обсуждаются в документе RFC-2082
Вопросы по данному курсу
8.1 Вопросы по данному курсу
Семенов Ю.А. (ГНЦ ИТЭФ)
Программу для проверки знаний по курсам этого сервера читатель может найти по адресу: saturn.itep.ru (knowtest). Список вопросов там почти в два раза длиннее.
В чем смысл 7-уровневой модели ISO?
Просто 7 круглое число.
Необходимо для стандартизации оборудования на каждом из уровней.
Связано с обеспечением идентичности форматов данных и протоколов на соответствующих уровнях для передатчика и приемника.
Соответствует числу дней в неделе и помогает унифицировать запись даты.
Как осуществляется синхронизация в региональных сетях Интернет?
Выполняется привязка к точному эталону времени.
Производится разводка синхронизующих сигналов для всех узлов от общего источника.
Производится синхронизация от локальных часов
Выполняется привязка к сигналам, которые служат для передачи данных
Зачем нужна преамбула в пакетах Ethernet?
Туда записывается характеристика последующего пакета
Служит для синхронизации приемника
Позволяет выделить начало пакета
Служит для прерывания приема в случае, когда не зарегистрирован конец предшествующего пакета
Чему равно число мод N в оптическом волокне диаметром d, с числовой апертурой А для длины волны l?
N = (2p2dA)/l
N = (2p2d2A2)/l2
N = 2p2dAl2
N = (2p2d2A2)/l4
Почему интеграл любого достаточно длинного фрагмента передаваемого кода должен быть равен нулю?
Иначе напряжение на входе приемника может меняться произвольным образом, что в конце концов приведет к пробою во входных цепях.
Позволяет стабилизировать порог выделения логического нуля и логической единицы из-за наличия на входе трансформаторов или конденсаторов
Это необходимо, чтобы отделить передаваемый сигнал от входного при использовании одной скрученной пары
Это помогает улучшить отношение сигнал-шум.
Что такое числовая апертура волокна А?
А = SQRT(n12 - n22)
А = SQRT(n12 + n22)
А = SQRT(n1 - n2)
А = arcsin(n1/n2)
Чему равно усиление G антенны с площадью А для длины волны l?
G = 4pA/l4
G = 4pAl2
G = 4pA/l2
G = 4pAl4
Чему равен угол излучения антенны радиусом R для длины волны l?
T = 0,61l/R2
T = 0,61l2/R2
T = 0,61l2/R4
T = 0,61l/R
Где по частоте применение радиоканалов ограничивается поглощением волн в атмосфере?
2,5 ГГц
20 ГГц
30 ГГц
100 ГГц
Чему равен максимальный размер сети 10Мбит/с Ethernet, если не использовать маршрутизаторы, бриджи или переключатели?
2,5 км
500м
2км
200 м
Что общего между сетями X.25, ISDN, Frame Relay и ATM?
Формат контрольной суммы
Набор кодов управляющих команд
Формат стартового и оконечного разделителей пакетов
Метод формирования виртуального канала
Какой зависимостью уровня сигнала характеризуются городские сотовые сети?
Амплитуда сигнала обратно пропорциональна расстоянию (сказываются отражения от стен зданий)
Амплитуда сигнала обратно пропорциональна квадрату расстояния
Уровень сигнала обратно пропорционален третьей степени расстояния
Уровень сигнала обратно пропорционален четвертой степени расстояния
Зачем используется многоуровневое кодирование сигнала?
В этом случае одному перепаду соответствует несколько бит кода
Это упрощает кодирующее оборудование
Это позволяет проверить корректность процедуры кодирования
Это улучшает отношение сигнал-шум
Зачем нужна эквилизация при формировании телекоммуникационного канала?
Эквилизация - это выравнивание условий передачи всех частот в пределах полосы пропускания
Эквилизация - это выравнивание порогов чувствительности приемника и передатчика
Эквилизация - это эхоподавление для всего спектра частот полосы пропускания
Эквилизация - это выравнивание отношения сигнал-шум для всего рабочего спектра частот
Что такое межсимвольная интерференция?
Это влияние определенных кодовых последовательностей на распознавание кодов, следующих за ними
Это ошибки, происходящие из-за наложения кодов символов
Это метод сжатия информации
Это искажение кодов за счет расплывания волновых пакетов
Что ограничивает число уровней при кодировании входного сигнала?
Возможности современной твердотельной технологии
Разрядность используемых АЦП
Ухудшение отношения сигнал-шум
Может возникнуть ситуация, когда выходное и входное устройство настроены на разное число уровней
В чем отличие PPP и SLIP?
Это два названия одного и того же протокола
Один из них рассчитан на последовательную, а другой - на параллельную передачу данных
Один использует CRC, а другой нет
PPP может работать с разными вложенными пакетами
Как заполняется память моста MAC-типа?
Это делает администратор, занося адреса объектов, подключенных к каждому порту
Мост исследует сетевое окружение и записывает результаты в память
Он использует информацию, содержащуюся в приходящих пакетах
Пользователи регистрируются в мосту сами при подключении.
Если ЭВМ может связаться с ЭВМ через обычный MAC-мост Б1, а ЭВМ может связаться с через такой же мост Б2, что от этого можно ожидать? Как это факт можно диагностировать?
Можно ожидать ускорения обмена между машинами и улучшения надежности, так как имеются два независимых канала связи
Все будет так, как если бы был один канал, так как обмен может идти только через один из каналов
Такая сеть работать не может
Для нормальной работы сети мосты должны поддерживать алгоритм "расширяющееся дерево"
Как осуществляется синхронизация станций в сетях CAN?
От стандартного эталона времени
Синхронизация вообще не нужна
Синхронизация осуществляется между передаваемыми порциями данных
Так как здесь используется схема доступа CSMA, то и синхронизация происходит, как в Ethernet посредством преамбулы.
В процессе преобразования звука в код используются m и A-преобразования. Зачем они нужны и в чем их отличие?
Это методы логарифмического преобразования, которые нужны для того, чтобы кривая преобразования прошла через начало координат
А-преобразование является линейным и служит для изменения масштаба преобразуемых величин
В Европе используется А-преобразование, а в США m
m-преобразование позволяет обеспечить лучшую точность
Для чего используется дифференциальный метод в процессе преобразования аналогового сигнала в цифровую последовательность кодов?
Дифференциальный метод улучшает отношение сигнал шум
Дифференциальный метод позволяет получить большую точность преобразования
Дифференциальный метод позволяет использовать корреляцию последовательных значений уровня сигнала
Дифференциальный метод позволяет исключить влияние вариации потенциала земли на результат преобразования
Что определяет минимальный размер пакета в сети Ethernet?
Размер заголовка + длина контрольной суммы
Минимальный размер равен заголовку + CRC + один байт
Минимальный размер зависит от типа пакета (IEEE 802.3, Ethernet II или SNAP) Минимальный размер пакета равен 64 байтам
Механизм коллапса в CSMA/CD?
Происходит просто при переполнении буферов
Из-за синхронизации передачи при большом числе столкновений
Из-за ограничения пропускной способности кабелей и сетевого оборудования
Реализуется, когда загрузка сегмента сети становится равной 10Мбит/c
Оцените пропускную способность телевизионного кабеля (российского; полоса ~60 MГц) в Мбит/c
Пропускная способность составляет 60 Мбит/c
Пропускная способность составляет 600 Мбит/c
Пропускная способность составляет 6000 Мбит/c
Пропускная способность составляет 12000 Мбит/c
Принципы работы виртуальных сетей на MAC-уровне
Виртуальные сети на МАС-уровне - это модель, используемая для описания работы обычной сети, например Ethernet
Виртуальные сети на МАС-уровне работают точно так же, как и на IP-уровне
При использовании технологии виртуальных сетей отдельные каналы переключателя невозможно использовать
В случае виртуальных сетей на МАС-уровне каналы переключаются так, что пакеты из заданных каналов могут попасть только в строго определенные каналы.
Почему оборудование для работы с мультимодовыми волокнами дешевле?
Это определяется конъюнктурой, сложившейся на рынке
Утверждение не верно, мультимодовое волокно предъявляет более жесткие требования к оборудованию
Одномодовое волокно имеет меньшую входную и выходную апертуру
В случае одномодового волокна оборудование должно выделять определенную моду световой волны.
Почему в Fast Ethernet может быть один повторитель первого класса и 2 – второго? Повторитель первого класса имеет большую задержку
Это жестко определено действующим стандартом
Повторители второго класса имеют большую полосу пропускания
В случае использования повторителя первого класса никакие другие повторители просто не нужны
Зачем нужны модемы (почему не передается непосредственно цифровой сигнал)?
Модем нужен, чтобы улучшить отношение сигнал-шум
Модем применяется для того, чтобы сделать канал более безопасным (усложнить перехват данных)
Модем нужен для преобразования аналогового сигнала в цифровой
Модем нужен для преобразования аналогового сигнала в цифровой и обратно
Для чего используются микромодемы?
Микромодемы используются, когда требуется минимизировать размер модема
Когда расстояние между приемником и получателем не допускает использование обычного модема
Когда расстояние мало, но нужно произвести изоляцию приемника и получателя по "земле"
Когда для передачи данных используется шина "MicroChannel"
Как модем осуществляет настройку на канал? Какие параметры при этом определяются?
Настройка производится при инсталляции
Настройка производится по-разному в зависимости от модели модема
Производится автоматическое согласование возможностей модемов на обоих концах канала
Минимизируется отношение сигнал шум
Что будет, если оконечная сигнатура не будет обнаружена сетевым интерфейсом?
Сеть прекратит работу и потребуется вмешательство администратора
Будет послан сигнал Jabber и сеть продолжит свою работу
Оконечная сигнатура будет выработана самим принимающим интерфейсом
Ситуация будет воспринята и обработана как случай столкновения
Особенности доступа к сети CAN?
Схема доступа полностью идентична Ethernet
Используется схема маркерного доступа
Применяется схема CSMA с анализом приоритета доступа
Используется схема доступа с фиксированной вероятностью начала передачи
Особенности сетей DQDB
Эти сети пригодны для организации конвейерной обработки в многопроцессорной системе
Это сети с двойной очередью и двойной шиной, схема с маркерным доступом
Сети DQDB имеют кольцевую структуру и предназначены для управления в реальном масштабе времени
Сети DQDB обеспечивают двойное качество и двойную полосу пропускания
Чем отличается сеть HIPPI от всех остальных сетей?
Эти сети используют параллельную схему передачи данных
Здесь используется особо скоростная последовательная схема обмена
Эта сеть обеспечивает необычно большую длину кабельных сегментов
В HIPPI применена нестандартная схема доступа к сетевой среде
VOCODER (Почему символьное отображения фразы всегда короче закодированного и сжатого его звукового образа?)
Символы используют оптимально короткие коды
При символьном отображении применяются более эффективные алгоритмы сжатия
При сжатии кодированного звука блоки данных имеют ограниченную длину, так как длинные блоки привели бы к слишком большим задержкам. А для коротких блоков нельзя достичь хорошего сжатия.
При символьном отображении отсутствуют индивидуальные особенности речи говорящего
Что такое эффект маскирования?
Влияние масок в процессе преобразования звука в код
Маскирующий эффект ограниченной полосы пропускания канала
Эффект связан с понижением чувствительности уха при частотах выше некоторой составляющей частоты высокой амплитуды
Эффект, аналогичный эхоподавлению, но для случая передачи звуковой информации
На чем базируется преимущество оптоволокна над медным кабелем?
Оптоволокно при равном сечении прочнее
Оптоволокно обеспечивает лучшее отношение сигнал-шум
Оптоволокно обеспечивает меньшее ослабление сигнала на километр
Отоволокно исключает влияние разностей потенциалов земель между передатчиком и приемником
В чем суть алгоритма “расширяющееся дерево”?
Это алгоритм, обеспечивающий оптимальную маршрутизацию в сетях Интернет
Это алгоритм, который решает проблему циклических маршрутов в локальной сети
Алгоритм помогает подключать новых членов в мультикастинг-группу
Алгоритм используется при рассылке мультимедийных данных
Чем наложенная сеть отличается от физической?
Наложенная сеть дешевле физической и по этой причине используется чаще
Физическая сеть работает поверх наложенной, что обеспечивает большую надежность
Наложенная сеть может обеспечить большую пропускную способность, что и обеспечивает ее привлекательность
Наложенная сеть работает поверх физической
Как может быть потерян пакет в локальной сети (согласно принципам SNMP-статистики)?
Пакет теряется при столкновении
Пакет теряется при переполнении буфера
Пакет теряется, если его получение не подтверждено
Пакет не может быть потерян в локальной сети никогда
Что такое блокировка при работе с socket?
Блокировка связана с тем, что пока выполняется одна процедура и процессор занят, другая процедура ждет своей очереди
Блокировка связана с ситуацией вызова процедуры ACCEPT в отсутствии запросов в очереди
Блокировка сопряжена с ожиданием завершения процедуры ввода/вывода
Блокировка вызывается ожиданием формирования socket
Пригодны ли сокеты для работы в протоколах, отличных от TCP/IP?
Нет, сокеты применимы только в рамках стека протоколов TCP/IP
Работа сокетов наcтраивается заданием определенных конфигурационных параметров
Сокеты могут использоваться с любыми телекоммуникационными протоколами
Сокеты применимы не только в TCP/IP
В чем проблема использования идеологии UNIX при сетевом обмене без установления связи?
UNIX при работе с socket не использует IP-адреса и нужно позаботиться об установлении соответствия между сокетом и IP-адресом
В UNIX любая процедура ввода/вывода рассматривает файл и внешнее устройство неотличимыми друг от друга
В UNIX любая процедура ввода/вывода предполагает, известными отправителя и получателя до начала обмена
В UNIX нет таймеров и по этой причине возникают проблемы при обрывах связи
Какие параметры обязательно задаются при конфигурировании сети?
IP-адрес ЭВМ
IP-адрес ЭВМ + маска субсети + IP-адрес маршрутизатора + IP-адрес DNS + IP-адрес сервера времени
Ничего задавать не нужно, если работает система plug&play
IP-адрес ЭВМ + маска субсети + IP-адрес маршрутизатора + IP-адрес DNS
Алгоритм вычисления CRC
Последовательность бит пакета делится на образующий полином, результат деления и является CRC
Коды, составляющие пакет, последовательно складываются. Если возникает флаг переноса, добавляется 1 к младшему биту
Коды пакета складываются по модулю 2 (исключающее ИЛИ)
Последовательность бит пакета делится на образующий полином, инвертированный остаток от деления и является CRC
Как можно измерить вероятность потери пакета в сети?
С использованием протокола SNMP
С помощью протокола ICMP
C помощью протокола Finger
Путем применения 6-го режима работы сетевого интерфейса
Методы измерения потоков в работающей сети
Путем подсчета числа пакетов, идущих по кабельному сегменту
По числу столкновений в сегменте сети
Посредством протокола SNMP
С помощью маршрутизатора
Почему базовая скорость канала ISDN равна 64 кбит в сек?
Это связано с полосой пропускания коммутируемого телефонного канала
Это число выбрано как 2 в 6-ой степени (могло быть выбрано и другое число)
Эта полоса пропускания удобна для формирования иерархии пропускных способностей цифровых каналов (например, SDH)
Эта полоса пропускания обеспечивает ровно 4 стандартных телефонных канала
Что происходит при сжатии информации?
Удаляются повторяющиеся нули, пробелы и знаки TAB
Удаляются вообще все повторяющиеся подряд символы
Производится преобразование исходного кодового текст путем циклических сдвигов
Заменяются одни кодовые последовательности на другие
Можно ли превзойти по эффективности алгоритм сжатия Хафмана?
Нельзя; Практически невозможно;
Легко и это практически всегда делается
Это возможно лишь в некоторых случаях
Как детектируются ошибки
Для детектирования ошибок используется кратность 8 длины Ethernet-пакета
Для детектирования ошибок используется CRC-суммирование на TCP-уровне
Для детектирования ошибок используется суммирование по модулю 1 на UDP-уровне
Для детектирования ошибок используются коды Хэмминга
Методы коррекции ошибок
Для исправления ошибок используется CRC-контрольные суммы
Для исправления ошибок используется продольный и поперечный контроль по четности
Для исправления ошибок используется методика контрольного суммирования по модулю 2
Для исправления ошибок используются коды Хэмминга
Как формируется виртуальный канал в X.25 или ISDN?
С использованием протокола ARP
С использованием протокола SNMP
На основе протокола X.3
С помощью процедуры SETUP
В чем X.25 и ISDN уступают Интернет и почему?
Интернет более универсален;
Он обеспечивает больший спектр услуг;
В Интернет можно получить большее быстродействие
Интернет обеспечивает большую надежность.
Можно ли дистанционно определить неработающий канал повторителя?
Можно, если повторитель снабжен SNMP-поддержкой
Нельзя, так как повторитель является пассивным сетевым прибором и не откликается на PING
Можно в любом случае, если к данному каналу подключена работающая ЭВМ
Это можно реализовать, применив режим 6 сетевого интерфейса
Метод маркерного доступа (чем лучше и чем хуже Ethernet?)
Ethernet удобнее для задач реального времени, так как может обеспечить большую пропускную способность
Ethernet привлекательнее, так как не накладывает ограничений на топологию сети
Маркерный доступ лучше, так как не ограничивает предельного размера локальной сети
Маркерный доступ лучше для решения задач управления в реальном масштабе времени, так как здесь имеется механизм приоритетного доступа
Зачем в каналах телефонной сети используются трансформаторы?
Для организации питания телефонного оборудования от сети переменного тока
Для отделения звукового сигнала от постоянного напряжения, передаваемого по телефонному кабелю
Для изоляции по переменному току с целью обеспечения безопасности пользователя
Для улучшения отношения сигнал-шум
Пришел пакет в интерфейс ISDN, к которому подключен телефон, факс и ЭВМ. Как интерфейс определит, какому из приборов его передать?
По тому, с каким из этих устройств была установлена связь на фазе выполнения SETUP
По адресу места назначения, как в TCP/IP
По значению поля SAPI и TEI
По значению поля тип оборудования
Как задается адрес TEI в ISDN?
Администратором при инсталляции системы
Автоматически интерфейсом NE1
Автоматически интерфейсом NE2
Часть адресов задается пользователем, а часть автоматически
Почему в Ethernet сегодня чаще используются скрученные пары, а не коаксиальный кабель?
Скрученная пара дешевле;
Ее проще монтировать;
Это диктуется фирмами-производителями оборудования;
Пара обеспечивает большую безопасность.
Как в последовательном канале выявляется начало и конец пакета?
По времени;
По изменению полярности сигнала;
По специальной сигнатуре;
По концу предыдущего пакета определяется начало следующего.
Как лучше разместить сервер и почему (буквой К обозначен концентратор)?
Лучше первый метод (верхний вариант)
Второй
Оба эквивалентны
Это зависит от типа используемого оборудования и от типа среды (скрученная пара, коаксиальный кабель или оптоволокно)
Тот же вопрос для случая, когда вместо сервера стоит переключатель
Лучше первый метод
Второй
Оба эквивалентны
Это зависит от типа используемого оборудования и от типа среды (скрученная пара, коаксиальный кабель или оптоволокно)
В чем проблемы передачи звука по каналам Интернет (канал имеет пропускную способность 32 кбит/c)?
Ограничение полосы, что приводит к потерям пакетов;
Нелинейные искажения из-за вариации времени передачи;
Малая управляемость;
Конкуренция сессий, что приводит к потере фрагментов.
Аудио или видео канал должны иметь высший приоритет при передаче данных?
Видео, так как он является более информационно емким
Аудио
Каналы должны иметь равный приоритет, так как в равной мере важны
Это зависит от общей пропускной способности канала
В чем отличие PDH и SDH?
PDH используется для асинхронной передачи, а SDH для синхронной
PDH ориентирован на работу с сетями ISDN, а SDH с Интернет
PDH американский стандарт передачи данных, а SDH - европейский
PDH при извлечении блока данных требуется полная разборка контейнеров, а в SDH - нет
Что определяет максимальное число повторителей в Ethernet (
Это записано в стандарте и по этой причине нужно выполнять эту регламентацию
Это диктуется требованиями ограничения задержки в субсети
При большом числе повторителей неизбежны искажения сигналов
При большем числе повторителей увеличится сверх меры суммарная загрузка субсети
Можно ли построить фрагмент сети Ethernet, в котором не будет столкновений?
Невозможно
Сейчас трудно из-за ограничений современных технологий
Можно
Это зависит от версии используемого протокола
Как получается 100Мбит/с в сетях 100BASET4?
Используется 3 скрученные пары для передачи в одном направлении
Используется 4 скрученные пары для передачи в одном направлении
Используется 2 скрученные пары, как и в случае 100base-TX
Для решения задачи используется специальный троичный код
Что ограничивает длину кольца в FDDI?
Тип используемого оптического волокна
Тип используемого оборудования
Это зависит от того, DAS или SAS узлы используются
Это зависит от длины волны используемого излучения
Cколько маркеров может находиться одновременно в сети FDDI?
Один
Два
Четыре
Это зависит от длины кольца
Почему Ethernet мало приемлем для задач реального времени?
Нет Ethernet-интерфейсов для подключения измерительного оборудования
Не гарантирована задержка реакции сети на событие
Слишком большая величина RTT
Слишком малое значение MTU
Как можно уменьшить число широковещательных пакетов в сетях Windows-95 и NT?
С помощью разделения сети на субсети с помощью переключателей
Введя NT-сервер
Запретив рассылку широковещательных запросов на фазе конфигурации рабочей станции
Поделив сеть на субсети с помощью маршрутизаторов
Что нужно согласовывать при построении канала из Европы в США?
Не нужно ничего согласовывать, так как применены международные стандарты
Нужно согласовывать скорости передачи
Нужно согласовывать кодировку, так как там используются разные схемы логарифмического преобразования
Нужно использовать специальные шлюзы, так как стандарты совершенно не имеют ничего общего
Чем определяется максимальный размер пакета в Ethernet? Почему нельзя увеличивать размер пакета беспредельно?
Слишком длинный пакет блокировал бы сетевой сегмент на слишком долгое время
Слишком длинные пакеты приводили бы к переполнению буфера сетевого интерфейса
Максимальная длина пакета определяется величиной TTL
Максимальная длина пакета задается значением BER
В чем заключается функция процедуры BIND?
Она устанавливает соответствие между созданным сокетом и IP-адресом
Она устанавливает связь между двумя сокетами
Она организует структуру очереди запросов для конкретного сокета и переводит систему в режим ожидания
Процедура BIND используется только в случае подготовки обмена с установлением соединения
Что ограничивает пропускную способность локальной сети?
Величина TTL
Значение MTU
Значение window
Величина времени жизни ARP-кэша
Какой длины поле CRC используется в сети ATM?
1 байт
2 байта
4 байта
10 бит
В какой сети предусмотрено выравнивание информационных потоков передатчика и приемника при перегрузке на физическом уровне?
Интернет
ISDN
Ethernet
Frame Relay
Можно ли построить сеть FDDI с длиной 100 км и числом станций 1000?
Можно
Нельзя, так как это запрещено протоколом
Это зависит от типа используемого кабеля
Это зависит от фирмы изготовителя оборудования
Что такое эхоподавление?
Это метод компенсации отражений из-за рассогласования кабелей
Это метод подавления отражений от стен при передаче звукового сигнала
Это способ подавления наводок со стороны соседних проводов при передаче сигнала по многопроводным кабелям
Это метод исключения влияния передачи на прием при работе с одной скрученной парой
Что больше NEXT или FEXT?
Все зависит от типа используемого кабеля
NEXT > FEXT
FEXT > NEXT
Обычно они равны
Зависимость NEXT от частоты передаваемого сигнала
NEXT пропорционально f (частоте)
NEXT пропорционально f1.5
NEXT пропорционально f2
NEXT пропорционально logf
Зависимость пропускной способности канала I от ширины полосы пропускания F
I = F log2(1+S/N)
I = F ln(1+S/N)
I = F lg(1+S/N)
I = (S/N)log2F
Как осуществляется синхронизация передатчика и приемника в Ethernet, нужна ли такая синхронизация?
Такая синхронизация не нужна, так как размеры сети не велики
Для синхронизации используется преамбула кадра
Для синхронизации используется стартовый разграничитель кадра
Для целей синхронизации используются все пакеты, которые следуют по сетевому сегменту
Почему оптоволоконные сети часто имеют кольцевую топологию?
Это определяется международным стандартом
Кольцо используется только при реализации схемы маркерного доступа
Это связано с тем, что по волокну можно передавать сигнал только в одном направлении
Кольцевая схема позволяет обеспечить меньшую вероятность ошибки при передаче
Чем отличаются каналы Е1 от Т1?
Е1 - европейское название канала, а Т1 -американское
Е1 имеет большую пропускную способность, чем Т1
Т1 имеет большую пропускную способность, чем Е1
Это два разных названия одного и того же канала
Что такое расстояние Хэмминга?
Это расстояние между узлами Интернет, выраженное в числе канальных сегментов между ними
Это разница длин кодов
Это номер бита, начиная с которого, два кода отличаются друг от друга
Это число бит, которыми отличаются коды равной длины друг от друга
В чем отличие полудуплексного от полнодуплексного каналов в случае сети Ethernet?
Первый требует одну скрученную пару (или оптическое волокно), а второй - две
Первый тип канала обеспечивает почти вдвое меньшую пропускную способность
Во втором типе канала не возможны столкновения
Эти два вида каналов эквивалентны, и в равной мере могут использоваться в сети Ethernet
Что ограничивает теорема Найквиста-Котельникова?
Теорема ограничивает пропускную способность канала в зависимости от уровня шумов
Теорема регламентирует минимальную частоту стробирования в зависимости от спектра входного сигнала
Теорема ограничивает предельно допустимое значение отношения сигнал-шум
Теорема ограничивает предельное значение ослабления сигнала при заданном отношении сигнал-шум
В чем особенности протокола NetBIOS?
Протокола NetBIOS облегчает маршрутизацию в рамках локальной сети
Протокола NetBIOS имеет собственную систему DNS
Символьные имена в протоколе NetBIOS распределяются динамически
Протокол NetBIOS упрощает построение корпоративных сетей с далеко отстоящими субсетями
Для чего используются адаптивные уровни ATM?
Для устранения разброса задержек, выявления ячеек, доставленных не по адресу
Для оптимальной адаптации к требованиям прикладной задачи
Для решения задачи укладки ячеек в виртуальные контейнеры
Для устранения сегментации пакетов и их восстановления, для мониторирования ошибок в управляющей информации
Основные особенности протокола Frame Relay?
Эта сеть может лучше противостоять перегрузкам, чем ISDN или Интернет
Эта сеть обеспечивает меньшие задержки, большую эффективность и пропускную способность, чем ISDN
Эта сеть ориентирована на межсетевые коммуникации
Эта сеть гарантирует пользователю определенную квоту пропускной способности
Особенности структуры и использования виртуальных контейнеров SDH?
Виртуальные контейнеры SDH имеют большие размеры, чем PDH
Более мелкие контейнеры должны занимать предопределенные позиции в более крупных контейнерах, что облегчает разборку их получателем
Иерархия контейнеров требует кратности размеров влагаемых модулей
Более мелкие контейнеры могут размещаться произвольным (плавающим) образом в больших виртуальных контейнерах
Кто уничтожает пакеты в сети FDDI (уничтожаются ли они вообще)?
Пакеты не уничтожаются, а используются повторно
Пакеты уничтожаются специально выделенным узлом (генератором маркеров и уборщиком мусора)
Пакеты уничтожаются получателем
Пакеты уничтожаются отправителем
При каких условиях будет работать такая локальная сеть?
Такая сеть будет работать при любых условиях
Такая сеть может работать, если переключатели SW1 и SW2 правильно сконфигурированы
Такая сеть может работать, если убрать мост BR2
Такая сеть может работать, если сетевые приборы поддерживают протокол "расширяющееся дерево"
Вопросы по курсу “Протоколы и ресурсы Интернет”
Какие запросы должен послать клиент, перед тем как будет установлена связь в рамках протокола TCP?
Запросы DNS и ARP
Всегда можно сразу послать запрос на установление связи
Один запрос ARP
Запросы DNS и 2*ARP
За счет чего можно идентифицировать отправителя сообщения?
Отправителя всегда можно идентифицировать по его IP-адресу, записанному в дейтограмме
Отправитель может быть идентифицирован на фазе авторизации
Отправитель идентифицируется с помощью электронной подписи
Отправитель идентифицируется с помощью его сертификата
Для чего используется регистр CSR?
Этот регистр используется для определения номера порта
Этот регистр определяет направление обмена данными
Регистр задает величину задержки при обработке прерывания в сетевом интерфейсе
Регистр контролирует состояние сетевого интерфейса
Для чего в Интернет введено понятие AS?
AS введено для упорядочения регистрации узлов в Интернет
AS используются для улучшения работы системы DNS-серверов
Без AS не может работать протокол BGP
AS введены для сокращения объема маршрутных таблиц
Какие параметры нужны для конфигурирования драйвера сетевой карты?
Никакие параметры задавать не нужно, все всегда определяется автоматически операционной системой
Задается адрес входной точки драйвера сетевой карты
При конфигурировании драйвера сетевой карты используется значение аппаратного прерывания, логический номер прерывания и блок портов
Задается имя драйвера сетевой карты
Какие задачи решает протокол RTCP?
Этот протокол выполняет для RTP те же функции, что и TCP для обычных процедур в Интернет
RTCP обеспечивает обратную связь для контроля качества при рассылке данных
RTCP служит для передачи управляющей информации
RTCP резервирует сетевые ресурсы для RTP
За счет чего обеспечивается безопасность транзакций в протоколе SET?
Исключительно за счет сертификатов отправителей
За счет электронных подписей отправителей сообщений и шифрования
Главным образом за счет подтверждений корректности операций со стороны партнеров
За счет аутентификации
Почему протокол SSL не может заменить протокол SET?
Эти протоколы не совместимы
SSL не может гарантировать секретности передачи номера кредитной карточки
SSL слишком медленен и не пригоден для интерактивной работы
Методы аутентификации SSL не согласуются с требованиями, налагаемыми на финансовые транзакции
В чем отличие протоколов DVMRP и PIM?
PIM более современный протокол маршрутизации и превосходит DVMRP по всем параметрам
PIM предназначен для работы с рассеянными группами, а DVMRP - c компактными
DVMRP предназначен для резервирования сетевых ресурсов, а PIM - для маршрутизации
DVMRP служит для подключения клиентов к группе, а PIM для целей мониторинга
В чем отличие процедур Ping и Traceroute?
Ping базируется на протоколе ICMP, а Traceroute на определенной опции непосредственно IP-протокола
Это две утилиты базируются на одном и том же протоколе и имеют практически идентичные функции
Эти утилиты базируются на протоколе ICMP, но Ping проверяет доступность узла, а traceroute - маршрут до него
Ping посылает больше пакетов, чем traceroute
Как работает протокол NTP?
NTP служит для получения меток времени от внутренних часов ЭВМ
NTP служит для поддержания первичных эталонов времени
NTP предназначен для калибровки внутренних часов с использованием первичных эталонов
NTP нужен для решения проблем синхронизации и калибровки часов в сети
В чем отличие POP-3 от IMAP?
IMAP просто новая версия POP-3
IMAP обеспечивает более высокий уровень безопасности
IMAP обеспечивает большую скорость пересылки
IMAP предлагает более гибкую систему почтовых ящиков
Какие алгоритмы использует PGP?
В PGP применен алгоритм шифрования DES
В PGP применен алгоритм шифрования RSA
В PGP применена электронная подпись и алгоритм шифрования IDEA
В PGP применен алгоритм шифрования SAFER
Как формируются ключи в алгоритме RSA?
Для получения ключей использован алгоритм Эль-Гамаля (y=gx mod p)
Для получения ключей использован алгоритм Диффи-Хелмана (A = gx mod n
Для шифрования здесь используется формула F(M) = Md mod n
Для получения ключей используется методика вычисления целочисленного логарифма
В чем отличие IPv6 от IPv4 кроме длины адресов?
В IPv6 разрешена мультикастинг-адресация, а в IPv4 - нет.
В IPv6 разрешена эникастинг-адресация
В IPv6 протокол IGMP заменен на ICMP
Для совместимости с IPv4 все функции IPv6 такие же, как и сейчас
Что такое эникастинг-адресация?
Эникастинг-адресация заменила в IPv6 широковещательную адресацию
Эникастинг-адресация является модификацией уникастинг-адресации
Эникастинг-адресация предполагает посылку мультикастинг запроса, при этом адресоваться будет узел, откликнувшийся первым
Эникастинг-адресация это название мультикастинг-адресации в IPv6
Зачем нужна сетевая маска?
Это нужно для организации субсетей
Это необходимо для обеспечения дополнительных мер безопасности
Этим достигается уменьшение количества широковещательных пакетов
Маска используется при шифровании передаваемых данных
Может ли поле версия в пакете IP находится в другом месте и почему?
Это поле может находиться где угодно, лишь бы был известен формат пакета
Поле версия находится всегда в конце пакета, так как это однозначно определяет его положение
Поле версия нужно лишь в случае, когда применяется принудительная маршрутизация, тип опции и определяет положение поля
Поле версия может находиться только в начале пакета
Зачем используется псевдо-заголовок в пакетах UDP?
Псевдозаголовок используется для определенных опций протокола UDP
Псевдозаголовок используется при вычислении контрольной суммы, чтобы контролировать корректность доставки UDP-дейтограмм
Применение псевдозаголовка необязательно (опционно)
Псевдозаголовок служит для уточнения функции дейтограммы
Стандартный номер порта для TCP один, как обеспечивается многопользовательский доступ, ведь сокет в этом случае тоже вроде бы один, а совместное его использование в TCP запрещено?
Для решения проблемы каждый раз берется новый номер порта
Разделение осуществляется по номеру порта и IP-адресу клиента, активизирующего канал
Запросы обслуживаются по очереди
Многопользовательское обслуживание предусмотрено самим протоколом TCP
Как работает иерархия серверов DNS?
Вышестоящие DNS-серверы заранее снабжают исчерпывающей информацией локальный сервер
Локальный DNS, запрашивает вышестоящие DNS, при отсутствии информации. Получив нужные данные, он хранит их и использует при последующих запросах
Если нужной информации не найдено, локальный DNS посылает широковещательный IP-запрос
Если нужной информации не найдено, посылается запрос в IN-addr.ARPA
Как по IP-адресу можно определить имя объекта?
Для этого посылается запрос локальному DNS
Для этого посылается запрос серверу IN-ADDR.ARPA
Для этого посылается запрос в национальный DNS
Этот запрос удовлетворяется региональным или локальным сервером DNS
Причины самопроизвольного размножения DNS запросов
Это может быть вызвано неверной маршрутизацией запросов
Это может быть спровоцировано ошибками в конфигурационных файлах выше стоящих DNS-серверов
Это может быть сопряжено с мультикастинг-запросами
Это может быть вызвано неверным содержанием конфигурационного файла DNS
Причины зацикливания пакетов в локальной сети
В силу особенностей протокола Ethernet это невозможно
Это возможно из-за наличия циклических путей через MAC-мосты и переключатели
Это возможно в случае использования протокола IGRP при значении вариации > 1
Это возможно при использовании протокола RIP
Причины зацикливания пакетов в региональной сети
Наличие циклического пути Использование маршрутов по умолчанию Неверный выбор параметров внешнего протокола маршрутизации Осцилляция маршрутов
Почему время установления маршрута для протокола RIP обычно больше, чем для OSPF или IGRP?
На самом деле установление маршрута в RIP быстрее (алгоритм проще) Это происходит из-за больших постоянных времени заложенных в протоколе RIP Сказывается специфика метрики, используемой в протоколах Установление маршрута в RIP занимает несколько циклов обновления пока метрика не достигнет значения 15
Всегда ли в маршрутизаторе используется только одна маршрутная таблица?
Всегда одна
Число маршрутных таблиц равно числу значений QOS
Число маршрутных таблиц зависит от выбранного значения TTL
Число таблиц определяет сетевой администратор при инсталляции
Сколько протоколов маршрутизации при пересылке в режиме уникастинга может активно поддерживать маршрутизатор?
Один Два
Три
Сколько угодно, зависит от модели маршрутизатора
Если удвоить максимально возможное значение метрики RIP, переходные процессы установления маршрута:
Удлинятся
Не изменятся
Станут короче
Это зависит от четности метрики
Чем отличается RIP от RIP-II? (в чем преимущества одного перед другим?)
В RIP-II переходные процессы установления маршрута происходят быстрее
RIP-II поддерживает использование субсетей, а RIP нет
В RIP-II возможен больший диапазон значений метрики
RIP-II может работать с адресами IPv6
Что общего и в чем отличия протоколов OSPF и IGRP?
Это несопоставимые протоколы
OSPF использует всю маршрутную информацию о всей сети, а IGRP - только информацию от ближайших соседей
OSPF может распараллеливать потоки данных, а IGRP нет
В OSPF метрика задается администратором, а в IGRP вычисляется независимо
Как задается метрика в протоколах маршрутизации RIP, OSPF, IGRP.
Все эти протоколы используют маршрутизацию, базирующуюся на векторе расстояния
В этих протоколах метрика задается администратором сети
В протоколах OSPF и IGRP метрика вычисляется на основе измерений свойств каналов, а в RIP определяется числом шагов до адресата
В протоколе OSPF метрику задает администратор, а в IGRP она вычисляется маршрутизатором
Причины осцилляции маршрутов и способы их устранения
Осцилляции маршрутов возможны при наличии циклических маршрутов из-за образования обратной связи
Осцилляции маршрутов возможны только при использовании маршрутов по умолчанию
Причиной осцилляции является медленное распространение информации об изменениях маршрутов
Осцилляции маршрутов возможны при использовании определенных типов маршрутизаторов
Что может являться причиной того, что пакет от точки А к точке Б движется по одному маршруту, а обратно - по другому?
Применен IP-туннель
Не верно задана метрика маршрутов
Ошибочно сконфигурирован DNS-сервер
Не верно описана маршрутная политика
Какую информацию может вернуть ARP-запрос в различных ситуациях?
ARP-запрос всегда возвращает MAC-адрес, соответствующий IP-адресу
Результат зависит от конфигурации DNS-сервера
При определенных условиях может быть возвращен MAC-адрес Gateway
При определенных условиях может быть возвращен адрес DNS-сервера
Методы атак против протокола TCP
Атака возможна только в случае, если атакующая машина находится на пути от клиента к серверу
Возможна атака за счет сбоя ISN-нумерации пакетов
Возможна атака с помощью фальсификации CRC
Атаки на TCP-уровне невозможны. Если бы это было не так, стали бы возможны атаки практически на любые процедуры Интернет, ведь практически все они базируются на протоколе TCP
Атаки против протокола HTTP
Возможна атака сразу после перехода сервера на технологию IPv6
Возможна атака с помощью имитации хакером работы в качестве сервера
Возможна атака с помощью создания ложного DNS
Возможна атака путем искусcтвенного понижения уровня аутентификации
Сопоставить протоколы UDP и TCP
UDP устаревший протокол и он везде, где только возможно, должен быть заменен TCP, который обеспечивает гарантированную доставку
UDP имеет меньшую избыточность по заголовку и по этой причине должен применяться везде, где только возможно
Каждый из этих протоколов имеет строго очерченную область применения (UDP - загрузка Х-терминалов, SNMP и т.д., а TCP - FTP, HTTP и пр.)
UDP используется в локальных сетях и для мультимедиа, а TCP (в основном в региональных) для информационного обмена, где требуется высокая надежность доставки
В чем принципиальное отличие традиционных протоколов маршрутизации и мультикастинговых?
В традиционном методе маршрут прокладывается от отправителя к получателю, а при мультикатинге наоборот.
Никакого отличия нет, уникастные и мультикастные пакеты маршрутизируются одинаково c использованием стандартных протоколов
Маршрут оптимизируется для группы участников мультикастинга
Для решения задач мультикастинга используются специальные маршрутизаторы и поэтому здесь нечего сравнивать.
Почему в IPv6 выбрана длина адреса в 4 длиннее, чем в IPv4?
Это сделано для того, чтобы раз и навсегда решить проблему дефицита IP-адресов
Это сделано, чтобы разрешить эникастинг
Это сделано для расширения возможного списка предоставляемых услуг
Это сделано для того, чтобы облегчить переход от IPv4 к IPv6 и упростить маршрутизацию
Почему для мультимедиа используется протокол UDP, а не TCP?
Это связано с меньшими издержками протокола UDP (компактнее заголовок дейтограммы)
Техника применения TCP для этих целей пока не разработана
Для протокола UDP легче реализовать маршрутизацию
Повторная пересылка пакетов в TCP не приемлема для целей мультимедиа
Обосновать особенности протоколов маршрутизации, использующих вектор расстояния.
Медленные переходные процессы установления маршрута при изменении обстановки
Быстрые переходные процессы установления маршрута при изменении обстановки
Ограниченное максимальное значение метрики
Возможность зацикливания пакетов
Зачем нужен протокол RARP?
Для организации мультимедийного обмена
Для определения имени бездисковых рабочих станций
Для определения IP-адреса бездисковых рабочих станций
Для загрузки бездисковых рабочих станций
Для чего служит протокол BOOTP?
Для организации видеоконференций
Для загрузки Х-терминалов
Для инициализации локальной субсети
Для управления подключением к мультикастинг-группам
Зачем нужен протокол RTP, какие дополнительные преимущества он предоставляет приложению?
Этот протокол обеспечивает надежную доставку мультимедийных данных
В RTP имеется система задания приоритетов, что позволяет эффективно резервировать ресурсы для мультимедийной сессии
RTP несет в себе временные метки и за счет этого достигается лучшее качество воспроизведения звука и изображения
В RTP предусмотрены удобные средства для облегчения маршрутизации мультимедийных данных
Причины возникновения циклов сообщений в RSVP.
Первопричиной циклов могут стать сообщения PATH
Вызвать зацикливание может сообщение ResvErr
Привести к зацикливанию может посылка сообщения RESV
Вызвать зацикливание может сообщение PathErr
Что такое валидатор?
Валидатор представляет собой характеристику документа, обеспечивающую его безошибочную доставку
Валидатор используется для определения того, разрешен ли данному пользователю доступ к данному документу
Валидатор служит для контроля модификации документов
Валидатор используется в протоколе RSVP для уведомления успешного резервирования ресурса
Как реализуется механизм резервирования ресурсов и QOS в TCP/IP?
Рассылаются сообщения администраторам сети, с тем, чтобы они учли ваши требования
Используются соответствующие опции протокола IP
Используются соответствующие опции протокола ICMP
Используются служебные биты заголовка пакетов TCP
Как работает протокол POP-3?
Как обычный почтовый протокол
POP-3 просто один из графических интерфейсов для работы с первичным почтовым сервером
В результате диалога POP-3 забирает сообщения из почтового ящика пользователя и предоставляет их адресату
POP-3 почтовый протокол, который призван в перспективе заменить SMTP
В чем отличие почтовых систем, базирующихся на UUCP и SMTP?
UUCP использует в качестве транспортного протокол UDP, а SMTP - TCP
UUCP работает на ЭВМ с UNIX, а SMTP - на любых машинах
UUCP является более современной версией SMTP
SMTP - почтовый протокол Интернет, а UUCP команда UNIX
Зачем придумали MIME?
Этот протокол разработан исключительно для передачи мультимедийных данных
Этот протокол служит для расширения возможности SMTP при работе с различными наборами символов
Этот протокол используется для передачи новостей
Этот протокол имеет целью расширение возможностей протокола HTTP
Если один из узлов поддерживает MIME, а другой нет, как они об этом узнают и как будут взаимодействовать?
Для решения проблемы должны быть посланы запросы к серверу DNS (чтение ресурсных записей)
Все должно быть оговорено на фазе конфигурирования рабочей станции
Поддержка MIME определяется по соответствующему полю в заголовке пакета, инициализирующего соединение по порту 25
Используется стандартная последовательность команд протокола SMTP
Как работает протокол HTTP, какая программа сложнее – сервера или клиента и почему?
Сложнее программа сервера, ведь он обслуживает большое число запросов одновременно
Сложнее программа клиента, именно она выполняет львиную долю работы
Эти две программы идентичны и функционально могут меняться местами
Программа сервера сложнее, так как ей приходится адаптировать форматы данных по запросу клиента (графики, звука и пр.) перед их передачей
Почему протокол HTTP одержал победу над протоколом GOPHER?
Это произошло потому, что HTTP предоставляет более удобный графический интерфейс
HTTP запоминает маршрут поиска и позволяет продолжить его позднее с прерванного места, а GOPHER - нет
HTTP позволяет осуществлять поиск вдоль дерева ссылок, а GOPHER - нет
HTTP позволяет создавать прокси-сервера
Можно ли передавать произвольную пользовательскую информацию с помощью протокола ICMP?
Можно, для этого только нужно написать специальную программу
Нельзя, так как протокол предназначен исключительно для диагностических целей.
Нельзя, так как в случае необходимости фрагментации, выполнить ее будет нельзя (она реализуется только для пакетов UDP и TCP)
Нельзя, так как ICMP имеет слишком низкий приоритет при прохождении маршрутизаторов
В локальной сети машины передают информацию со скоростью 10 Мбит/с (или даже 100 Мбит/с), внешний канал сети имеет полосу в 1Мбит/с. Как эти скорости обмена согласуются на протокольном уровне?
Эта проблема решается заданием соответствующих параметров в Gateway/маршрутизаторе
Для согласования применяется протокол SNMP
Согласование осуществляется с использованием протокола ICMP
Проблема решается с помощью задания соответствующих флагов в пакетах TCP и параметров этого протокола
Почему для непосредственной передачи данных не используется IP-протокол (зачем-то используют TCP или UDP, а ведь это увеличивает протокольные издержки и снижает пропускную способность)?
Это задано 7-уровневой моделью и по этой причине надо выполнять данные регламентации
Это нужно, чтобы обеспечить каналы с установлением и без установления связи
Это имеет исключительно исторические причины
Это сделано для обеспечения работы IP-протокола с мультимедийными данными
Как осуществляется управление внешним протоколом маршрутизации BGP-4?
Задаются параметры при конфигурации системы
Используется протокол SNMP и база данных MIB
Управление осуществляется по специально выделенному последовательному каналу
Для решения задачи управления используется описание маршрутной политики и соответствующие базы данных RIB
Какими маршрутами управляет протокол BGP-4?
Исходящими из LAN в Интернет
Завершающимися в LAN
Транзитными, идущими через LAN
Любыми выше перечисленными маршрутами
Если существуют два соседних маршрутизатора, один из них поддерживает протокол BGP-3, а другой - BGP-4, как они будут взаимодействовать друг с другом?
Будет выбран BGP-3
Будет выбран BGP-4
Будет выбран какой-то другой протокол, например OSPF, если они оба его поддерживают
Будут поменяны параметры BGP-4, так чтобы он мог работать с партнером, поддерживающим BGP-3
Почему маршрутизатор работает как правило быстрее, чем программа с аналогичной функцией в быстродействующей ЭВМ?
Программа в маршрутизаторе лучше оптимизирована
В маршрутизаторе применяется очень быстродействующий процессор
В маршрутизаторе часть процедур выполняется на аппаратном уровне
В маршрутизаторе используется более быстродействующая память
В чем преимущества и недостатки подключение внешних клиентов к локальной сети через последовательный канал и бридж (напр., радиобридж) при условии равной пропускной способности?
Последовательный канал предоставляет удобные средства управления пропускной способностью, а бридж - нет.
Бридж предпочтительнее, так как он исключает паразитный транзитный трафик (например, мультикастинг)
Это два совершенно идентичные во всех отношениях решения
Последовательный канал предпочтительнее, когда подключается коммерческий клиент, так как легче измерить трафик
Как работает протокол Finger?
Finger устанавливает связь с объектом, после чего посылает пакет с форматом заголовка Finger, содержащим запрос
Finger получает нужную информацию, исполняя процедуру EXPN на ЭВМ адресата запроса
Finger базируется на процедуре REXEC
Finger обеспечивает интерфейс для удаленной программы пользователя RUIP
В чем может быть причина того, что после инсталляции сети ваши почтовые сообщения уходят, а посылаемые вам сообщения пропадают?
Неверно прописан IP-адрес вашего mail-сервера
Ошибка в конфигурации DNS
Ваш локальный почтовый сервер не известен региональному серверу
Неправильно сконфигурирован маршрутизатор или Gateway
Откуда DNS узнает адреса других серверов имен?
Из своих конфигурационных файлов
Из откликов на свои широковещательные запросы
Из информации других DNS, рассылаемой периодически
Из данных, введенных администратором при инсталляции
В чем отличие протоколов FTP от Telnet (с точки зрения алгоритма их работы)?
FTP использует Telnet для формирования командного канала
FTP не имеет ничего общего с Telnet, так как этот протокол служит для пересылки файлов, а telnet - для удаленного доступа
FTP и Telnet используют разные транспортные протоколы
В этих протоколах используются разные схемы контрольного суммирования
Зачем нужен протокол TFTP (ведь он представляет собой потенциальную угрозу сетевой безопасности)?
Это устаревший протокол, который не используется в настоящее время
Этот протокол служит лишь для тестирования каналов и локальной сети
Протокол используется для пересылки картинок WEB-броузерами
Этот протокол используется для загрузки Х-терминалов и для получения файлов-приложений при отправке электронной почты
Что делает поисковая система, когда не поступает запросов поиска информации?
Через какое-то время отключается и впадает в "спячку", откуда она выходит при поступлении первого запроса
Система занимается индексированием файлов
Система ищет новые серверы
Система перепроверяет корректность имеющихся у нее данных
Что такое анонимное FTP?
Это FTP, когда клиент не хочет, чтобы он был идентифицирован файл-сервером
Это режим файлового обмена, когда клиент организует обмен между двумя узами, отличными от его собственного
Это FTP, когда имя клиента равно anonymous
Это обмен, когда клиент не задает имени пересылаемого файла
Как можно устранить повторные ссылки на один и тот же документ в перечне, предлагаемом в качестве результата работы поисковой системы?
Надо каждый документ, помещаемый в депозитарий любого сервера снабдить уникальным идентификатором
Надо повторить запрос, видоизменив его так, чтобы повторных ссылок не было
Надо послать запрос поисковой системе, чтобы она убрала повторные ссылки из своего индекса
Можно запустить программу фильтрации для совокупности полученных ссылок
Можно ли отправить почтовое сообщение, не имея акаунтинга ни на одном из почтовых серверов?
Это невозможно
Это можно реализовать с помощью одной из опций протокола ICMP
Это возможно через HTTP и порт 80
Это можно сделать, используя процедуру telnet и порт 25
В чем назначение протокола ICMP в условиях сильно загруженного виртуального канала?
Протокол служит для сообщений о потере пакетов
Протокол используется для измерения RTT и оптимизации параметров пересылки
Протокол служит для контроля процента потерь пакетов и оптимального выбора маршрута передачи (выбор в случае примерно равных метрик маршрутов)
Протокол используется для понижения средней частоты посылки пакетов
Уязвимые точки почтового протокола SMTP
Возможность отправки сообщения без акаунтинга и почтового ящика на каком-либо почтовом сервере
Возможность получения частной информации с помощью команд VRFY и EXPN
Нельзя шифровать передаваемые сообщения
Не гарантируется доставка сообщения
Как влияет размер окна (например, в TCP или ISDN) на пропускную способность канала?
Чем шире окно, тем выше пропускная способность
Чем шире окно, тем меньше пропускная способность
Влияние размера окна проявляется по-разному в различных протоколах
Всегда существует оптимальный размер окна
Почему спутниковый и наземный канал с идентичными быстродействиями обеспечат разную пропускную способность при работе с TCP?
Спутниковый канал обеспечит большую пропускную способность из-за лучшего отношения сигнал-шум
Спутниковый канал имеет меньшую пропускную способность из-за большого RTT и ограничений по window
Эти оба варианта эквивалентны, так как использует один и тот же стек протоколов
Спутниковый канал лучше адаптируется к изменениям условий и по этому в среднем обеспечивает большую широкополосность
Что такое алгоритм медленного старта?
Он определяет процедуру формирования виртуального канала в протоколе TCP
Это алгоритм определяет процедуру вычисления значений таймаутов
Это алгоритм определяет установление правильного значения window после потри пакета
Он задает процедуры прерывания при возникновении оговоренного сетевого события
Почему пропускная способность канала при работе с TCP и 5% потерь пакетов может упасть вдвое?
Это зависит от используемого маршрутизатора
Это происходит при использовании фрагментации пакетов
Это происходит при больших значениях RTT
Это связано с процедурой "медленного старта" и повторными пересылками
Почему протокол TCP обычно не используется для передачи мультимедийных данных?
TCP не используется для этих целей из-за дороговизны
Из-за требований реального времени TCP создает чрезмерные издержки благодаря большому размеру заголовков
TCP не приемлемо из-за возможности "медленного старта"
Это бессмысленно, так как задержанная доставка ничего хорошего не даст
Методы улучшения эксплуатационных характеристик протокола TCP
Правильно выбрать значение TTL
Оптимизировать алгоритм вычисления RTT и его дисперсии
Заменить TCP на XTP или другой аналогичный протокол
Использование группового подтверждения
Для чего нужно TTL при передаче мультимедийных данных?
Нужно, чтобы правильно задать значения тайм-аутов
TTL используется при конфигурации протоколов маршрутизации (напр. PIM)
TTL здесь нужно, чтобы ограничить зону распространения мультимедийных данных
TTL нужно для того, чтобы блокировать зацикливание пакетов при адресных ошибках
Для чего используется TTL?
Для задания масштаба RTT
Для определения времени хранения почтовых сообщений в буфере
Для определения времени жизни информации в DNS-кэше
Для ограничения зоны распространения мультикастинг-информации
Для чего используется прокси-ARP?
Это версия ARP, используемая с прокси-серверами
Используется для выявления IP-адреса для бездисковых рабочих станций (Х-терминалов)
Версия протокола для разрешения адресных проблем при мультикастинге
Это версия протокола ARP для построения корпоративных сетей содержащих разбросанные субсети
Как будут взаимодействовать две рядом стоящие машины (общий сетевой сегмент), если у них IP-адреса из разных блоков С-класса?
Непосредственно. Пошлют ARP-запросы, получат соответствующие MAC-адреса друг друга и начнут обмен
Схема взаимодействия зависит от значений сетевых масок
Схема взаимодействия зависит от содержимого ARP-кэша
Будут вести обмен через ближайший Gateway
Как влияет значение и точность измерения RTT и его дисперсии на эффективную работу канала?
Чем больше RTT, тем лучше
Никак не влияет
Чем точнее измерения этих параметров, тем выше пропускная способность
Чем меньше RTT, тем больше пропускная способность
Может ли использоваться протокол SNMP для контроля потока с одного конкретного IP-адреса на другой? Можно ли организовать аналогичный контроль с учетом номера порта?
Нет, нельзя
Можно, если использовать маршрутизатор
Можно, если использовать модель переключателя, поддерживающую SNMP и подключенного к сегменту, где среди прочих стоит исследуемая станция
Можно, если переключатель, к которому среди прочих подключена данная ЭВМ, поддерживает VLAN
Зачем в пакетах SNMP используется поле community?
Для объединения фрагментов MIB в единое целое
Поле community предназначено для формирование пользователей, запрашивающих идентичную информацию, в группы
Поле community используется для выбора определенной версии MIB
Поле выполняет функцию пароля
Как обновляется содержимое прокси-сервера?
Обновление содержимого происходит при каждом запросе клиента
Обновление осуществляется при несовпадение валидаторов записи в кэше и объекта исходного сервера
Обновление происходит при запросе объекта, который отсутствует в кэше
Обновление записи происходит при истечение ее срока годности
Что такое метод в HTTP?
Метод определяет способ установления связи между клиентом и прокси или между прокси и исходным сервером
Метод - это процедура GET реализуемая по требованию клиента
Метод определяет схему обновления содержимого прокси-сервера
Метод определяет процедуру, выполняемую для выбранного ресурса
Почему использование IP-туннеля может породить асимметричность путей пакета и отклика на этот пакет?
Асимметричность путей может возникнуть из-за разной маршрутной политики маршрутизаторов, находящихся в начале и в конце туннеля
При правильной конфигурации туннеля асимметричности путей не возникнет
Асимметричность пути туда и обратно невозможна, так как этому воспрепятствуют маршрутизаторы
Асимметричность путей возможна, так как маршрут задается адресом места назначения, а этот адрес разный на пути к адресату и на пути к концу туннеля
Базовые методы обеспечения безопасности WWW-серверов
Шифрование адреса места назначения
Шифрование имени сервера
Применение протокола SSH
Применение сертификатов для идентификации пользователя и протокола SSL
В чем отличие протоколов безопасности SSH, SET и SSL?
Протоколы SSH, SET и SSL служат для целей обеспечения безопасности при удаленном доступе для разных операционных сред
Протокол SET служит для организации торговли в Интернет, SSH для безопасного удаленного доступа, а SSL - для безопасного доступа к WWW
SSH допускает использование сертификатов, а остальные нет
SET позволяет однозначно идентифицировать отправителя, а SSL и SSH - нет
В чем заключаются принципы маршрутной политики?
Маршрутная политика определяет региональные принципы взаимодействия системы маршрутизаторов
Маршрутная политика определяет взаимосогласованные подходы администраторов автономных систем к проблемам маршрутизации
Маршрутная политика - синоним маршрутизации
Маршрутная политика определяет, какую маршрутную информацию маршрутизатор воспринимает, какую рассылает, как на основании имеющихся данных формируются маршрутные таблицы
Могут ли локальные сети разных, удаленных друг от друга организаций принадлежать одной автономной системе?
Нет, не могут
Могут, если имеют общую администрацию
Могут, если имеют одного сервис провайдера
Могут, если проводят идентичную маршрутную политику
Как система узнает, что клиент покинул группу (IGMP)?
Клиент уведомляет непосредственно отправителя информации перед выходом из группы
Клиент уведомляет локальный Gateway перед выходом из группы
Клиент сообщает всем членам группы о выходе
Клиент просто не подтверждает свое членство в группе
Как реализуется функция IGMP в рамках протокола IPv6?
IGMP входит в стек TCP/IP и его функции в IPv6 остаются неизменными
В IPv6 его функции выполняет протокол SNMP
В IPv6 его функции выполняет протокол ICMP
В IPv6 его функции выполняет протокол RSVP
Какие утилиты используются при поиске людей и узлов, на каких протоколах они базируются?
Этой цели служит протокол NNTP
Этой цели служит протокол Finger
Этой цели служит протокол DNS
Этой цели служит протокол SMTP
В чем особенности работы службы новостей?
Протокол NNTP аналогичен другим протоколам стека TCP/IP, имеет свой формат пакетов и прочие атрибуты
Протокол работает с использованием сообщений-откликов
Протокол работает с использованием протокола UDP
Система новостей базируется на протоколе SMTP
Как определяется степень соответствия документа запросу (релевантность) в системах информационного поиска?
Это делается по значению идентификатора документа, присваиваемому ему в процессе индексации
Это делается по числу ключевых слов из запроса, присутствующих в документе
Это делается в соответствии с величиной W = log(N/n)+1, где N - число документов, а n - число документов, где встречается данное ключевое слово
Это делается в соответствии с величиной (Nзн2)/Nс, где Nзн - число ключевых слов в документе, а Nс - полное число слов
Как работают подписные листы (LISTSERV)? (принцип работы, возможности, предоставляемые пользователю)
Подписные листы служат для получения информации по заданной тематике, система работает так же, как система рассылки новостей
Подписные листы формируются администратором и позволяют рассылать сообщения всем, кому хочет администратор
Подписной лист может иметь встроенную базу данных для хранения текстов и программ
Подписные листы формируются самими участниками
В чем отличие X-Windows от Windows-NT?
Windows-NT - операционная система, а X-Windows система клиент-сервер
X-Windows работает под UNIX, а Windows-NT - нет
Отличия относятся исключительно к сфере приложений
Windows-NT обеспечивает несравненно лучшую сетевую безопасность
Введение (общие принципы построения сетей)
1 Введение (общие принципы построения сетей)
Семенов Ю.А. (ГНЦ ИТЭФ)
Интернет является сетью виртуальных сетей. В 1991 году у нас (тогда еще в СССР) о нем знали несколько десятков человек, которые только что освоили электронную почту (через RELCOM) и попробовали, что такое FidoNet. Первое сообщение по электронной почте было послано президентом США Биллом Клинтоном 2 марта 1993 года. Первая новелла Стивена Кинга была опубликована по каналам Интернет 19 сентября 1993 года (до появления печатной копии), к тому же году относится начало синхронной передачи радио-программ по сетям Интернет. В конце 1993 года заработала первая очередь оптоволоконной опорной сети Москвы, полностью профинансированная Джорджем Соросом. В 1994 году НАТО организовало первую конференцию по Интернет в России (в Голицыно под Москвой). С помощью DFN (Deutsche Forschung Naetze), а затем Дж. Сороса и RELARN круг любителей Интернет расширился до сотен и тысяч, а после включения программ Минвуза и Министерства науки РФ счет пошел на десятки тысяч. Это произошло прежде всего потому, что созрели условия - в различных учреждениях (сначала научных, а затем коммерческих и государственных) и у частных лиц оказались сотни тысяч персональных ЭВМ. К этому же времени (1992-93 годы) в мире стала формироваться сеть депозитариев, доступных через анонимный доступ (FTP), а несколько позднее и WWW-серверов. На рис. 1.1 показан рост числа ЭВМ, подключенных к Интернет по годам с 1989 по 1998 годы. Видно, что рост числа узлов сети имеет экспоненциальный характер. Можно смело утверждать, что протоколы Интернет, созданные для осуществления связи в случае нанесения десятков ядерных ударов по США со стороны СССР, явились одним из немногих (возможно единственным) положительным результатом холодной войны.
Рис. 1.1. Рост числа ЭВМ, подключенных к Интернет в период 1989-98 годы (по вертикальной оси отложено число ЭВМ в миллионах)
Сегодня, когда Интернетом заинтересовались широкие массы трудящихся, и определенная часть их подключилась к расширению этой сети, стала актуальной проблема оптимального проектирования сетей и их подключения к общенациональной и международной сети Интернет.
Проектировщикам и создателям сетей приходится учитывать многие десятки факторов при выборе того или иного типа сети, сетевого оборудования, операционной системы (UNIX, MS-DOS, IRIS, Windows-NT, SOLARIS или что-то еще), программного обеспечения, внешних каналов связи (выделенный канал, коммутируемая телефонная сеть, цифровая сеть, радио или спутниковый канал) и в конце концов сервис-провайдера. За всем этим стоят как технологические проблемы, так и финансовые трудности, тяжелый выбор между дешевой и хорошей сетью.
Если вас интересуют оригинальные тексты протоколов Интернет, вы можете получить их, например, через анонимное FTP по адресу ds.internic.net (в каталоге RFC) или на нашем сервере store.in.ru/rfcs (зеркало). Эти документы можно найти и в других депозитариях.
Документы RFC делятся на стандарты, проекты стандартов, временные (экспериментальные) регламентации и предложения. Чем больше номер RFC, тем более поздней дате этот документ соответствует. О статусе тех или иных RFCможно узнать из RFC-1500 и -1780 (см. также файл std-inde.txt из того же депозитария, что и rfc-index.txt). Если вы хотите найти какой-то RFC-документ, начните с просмотра индексного файла (напр. rfc-index.txt). Первый документ RFC был выпущен в 1969 году более 30 лет тому назад. Далее темп публикаций варьировался в довольно широких пределах, в 1997-99 годах наблюдается заметный всплеск активности, связанный с потребностями мультимедиа (RTP, RSVP, PIM и т.д.), безопасностью и IPv6. Вариация публикаций документов RFC по годам представлена на рис 1.2.
Рис. 1.2. Распределение публикаций документов RFC по годам с 1969 по 1999
Из этого распределения видно, что к 1979 году окончательно сформировался стек базовых протоколов и начался экстенсивный рост сети Интернет. По мере выявления недостатков протоколов и новых потребностей после 1989 года началась активная разработка новых направлений и приложений в Интернет.
Но все по порядку. Начнем с того, как устроен Интернет. На рис. 1.3 показана общая схема, которая облегчит дальнейшее обсуждение данной проблематики (буквами R отмечены маршрутизаторы-порты локальных сетей).
Каждая из сетей, составляющих Интернет, может быть реализована на разных принципах, это может быть Ethernet (наиболее популярное оборудование), Token Ring (вторая по популярности сеть), ISDN, X.25, FDDI или Arcnet. Все внешние связи локальной сети осуществляются через порты-маршрутизаторы (R). Если в локальной сети использованы сети с разными протоколами на физическом уровне, они объединяются через специальные шлюзы (например, Ethernet-Fast_Ethernet, Ethernet-Arcnet, Ethernet-FDDI и т.д.). Выбор топологии связей определяется многими факторами, не последнюю роль играет надежность. Использование современных динамических внешних протоколов маршрутизации, например BGP-4, позволяет автоматически переключаться на один из альтернативных маршрутов, если основной внешний канал отказал. Поэтому для обеспечения надежности желательно иметь не менее двух внешних связей. Сеть LAN-6 (см. рис. 1.3) при выходе из строя канала R2-R6 окажется изолированной, а узел LAN-7 останется в сети Интернет даже после отказа трех внешних каналов.
Широкому распространению Интернет способствует возможность интегрировать самые разные сети, при построении которых использованы разные аппаратные и программные принципы. Достигается это за счет того, что для подключения к Интернет не требуется какого-либо специального оборудования (маршрутизаторы не в счет, ведь это ЭВМ, где программа маршрутизации реализована аппаратно). Некоторые протоколы из набора TCP/IP (ARP, SNMP) стали универсальными и используются в сетях, построенных по совершенно иным принципам.
Рис. 1.3. Схема построения сети Интернет
В некотором смысле Интернет возник эволюционно - в начале был Bitnet, fidonet, usenet и т.д. Со временем стало ясно, что конкуренция сетей должна быть заменена их объединением, так как от этого выигрывают все и пользователи и сервис-провайдеры. Ведь объединенная сеть имеет большие информационные ресурсы, может предложить более широкий список услуг и становится по этой причине привлекательной для еще большего числа клиентов.
Технология WWW- серверов сделала Интернет важной средой для целевой рекламы, приближенной к конечному потребителю. Стремительный рост числа узлов www продемонстрирован на рис. 1.4. Здесь также наблюдается экспоненциальный рост. Сам факт использования Интернет для обливания грязью кандидатов во время предвыборной компании, говорит о том, что эта технология освоена и признана эффективной нашими политиками. Наше общество с удивительным упорством сначала осваивают все негативное, оставляя, очевидно, позитивное на десерт.
Рис. 1.4. Рост числа узлов WWW в период 1994-99 годы
В перспективе Интернет может стать и всемирной ярмаркой товаров и услуг. Ведь клиент может не только увидеть изображение товара и ознакомиться с условиями поставки, но и в диалоговом режиме получить ответы на интересующие его вопросы, а затем одним нажатием на клавишу мышки сделать заказ на понравившийся ему товар или услугу. В принципе для этого не нужен даже номер кредитной карточки, его заменит зашифрованный соответствующим образом идентификатор пользователя (сертификат) или его IP-адрес (если он работает на своей домашней машине). Таким образом, можно будет заказывать билеты на самолет или в театр, планировать программу своего телевизора на неделю вперед и т. д.
Современные системы мультимедиа позволяют совместить телевизор, видеомагнитофон, факс и видеотелефон, причем это не фантазия на тему далекого будущего - это услуги доступные уже сегодня (при наличии широкополосного канала связи (64-512 Кбит/с)). Если вы имеете доступ к Интернет, вам уже не нужно платить за международные телефонные переговоры, вы можете сделать это с помощью ip-phone или другого аналогичного продукта, при условии что ваш партнер также имеет доступ к Интернет (данное требование в ближайшем будущем перестанет быть обязательным). Все более широкий круг услуг предлагает Интернет и в сфере развлечений. Здесь имеются игровые серверы, аренда обычных и сетевых компьютерных игр, различные конкурсы и соревнования.
Теперь рассмотрим, как строятся каналы связи (стрелки на рис. 1.5). В простейшем случае связь можно организовать через городскую коммутируемую телефонную сеть, для этого нужны модемы - по одному на каждой из сторон канала (Рис. 1.5a). Традиционные модемы могут обеспечить при хорошем качестве коммутируемой аналоговой телефонной сети пропускную способность до 56 Кбит/с (кабельные широкополосные модемы при длине соединения порядка 2км могут обеспечить 2 Мбит/с). Привлекательность такого решения заключается в возможности подключения к любому узлу, имеющему модемный вход. Наиболее широко указанный метод связи используется для подключения к узлам Интернет домашних ЭВМ. Недостатком такого решения является низкая надежность канала (особенно в России), малая пропускная способность и необходимость большого числа входных телефонных каналов и модемов.
Использование выделенной 2- или 4-проводной линии (рис. 1.5Б) обеспечивает большую надежность и пропускную способность (до 256 кбит/с при длинах канала < 10 км). Но и здесь на каждый вход требуется отдельный модем, да и скоростные модемы, работающие на выделенную линию, относительно дороги. Выделенные линии чаще служат для межсетевого соединения (рис. 1.5В). Функциональным аналогом выделенных линий являются оптоволоконные, спутниковые и радио-релейные каналы. Этот вариант позволяет строить сети с пропускной способностью в несколько 1-100 Мбит/с и более.
Привлекательные возможности предлагают цифровые сети ISDN. Здесь можно использовать групповые телефонные номера, когда пара модемов обслуживает 10 и более пользователей (ведь они работают, как правило, не все одновременно). Кроме того, ISDN предлагает пользователям каналы с пропускной способностью не ниже 64кбит/c, а при необходимости возможно формирование и более широкополосных каналов. ISDN позволяет делить один и тот же канал между многими пользователями для передачи данных, факсов и телефонных переговоров. isdn органично стыкуется с внешними каналами X.25. К недостаткам системы следует отнести ограниченность ширины окна (число переданных пакетов без получения подтверждения приема), что делает неэффективным использование широкополосных и особенно спутниковых каналов. В области межсетевых связей свою нишу занимает Frame Relay. Этот протокол имеет контроль перегрузок, работающий на аппаратном уровне
Рис. 1.5. Схемы каналов, использующих городскую телефонную сеть
На рис. 1.5 показана схема построения сети с использованием исключительно соединений типа точка-точка. Это наиболее часто встречающийся, но не единственный вариант. Дорога 'от околицы до околицы' прокладывается там, где она нужна и теми, кому она нужна непосредственно, но, согласитесь, построить так магистраль Москва Санкт-Петербург нельзя. При построении крупных общенациональных и интернациональных сетей применяются сверхширокополосные каналы и схемы типа опорной сети (backbone). Узлы такой сети могут располагаться в каких-то крупных организациях или быть самостоятельными (принадлежать государственным PTT). Такие сети обычно базируются на протоколах SDH (Sonet). Информация в этих сетях передается в виде больших блоков (виртуальных контейнеров). Использование опорной сети обычно оправдано при организации интернациональных связей, но бывают и исключения. Примером такого исключения является Московская опорная сеть, построенная на основе FDDI (100Мбит/с) и объединяющая более десяти научных организаций (длина первой очереди около 30 км). Московская сеть выполнена по схеме с 'прозрачными' IP-мостами, обычно же более мощные опорные сети маршрутизируемы, то есть блоки данных адресуются конкретным узлам, где они разбираются и сортируются. Контейнер может содержать сообщения, адресованные разным получателям, что несколько противоречит идеологии протоколов TCP/IP. IP-пакеты могут вкладываться в эти контейнеры и транспортироваться до заданного узла опорной сети. Классическим примером опорной сети является E-bone (Европейская опорная сеть). Эта сеть объединяет 27 стран (России в этом списке нет) и более 60 сервис-провайдеров, пропускная способность для различных участков лежит в пределах 2-34Мбит/с. Опорная сеть подобна международной автомагистрали, по ней добираются до ближайшего к точке назначения узла, а далее по 'проселочным' каналам до конечного адресата.
Резкое увеличение передаваемых объемов информации в локальных и региональных сетях привело к исчерпанию имеющихся ресурсов, а реальные прогнозы потребностей указывают на продолжение роста потоков в десятки и сотни раз. Единственной технологией, которая способна удовлетворить эти потребности, являются оптоволоконные сети (Sonet, SDH, ATM, FDDI, Fiber Channel). Каналы этих сетей уже сегодня способны обеспечить пропускную способность 155-622 Мбит/с, ведутся разработки и испытания каналов с пропускной способностью в 2-20 раз больше, например, гигабитного ethernet. Осваивается техника мультиплексирования частот в оптоволокне (WDM), что позволяет поднять его широкополосность в 32 раза и в перспективе довести быстродействие каналов до 80 Гбит/с и более. По мере роста пропускной способности возрастают проблемы управления, синхронизации и надежности. Практически все сети строятся сегодня с использованием последовательных каналов. Это связано прежде всего со стоимостью кабелей, хотя и здесь существуют исключения (например, HIPPI). Разные сетевые услуги предъявляют разные требования к широкополосности канала. На рис. 1.6 представлены частотные диапазоны для основных видов телекоммуникационных услуг. В Интернет практически все перечисленные услуги доступны уже сегодня (кроме ТВ высокого разрешения). Стремительно развиваются распределенные системы вычислений (например, проект GREED), управления и информационного обслуживания. Современная технология микропроцессоров предполагает достижение быстродействия в 5 Гбит/с к 2003-4 годам (технология с характеристическим размером объектов на кристалле 80-130 нм).
Рис. 1.6. Требования к пропускной способности канала для различных видов сервиса.
Рассмотрев диаграмму, можно сделать определенные прогнозы на ближайшее будущее сетей. Через несколько лет можно ожидать слияния функций телевизора и ЭВМ, а это потребует пропускных способностей от магистральных каналов на уровне 0,1-10 Гбит/с. Широкополосность каналов, приходящих в каждый семейный дом составит 1-10 Мбит/с, что позволит реализовать видео-телефонию, цифровое телевидение высокого разрешения, доступ к централизованным информационным службам и многое другое. Уже существующие оптоволоконные системы обеспечивают и в 10 раз большую пропускную способность. Можно предположить и появление локальных сетей внутри жилища. Такие сети способны взять под контроль кондиционирование воздуха, безопасность дома в самом широком смысле этого слова, например, оповещение о нежелательном вторжении, пожаре или возможном землетрясении (в сейсмически опасных районах), появление вредных примесей в воздухе. Такая система разбудит хозяина в указанное время, подогреет завтрак, напомнит о предстоящих делах на день, запросит и предоставит хозяину свежий прогноз погоды и справку о состоянии дорог, своевременно сделает заказ на авиабилет и т.д. Все это технологически возможно уже сегодня, пока относительно дорого, но цены весьма быстро падают. Примером может служить сеть CAN, разработанная для сбора данных и управления автомобилем. Стремительное расширение сети Интернет не имеет аналогов в истории, так что любой самый фантастический прогноз в этой области может сбыться.
Протоколы Интернет (TCP/IP) существуют уже около 30 лет. Требования к телекоммуникационным каналам и услугам выросли, и этот набор протоколов не удовлетворяет современным требованиям. Появляются новые протоколы Delta-t (для управления соединением), NetBLT (для передачи больших объемов данных), VMTP (для транзакций; RFC-1045) и XTP для повышения эффективности передачи данных (замена TCP), блоки протоколов для работы с мультимедиа (RTP, RSVP, PIM, ST-II и пр.), но, безусловно, наиболее революционные преобразования вызовет внедрение IPv6.
WAIS
4.5.12 WAIS
Семенов Ю.А. (ГНЦ ИТЭФ)
WAIS (Wide Area Information Server) распределенная система поиска информации. Поиск производится по базам данных, содержащим текстовые документы (но допустимы также графические, звуковые или видео документы). Тематика баз данных и поиска произвольны. Базы данных могут иметь любую структуру, но пользователю не нужно знать языка управления этими базами. WAIS использует естественный управляющий язык. WAIS доступен в Интернет. Для пользователей, имеющих доступ только к электронной почте, предназначен интерфейс, размещенный по адресу waismail@quake.think.com. В сети Интернет существует много серверов WAIS. Список депозитариев серверов достаточно широк, начать можно с анонимного FTP по адресу Think.com секция /wais, файл wais-sources.tar.Z (файл архивирован и пересылка должна осуществляться в режиме BINARY). В настоящее время многие WAIS-сервера интегрированы в сети WEB.
Доступ к WAIS-клиентам возможен и напрямую с помощью команды TELNET по адресам:
Авторизация |
Место расположения |
|
quake.think.com (192.31.181.1) |
(login: wais) |
США |
sunsite.unc.edu (152.2.22.81) |
(login: swais) |
США |
info.funet.fi (128.214.6.102) |
(login: wais) |
Финляндия |
swais.cwis.uci.edu (128.200.15.2) |
(login: swais) |
США |
kunzu.cnidr.org (128.109.130.57) |
(login: wais) |
США |
nnsc.nsf.net (128.89.1.178) |
(alogin: wais) |
США |
Существуют клиент-серверы WAIS для систем MS-DOS, VMS, MVS, OS/2, UNIX и Macintosh, а также для GNU Emacs, NeXT, X-Windows, MS-Windows, Sunview и т.д. Эти продукты несколько отличаются друг от друга, но обычно процедура содержит следующие шаги:
Пользователь выбирает набор баз данных, где будет проводиться поиск, из числа имеющихся. Формулируется задание на поиск, выбираются ключевые слова. В процессе поиска WAIS запрашивает информацию из всех указанных баз данных. Отображаются заголовки документов, отвечающих критериям отбора. Документы аранжируются согласно их степени соответствия условиям запроса. Для получения копии пользователь просто отбирает документы из предлагаемого списка.При необходимости пользователь может переформулировать критерии отбора и повторить поиск. Вновь найденные документы, если они не совпадают с уже известными будут добавлены в список.
Ниже приводится таблица команд WAIS
Таблица 4.5.13.1. Команды WAIS
Основные команды |
|
h |
Выдать перечень команд [help] |
? |
тоже что и h |
q |
Уйти из WAIS (quit) |
Смена текущей строки |
|
DOWN |
Сместиться на одну строку вниз |
j |
То же, что и DOWN |
Ctrl-N |
То же, что и DOWN |
UP |
Сместиться на одну строку вверх |
k |
То же, что и UP |
Ctrl-P |
То же, что и UP |
число |
Переход к строке с указанным номером |
/эталон |
Перейти к строке, начинающейся с эталона |
J |
Сместиться на один экран вниз |
Ctrl-D |
То же, что и J |
K |
Сместиться вверх на один экран |
Ctrl-U |
То же, что и K |
Выбор источника |
|
Пробел |
Выбор или отмена выбора источника |
= |
Отменить выбор каких-либо источников |
RETURN |
После выбора источников запрашивает новое ключевое слово |
r |
Заново отображает результат предшествующего поиска |
v |
Отображает техническую информацию об источнике |
Выполнение поиска |
|
RETURN |
Начало поиска после ввода ключевых слов |
RETURN |
Отображает результат при просмотре результата поиска |
w |
Запрос новых ключевых слов |
s |
Повторное отображение первоначального экрана |
Чтение статьи |
|
пробел |
Отобразить следующий экран |
q |
Прервать чтение статьи (quit). |
Имеется возможность доступа к ресурсам системы WAIS и через электронную почту. Запрос посылается по адресу waismail@quake.think.com, строка Subject игнорируется. Далее (в теле сообщения) могут следовать команды (вертикальная черта (|) указывает на выбор параметров):
| help | отображение справочного файла |
| maxres number | установка максимального числа искомых документов |
где: source-name имя источника, как оно было найдено в оглавлении сервера (с или без расширения .SRC). Если нужно провести поиск по нескольким источникам, их имена заключаются в двойные кавычки. keywords ключевые слова, по которым проводится поиск.
Можно сформулировать несколько запросов в одном e-mail. Если имя источника не будет узнано, вы получите список имен возможных источников.
retrieve docid
Извлечение копии документа из базы данных. docid является DocID (идентификатор найденного документа). Если вы посылаете несколько запросов, они должны быть разделены пустыми строками. docid должен строго соответствовать имени документа, полученного вами в результате запроса-поиска (включая пробелы, если они имелись). Могут копироваться не только текстовые документы. Такие документы будут пересланы в формате UUENCODE.
DocID: docid
То же, что и retrieve. Эта форма идентична по форме ответу на поисковый запрос. Процедура делает возможным использовать replay в e-mail для копирования найденных документов.
Примеры использования WAIS
telnet quake.think.com
Trying 192.216.46.98 ... (IP-адрес сервера)
Connected to quake.think.com.
Escape character is '^]'.
SunOS UNIX (wais)
login: wais (ввод идентификатора)
Last login: Sun Aug 27 01:57:07 from france.cityu.edu
Welcome to swais, the text-terminal telnet client to WAIS.
Please type user identifier (optional, i.e. user@host): semenov@ns.itep.ru
(в качестве пароля предлагается напечатать ваш почтовый адрес).
TERM = (vt100) ibmpc (нужно ввести тип терминала, с которым вы работаете)
Starting up. This may take awhile...
SWAIS Source Selection Sources: 549
# |
Server |
Source |
Cost |
001: |
[ wais.access.gpo.gov] |
103_cong_bills |
Free |
002: |
[ wais.access.gpo.gov] |
104_cong_bills |
Free |
003: |
[ wais.access.gpo.gov] |
1992_cri |
Free |
004: |
[ wais.access.gpo.gov] |
1993_cri |
Free |
005: |
[ wais.access.gpo.gov] |
1994_cri |
Free |
006: |
[ wais.access.gpo.gov] |
1994_hob |
Free |
007: |
[ wais.access.gpo.gov] |
1994_record |
Free |
008: |
[ wais.access.gpo.gov] |
1994_register |
Free |
009: |
[ wais.access.gpo.gov] |
1994_unified_agenda |
Free |
010: |
[ wais.access.gpo.gov] |
1995_cri |
Free |
011: |
[ wais.access.gpo.gov] |
1995_hob |
Free |
012: |
[ wais.access.gpo.gov] |
1995_record |
Free |
013: |
[ wais.access.gpo.gov] |
1995_register |
Free |
014: |
[ wais.access.gpo.gov] |
1995_unified_agenda |
Free |
015: |
[ archie.au] |
aarnet-resource-guide |
Free |
016: |
[ndadsb.gsfc.nasa.gov] |
AAS_jobs |
Free |
017: |
[ndadsb.gsfc.nasa.gov] |
AAS_meeting |
Free |
018: |
[ munin.ub2.lu.se] |
academic_email_conf |
Free |
Keywords:
<space> selects, w for keywords, arrows move, <return> searches, q quits, ? for Help
Слово Free на правом поле означает бесплатный доступ. Сразу после вывода на экран оказывается подсвеченной позиция <001> (номера позиций проставлены на левом поле). В квадратных скобках приведены адреса серверов, доступ к которым может быть предоставлен, сразу за ним следует наименование базы данных или документа. Используя стрелки <вверх> и <вниз>, можно подсветить нужную вам позицию. После нажатия клавиши <Enter> (или на некоторых клавиатурах RETURN) позиция будет выбрана и вам будет предложена возможность ввести ключевые слова для последующего поиска. Выберем для примера aarnet-resource-guide.src.
Enter keywords with spaces between them; <return> to search; ^C to cancel
Keywords: isdn (в качестве ключевого слова введено ISDN).
Searching aarnet-resource-guide.src...
Initializing connection...
Searching 1995_register
Found 1 items.
SWAIS Search Results |
Items: 1 |
||||
# |
Score |
Source |
Title |
Lines |
|
001: |
[1000] |
(aarnet-resource) |
Charles Sturt University |
66 |
|
Retrieving: Charles Sturt University
Getting "Charles Sturt University" from aarnet-resource-guide.src...
WARNING: terminal cannot "scroll backwards" (press RETURN)
(ниже следует текст документа)
Charles Sturt University
Address: |
Division of Information Technology PO Box 588 WAGGA WAGGA 2650 |
Description:
The Division of Information Technology offers computing services for teaching, research and university administration and is a centrally funded support service of the University.
The University has a Facom 340S, VAX 6320 and 6310 systems (VMS), a HP935 (HP-UX), and a SUN 4/75S, as well as a range of workstation-level Unix hosts.
Numerous PC and Mac Networks are spread through the faculties and divisions. ISDN links between the three campuses of CSU bring the ethernet/fibre "backbones" on each individual campus into a single university-wide TCPIP/LAT Network.
Network Access: Systems are generally available via AARNet and Austpac.
Who Can Use:
Computing services are provided to Charles Sturt University community.
Account for outside users are considered on a case by case basis.
Press any key to continue |
(для того чтобы продолжить просмотр текста следует нажать любую клавишу). |
Возможна и несколько другая форма доступа к WAIS (например, из ЭВМ SUN):
ns> telnet info.funet.fi
Trying 128.214.6.21 ...
Connected to info.funet.fi.
Escape character is '^]'.
SunOS UNIX (info)
Finnish University and Research Network FUNET Information Service
The following information services are available:
gopher |
Menu-based global information tool |
www |
World Wide Web, Global hypertext web |
wais |
Wide Area Information Server, global databases on different topics |
x500 |
X.500 clients are on nic.funet.fi, login: dua, no password |
archie |
Database of Internet Archive contents |
exit |
Exit FUNET information services |
Select WAIS interface:
swais VT100-based WAIS client
Select interface (return for back to main menu) ? swais
Supported terminal types are: vt100, xterm
Starting WAIS ..
Source Selection |
Server Source |
Cost |
|
001: |
[ archie.au] |
aarnet-resource-guide |
Free |
002: |
[ munin.ub2.lu.se] |
academic_email_conf |
Free |
003: |
[wraith.cs.uow.edu.au] |
acronyms |
Free |
004: |
[ archive.orst.edu] |
aeronautics |
Free |
005: |
[ ftp.cs.colorado.edu] |
aftp-cs-colorado-edu |
Free |
006: |
[nostromo.oes.orst.ed] |
agricultural-market-news |
Free |
007: |
[ archive.orst.edu] |
alt.drugs |
Free |
008: |
[ wais.oit.unc.edu] |
alt.gopher |
Free |
009: |
[sun-wais.oit.unc.edu] |
alt.sys.sun |
Free |
010: |
[ wais.oit.unc.edu] |
alt.wais |
Free |
011: |
[alfred.ccs.carleton.] |
amiga-slip |
Free |
012: |
[ munin.ub2.lu.se] |
amiga_fish_contents |
Free |
013: |
[ 150.203.76.2] |
ANU-Aboriginal-EconPolicies |
$0.00/minute |
014: |
[ coombs.anu.edu.au] |
ANU-Aboriginal-Studies |
$0.00/minute |
015: |
[ coombs.anu.edu.au] |
ANU-Asian-Computing |
$0.00/minute |
016: |
[ coombs.anu.edu.au] |
ANU-Asian-Religions |
$0.00/minute |
017: |
[ 150.203.76.2] |
ANU-Australian-Economics |
$0.00/minute |
018: |
[ 150.203.76.2] |
ANU-CAUT-Academics |
$0.00/minute |
Российского пользователя не остановит и плата за ресурс, если она составляет $0.00. Выберем позицию agricultural-market-new, а в качестве ключевого слова введем price (кого не интересуют цены на продукты питания?):
Keywords: price
Searching agricultural-market-news.src...
Initializing connection...
Found 40 items. (найдено 40 записей)
SWAIS Search Results Items: 40
# Score Source Title Lines
001: |
[1000] |
(agricultural-ma) |
Re: |
MG |
LS756 |
||
002: |
[772] |
(agricultural-ma) | Re: |
MG |
LS754 |
211 |
|
003: |
[557] |
(agricultural-ma) | Re: |
AM |
LS753 |
SUP%RIOR VIDEO | 277 |
004: |
[514] |
(agricultural-ma) |
Re: |
MG |
LS750 |
155 |
|
005: |
[500] |
(agricultural-ma) | Re: |
ML |
LS143 |
QUINCY AUCTION,QUINCY | 158 |
006: |
[486] |
(agricultural-ma) |
Re: |
WA |
PY100 |
CHICKEN PURCHASES | 480 |
007: |
[457] |
(agricultural-ma) | Re: |
RH |
LS751 |
127 |
|
008: |
[443] |
(agricultural-ma) | LS. |
MN |
LL Re: |
USDA 04/26/94 20:51 | 172 |
009: |
[443] |
(agricultural-ma) | Re: |
ML |
LS144 |
TOPPENISH (RESEND) | 161 |
010: |
[400] |
(agricultural-ma) | Re: |
KO |
LS757 |
ADA WGTD AVG W/COWS | 115 |
011: |
[371] |
(agricultural-ma) | Re: |
RH |
LS764 |
138 |
|
012: |
[343] |
(agricultural-ma) | Re: |
KO |
LS752 |
MCALESTER WGTD AVGW/COW | 100 |
013: |
[343] |
(agricultural-ma) | Re: |
MG |
LS752 |
91 |
|
014: |
[343] |
(agricultural-ma) | Re: |
MG |
LS797 |
122 |
|
015: |
[343] |
(agricultural-ma) | Re: |
RH |
LS750 |
107 |
|
016: |
[343] |
(agricultural-ma) | Re: |
RH |
LS757 |
ROCKINGHAM FEEDER CATTLE | 140 |
017: |
[343] |
(agricultural-ma) | Re: |
RH |
LS758 |
STAUNTON UNION FEEDERCA | 102 |
018: |
[343] |
(agricultural-ma) | Re: |
RH |
LS795 |
114 |
|
<space> selects, arrows move, w for keywords, s for sources, ? for help
Выбираем позицию <3>. Ниже следует текст, выданный в результате на экран.
Retrieving: Re: AM LS753 SUPRIOR VIDEO "Re: SUP%RIOR
VIDEO" from agricultural-market-news.src...
SWAIS Document Display Page: 1
Subject: AM LS753 SUP%RIOR VIDEO
Date: Mon, 21 Aug 95 01:58:17 PM
AM LS753
Amarillo, Texas Mon Aug 21, 1995 USDA-TX Dept of Ag Market News
Superior Video Auction - Final Report - Two day auction Aug 18 & 19.
Offerings < 91,000
Trade and demand moderate to good. Cattle offered from 16 States, Mexico and Canada. Prices based on net weights after a 1-3 percent shrink or equivalent with a 4-10 cent slide on calves and 3-8 cent slide on yearlings. Offerings included 31 percent feeder steers and differs over 600 lbs and 69 percent feeders under 600 lbs.
************************************************************
Press any key to continue, 'q' to quit.
Southcentral States: Texas, Oklahoma, New Mexico,
Kansas and Missouri.
************************************************************
Feeder Steers Medium and Large 1
Head |
Weight |
Avg Wt |
Price |
Avg Price |
Delivery |
220 |
425-425 |
425 |
74.10-74.10 |
74.10 |
Current |
84 |
625-625 |
625 |
67.35-67.35 |
67.35 |
Current |
60 |
850-850 |
850 |
62.00-62.00 |
62.00 |
Current |
190 |
525-525 |
525 |
66.25-66.25 |
66.25 |
Septmbr |
78 |
585-585 |
585 |
69.35-69.35 |
69.35 |
Septmbr |
130 |
740-740 |
740 |
64.85-64.85 |
64.85 |
Septmbr |
382 |
800-835 |
821 |
64.00-66.00 |
64.96 |
Septmbr |
540 |
860-860 |
860 |
64.35-64.35 |
64.35 |
Septmbr |
70 |
360-360 |
360 |
77.50-77.50 |
77.50 |
Oct+Nov |
Press any key to continue, 'q' to quit. (таблица напечатана с сокращениями)
Если вы выдали более одного ключевого слова, тогда все документы, содержащие любое из перечисленных слов будут включены в список найденных.
Если нужно узнать о WAIS больше (библиография, утилиты, исходные тексты), обращайтесь к Barbara Lincoln Brooks из WAIS inc. Библиография доступна по адресу ftp.wais.com в секции /pub/wais-inc-doc. Общую информацию по WAIS можно найти через FTP по адресу: quake.think.com /wais/doc или sunsite.unc.edu /pub/docs/about-the-net/libsoft/wais.txt. Для любителей доступа через WWW: www.wais.com или www.earn.net. Те же, кто для целей поиска предпочитает gopher, могут воспользоваться сервером: gopher-gw.micro.umn.edu. Можно узнать кое-что о WAIS и через telnet: quake.think.com Login: wais.
Программы доступны по адресам (FTP): ftp.cnidr.org ftp.wais.com quake.think.com sunsite.unc.edu
По вопросам получения бесплатного программного обеспечения обращайтесь по адресу: freewais@cnidr.org. Подписной почтовый лист имеет адрес: wais-discussion@wais.com. Для подписки посылайте запрос по адресу (формат запросов описан в разделе LISTSERV): wais-discussion-request@wais.com. Группа новостей в USENET (FAQ): comp.infosystems.wais; полезную информацию можно получить и через анонимное FTP по адресу rtfm.mit.edu в каталоге /pub/usenet/news.answers/wais-faq.
Whois
4.5.8.1 Whois
Семенов Ю.А. (ГНЦ ИТЭФ)
WHOIS обеспечивает каталожную службу для пользователей сети (RFC-0954). Эта служба заключается в поиске e-mail адресов, почтовых адресов и телефонных номеров. WHOIS может поставлять информацию о сетях, о структуре доменов и т.д. Главная база данных, относящихся к сетям, поддерживается Регистрационной службой Интернет (InterNic). В действительности имена при регистрации доменов и при выдаче IP-адресов автоматически вводятся в базу данных. Каждая запись в базе имеет уникальный идентификатор (handle), имя, тип записи и ряд других полей в зависимости от типа записи. База данных поддерживается в каждой сети независимо и взаимодействие между ними не всегда существует.
В системах UNIX имеется аналог этой службы – rwho, которая предоставляет даже несколько большую информацию, сообщая дополнительно о том, кто работает в данный момент в каждой из подключенных к сети машин.
Сейчас создан новый протокол WHOIS++, в котором учтены прежние недостатки. WHOIS доступно для пользователей Интернет с помощью команды telnet. Возможна посылка запросов и по электронной почте.
Обращение к базе данных производится по команде WHOIS (значение параметра заключается в угловые скобки). Обращение к местному клиент-серверу производится по форме:
WHOIS <-h имя_сети> идентификатор
Где имя_сети - адрес домена, куда вы собираетесь послать запрос (например, whois.internic.net); идентификатор - фамилия человека, название сети или домена, IP-адрес. С идентификатором могут использоваться специальные символы, определяющие тип поиска.
. (точка) |
перед идентификатором задает поиск по фамилии; |
! |
перед идентификатором задает поиск по handle; |
... or |
после идентификатора определяет режим частичного поиска: все, что начинается с идентификатора подходит. |
@ |
(в идентификаторе) осуществляет поиск по e-mail адресу. |
| * | перед идентификатором извлекает полный список рекордов, соответствующих идентификатору (например, сеть и все зарегистрированные пользователи). |
% |
перед идентификатором извлекает список всех зарегистрированных пользователей узла (или региона). |
~ |
перед идентификатором выдает распечатку объекта, который точно соответствует идентификатору. |
Эти символы могут использоваться и в комбинации. Результат поиска отображается либо в виде полного текста найденной записи, либо в виде списка строк, характеризующих найденные рекорды. В обоих случаях handle следует в скобках за именем.
Для получения информации в интерактивном режиме используется telnet по адресу whois.internic.net (или whois.ripe.net). Далее прописные буквы обозначают приемлемые сокращения; опционные параметры помещаются в угловые скобки.
| WHOIS | Вызов программы; |
| ? | Вызов справочного материала; |
| HElp | Вызов полномасштабной справочной поддержки; |
| Q, QUIT, Клавиша <Enter> | Выход из WHOIS |
| <ключевое слово>идентификатор | Поиск в базе записей, содержащих идентификатор, ключевое слово может использоваться, чтобы ограничить область поиска каким-то одним полем. |
| PErson | Ограничивает поиск людьми; |
| DOmain | Ограничивает поиск доменами (например, DO EARN.NET); |
| HOst | Oграничивает поиск ЭВМ (например, HO PRINCETON); |
| NEtwork | Ограничивает поиск сетями (например, NE EBONE); |
| Organization | Ограничивает поиск организациями (например, O CERN) |
| NАme | То же что и лидирующая '.' в идентификаторе; |
| HАndle | То же что и ! в идентификаторе; |
| PАrtial | То же что и завершающая '.' в идентификаторе; |
| Mailbox | То же что и @ в идентификаторе; |
| EXPand | То же что и '*' в идентификаторе; |
| SUBdisplay | То же что и '%' в идентификаторе; |
| Full or '=' | Детально отображает каждый найденный объект; |
| SUMmary or '$' | Выдает лишь список найденного; |
Использование базы данных для получения списка лиц для коммерческих целей категорически запрещено (при выявлении расстрел на месте преступления :-)).
Пример использования WHOIS.
telnet wais.ripe.net
Trying 39.13.5.97 ... (IP-адрес сервера)
Connected to info.ripe.net.
Escape character is '^]'.
RIPE Network Coordination Centre (NCC)
INTERACTIVE INFORMATION SERVICE
Report bugs to <ncc@ripe.net>.
Enter terminal type (? for help) [vt100]: ibmpc
Number of lines your terminal can display ? [24]
Information Services Menu
| 1 - About RIPE and the RIPE NCC | |
| 2 - Browse through the NCC Document Store (Gopher) | |
| 3 - Keyword Search of the NCC Document Store (WAIS) | |
| 4 - Search the RIPE Database (whois) | |
| (DISABLED) | 5 - Browse through the NCC Document Store (WWW) |
| 6 - HELP for mailing documents to the UK | |
| q - Quit |
Enter Selection: 4 (выбираем позицию 4 - WHOIS)
Enter search key [q to quit]: msu.su. (Проводим поиск записей, относящихся к домену msu.su). Система выдает:
domain: MSU.SU
descr: Lomonosov Moscow State University
admin-c: SB16
admin-c: DA196
tech-c: DA196
tech-c: SN4-RIPE
zone-c: DA196
nserver: unisun.radio-msu.net sun01a.desy.de
nserver: ns1.barrnet.net ns2.barrnet.net
sub-dom: npi cs srcc phys chem cogsci bio bog mics math geogr med
sub-dom: econ rector logos geol lib sai journ cshe hist genebee
sub-dom: law soc pvt
changed: ada@radio-msu.net 950316
source: RIPE
person: Sergey F. Berezhnev
address: Nuclear Physics Institute
address: Moscow State University
address: 119899 Moscow
address: Russia
phone: +7 095 932 8974
phone: +7 095 939 5877
fax-no: +7 095 932 8974
e-mail: sfb@radio-msu.net
nic-hdl: SB16
notify: noc@radio-msu.net
changed: ada@radio-msu.net 950303
source: RIPE
person: Dmitry A. Avdeyev
address: Nuclear Physics Institute
address: Moscow State University
address: 119899 Moscow
address: Russia
phone: +7 095 932 8880
phone: +7 095 939 5877
fax-no: +7 095 932 8974
e-mail: ada@radio-msu.net
nic-hdl: DA196
notify: ada@radio-msu.net
mnt-by: RADIO-MSU-MNT
changed: ada@radio-msu.net 950302
source: RIPE
person: Serge Yu. Nikiphorov
address: Nuclear Physics Institute
address: Moscow State University
address: 119899 Moscow
address: Russia
phone: +7 095 932 8880
phone: +7 095 939 5877
e-mail: serg@radio-msu.net
nic-hdl: SN4-RIPE
changed: ada@radio-msu.net 950130
source: RIPE
Enter search key [q to quit]: q
Еще один пример поиска в базе данных WHOIS, здесь задача решается с помощью команды, обращенной к серверу RIPE. Ищется информация об узле itep.ru: whois –h whois.ripe.net itep.ru (ЭВМ SUN):
domain: ITEP.RU
descr: Institute for Theoretical and Experimental Physics
descr: ITEP, B.Cheremushkinskaja 25,
descr: Moscow 117259, Russia.
admin-c: Yuri Al. Semenov
tech-c: Andrey N. Bobyshev
zone-c: Andrey N. Bobyshev
nserver: ns.itep.ru suncom.itep.ru sun01a.desy.de
dom-net: 192.148.166.0 193.124.224.0 193.124.225.0 193.124.226.0
remarks: fully-managed
changed: bobyshev@cl.itep.ru 950218
source: RIPE
person: Yuri Al. Semenov
address: Institute for Theoretical
address: and Experimental Physics
address: B.Cheremushkinskaja 25,
address: Moscow 117259, Russia.
phone: +7 095 1230292
fax-no: +7 095 1236584
e-mail: semenov@cl.itep.ru
changed: bobyshev@cl.itep.ru 941005
source: RIPE
person: Andrey N. Bobyshev
address: ITEP
address: B.Cheremushkinskaja 25,
address: Moscow 117259, Russia.
phone: +7 095 1230292
fax-no: +7 095 1236584
e-mail: bobyshev@cl.itep.ru
nic-hdl: AB293
changed: bobyshev@cl.itep.ru 941005
source: RIPE
Существуют и другие программы для поиска информации о клиентах сети Internet (например, knowbot). Обращение к такой программе может быть выполнено, в частности, командой telnet nri.reston.va.us 185 (185 - номер порта). После входа в систему вы можете выдать запрос информации о возможностях системы поиска, напечатав ?, или просто выдав команду query vanja ivanov. Пользователи могут послать запрос через e-mail по адресу mailserv@internic.net. Команды записываются в поле subject. Текст сообщения обычно пуст, если subject не содержит команд, то интерпретируется первая строка текста сообщения. Запросы должны начинаться со слова WHOIS. Например: WHOIS \!EARN (\ представляет собой символ esc). Служба WHOIS документирована в RFC-1400. С любыми вопросами следует обращаться по адресу action@internic.net. Исчерпывающую информацию о WHOIS можно получить через анонимное FTP по адресам: nic.merit.edu /documents или sipb.mit.edu /pub/whois/whois-servers.list. Для этих же целей можно воспользоваться WWW: www.earn.net gnrt/whois.html или gopher: phantom.bsu.edu :4320/7whois%20rs.internic.net (число после двоеточия - номер порта). К материалам о WHOIS имеется доступ и с помощью telnet: rs.internic.net.
Winsock (для UNIX, Windows- и -NT)
7.1 Winsock (для UNIX, Windows-95 и -NT)
Семенов Ю.А. (ГНЦ ИТЭФ)
Какие бы замечательные идеи в области телекоммуникаций, распределенных баз знаний или поисковых систем вам не пришли в голову, реализовать их на практике можно, лишь написав соответствующую программу. Основные операционные среды (Unix, Windows 95, NT или 2000) базируются в настоящее время на идеологии соединителей (socket). Эта технология была разработана в университете г. Беркли (США) для системы Unix, поэтому соединители иногда называют соединителями Беркли (berkeley sockets). Соединители реализуют механизм взаимодействия не только партнеров по телекоммуникациям, но и процессов в ЭВМ вообще (см. [15]). Вопросы сетевого программирования под MS DOS рассмотрены в [24].
Работа с соединителями содержит ряд этапов: соединитель создается, настраивается на заданный режим работы, используется для организации обмена и, наконец, ликвидируется. Технология соединителей поддерживает работу с любыми стеками протоколов, совмещенные процедуры ввода/вывода, использование большого числа сервис-провайдеров (серверов услуг), возможность группирования соединителей, что позволяет реализовать их приоритетное обслуживание, и многое другое. Набор операторов, поддерживающих интерфейс сервис провайдера, образует отдельную динамическую библиотеку.
Для общей синхронизации работы сервис-провайдеров и приложений в winsock введено понятие объектов событий. Объекты событий служат в частности для организации работы совмещенных по времени процессов информационного обмена. Здесь уместно замечание об использовании стандартных номеров портов. В много задачных, многопользовательских системах стандартные номера портов используются при инициализации процесса. Так как допускается несколько идентичных соединений (например, несколько одновременных сессий FTP) между клиентом и сервером, стандартными номерами портов здесь не обойтись. Ведь psips сервера могут соотвествовать несколько pcipc клиента.
В системах, ориентированных на соединение, пара комбинаций IP-адресов и номеров портов однозначно определяет канал связи между двумя процессами в ЭВМ. Такая комбинация называется соединителем (socket). Номера портов могут и совпадать, так как относятся к разным машинам, но IP-адреса должны быть обязательно разными. Впервые идея соединителя была использована в системе 4.3 BSD Unix для организации сетевого ввода/вывода. В Unix внешнее устройство и файл с точки зрения системного программиста эквивалентны. Сетевые процедуры несколько сложнее и не укладываются в такую простую схему. Из этой простой схемы выпадают, прежде всего, операции, при которых сервер пассивно ожидает обращения особенно для операций обмена не ориентированных на соединение. Соединитель является пограничным понятием между протоколами телекоммуникаций и операционной системой ЭВМ. Соединители играют важную роль при написании прикладных программ (API).
Соединитель отправителя = IP-адрес отправителя + номер порта отправителя
Соединитель адресата = IP-адрес адресата + номер порта адресата
Межкомпьютерные коммуникации не сводятся к знакомству с соседским депозитарием, к выполнению операций Telnet, FTP и т.д. Одной из важнейших задач является удаленный контроль за процессами в больших рассредоточенных системах, когда обмен информацией активизируется не человеком, а ЭВМ. Примерами таких задач могут служить управление современными высокотехнологичными производствами, сбор метео- или другой геофизической информации в реальном масштабе времени, эксперименты в области физики высоких энергий, где для контроля установки и сбора экспериментальных данных используются десятки (а иногда и сотни) вычислительных машин, которые обмениваются диагностической информацией и данными. Именно для решения таких задач и применяются идеи соединителей (sockets), "труб" и т.д.. Понятие соединителя в прикладных программах это не просто комбинация IP-адресов и номеров портов, это указатель на структуру данных, где хранятся параметры виртуального канала. Прежде чем воспользоваться соединителем, его нужно сформировать. Оператор формирования соединителя имеет вид:
s=socket(INT AF, INT type, INT protocol);
где все параметры целочисленные, AF (address_family) - характеризует набор протоколов, соответствующий данному соединителю (это может быть набор Internet, Unix, Appletalk и т.д.). Для Интернет AF может принимать только значение PF_INET, для Unix - PF_UNIX. Аргумент type определяет тип коммуникаций (SOCK_STREAM, SOCK_RAW, и SOCK_DGRAM). Аргумент protocol задает код конкретного протокола из указанного набора (заданного AF), который будет реализован в данном соединении. Протоколы обозначаются символьными константами с префиксом IPPROTO_ (например, IPPROTO_TCP или IPPROTO_UDP). Допускается значение protocol=0 (протокол не указан), в этом случае используется значение по умолчанию для данного вида соединений. Значения AF и type можно обычно найти в файле <sys/socket.h>. Возвращаемый параметр S представляет собой дескриптор соединителя. Параметр SOCK_STREAM говорит о том, что вы намерены создать надежный двунаправленный канал обмена, ориентированный на соединение (TCP для Интернет). Связь c другим процессом в этом случае устанавливается оператором connect. После установления соединения данные могут посылаться оператором send или получаться посредством оператора recv. Параметр SOCK_DGRAM характеризует канал, не ориентированный на соединение, с пакетами фиксированного размера (например, UDP в случае AF= PF_INET). Такой канал позволяет использовать операторы sendto и recvfrom. Параметр SOCK_RAW определяет третий режим, при котором возможно использование протоколов нижнего уровня, например ICMP. Таким образом, формирование соединителя - это создание описывающей его структуры данных.
Если операция socket завершилась успешно, s равно дескриптору соединителя, в противном случае s=INVALID_SOCKET (-1). С помощью оператора WSAGetLastError можно получить код ошибки, проясняющий причину отрицательного результата.
Дескриптор соединителя указывает на элемент таблицы дескрипторов, соответствующий данному соединителю. Оператор socket отводит место в этой таблице. Элемент такой таблицы имеет вид:
Код семейства протоколов;
Код типа сервиса;
Локальный IP-адрес;
Удаленный ipIPадрес;
Номер локального порта;
Номер удаленного порта;
IP-адрес определяет интерфейс ЭВМ, а номер порта в данном случае характеризуют сетевую процедуру.
Так как в Unix возможно формирование соединителя без IP-адресов, а для практической работы они нужны, имеется оператор bind, который позволяет присвоить определенный адрес заданному соединителю:
r=bind(s, const struct socketaddr far*name, int namelen),
где s - целочисленный код дескриптора, параметр name (идентификатор локального адреса) обычно (для Интернет) содержит три величины: IP-адрес ЭВМ, код протокольного набора, номер порта, который определяет характер приложения. Структура адресной информации имеет вид:
struct sockaddr {
u_short sa_family;
char sa_data[14];
};
Параметр namlen определяет длину второго параметра. В рамках этой идеологии легко реализовать систему клиент-сервер. IP-адрес может быть сделан равным INADDR_ANY (или =0), если ЭВМ имеет несколько интерфейсов. При номере порта равным нулю, windows socket присвоит порту уникальный номер в диапазоне 1024-5000. Приложение может выполнить операцию getsockname после bind, чтобы определить присвоенный адрес. Оператор bind выполняется до операций connect или listen. При корректном выполнении оператор bind возвращает код 0 (r=0), в противном случае SOCKET_ERROR=-1. Команда bind выдается для записи собственного номера порта. Сервер генерирует команду bind, чтобы подготовить определенный вид связи (например, FTP), и пассивно ожидает запроса connect со стороны клиента:
R=connect(s, const struct socketaddr FAR*name, int namelen),
где s - дескриптор соединителя, name - идентификатор адреса места назначения (указатель на структуру данных), а namelen - длина этого адреса. Таким образом, оператор connect сообщает ip-адрес и номер порта удаленной ЭВМ. Если адресное поле структуры name содержит нули, оператор connect вернет ошибку WSAEADDRNOTAVAIL (или SOCKET_ERROR=-1). Установка в режим ожидания осуществляется командой listen, которая организует очередь запросов:
R=listen(s, int backlog),
где backlog - задает максимальный размер очереди для приходящих запросов соединения (то есть сколько запросов может быть принято на обслуживание без потерь, обычно этот параметр равен 5). При переполнении очереди будет послано сообщение об ошибке. Следует иметь в виду, что клиент, ориентированный на соединение, также должен прослушивать порт протокола, ожидая появления дейтограмм-откликов. Ожидающий соединитель посылает каждому отправителю сообщение-отклик, подтверждающее получение запроса на соединение. Оператор listen подготавливает соединитель к обработке потока запросов, система должна быть достаточно быстродействующей. Запросы из очереди извлекаются оператором accept:
R=accept(s, struct sockaddr FAR*addr, int FAR*addrlen),
где s - дескриптор соединителя, который прослушивает соединение (тот же, что и в listen), addr - опционный указатель на структуру, которая содержит адрес, addrlen - код длины адреса. Оператор accept позволяет серверу принять запрос от клиента. Когда входная очередь сформирована, программа реализует процедуру accept и переходит в режим ожидания запросов. Программа извлекает первый элемент очереди, создает новый соединитель со свойствами, идентичными s, и при успешном выполнении возвращает дескриптор нового соединителя. При возникновении ошибки возвращается код INVALID_SOCKET. По окончании обработки запроса сервер вновь вызывает accept, который возвращает ему дескриптор соединителя очередного запроса, если таковой имеется. Если очередь пуста, accept блокирует программу до получения связи. Существуют серверы с параллельной и последовательной обработкой запросов. Параллельный обработчик запросов не ждет завершения обработки предшествующего запроса и вызывает оператор accept немедленно. В системе Unix используются обычно параллельные обработчики запросов.
Схема взаимодействия различных операторов winsock в рамках идеологии клиент/сервер для случая процедур, ориентированных на соединение, показана на рисунке 7.1. Стрелками обозначены направления посылки сетевых сообщений.
Следует иметь в виду, что программе клиента (выделена рамкой) не нужно знать номер порта, по этой причине она не обращается к процедуре bind, а для установления связи сразу вызывает оператор connect. Современные распределенные информационные системы, WWW-серверы, поисковые системы и т.д. эффективно используют механизмы формирования соединителей и многие процедуры, описанные в данном разделе. Из литературы [24] известно, что для многих видов услуг в Интернет выделены строго определенные номера портов. Доступ же к этим услугам должен быть обеспечен достаточно большому числу пользователей. С клиентской стороны при этом используются номера портов со значениями из диапазона 1024-5000. Для каждого нового клиентского запроса в ЭВМ-сервере, как правило, открывается новый процесс.
Рис. 7.1.Схема взаимодействия операторов winsock для процедур, ориентированных на соединение
Лишь при успешной реализации всех перечисленных операций может начаться обмен данными. Для пересылки данных могут использоваться команды write, read, send, recv. Команды write и read имеют форму вызова:
R=write(s, buf, len) или R=read(s, buf, len),
где s - дескриптор соединителя, buf - имя массива, подлежащего пересылке (или предназначенного для приема), len - длина этого массива. Оператор writev отличается от write тем, что данные могут не лежать в виде непрерывного массива:
R=writev(s, io_vect, vectlen) или R=readv(s, io_vect, vectlen),
где s - дескриптор соединителя, io_vect - вектор-указатель на список указателей, vectlen - длина списка указателей. Команда выполняется медленнее, чем write или read. Список указателей имеет формат (рис. 7.2):
Рис. 7.2 Формат списка указателей для функций readv и writev
Команды send(s, msg_buf, buflen, flags) и recv имеют аналогичный формат, но среди параметров обращения содержат переменную flags, которая служит для целей диагностики и управления передачей данных (например, пересылка информации с высоким приоритетом (MSG_OOB - Message Out Of Band), что используется, в частности, при передаче звуковых сообщений). При работе с операторами send или recv надо быть уверенным, что принимающая сторона знает, что ей следует делать с этими приоритетными сообщениями. Другой возможный флаг, определяемый константой MSG_PEEK, позволяет анализировать запросы из входной очереди транспортного уровня. Обычно после считывания данных из входной очереди, они уничтожаются. Когда MSG_PEEK=1, данные из входной очереди не стираются. Этот флаг используется, например, программой FTP. При успешном выполнении команды будет возвращено число переданных байтов, в противном случае -1.
Все перечисленные выше операторы рассчитаны на использование в рамках протоколов, ориентированных на установление соединения (TCP), где не требуется указание адреса места назначения. В протоколах типа UDP (не ориентированных на соединение) для передачи информации используются операторы sendto, recvfrom или sendmsg:
R=sendto
(s, msg_buf, buflen, flags, adr_struc, adr_struc_len)
или recvfrom(s, msg_buf, buflen, flags, adr_struc, adr_struc_len),
где s - дескриптор соединителя, msg_buf - указатель на буфер, где лежит сообщение, buflen - длина этого буфера (длина сообщения), adr_struc - адресная структура, содержащая исчерпывающую информацию об адресате, adr_struc_len - длина этой структуры. Оператор recvfrom принимает все данные, приходящие на его порт. Приняв дейтограмму, recvfrom записывает также адрес, откуда эта дейтограмма получена. Сервер может посылать по этому адресу дейтограмму-отклик. Вызов оператора sendmsg имеет форму:
R=sendmsg(s, msg_struc, flags) [или recvmsg(s, msg_struc, flags)],
где s - дескриптор соединителя, msg_struc - информационная структура, формат которой показан ниже на рисунке 7.3. Применение структур делает программирование пересылки сообщений более гибким. Следует учитывать, что для обменов, не ориентированных на соединение, соединитель как бы состоит лишь из одной половины (IP-адрес и номер порта). “Соединители”, созданные для обмена (UDP) однажды, далее могут жить своей жизнью. Они могут принимать пакеты от других аналогичных “соединителей” и сами посылать им дейтограммы (кавычки здесь связаны с тем, что это не реальный соединитель и никакого соединения здесь не осуществляется).
Рис. 7.3. Формат информационной структуры msg_struc
Взаимодействие операторов winsock для систем, не ориентированных на соединение, показано на рисунке 7.4. Здесь также как и в случае, ориентированном на соединение, сервер вызывает socket и bind, после чего обращается к процедуре recvfrom (вместо read или recv). Программа-клиент в данной схеме обращается к оператору bind и совсем не использует оператор connect (ведь предварительного соединения не нужно). Для передачи запросов и приема откликов здесь служат операторы sendto и recvfrom, соответственно.
Рис. 7.4. Схема взаимодействия операторов winsock для процедур, не ориентированных на соединение
Помимо уже описанных операторов для работы с соединителями (sockets) имеется еще один - select, довольно часто используемый серверами. Оператор select позволяет процессу отслеживать состояние одного или нескольких соединителей. Для каждого соединителя вызывающая программа может запросить информацию о статусе read, write или error. Форма обращения имеет вид:
R=select(num_of_socks, read_socks, write_socks, error_socks, max_time),
где num_of_socks - число контролируемых соединителей (в некоторых реализациях не используется и является необязательным, по умолчанию это число не должно превышать 64). В версии Беркли read_socks, write_socks и error_socks представляют собой побитовые маски, определяющие тип соединителя. Параметр read_socks представляет собой указатель на структуру, описывающую набор соединителей, состояние которых контролируется на возможность чтения (версия winsock). Если соединитель находится в состоянии listen, он будет помечен как “готов для чтения”, при условии, что запрос на соединение уже получен. Это предполагает выполнение оператора accept без блокировки. Для других соединителей “готовность к чтению” подразумевает наличие в очереди запросов чтения. Для соединителей типа SOCK_STREAM это означает, что виртуальный соединитель, соответствующий данному соединителю закрылся, и операторы recv или recvfrom будут выполнены без блокировки. Если виртуальное соединение закрыто корректно, оператор recv вернет код 0, в противном случае (например, принудительное закрытие) будет возвращен код WSAECONNRESET. Параметр write_socks - указатель на набор соединителей, состояние которых контролируется на возможность записи. Если соединитель находится в процессе выполнения процедуры connect, “способность к записи” означает, что установление связи завершено. Для других соединителей это значит, что операции send или sendto будут выполнены без блокировки. Параметр error_socks - это указатель на набор соединителей, контролируемых на ошибки. В некоторых реализациях этот аргумент идентифицирует список соединителей, помеченных как приоритетные. Соединитель помечается как приоритетный, если опция SO_OOBINLINE=FALSE. На случай ошибки оператор select отмечает соединитель, где это произошло. select работает лишь с теми соединителями, которые были выделены с помощью масок. При успешном выполнении оператор возвращает число соединителей, готовых к операциям ввода/вывода и модифицирует коды масок в соответствии с состоянием соединителей. Прикладная программа может использовать результаты вызова оператора select, анализируя полученные коды масок. Аргумент max_time определяет максимальное время, выделенное select для завершения своей работы. Для уточнения типа ошибки, возникшей при исполнении операции select, можно воспользоваться процедурой WSAGetLastError.
Другим важным оператором является closesocket(s), который закрывает канал соединителя с одной из сторон. Все описанные выше операторы (кроме socket, bind и listen) блокируют работу программы до своего завершения. Практически любая операция, непосредственно связанная с выполнением процедур ввода/вывода, может блокировать выполнение других прикладных функций winsock.
Для обслуживания прикладных процессов (например, WWW-сервера, работа с распределенными базами данных и пр.) разработано много других сервисных программ (WINSOCK.DLL), перечень которых представлен в таблице 7.1.
Таблица 7.1. Перечень служебных операторов для работы с соединителями (Беркли)
Имя команды
Назначение
Программа ioctlsocket(s, long cmd, u_long FAR*argp) служит для получения параметров соединителя (выполнение не зависит от типа протокола и коммуникационной субсистемы). Аргумент cmd представляет собой код команды, которая будет выполнена для соединителя s, argp - указатель на параметр команды. Возможно применение команд: FIONBIO - разрешает/запрещает режим блокировки соединителя s (команда WSAAsyncSelect ставит соединитель в режим запрета блокировок автоматически). FIONREAD - определяет объем данных, которые могут быть автоматически считаны через соединитель s. SIOCATMARK - задает режим чтения приоритетной информации (для соединителей типа SOCK_STREAM.
Программа setsockopt(s, int level, int optname, const char far*optval, int optlen) устанавливает текущие значения опций для соединителя s. Аргумент level описывает уровень, на котором определена данная опция (например, SOL_SOCKET или IPPROTO_TCP). optname - имя опции, значение которой устанавливается, optval - указатель на буфер, где лежит значение опции, optlen - размер этого буфера. Для опции SO_LINGER - это размер структуры, для остальных - длина целого. При корректном исполнении setsockopt возвращает нуль, в противном случае SOCKET_ERROR. Программа setsockopt поддерживает следующие опции (BSD поддерживает и некоторые другие опции; колонка тип соответствует значению optval, таблица 7.2):
Таблица 7.2. Опции соединителей для оператора setsockopt.
Опция |
Тип |
Назначение |
| SO_BROADCAST | булев | Позволяет передачу широковещательных сообщений |
| SO_DEBUG | булев | Осуществляет запись отладочных данных. |
| SO_DONTLINGER | булев | Разрешает закрытие без ожидания при наличии не отосланной информации. Эта опция эквивалентна SO_LINGER с l_onoff=0. |
| SO_DONTROUTE | булев | Запрет маршрутизации - отправка непосредственно интерфейсу. |
| SO_KEEPALIVE | булев | Посылка сообщения keepalive (“еще жив”) |
| SO_LINGER | структура | Задержка закрытия в случае наличия не отосланной информации. |
| SO_OOBINLINE | булев | Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных |
| SO_RCVBUF | целый | Определяет размер входного буфера |
| SO_REUSEADDR | булев | Позволяет соединителю использовать адрес, который уже задействован |
| SO_SNDBUF | целый | Определяет размер выходного буфера |
| TCP_NODELAY | булев | Запрещает использование алгоритма Нагля (TCP). |
/p> Программа getsockopt(s, int level, int optname, char far*optval, int FAR* optlen) позволяет получить значение опции для любого типа соединителей. Значения параметров обращения аналогичны setsockopt. Ниже представлена таблица (7.3) поддерживаемых опций.
В среде Windows существуют аналоги (асинхронные) многих из приведенных выше операторов. Имена этих операторов имеют префикс WSA (Windows Socket Asynchronous). Асинхронными они названы по той причине, что их выполнение сопряжено с определенным диалогом и ни начало, ни завершение не ограничено какими-либо временными рамками. Список таких операторов представлен в таблицах 7.4 и 7.5 (версия windows socket 2.2).
Таблица 7.3. Опции соединителей для оператора getsockopt
Опция |
Тип |
Назначение |
| SO_ACCEPTCONN | булев | Соединитель в режиме listen |
| SO_BROADCAST | булев | Разрешена передача широковещательных сообщений |
| SO_DEBUG | булев | Отладочный режим разрешен |
| SO_DONTLINGER | булев | Если равен TRUE, SO_LINGER-опция запрещена |
| SO_DONTROUTE | булев | Запрет маршрутизации. |
| SO_ERROR | целое | Выдает статус ошибок |
| SO_KEEPALIVE | булев | Сообщение keepalive (“еще жив”) послано |
| SO_LINGER | структура | Возвращает текущие значения опции SO_LINGER |
| SO_OOBINLINE | булев | Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных |
| SO_RCVBUF | целый | Сообщает размер входного буфера |
| SO_REUSEADDR | булев | Соединителю разрешено использовать адрес, который уже задействован |
| SO_SNDBUF | целый | Сообщает размер выходного буфера |
| SO_TYPE | целый | Тип соединителя (например, SOCK_STREAM) |
| TCP_NODELAY | булев | Использование алгоритма Нагля запрещено (tcp). |
Имя оператора |
Назначение |
| WSAAsyncGetHostByAddr | Аналог оператора gethostbyaddr |
| WSAAsyncGetHostByAddr | Аналог оператора gethostbyaddr |
| WSAAsyncGetHostByName | Аналог оператора gethostbyname |
| WSAAsyncGetProtoByName | Аналог оператора getprotobyname |
| WSAAsyncGetProtoByNumber | Аналог оператора getprotobynumber |
| WSAAsyncGetServByName | Аналог оператора getservbyname |
| WSAAsyncGetServByPort | Аналог оператора getservbyport |
| WSAAsyncSelect | Функциональный аналог оператора select |
| WSACancelAsyncRequest | Прерывает выполнение операторов типа WSAAsyncget*by* |
| WSACancelBlockingCall | Прерывает выполнение блокирующего оператора приложения (API) |
| WSACleanup | Сообщает Windows sockets о завершении работы программы с DLL |
| WSAGetLastError | Выдает сообщение о последней ошибке |
| WSAIsBlocking | Определяет, является ли Winsock DLL блокирующей |
| WSASetBlockingHook | Устанавливает перехват блокирующего вызова |
| WSASet LastError | Фиксирует тип ошибки для последующего вызова WSALastError |
| WSAStartup | Инициализирует следующий уровень Winsock |
| WSAUNhookBlockingHook | Восстанавливает прежнюю блокировку. |
/p> Из этого списка можно выделить две программы WSAStartup и WSACleanup, первая вызывается в начале любой процедуры, вторая - ее завершает. wsastartup может вызываться за время сессии несколько раз, она позволяет указать версию winsock или получить информацию об ее конкретной реализации. При вызове WSAStartup осуществляется диалог с динамической библиотекой WINSOCK.DLL и настройка параметров системы. При аварийном завершении программы нужно корректно окончить работу с WINSOCK.DLL. Следует при этом помнить, что WSACleanup воздействует на все потоки завершаемого процесса (например, в случае Windows 95 или NS). Определенные проблемы может вызвать перенос программ из Unix в Windows, так как там вместо read и write используются операторы recv и send, вместо ioctl - ioctlsocket, а вместо close - closesocket. Некоторые операторы вообще непереносимы: readv, writv, recvmsg и sendmsg и части программы, где они содержатся, необходимо переписать. При обнаружении ошибки Unix присваивает переменной errno соответствующее значение. В winsock для этой цели используется символьная константа SOCKET_ERROR (равная -1), а для уточнения типа ошибки следует вызвать WSAGetLastError. В системах Windows 95 или NT этот оператор обращается к программе Win32 GetLastError, которая возвращает значение ошибки для сессии, вызвавшей эту ошибку.
Таблица 7.5. Асинхронные операторы
WSAAccept * |
Расширенная версия accept, которая позволяет условное подключение и формирование групп соединителей. |
WSACloseEvent |
Уничтожает объект события. |
WSAConnect * |
Расширенная версия connect, которая позволяет обмениваться данными о соединении и QoS-информацией. |
WSACreateEvent |
Создает объект события. |
WSADuplicateSocket |
Создает новый дескриптор соединителя для случая использования его несколькими процессами. |
WSAEnumNetworkEvents |
Выявляет сетевые события. |
WSAEnumProtocols |
Выдает информацию о каждом доступном протоколе. |
WSAEventSelect |
Связывает сетевое событие с объектом события. |
WSAGetOverlappedResult |
Сообщает состояние выполнения совместной операции обмена. |
WSAGetQOSByName |
Выдает параметры qos для заданного имени сетевой услуги. |
WSAHtonl |
Расширенная версия htonl |
WSAHtons |
Расширенная версия htons |
WSAIoctl * |
Версия ioctlsocket, пригодная для совмещения процедур ввода/вывода |
WSAJoinLeaf * |
Подключает периферийный узел к многоточечной сессии. |
WSANtohl |
Расширенная версия ntohl |
WSANtohs |
Расширенная версия ntohs |
WSARecv * |
Расширенная версия recv, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров. |
WSARecvDisconnect |
Завершает работу соединителя и выдает информацию о завершении, если соединитель был ориентирован на работу в связанном состоянии. |
WSARecvFrom * |
Расширенная версия recvfrom, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей и получать флаги в качестве входных и выходных параметров |
WSAResetEvent |
Обнуляет объект события. |
WSASend * |
Расширенная версия send, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей. |
WSASendDisconnect |
Инициализирует процедуру закрытия соединения и опционно посылает сообщение disconnect. |
WSASendTo * |
Расширенная версия sendto, которая позволяет совмещать по времени операции ввода/вывода, использовать многобуферную схему при работе с векторами указателей. |
WSASetEvent |
Устанавливает объект события. |
WSASocket |
Расширенная версия socket, которая использует структуру WSAPROTOCOL_INFO в качестве входной информации и позволяет создать соединители, работающие одновременно. Позволяет также формировать группы соединителей. |
WSAWaitForMultipleEvents |
Присылается, если любой или все специфицированные объекты находятся в сигнальном состоянии или когда истекает время таймаута. |
/p> * Программа может вызвать блокировку при работе с блокирующим соединителем.
При написании программ на персональной ЭВМ, например, на С++ или ассемблере существует возможность выбора модели памяти: small, medium, compact, large или huge. Эти модели отличаются друг от друга числом сегментов (по 64 Кбайт) памяти, выделяемой для программы и данных. Модель small предполагает, что все указатели имеют тип near, если явно не указано обратное (не записан модификатор FAR). Модель large считает по умолчанию все указатели дальними, если явно не присутствует модификатор near. В модели huge длина блока данных может превышать размер одного сегмента. С особенностями этих моделей рекомендуется ознакомиться по описаниям конкретных трансляторов. Используя те или иные модели при создании сетевых программ, нужно учитывать проблемы, которые могут возникнуть при переносе вашей программы из одной операционной среды в другую. ОС Unix, Windows NT и Windows 97 не поддерживают каких-либо моделей памяти и их система адресации скорее совместима с моделью large. Но при переносе программы из одной среды в другую об этой проблеме лучше не забывать и перед началом отладки полезно изучить особенности адресации.
При программировании под Windows 3.1 нужно учитывать то, что для доступа к процессору (ЦПУ) необходимо, чтобы программа, захватившая его раньше, прекратила свою работу и освободила ЦПУ. Этого не требуется в среде Unix, Windows 95 или Windows NT. Различие этих операционных сред особенно заметно при выполнении блокирующих процедур, рассмотренных выше, например операции сетевого ввода/вывода. Блокирующие процедуры являются потенциальным источником “повисания” программ, например, оператор recv может вечно ждать отклика, в то время как удаленный сервер будет ждать сообщения от программы, выполняющей recv. По этой причине создание не блокирующих соединителей представляется привлекательным. Такие соединители формируются путем вызова стандартного оператора socket с последующим обращением к процедуре, изменяющей режим работы соединителя (по умолчанию создается блокирующий соединитель). После этого при вызове блокирующего оператора, например, recv при условии, что соединитель не имеет запрашиваемых данных, система возвратит флаг ошибки. Таким образом, при работе с неблокирующим соединителем, операционная система проверяет возможность немедленного выполнения процедуры, и возвращает сигнал ошибки, если это не возможно. Все операторы winsock являются асинхронными и неблокирующими. Асинхронные операции при невозможности выполнить требуемую операцию не выдают сообщения об ошибке, за тем, чтобы процедура была выполнена так как нужно, в этом случае следит операционная система. По завершении асинхронной операции ОС Windows посылает сообщение тому окну, из которого эта операция была вызвана. Но и операторы, работающие с неблокирующими соединителями Беркли, также являются неблокирующими. В то же время все операции ввода и вывода в Unix являются синхронными.
Хотя оператор WSAAsyncSelect считается аналогом select, между ними имеется существенное отличие. WSAAsyncSelect - единственный оператор, использующий дескриптор соединителя в качестве параметра. Если select контролирует состояние нескольких соединителей, для того чтобы достичь того же результата с помощью wsaasyncselect надо реализовать столько вызовов, сколько соединителей мы хотим мониторировать. Форма обращения к WSAAsyncSelect имеет вид:
WSAAsyncSelect
(SOCKETs, HWND hWnd, unsigned int wMsg, long lEvent),
где s - дескриптор соединителя, состояние которого мы хотим контролировать, аргумент, hWnd - дескриптор окна-получателя сообщения; wMsg - определяет тип посылаемого сообщения (эти два параметра являются стандартными для всех функций Windows); lEvent - битовая маска, определяющая тип событий, которые нас интересуют. Возможные значения параметра lEvent приведены в таблице 7.6.
Таблица
7.6. Возможные значения параметра lEvent оператора WSAAsyncSelect
Значение |
Назначение |
| FD_READ | Готовность к чтению |
| FD_WRITE | Готовность к записи |
| FD_OOB | Поступление Out_Of_Band данных |
| SD_ACCEPT | Контроль установки входного соединения |
| FD_CONNECT | Контроль реализованных соединений |
| FD_CLOSE | Контроль закрытия соединения |
Как уже было отмечено, обращение к WSAAsyncSelect переводит соединитель в неблокирующее состояние. При необходимости реализовать, например, процедуру recv, следует обратиться с начала к WSAAsyncSelect, запросив Windows информировать вас о готовности чтения (lEvent=FD_READ). После этого обработчик сообщений windows при получении соответствующего сигнала предоставит возможность прикладной программе перейти к выполнению операции recv. Так как соединитель уже получил данные, блокировки не произойдет и программа их немедленно получит.
Особое внимание блокирующим операциям должно быть уделено в Windows 3.1, поскольку блокировка остановит не только выполнение задачи, вызвавшей эту операцию, но и все другие приложения (ЭВМ станет неуправляемой на время блокировки). Здесь блокирующие процедуры должны быть запрещены, вместо этого при необходимости вызова такой процедуры windows реализует цикл по проверке состояния соединителя (очереди сообщений). Остальные приложения могут при этом продолжить свою работу, а при получении благоприятного сообщения Windows разрешает выполнение блокирующей процедуры, так как она уже не может вызвать блокировки. Осложнения могли бы возникнуть, если обработчик сообщений Windows получит сигнал, который приведет к вызову другой блокирующей процедуры. Сегодня в Windows действует правило, запрещающее такие вызовы из прикладных программ как блокирующие, так и неблокирующие. То есть, на время выполнения блокирующей процедуры все обращения к сетевому интерфейсу запрещены.
Имеется несколько операторов Winsock, предназначенных для работы с блокирующими процедурами (смотри таблицу 7.7):
Таблица 7.7.
WSACancelBlockingCall |
прерывание блокирующей процедуры (без аргументов); |
WSAIsBlocking |
определение блокирующей операции (без аргументов); |
WSASetBlockingHook |
перехват блокирующего вызова, организация цикла ожидания; |
WSAUNhookBlockingHook |
восстановление прежней блокировки. |
Аппарат соединителей предполагает возникновение и исчезновение вычислительных и управляющих процессов. Новый процесс может наследовать "старые" соединители. В этом случае может возникнуть необходимость выяснить, адрес партнера, с которым взаимодействует данный соединитель. Эту задачу можно решить с помощью команды getpeername(s, destaddr, addrlen), где destaddr - указатель на структуру типа (рис. 7.5):
Рис. 7.5. Указатель на структуру типа для команды getpeername
AF
- идентифицирует семейство протоколов (для TCP/IP=2), для которого порожден данный соединитель, вся структура занимает 16 октетов. addrlen - указатель на переменную, куда будет записана длина адреса. Соединитель может быть выключен командой close(s), где s идентификатор соединителя, который надлежит закрыть. Если пользователь не хочет более посылать или получать данные, он может выдать команду shutdown(s, how), где параметр how может принимать значения: 0 - блокируется прием данных; 1 - блокируется передача данных; 3 - блокируются любые обмены.
Каждое соединение должно иметь свой неповторимый код ISN (Initial Sequence Number). Этот код посылается клиентом серверу с помощью сегмента SYN. Для реализации режима соединения прикладная программа на одном конце канала устанавливается в режим пассивного доступа ("passive open"), а операционная система на другом конце ставится в режим активного доступа ("active open"). Протокол TCP предполагает реализацию 11 состояний (ESTABLISHED, CLOSED, LISTEN, SYN_SENT, SYN_RCVD и т.д.), переход между которыми строго регламентирован (смотри раздел 4.4.3).
При написании диагностических и управляющих программ под Windows 95 или NT можно использовать простые соединители (Sock_Raw) или библиотеку ICMP.DLL (эта динамическая библиотека не является частью Win32 API). Библиотека ICMP.DLL содержит в частности процедуру ICMPSendEcho, которая посылает запросы эхо по указанному адресу и возвращает отклик в пределах указанного временного интервала. В качестве аргументов запрос ICMPSendEcho использует ICMP-дескриптор, который получается в результате запроса IcmpCreateFile.
HANDLE WINAPI IcmpCreateFile(VOID);
/* Оператор создает ICMP-дескриптор; при ошибке возвращает INVALID_HANDLE_VALUE */
BOOL WINAPI IcmpCloseHandle(HANDLE IcmpHandle);
/* Оператор ликвидирует ICMP-дескриптор; при возникновении ошибки возвращает значение FALSE */
Обращение к процедуре посылки ICMP запроса эхо имеет формат:
DWORD WINAPI IcmpSendEcho(
HANDLE IcmpHandle,
/* дескриптор, полученный в результате запроса IcmpCreateFile */
LPVOID RequestData,
/* указатель на буфер, где лежат данные, подлежащие посылке */
LPVOID ReplyBuffer,
/* указатель на буфер для приема пакета-отклика */
);
}; ICMPECHO, *PICMPECHO, FAR *LPICMPECHO;
} IPINFO, *PIPINFO, FAR *LPIPINFO;
Приложение может использовать WSAEnumProtocols для определения того, какой транспортный протокол (стек протоколов) поддерживается, и попутно можно получить дополнительную информацию, которая содержится в структуре WSAPROTOCOL_INFO.
В то время как в WinSock 1.1 имеется только одно семейство адресов AF_INET, включающее в себя ограниченное число известных типов соединителей и идентификаторов протоколов, в WinSock 2 это ограничение снято. Информация по WinSock 2 доступна по адресу:
www.stardust.com/winsock/ws_specs.htm
В настоящее время WinSock допускает совмещение по времени нескольких операций ввода/вывода. Такого рода операции возможны только для соединителей, созданных оператором WSASocket с флагом WSA_FLAG_OVERLAPPED=1 (Win32).
Запросы получения и отправки информации возвращают отклик немедленно. Если получен нуль, это означает, что операция ввода/вывода завершилась успешно, если же получен флаг SOCKET_ERROR с кодом ошибки WSA_IO_PENDING, указывает на успешное начало операции, последующие сообщения позволят судить о дальнейшем выполнении операции.
Допуская возможность нескольких операций ввода/вывода одновременно, нужно обеспечить соответствие между этими процессами и сообщениями об их завершении. В Winsock эта проблема решена с помощью введения объектов события (event objects), по аналогии с Win32. Эти объекты создаются, уничтожаются, устанавливаются в определенное состояние и т.д. Приложение может использовать оператор WSACreateEvent для создания дескриптора (указателя) объекта события, который передается в качестве обязательного параметра для совмещаемых во времени процедур посылки и получения данных (WSASend, WSASendTo, WSARecv, WSARecvFrom). Каждому оператору создания объекта WSACreateEvent должен соответствовать оператор WSACloseEvent, ликвидирующий его. Объекты события используются также оператором WSAEventSelect для того, чтобы связать FD_XXX сетевое события с объектами события.
В 32-разрядной среде операторы для работы с объектами события WSACreateEvent, WSACloseEvent, WSAResetEvent, WSASetEvent, WSAGetOverlappedResult и WSAWaitForMultipleEvents строго соответствуют операторам Win32.
Приложение может установить режим ожидания с блокировкой для одного или нескольких объектов события, используя оператор WSAWaitForMultipleEvents. Для этих целей можно применить и WaitForMultipleObjects. Если при ожидании предпочтительнее отсутствие блокировки, можно воспользоваться оператором WSAGetOverlappedResult, чтобы проконтролировать завершение заданного процесса.
Операторы запуска совмещаемых по времени процессов ввода/вывода WSASend, WSASendTo, WSARecv, WSARecvFrom используют в качестве опционного указателя lpCompletionRoutine, который позволяет по завершении процесса обмена передать управление определенной приложением программе.
В версии WinSock 2 введено понятие группы соединителей, которое позволяет приложению сообщить сервис провайдеру, что данный набор соединителей имеет определенные идентичные свойства (атрибуты). К числу этих свойств относятся относительные приоритеты отдельных соединителей в пределах группы, а также спецификация качества услуг (QOS).
Приложения, реализующие мультимедийные потоки данных, нуждаются в организации специфических взаимоотношений между наборами соединителей. Как минимум это может включать подсказку сервис провайдеру о приоритетности потоков информации. Например, при проведении видеоконференций звуковое сопровождение должно иметь более высокий приоритет, чем видеоинформация. Кроме того, существуют сервис провайдеры, которые могут обеспечить запрашиваемое качество обслуживание (код QOS).
WSASocket
и WSAAccept представляют собой два новых оператора, используемых для создания соединителей и групп, а также для включения соединителя в определенную группу. Идентификатор группы соединителя можно узнать с помощью оператора getsockopt с опцией SO_GROUP_ID. Установка и проверка относительного приоритета соединителей в группе осуществляется соответственно операторами getsockopt и setsockopt с опцией SO_GROUP_PRIORITY. Опции соединителей приведены в таблице 7.8.
Таблица 7.8. Опции соединителей
| Опция | Тип | Назначение | Значение по умолчанию |
| SO_GROUP_ID | GROUP | Идентификатор группы, к которой принадлежит соединитель. | NULL |
| SO_GROUP_PRIORITY | int | Относительный приоритет соединителей, принадлежащих к группе. | 0 |
| SO_MAX_MSG_SIZE | int | Максимальный размер сообщения для соединителей, ориентированных на сообщения. Не имеет смысла для соединителей типа stream. | Зависит от реализации |
| SO_PROTOCOL_INFO | struct WSAPROTOCOL_INFO | Описание протокольной информации. | Зависит от протокола |
| PVD_CONFIG | char FAR * | Информационная структура, содержащая данные о сервис провайдере. | Зависит от реализации |
Таблица 7.9. Коды операций
Код операции |
Input Type |
Output Type |
Значение |
| SIO_ASSOCIATE_HANDLE | зависит от API | не использ. | Связывает соединитель с заданным дескриптором интерфейса-партнера. |
| SIO_ENABLE_CIRCULAR_QUEUEING | не использ. | не использ. | Разрешает организацию кольцевой очереди. |
| SIO_FIND_ROUTE | struct sockaddr | не использ. | Запрос маршрута до заданного адреса. |
| SIO_FLUSH | не использ. | не использ. | Аннулирует текущее содержимое очереди на отправку. |
| SIO_GET_BROADCAST_ADDRESS | не использ. | struct sockaddr | Определяет протокольно-зависимый широковещательный адрес для использования в sendto/WSASendTo |
| SIO_GET_QOS | не использ. | QOS | Определяет текущую спецификацию соединителя. |
| SIO_GET_GROUP_QOS | не использ. | QOS | Определяет спецификацию группы, к которой принадлежит соединитель |
| SIO_MULTIPOINT_LOOKBACK | BOOL | не использ. | Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем локальной ЭВМ. |
| SIO_MULTICAST_SCOPE | int | не использ. | Определяет режим, в котором будут осуществляться мультикастинг-обмены. |
| SIO_SET_QOS | QOS | не использ. | Устанавливает новую спецификацию для соединителя. |
| SIO_SET_GROUP_QOS | QOS | не использ. | Устанавливает новую спецификацию группы, к которой принадлежит соединитель. |
| SIO_TRANSLATE_HANDLE | int | зависит от API | Возвращает дескриптор для соединителя s, который соответствует контексту интерфейса-партнера. |
WSAAccept (
IN |
SOCKET |
s , |
OUT |
struct sockaddr FAR |
addr, |
IN OUT |
LPINT |
addrlen , |
IN |
LPCONDITIONPROC |
lpfnCondition, |
IN |
DWORD |
dwCallbackData |
| s | дескриптор соединителя, который находится в режиме listen. |
| addr | опционный указатель на буфер (структуру), где должен храниться адрес подключаемого объекта, формат адреса определяется типом протокола, заданным при создании соединителя. |
| addrlen | Опционный указатель на целую переменную, которая определяет длину аргумента addr. |
| lpfnCondition | Адрес опционной условной процедуры, которая на основе полученной информации, создает группу или подключает соединитель к уже существующей группе. |
| dwCallbackData | Параметр, возвращаемый приложению. Этот параметр не интерпретируется WinSock. |
/p>
IN
и OUT указывают на то, является ли данный параметр входным или выходные.
Программа извлекает очередную заявку на соединение из очереди соединителя s и проверяет с помощью специфицированной программы выполнение условий соединения. Если условия выполнены, возвращается флаг CF_ACCEPT, программа создает новый соединитель и осуществляет подключение его к группе в соответствии с параметром g, выработанным программой проверки условий. Вновь созданный соединитель имеет те же параметры, что и s, включая те, что задаются операторами контроля WSAAsyncSelect или WSAEventSelect. Если программа проверки условия вернула флаг CF_REJECT, запрос на соединение аннулируется. При невозможности принять решение немедленно, программа проверки условия должна вернуть флаг CF_DEFER, при этом никаких действий не предпринимается. Когда приложение будет готово обслужить запрос на соединение, оно снова запустит процедуру WSAAccept и пришлет либо CF_ACCEPT, либо CF_REJECT в качестве результата проверки условий.
Для соединителей, которые остаются в блокирующем режиме, когда в очереди нет запросов на соединение, WSAAccept блокирует вызывающую программу до появления заявки на соединение. Для соединителей неблокирующего типа, когда очередь пуста, оператор WSAAccept вернет флаг ошибки.
При завершении процедуры в addrlen будет записана реальная длина адреса в байтах. Если addr и (или) addrlen равны нулю, это означает, что нет никакой информации об адресе удаленного адресата. В противном случае эти параметры несут в себе реальную информацию не зависимо от результатов проверки условий. Прототип программы проверки условий имеет формат:
int CALLBACK
ConditionFunc(
IN |
LPWSABUF |
lpCallerId , |
IN |
LPWSABUF |
lpCallerData , |
IN OUT |
LPQOS |
lpSQOS , |
IN OUT |
LPQOS |
lpGQOS, |
IN |
LPWSABUF |
lpCalleeId , |
OUT |
LPWSABUF |
lpCalleeData , |
OUT |
GROUP FAR * |
g |
IN |
DWORD |
dwCallbackData |
ConditionFunc
представляет собой указатель имени программы, которая служит для проверки условий. В 16-битной версии Windows, эта программа выполняется в рамках той же сессии, что и WSAAccept, поэтому вызов каких-либо иных WinSock операторов кроме WSAIsBlocking и WSACancelBlockingCall не возможен. Программа проверки условий должна находиться в DLL или прикладном модуле. Для определения адреса программы проверки условий следует пользоваться оператором MakeProcInstance.
Переменные lpCallerId и lpCallerData являются параметрами, которые содержат адрес партнера и любую пользовательскую информацию, которая была прислана вместе с запросом на соединение.
lpSQOS
представляет собой указатель на текущую спецификацию QOS соединителя s (по одной для каждого из концов виртуального канала), за которой следуют дополнительные параметры, заданные провайдером. Нулевое значение lpSQOS указывает на то, что вызывающая сторона не задала значения QOS.
lpGQOS
- указатель на спецификацию QOS группы соединителей, созданной запрашивающей стороной (для каждого из направлений обмена), за которой следуют дополнительные параметры, заданные провайдером.
lpCalleeId
представляет собой локальный адрес вызывающей стороны.
lpCalleeData
используется программой проверки условий для записи результатов ее работы.
lpCalleeData
первоначально содержит размер буфера, предназначенного для сервис провайдера. Положение буфера определяется указателем lpCalleeData->buf. Программа проверки условий должна скопировать lpCalleeData->len байт в lpCalleeData->buf, а затем провести актуализацию lpCalleeData->len, с тем чтобы сообщить действительное число переданных байтов.
В таблице 7.10 представлен перечень кодов-сообщений об ошибках вместе с их эквивалентами для Berkley-соединителей.
Таблица 7.10. Краткое описание сообщений об ошибках
WinSock-код |
Berkeley-эквивалент |
Код ошибки |
Значение |
| WSAEINTR | EINTR | 10004 | Как в стандартном C |
| WSAEBADF | EBADF | 10009 | Как в стандартном C |
| WSAEACCES | EACCES | 10013 | Как в стандартном C |
| WSAEFAULT | EFAULT | 10014 | Как в стандартном C |
| WSAEINVAL | EINVAL | 10022 | Как в стандартном C |
| WSAEMFILE | EMFILE | 10024 | Как в стандартном C |
| WSAEWOULDBLOCK | EWOULDBLOCK | 10035 | Как в BSD |
| WSAEINPROGRESS | EINPROGRESS | 10036 | Эта ошибка возникает, если какая-либо процедура WinSock вызвана во время исполнения блокирующей операции. |
| WSAEALREADY | EALREADY | 10037 | Как в BSD |
| WSAENOTSOCK | ENOTSOCK | 10038 | Как в BSD |
| WSAEDESTADDRREQ | EDESTADDRREQ | 10039 | Как в BSD |
| WSAEMSGSIZE | EMSGSIZE | 10040 | Как в BSD |
| WSAEPROTOTYPE | EPROTOTYPE | 10041 | Как в BSD |
| WSAENOPROTOOPT | ENOPROTOOPT | 10042 | Как в BSD |
| WSAEPROTONOSUPPORT | EPROTONOSUPPORT | 10043 | Как в BSD |
| WSAESOCKTNOSUPPORT | ESOCKTNOSUPPORT | 10044 | Как в BSD |
| WSAEOPNOTSUPP | EOPNOTSUPP | 10045 | Как в BSD |
| WSAEPFNOSUPPORT | EPFNOSUPPORT | 10046 | Как в BSD |
| WSAEAFNOSUPPORT | EAFNOSUPPORT | 10047 | Как в BSD |
| WSAEADDRINUSE | EADDRINUSE | 10048 | Как в BSD |
| WSAEADDRNOTAVAIL | EADDRNOTAVAIL | 10049 | Как в BSD |
| WSAENETDOWN | ENETDOWN | 10050 | Как в BSD. Ошибка возникает в любое время, когда приложение WinSock обнаруживает ошибку на нижележащем уровне. |
| WSAENETUNREACH | ENETUNREACH | 10051 | Как в BSD |
| WSAENETRESET | ENETRESET | 10052 | Как в BSD |
| WSAECONNABORTED | ECONNABORTED | 10053 | Как в BSD |
| WSAECONNRESET | ECONNRESET | 10054 | Как в BSD |
| WSAENOBUFS | ENOBUFS | 10055 | Как в BSD |
| WSAEISCONN | EISCONN | 10056 | Как в BSD |
| WSAENOTCONN | ENOTCONN | 10057 | Как в BSD |
| WSAESHUTDOWN | ESHUTDOWN | 10058 | Как в BSD |
| WSAETOOMANYREFS | ETOOMANYREFS | 10059 | Как в BSD |
| WSAETIMEDOUT | ETIMEDOUT | 10060 | Как в BSD |
| WSAECONNREFUSED | ECONNREFUSED | 10061 | Как в BSD |
| WSAELOOP | ELOOP | 10062 | Как в BSD |
| WSAENAMETOOLONG | ENAMETOOLONG | 10063 | Как в BSD |
| WSAEHOSTDOWN | EHOSTDOWN | 10064 | Как в BSD |
| WSAEHOSTUNREACH | EHOSTUNREACH | 10065 | Как в BSD |
| WSASYSNOTREADY | 10091 | Выдается WSAStartup, указывает, что сетевая субсистема использоваться не может. | |
| WSAVERNOTSUPPORTED | 10092 | Выдается WSAStartup, указывая на то, что WinSock DLL не может поддерживать это приложение. | |
| WSANOTINITIALISED | 10093 | Выдается любой процедурой кроме WSAStartup, указывая на то, что успешное исполнение WSAStartup не было осуществлено. | |
| WSAEDISCON | 10094 | Выдается recv, WSARecv, чтобы отметить начало разрыва связи удаленным партнером | |
| WSA_OPERATION_ABORTED | TBD | Совмещенные по времени процедуры прерваны из-за закрытия соединения, или выполнения команды SIO_FLUSH в WSAIoctl | |
| WSAHOST_NOT_FOUND | HOST_NOT_FOUND | 11001 | Как в BSD |
| WSATRY_AGAIN | TRY_AGAIN | 11002 | Как в BSD |
| WSANO_RECOVERY | NO_RECOVERY | 11003 | Как в BSD |
| WSANO_DATA | NO_DATA | 11004 | Как в BSD |
/p> Современные версии WinSock обеспечивают протокольно- независимый доступ ко всем ресурсам сети, включая такие стандартные приложения, как DNS, SAP, X.500 и т.д.
Позволяют реализовать несколько сессий ввода/вывода одновременно.
Поддерживают любые стандартные уровни сервиса (QOS - Quality of service). Осуществляют объединение соединителей по группам в соответствии с их параметрами.
Допускается многопротокольная широковещательная или мультикастинг-адресация.
Предусматривается совместное использование соединителей несколькими процессами, условное создание соединителей и объединение их в группы.
Введено понятие WOSA-интерфейса (Windows Open Service Architecture), который обеспечивает связь между прикладной программой и сетевыми процедурами ОС. Этот интерфейс заметно упрощает программирование при работе с пакетами.
Каждая процедура, распознаваемая WOSA, имеет в свою очередь несколько интерфейсов, ориентированных на конкретных сервис-провайдеров. Применение этих средств реализуется через DLL.
WinSock, следуя модели WOSA, обеспечивает прикладной интерфейс для сетевого программирования (API - Application Programming Interface), который организует доступ к транспортным услугам и серверу имен сервис-провайдера (SPI - Service Provider Interfaces). SPI ориентирован на использование в рамках 32-битовой модели Microsoft Windows, включая Windows NT и Windows 95.
Транспортные сервис-провайдеры (например, TCP/IP или IPX/SPX) и именные серверы (DNS) в WinSock представляют собой динамические библиотеки (DLL) с одной точкой входа для процедур инициализации WSPStartup или NSPStartup (обратите внимание на то, что здесь под сервис-провайдером подразумевается система, способная предоставить определенный вид услуг). Все остальные процедуры сервис-провайдера сделаны доступными для WinSock DLL через диспетчерскую таблицу. Динамическая библиотека сервис-провайдера загружаются в память WinSock DLL только по мере необходимости и выгружаются, когда они более не нужны. Динамическая библиотека сервис-провайдера имеет обычно расширение .WSP или .NSP. Процедуры WinSock SPI имеют префиксы:
Сервис- провайдеры WinSock при работе со строками используют UNICODE. WinSock DLL выполняют необходимые преобразования при работе с приложениями, использующими ANSI или UNICODE.
Конкретный сервис-провайдер может поддерживать один или более протоколов. Так TCP/IP-провайдер должен как минимум поддерживать TCP- и UDP-протоколы, в то время как IPX/SPX-провайдер - IPX, SPX и SPX II. Каждый поддерживаемый протокол описывается в структуре WSAPROTOCOL_INFO, а набор таких структур представляет собой каталог используемых протоколов (более детальную информацию по данной тематике можно найти по адресу: www.stardust.com/winsock/ws_specs.htm).
Одной из главных задач WinSock DLL является выполнение функции регулировщика информационных потоков между приложениями и сервис-провайдерами. Каждый сервис-провайдер взаимодействует только с WinSock DLL. WinSock DLL заботится об объединении потоков событий от разных сервис-провайдеров и направлении их приложению. Эта библиотека берет на себя функции арбитража и синхронизации. Взаимоотношения между сервис-провайдерами (даже если они поддерживают разные протоколы) улаживаются также WinSock DLL.
Работа WinSock DLL базируется на параметрах соединителей, которые задаются при формировании (socket и WSASocket), именно эта информация определяет, какой из сервис провайдеров будет задействован. Для выбора сервис провайдера используется процедура WSPSocket. В случае процедуры socket, WinSock DLL находит запись в структуре WSAPROTOCOL_INFO, которая соответствует входным параметрам (идентификатор стека протоколов, тип соединителя, протокол).
Сервис-провайдеры используют сетевые протоколы низкого уровня. WinSock DLL осуществляет управление на среднем уровне, обеспечивая связь транспортных протоколов с приложениями.
Транспортный SPI WinSock аналогичен WinSock API с точки зрения базовых процедур с соединителями. Так процедурам connect и WSAConnect ставится в соответствие WSPConnect; accept и WSAAccept - WSPAccept, а socket и WSASocket - WSPSocket.
Так как WinSock DLL не поставляется теперь разработчиками стека протоколов, расширение функциональных возможностей представляет определенную проблему. Для преодоления этих трудностей новейшие версии WinSock используют процедуру WSAIoctl, чтобы помочь сервис-провайдерам на практике реализовать какие-либо функциональные новшества.
Для введения расширенных возможностей приложение должно запросить указатель на точку входа в соответствующую программу. Это делается с помощью процедуры WSAIoctl, используя команду SIO_GET_EXTENSION_FUNCTION_POINTER. При этом входной буфер процедуры WSAIoctl содержит идентификатор запрашиваемой функции, в выходной буфер будет занесен указатель на нужную программу.
Идентификаторы, присвоенные новым функциям, должны быть уникальными глобальными идентификаторами (GUID - Global Unique IDentifiers), которые присваиваются им поставщиками сервис-провайдеров.
Для того чтобы транспортный протокол стал доступен через WinSock, он должен быть правильно инсталлирован и зарегистрирован в WinSock. Когда транспортный сервис-провайдер инсталлирован с помощью программы поставщика, соответствующая информация должна быть введена в конфигурационную базу данных, чтобы дать WinSock DLL необходимые данные для взаимодействия с сервис-провайдером.
В WinSock DLL содержится процедура WSCInstallProvider для инсталляции программ поставщиков и процедура выгрузки этих программ WSCDeinstallProvider.
Структура WSAPROTOCOL_INFO поставляется для каждого протокола и указывает на то, является ли этот протокол базовым, слоевым или стеком. Величина поля ProtocolChain.ChainLen интерпретируется как:
| 0 | протокол слоя |
| 1 | базовый протокол (или стек, если стек состоит из одного протокола) |
| >1 | стек протоколов. |
SDK ( System Development Kit) для WinSock включает в себя инструментальную WinSock и отладочную DLL.
При разработке протокольно-независимых приложений для систем клиент-сервер нужно зарегистрировать имя сервера в банке имен, только это может сделать его доступным извне. Программа-клиент может функционировать лишь при условии, если она способна найти необходимую ей процедуру в поле имен и получить доступ к соответствующему транспортному протоколу и адресной информации. Для тех кто работает с протоколами TCP/IP это может в начале вызвать определенные трудности, которые компенсируются возможностями создания программ, пригодных для широкого класса самых разнообразных протоколов (например, Novell). Под работой с полем имен здесь подразумевается возможность установления соответствия между протоколом и адресным атрибутом сетевой услуги, которой присвоено какое-то имя. Примерами таких полей имен могут служить уже используемые системы DNS (Domain Name System), NDS (Netware Directory Services), X.500 и др. Поля имен могут быть динамическими, статическими и постоянными.
Динамические поля имен служат для краткосрочной регистрации сетевой услуги. Часто они базируются на широковещательной системе определения доступности той или иной услуги. Примерами таких систем являются SAP в среде Netware и NBP в среде Appletalk.
Статические поля имен формируются при первоначальном создании сервера имен и в дальнейшем могут изменяться лишь администратором сети. Традиционная система DNS относится именно к этой разновидности. Программа может воспользоваться таким банком имен, но не может произвести туда запись.
Постоянное поле имен сходно с динамическим - запись туда происходит в реальном масштабе времени, но после регистрации имя записывается в постоянную память и остается там до тех пор, пока не придет запрос на ликвидацию этой записи. Примерами такой системы могут служить X.500 и NDS.
Некоторые поля имен организованы иерархически, X.500 и NDS, например, позволяют неограниченное число уровней вложения. Программные интерфейсы, предназначенные для посылки запросов в именные базы данных, сильно варьируются в зависимости от разновидности используемого поля имен. Сервер имен представляет собой резидентную программу, которая обеспечивает интерфейс между WinSock SPI и некоторой существующей базой данных имен.
Используемые услуги в WinSock группируются в классы услуг и в пределах класса имя услуги должно быть уникально. Примерами классов услуг могут служить FTP и SQL. Каждому классу присваивается имя и идентификатор (ID). Имя класса может не быть уникальным, но идентификатор обязан быть неповторимым. В качестве идентификаторов классов услуг в Winsock используются GUID (Globally Unique Identifiers). Для генерации GUID имеется специальная программа (UUIDGEN.EXE), которой может воспользоваться разработчик новых классов услуг.
DNS в Internet не имеет развитой системы для записи информации о классах услуг. Для TCP/IP-класса услуг GUID присвоен раз и навсегда.
WinSock DLL может маршрутизовать прикладные операции в пространстве имен и переадресовывать их соответствующим серверам имен.
Процедуры установки классов услуг, регистрации и обслуживания запросов осуществляются непосредственно через интерфейс API - SPI. Процедура WSAGetServiceClassNameByServiceClassId не имеет аналога среди операторов SPI, так как эта процедура WinSock DLL осуществляет обращение к NSPGetServiceClassInfo.
Переключение сервера имен из активного состояния в пассивное и обратно осуществляется с помощью процедуры WSCEnableNSProvider. В активном состоянии могут находиться несколько серверов имен одновременно. Инициализация сервис провайдеров выполняется с помощью процедуры WSPStartup (см. аналогично WSAStartup). Каждой процедуре WSPStartup должна соответствовать процедура WSPCleanup.
Процедура WSPSocket имеет параметр flags, который позволяет контролировать атрибуты соединителя. Флаг WSA_FLAG_OVERLAPPED указывает на то, что данный соединитель будет использоваться в режиме совмещения процессов ввода/вывода.
Существуют атрибуты, ответственные за использование соединителя для работы в многоточечном и/или мультикастинг режимах. Только соединители, созданные для работы в многоточечном режиме, пригодны для запуска многоточечных сессий с помощью WSPJoinLeaf.
Соединитель, созданный для работы в блокирующем режиме, может быть преобразован в неблокирующий с помощью процедур WSPAsyncSelect, WSPEventSelect или WSPIoctl. Перевод соединителя в блокирующий режим производится посредством процедур WSPIoctl, если WSPAsyncSelect неактивен, или WSPEventSelect, если активен.
Процедура WSPCloseSocket ликвидирует дескриптор соединителя и все процессы, использующие этот соединитель, будут прерваны.
Понятие блокировки для среды Windows было фундаментальным. В WinSock 1.1, блокирующие процедуры WinSock были проблемой, так как они парализовали взаимодействие приложения и надстройки Windows, а применение псевдо-блокирующей техники не всегда давало удовлетворительный эффект. В ОС типа Windows 95 или Windows NT блокирующие процедуры уже не могут вызвать каких-либо проблем, более того, они уже представляются привлекательными. Интерфейс WinSock 2 API уже не поддерживает более псевдоблокировку, но для обеспечения совместимости с WinSock 1.1 он эмулирует этот механизм.
В среде Win16, где настоящее блокирование не поддерживается ОС, блокирующие процедуры, которые не могут быть закончены немедленно, обслуживаются с использованием псевдоблокировки. Сервис-провайдер инициализирует процедуру, после чего входит в цикл, внутри которого осуществляет доставку любых сообщений Windows и проверяет завершение процедуры. Если процедура завершилась, или если вызван оператор WSPCancelBlockingCall, происходит выход из цикла, а блокирующая процедура завершается с соответствующим результатом.
Эта схема вполне приемлема для простых приложений. Но она неприемлема для приложений, где должны реализоваться сложные схемы доставки сообщений, например, для модели MDI (Multiple Document Interface). Для таких приложений псевдоблокировка должна быть реализована в самом приложении. Сервис-провайдер в этом случае должен вызывать именно этот цикл. Для этого он должен получить указатель на него, обратившись к WPUQueryBlockingCallback.
Сервис-провайдер WinSock не может исходить из предположения, что псевдоблокировка, используемая приложением, обеспечит обработку сообщений. Если приложение не приспособлено для решения таких задач, оно откликнется флагом FALSE. Если сервис-провайдер требует обработки сообщений для своих внутренних нужд, он может вызвать процедуру PeekMessage до передачи управления циклу псевдоблокировки в приложении.
Сервис- провайдер WinSock использует псевдоблокировку лишь при выполнении определенных условий:
Программа определена как блокирующая,
Соответствующий соединитель работает в блокирующем режиме,
Запрос не может быть выполнен немедленно.
Если условия не выполнены, уход в цикл псевдоблокировки осуществлен не будет.
Если во время цикла псевдоблокировки получено сообщение Windows, существует опасность того, что будет предпринята попытка вызова еще одной процедуры WinSock. Из-за трудностей управления этим процессом WinSock 1.1 запрещает такие вызовы. Любая попытка осуществить вложенный вызов процедур WinSock вызовет ошибку WSAEINPROGRESS. Для WinSock 1.1 это ограничение справедливо как для блокирующих, так и для неблокирующих процедур. Имеется два исключения из этого правила. Это процедура, которая позволяет приложению проверить, находится ли система в цикле псевдоблокировки (WSAIsBlocking), и процедура ухода из этого цикла (WSPCancelBlockingCall).
WinSock 2 DLL имеет средства для формирования объектов событий, как для приложения, так и для сервис-провайдера, хотя на практике объекты событий создаются в основном приложениями. Для формирования объектов событий в WinSock имеется оператор WPUCreateEvent. Дескриптор объекта события имеет смысл лишь в контексте программы, его сформировавшей. В среде Win32 работа с объектами событий выполняется самой операционной системой.
Объекты событий в WinSock представляют собой простые конструкции, которые могут создаваться и уничтожаться, они могут устанавливаться и сбрасываться. Клиент создает объект события и передает его дескриптор в качестве параметра таким процедурам как WSPSend и WSPEventSelect. Когда оговоренные условия выполнены, сервис-провайдер использует дескриптор для того, чтобы установить объект события с помощью оператора WPUSetEvent. При этом клиент WinSock SPI может находиться в состоянии блокировки-ожидания или в режиме запроса, ожидая, когда объект события будет установлен. Клиент может сбросить объект события в нуль, снова его установить и использовать снова.
Субъект (приложение или сервис-провайдер), создавший объект события, ответственен и за его ликвидацию. Сервис-провайдер может это сделать с помощью WPUCloseEvent.
Одной из главных задач сервис-провайдера является сообщение приложению о том, что произошло соответствующее сетевое событие. Список сетевых событий включает в себя:
| FD_CONNECT | Канал до удаленной ЭВМ или для мультикастинг-сессии сформирован |
| FD_ACCEPT | Удаленная ЭВМ выставила запрос на соединение; |
| FD_READ | Получены данные и их можно считать; |
| FD_WRITE | В буферах сервис-провайдера появилось свободное место и можно послать очередную порцию информации; |
| FD_OOB | Для чтения доступна высокоприоритетная информация; |
| FD_CLOSE | Удаленная ЭВМ закрывает канал; |
| FD_QOS | Произошло изменение оговоренного значения QOS (качества услуг); |
| FD_GROOUP_QOS | Произошло изменение оговоренного значения QOS для данной группы соединителей. |
В Windows Sockets 1.1 используется асинхронный механизм получения информации о сетевых событиях. Для регистрации интересующих событий можно использовать процедуру WSPAsyncSelect. Когда нужное сетевое событие произойдет, соответствующему окну будет послано сообщение, заданное клиентом. Сервис-провайдер использует для тех же целей процедуру WPUPostMessage. В среде Win32 этот метод получения данных о событиях нельзя считать эффективным.
WSPEventSelect
ведет себя практически также как WSPAsyncSelect за исключением того, что вместо посылки сообщения Windows при сетевом событии типа FD_XXX, устанавливается соответствующий объект события.
Факт прихода сетевого события FD_XXX сервис-провайдером запоминается. Вызов процедуры WSPEnumNetworkEvents вызывает копирование текущего содержимого памяти сетевых событий в буфер клиента, а основная память событий очищается.
Сервис-провайдеры (ISDN или ATM) могут использовать групповые значения QOS при формировании виртуального канала и повышения эффективности своей работы. Пакеты для соединителей в пределах группы мультиплексируются обычным образом.
Операторы WSPSocket и WSPAccept предназначены для формирования соединителей и подключения новых соединителей, к той или иной группе. Однажды включенный в группу соединитель остается в ней до своего закрытия. Группа прекращает свое существование, лишь когда последний соединитель группы будет закрыт. Идентификатор группы соединителей может быть получен с помощью оператора WSPGetSockOpt с опцией SO_GROUP_ID. Узнать об относительном приоритете соединителя в группе можно, воспользовавшись процедурой WSPGet/SetSockOpt с опцией SO_GROUP_PRIORITY.
Групповое значение QOS можно задать при выполнении WSPConnect, или WSPIoctl с SIO_SET_GROUP_QOS, если специфицированный соединитель является “учредителем” группы. Оператор WSPIoctl с SIO_GET_GROUP_QOS может использоваться для получения группового значения QOS заданного соединителя.
Для провайдеров, поддерживающих группирование соединителей, минимально необходимы следующие функции:
Создание новых групп и присвоение им уникальных идентификаторов.
Возможность включения соединителя в одну из существующих групп.
Учет провайдером значения QOS порождающего соединителя при формировании списка параметров нового соединителя, включаемого в группу.
Существуют группы двух видов. Одни включают в себя соединители, ориентированные на соединение, они могут быть подключены только к определенному адресу ЭВМ, остальные группы относятся к другому виду. Провайдер не может включить в группу соединитель, который не удовлетворяет этому условию. Провайдер не может также выполнить соединение, если адресат не соответствует адресу места назначения группы соединителей. Групповой адрес места назначения определяется, когда выполняется процедура connect для первого из соединителей группы.
Единственный индивидуальный параметр соединителя в группе - его внутренний уровень приоритета. Провайдер должен уметь считывать значение приоритета, но он может полностью игнорировать этот параметр. В настоящее время не существует каких-либо механизмов для сопоставления приоритетов соединителей, принадлежащих к разным группам, или соединителей вне групп. Поддержка провайдеров групп не означает непременную поддержку различного качества услуг (QOS, см. RFC-1363).
Поддержание работы с приоритетами соединителей в пределах группы является рекомендательным требованием. Схема приоритетов WinSock 2 имеет смысл лишь для мультиплексирования данных при соединении точка-точка, например, в случае телефонной связи или любых других вариантах, реализующих коммутацию каналов.
Характер информационного обмена описывается спецификацией потока (flow specs), для каждого соединителя используется две такие спецификации, по одной для каждого из направлений обмена. Запрос на соединение реализуется через процедуры WSPConnect или WSPIoctl с кодом команды SIO_SET_QOS/SIO_SET_GROUP_QOS. Спецификация потока параметрически задает уровень сервиса (QOS) и определяет механизм адаптации приложения к сетевым условиям.
В WinSock 2 спецификация потока содержит следующие характеристики QOS:
Описание источника информационного потока, которое характеризует способ, используемый приложением, для введения потока данных в сеть. Эта спецификация выполняется в терминах модели пакетов символов (token bucket) и включает частоту символов, их размер, частоту пакетов символов и их размер, а также максимальное значение информационного потока.
Задержка (latency) - приемлемые верхние пределы задержки и ее вариации.
Гарантированный уровень обслуживания. Предполагается, что провайдер, который не способен обеспечить требуемый уровень сервиса (QOS), не сможет быть подключен.
Цена (параметр зарезервирован на будущее).
Параметры, специфические для провайдера (спецификация потока может быть расширена, чтобы имелась возможность описать некоторые особенности провайдера).
Для протоколов, ориентированных на соединение более удобно для приложения оговаривать QOS при формировании соединения. Это делается путем запроса WSPConnect, направленного сервис-провайдеру. Если QOS было задано с помощью WSPIoctl, его значение может быть переписано при выполнении процедуры WSPConnect.
Бессвязные соединители могут также использовать WSPConnect с целью установления определенного уровня QOS для канала связи с партнером
После каждой попытки установить связь провайдер производит коррекцию спецификации потока для того, чтобы наилучшим образом отразить реальную ситуацию в сети. Предполагается, что клиенты могут использовать текущую сетевую информацию для того, чтобы оптимально реализовать возможности сети.
Но после того как информация о состоянии сети получена, условия могут измениться, партнеры могут согласовать другой уровень QOS, так что приложение должно быть готово ко всему. Для информирования клиента о возможных изменениях условий в Winsock используется механизм сетевых событий (FD_QOS и FD_GROUP_QOS). Сервис-провайдер должен генерировать события типа FD_QOS/FD_GROUP_QOS, если уровень сервиса изменился значительно. Клиент должен использовать WSPIoctl с кодами команд SIO_GET_QOS и/или SIO_GET_GROUP_QOS, чтобы получить соответствующую спецификацию потока и выяснить, изменился ли уровень сервиса (QOS). Структура QOS должна актуализоваться вне зависимости от типа события FD_QOS/FD_GROUP_QOS. Если новый уровень сервиса неприемлем, клиент может попытаться приспособиться к новым условиям или закрыть соединение. При повторной попытке согласовать уровень QOS успешный выход из процедуры WSPIoctl указывает, что новое значение QOS приемлемо. Структура QOS в WinSock 2 описана в файле Winsock2.h и представлена ниже.
typedef enum
{
BestEffortService,
ControlledLoadService,
PredictiveService,
GuaranteedService
} GUARANTEE;
typedef struct _flowspec
{
GUARANTEE LevelOfGuarantee;
1, если есть доступ,
0, если нет */
} FLOWSPEC, FAR * LPFLOWSPEC;
typedef struct _QualityOfService
{
} QOS, FAR * LPQOS;
Определения:
LevelOfGuarantee |
Согласуемый уровень сервиса. Определены четыре уровня: гарантированный, предсказуемый, контролируемая загрузка и лучшее, что возможно. Предсказуемый уровень сервиса может дать наилучший результат при использовании определенного ресурса сети, в то время как гарантированный уровень соответствует необходимому уровню услуг конкретного приложения. Провайдеры могут предоставлять один, оба или ни одного их этих двух видов услуг. |
GuaranteedService |
Провайдер, поддерживающий гарантированный уровень сервиса, использует алгоритм очередей, в котором поток изолируется от влияния других потоков, и гарантирует, на сколько возможно, пропускную способность. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Если поток находится в пределах допустимого, то гарантируется и задержка отклика. Этот вид сервиса предусмотрен для приложений реального времени. |
PredictiveService |
Провайдер, поддерживающий предсказуемый уровень сервиса, гарантирует пропускную способность, по крайней мере равную TokenRate, на время соединения. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Значение задержки не гарантируется. Этот вид сервиса предназначен для приложений, способных адаптироваться к вариациям качества услуг, например, передача видео изображения. |
ControlledLoadService |
Этот уровень сервиса предполагает, что система сетевых устройств, которыми пользуется приложение, обеспечит условия работы, близкие к тем, которые достижимы при незагруженных каналах, для используемой транспортной среды. Приложения, использующие этот уровень сервиса, могут ожидать что: 1. Большая часть передаваемых пакетов будет успешно доставлена (процент потерь определяется частотой ошибок транспортной среды). 2. Задержка доставки не будет заметно превышать минимальное время распространения сигнала в используемой транспортной среде. |
| BestEffortService | Провайдеры, поддерживающие уровень сервиса “лучшее что возможно”, рассматривают спецификацию потока, как руководство к действию. И пытаются сделать все возможное, чтобы поддержать запрашиваемый уровень сервиса (без каких-либо твердых гарантий). |
| TokenRate/TokenBucketSize | Модель “блоков символов” (Token bucket model) используется для задания верхнего предела скорости обмена. Величина value -1 в этом случае означает, что не существует никаких ограничений на скорость обмена. Значение TokenRate (частота символов) выражается в байтах в сек, а TokenBucketSize в байтах. Блок имеет определенный объем (TokenBucketSize), который заполняется с определенной скоростью (TokenRate). Если в блоке достаточно места, приложение может посылать данные, что приводит к уменьшению свободного места. Если же свободного места нет, приложение должно прервать обмен и ждать. Если приложение в течение определенного времени слало данные со скоростью меньше чем TokenRate, оно может затем на некоторое время превысить эту скорость. |
PeakBandwidth |
Значение этого поля (выражается в байтах в сек) ограничивает максимальную скорость пересылки пакетов приложением. Промежуточные системы могут использовать эту величину для оптимизации использования имеющихся ресурсов. |
Latency |
Характеризует максимально приемлемую задержку между посылкой бита отправителем и его получением адресатом (в миллисекундах). |
DelayVariation |
Значение этого поля в миллисекундах характеризует разницу между максимальной и минимальной задержкой доставки пакетов. Этот параметр используется приложением для расчета объема входного буфера. |
CostOfCall |
Зарезервировано на будущее и должно равняться нулю. |
NetworkAvailability |
Это поле, доступное провайдерам только в режиме чтения, используется для сообщения приложению о доступности транспортной среды (например, знакомая многим ситуация потери спутника антенной). |
/p> Приложения, которые не склонны иметь дело с QOS-структурой непосредственно, могут воспользоваться именами известных видов сервиса и получить нужные данные с помощью запроса WSPGetQOSByName.
Прежде чем использовать соединитель, надо связать его с локальным адресом. Это выполняется с помощью процедуры WSPBind, или WSPConnect.
Сервер сначала создает соединитель, связывает его с известным локальным адресом (что позволяет клиенту найти его) и переводит соединитель в режим ожидания посредством WSPListen, готовя его к приему запросов на соединение. Одновременно система подготавливает структуру для формирования очереди запросов. Сервис-провайдер заносит поступающие запросы в очередь, где они ожидают обработки. Запросы могут быть удалены клиентом из очереди по таймауту.
Если использован соединитель блокирующего типа, сервер может немедленно вызвать процедуру WSPAccept, которая вызовет блокировку на время ожидания запроса на соединение. В качестве альтернативы сервер может использовать один из механизмов обработки сетевых событий, описанный ранее. В зависимости от выбранного механизма провайдер или пошлет сообщение Windows или даст знать о приходе запроса на соединение через объект события.
Клиент со своей стороны создаст соответствующий соединитель, запустит процедуру подключения и пошлет запрос WSPConnect, указав известный адрес сервера. Если соединитель является блокирующим, WSPConnect вызовет блокировку до тех пор пока сервер не получит и не обработает запрос на соединение или пока не произойдет таймаут. Клиент должен использовать механизм сетевых событий для отслеживания процесса соединения.
Когда сервер запускает процедуру WSPAccept, сервис-провайдер инициализирует программу проверки условий, поставляемую приложением. В качестве параметров обращения используется информация, полученная вместе с запросом на соединение (берется из очереди запросов). Эта информация включат в себя адрес подключаемой ЭВМ, данные о пользователе и характеристику QOS, если таковая имеется. На основе полученной информации сервер определяет, принять данный запрос или нет.
Если сервер принял запрос, он должен сформировать новый соединитель с теми же атрибутами что и соединитель ожидавший прихода запроса. Исходный соединитель остается в режиме ожидания последующих запросов.
Для получения локального адреса сопряженными соединителями используется запрос WSPGetSockName. Это особенно полезно, когда послан запрос WSPConnect без предварительного вызова процедуры WSPBind.
Как было сказано ранее, процедура WSPAccept позволяет воспользоваться поставляемой клиентом программой проверки условий, которая осуществляет условную обработку запросов на соединения, ожидающие обслуживания. Принятие решения осуществляется на основе информации, поступающей вместе с запросом (идентификатор источника запроса, QOS и т.д.). Если программа проверки условий возвращает флаг CF_ACCEPT, формируется новый соединитель с теми же свойствами, что и исходный. Если программа проверки вернет флаг CF_REJECT, запрос на соединение будет отвергнут. При возвращении флага CF_DEFER принятие решения откладывается, а запрос на соединение остается в очереди. Клиент должен будет осуществить вызов WSPAccept еще раз.
Некоторые протоколы позволяют переслать информацию в процессе установления связи. Если такая информация получена, она помещается в буфер провайдера, а WinSock SPI получает указатель на этот буфер и длину записи. Если клиент WinSock SPI желает послать некоторую информацию в ответ, он может скопировать ее в буфер, предоставляемый сервис-провайдером.
Разрыв соединения может быть выполнен несколькими способами. Для инициализации прерывания связи можно, например, применить процедуру WSPShutdown (с параметром how равным SD_SEND или SD_BOTH), и WSPSendDisconnect. Процедура WSPCloseSocket может быть применена и для аварийного прерывания соединения.
Сервис провайдер сообщает о разрыве соединения по инициативе удаленного партнера с помощью сетевого события FD_CLOSE. При реализации процедуры разрыва соединения возможен обмен определенной информацией, если это предусмотрено используемым протоколом.
Инициатор разрыва связи может вызвать WSPSendDisconnect, чтобы сообщить, что данных больше посылаться не будет и можно ликвидировать соединение. При этом может быть послана некоторая служебная информация, предусмотренная протоколом обмена. Для чтения этой информации партнер может воспользоваться оператором WSPRecvDisconnect. По завершении этого обмена обе стороны вызывают процедуры WSPCloseSocket.
Следует различать процедуры прерывания (shutdown) связи и ее разрыва (close). Прерывание связи сопряжено с определенным диалогом между партнерами, после чего связь “замораживается”, но дескриптор связи сохраняется. Существует два типа прерывания связи: аварийное (аппаратное) и нормальное. При нормальном прерывании любые данные, которые стояли в очереди, пересылаются до завершения процесса прерывания. При аварийном же прерывании непосланная информация теряется.
В Windows Sockets, как процедура WSPShutdown, так и WSPSendDisconnect могут использоваться для инициализации прерывания связи. В то время как запрос WSPCloseSocket служит для ликвидации дескрипторов соединителей и освобождения связанных с ними ресурсов.
Путем установки определенных значений для опций соединителей SO_LINGER и SO_DONTLINGER можно получит следующие варианты реализации процедуры WSPCloseSocket.
Процедура аварийного прерывания соединения, которая возвращается из WSPCloseSocket немедленно.
Нормальное прерывание соединения (graceful shutdown); задержка исполнения до завершения исполнения процедуры или до истечения заданного времени. Если таймаут наступает до завершения процедуры прерывания соединения, запускается процесс аварийного разрыва соединения.
Нормальное прерывание соединения с немедленным возвратом и завершением процедуры прерывания в фоновом режиме. Этот алгоритм реализуется по умолчанию. Приложение при этом не знает, когда и как завершается процесс прерывания соединения.
Для соединителей, соответствующих протоколам неориентированных на соединение, работа, выполняемая оператором WSPConnect, связана главным образом с установлением адреса места назначения по умолчанию, что позволит в дальнейшем использовать соединитель в операциях обмена, ориентированных на соединение (WSPSend and WSPRecv). Любые дейтограммы, полученные от отправителя с адресом, отличным от специфицированного, будут проигнорированы.
Место назначения по умолчанию может быть изменено с помощью повторного вызова WSPConnect. Любая дейтограмма из входной очереди будет отброшена, если новый адрес отличается от адреса, заданного в предыдущем WSPConnect.
Если новый адрес равен нулю, соединитель будет отсоединен, так как удаленный адрес не определен, в результате операторы WSPSend и WSPRecv возвратят флаг ошибки WSAENOTCONN, в то же время WSPSendTo и WSPRecvFrom могут использоваться по-прежнему. Существует три базовых способа выполнения операций ввода/вывода:
Блокирующий ввод/вывод,
Неблокирующий ввод/вывод с асинхронными сетевыми событиями,
Совмещенный ввод/вывод.
Первый вариант является режимом по умолчанию, неблокирующий вариант может использоваться на любом соединителе, который поставлен в соответствующий режим. Третья разновидность обмена реализуется только на соединителях, которые при формировании были объявлены совмещенными. Процедуры посылки WSPSend и WSPSendTo и приема WSPRecv и WSPRecvFrom реализуют все три указанных режима обмена. Сервис-провайдеры определяют метод обмена на основе режима работы соединителя, атрибутов и входных параметров.
Простейшим режимом обмена в WinSock 2 является блокирующий ввод/вывод. Этот режим устанавливается по умолчанию. Любая операция ввода/вывода на блокирующем соединителе вернет управление системе только по завершении процедуры. Таким образом, в ходе любой сессии может выполняться только одна операция ввода/вывода. Это простой режим, но отнюдь не самый эффективный.
Если соединитель находится в неблокирующем состоянии, любая операция обмена должна либо завершаться немедленно, либо возвращать флаг ошибки WSAEWOULDBLOCK, указывая, что операция не может быть завершена корректно. Необходим механизм для определения, когда следует попытаться выполнить операцию еще раз. Для решения этой проблемы определен список сетевых событий, наступление которых может контролироваться с помощью процедур WSPSelect, WSPAsyncSelect или WSPEventSelect.
В WinSock 2 впервые разрешено совмещение нескольких процедур ввода/вывода и потребована поддержка этого режима всеми сервис-провайдерами. Этот режим возможен только для соединителей, сформированных с помощью WSPSocket с флагом WSA_FLAG_OVERLAPPED.
Для приема данных клиент может воспользоваться процедурами WSPRecv или WSPRecvFrom, чтобы указать буферы, куда будут записываться данные. Если один или более буферов подготовлены приложением до начала обмена, информация будет заноситься непосредственно в буферы пользователя и многоступенчатое копирование будет исключено. Если буферов заранее приложением не подготовлено, информация заносится сервис-провайдером во внутренний буфер и система ждет запроса, чтобы перенести данные в буфер приложения. Исключением из этого правила является случай, когда приложение использует WSPSetSockOpt для установления нулевого размера входного буфера. В этом варианте данные принимаются лишь при наличии указателей на буфер приложения. При посылке информации клиенты для выдачи указателей на буфер данных используют WSPSend или WSPSendTo.
В совмещенном режиме процедуры посылки и получения данных завершаются немедленно. Полученный по возврату нуль, указывает на то, что процедура завершилась успешно. То есть, сформирован соответствующий объект события или программа завершения установлена в очередь с помощью WPUQueueApc. Возврат флага SOCKET_ERROR, сопряженного с кодом ошибки WSA_IO_PENDING, указывает, что совмещенная операция успешно начата и будет позднее сообщено, когда выходной буфер будет свободен или входной буфер будет заполнен. Любые другие коды ошибок говорят о сбое.
Совмещаться могут как операции ввода, так и вывода. Следует иметь в виду, что если было послано несколько блоков данных друг за другом, сообщения о завершении операций по их пересылке могут прийти в другом порядке. Тоже может произойти и при приеме данных.
Сервис-провайдеры имеют два способа сообщать о завершении совмещенных по времени операций: установка объекта события, заданного программой-клиентом, или запуск заданной клиентом программы завершения. В обоих случаях каждой из совмещенных операций ставится в соответствие структура WSAOVERLAPPED. Память для размещения этой структуры выделяется клиентом и используется им для указания того, какой из объектов следует установить при завершении процесса обмена. Структура WSAOVERLAPPED может использоваться сервис-провайдером для хранения дескриптора соответствующей совмещенной процедуры. Для извлечения нужной информации из указанной структуры можно воспользоваться оператором WSPGetOverlappedResult.
Если параметр lpCompletionRoutine совмещенной операции не равен нулю, то сервис-провайдер может вызвать программу завершения, специфицированную клиентом. WinSock DLL предлагает асинхронную процедуру вызова (APC) программ завершения обмена.
Для реализации той или иной функции в рамках сессии сервис-провайдер вызывает сначала процедуру WPUQueueApc. Сервис-провайдер должен позаботиться о том, чтобы процесс, соответствующий выбранному контексту, был активным до вызова функции WPUQueueApc.
WPUQueueApc
берет в качестве входных параметров указатель на структуру WSATHREADID, указатель на процедуру APC и 32-разрядный контекстный код. Сервис-провайдеры всегда получают указатель на соответствующую структуру WSATHREADID через параметр lpThreadId. Провайдер должен запомнить структуру WSATHREADID и выдать указатель на ее копию в качестве параметра оператора WPUQueueApc.
Так как механизм APC работает только с одним 32-разрядным контекстным кодом, процедура APC не может быть сама программой завершения, заданной клиентом. Сервис-провайдер должен выдать указатель на свою собственную процедуру APC, которая, используя контекстный код, обеспечивает доступ к необходимой информации для совмещенной операции обмена и вызывает заданную клиентом программу завершения.
Сервис-провайдер должен позволить клиентам WinSock 2 вызов процедур чтения или записи во время выполнения процедуры завершения обмена и гарантировать, что для данного соединителя не будет допущено вложение операций завершения.
Структура WSAOVERLAPPED создает коммуникационную среду между запуском совмещенной операции обмена и последующим ее завершением. Структура WSAOVERLAPPED совместима со структурой OVERLAPPED для Win32:
typedef struct _WSAOVERLAPPED {
Приоритетные данные могут доставляться пользователю независимо от обычной информации. Для коммуникационных протоколов, где предусмотрена пометка данных как срочные (например, TCP, позволяющий доставку срочной информации в общем потоке данных) система извлекает приоритетную информацию из общего потока и запоминает отдельно.
Пользователь может определить, имеется ли приоритетная непрочитанная информация, используя процедуру WSPIoctl(SIOCATMARK). Для протоколов, где положение приоритетной информации в общем потоке имеет смысл, сервис-провайдер обеспечивает указатели, определяющие это положение. Для таких протоколов допускается обработка приоритетных данных в общем информационном потоке. Это достигается путем установки опции соединителя SO_OOBINLINE (OOB - Out-Of-Band). Для других протоколов, где блоки приоритетных данных независимы от общего информационного потока, попытка установить опцию SO_OOBINLINE вызовет ошибку. Приложение может использовать команду SIOCATMARK WSPIoctl для определения наличия непрочитанных блоков приоритетной информации. При запрещении SO_OOBINLINE (disabled - значение по умолчанию):
Сервис-провайдер WinSock сообщает клиенту о FD_OOB событиях, если клиент зарегистрирован для этого с помощью процедуры WSPAsyncSelect, точно таким же образом FD_READ используется для сообщения о присутствии обычных данных. Таким образом, FD_OOB посылается, когда поступает приоритетная информация, а также когда данные прочитаны с использованием флага MSG_OOB, в условиях присутствия приоритетных данных, подлежащих чтению. Сообщение FD_READ для приоритетных данных не посылается.
Сервис-провайдер WinSock возвращает соответствующий набор exceptfds при выполнении процедуры WSPSelect, если приоритетные данные присутствуют в очереди соединителя.
Клиент может вызвать WSPRecv с MSG_OOB для чтения блока приоритетных данных.
Клиент может вызвать процедуру WSPRecv без MSG_OOB для чтения потока обычной информации. Блок приоритетных данных не может появиться в потоке обычных данных. Если приоритетные данные остаются после запроса WSPRecv, сервис-провайдер дает сообщение клиенту с помощью флага FD_OOB или через exceptfds при использовании запроса B>WSPSelect.
Для протоколов, где приоритетные данные находятся в потоке обычных данных, одного запроса WSPRecv недостаточно. Один вызов WSPRecv вернет обычные данные до маркера, и потребуется второй запрос WSPRecv для чтения данных после маркера.
При разрешении SO_OOBINLINE (enabled):
Сообщение FD_OOB не посылается для приоритетных данных, а процедуры WSPSelect и WSPAsyncSelect рассматривают эти данные как обычные, о типе информации можно судить по readfds соединителя или по сообщению FD_READ, соответственно.
Клиент не может осуществлять вызов WSPRecv с флагом MSG_OOB для чтения блока приоритетных данных - в противном случае будет получен код ошибки WSAEINVAL.
Клиент может вызвать WSPRecv без флага MSG_OOB. Любая приоритетная информация будет доставлена в потоке обычных данных. Приоритетные данные не будут никогда перемешаны с обычными данными, необходимо три запроса чтения для получения приоритетной информации. Первый запрос возвращает обычные данные, предшествующие приоритетным, второй - возвращает приоритетные данные, третий возвращает нормальные данные, следующие за приоритетными.
Программа WSPAsyncSelect прекрасно приспособлена для выявления приоритетных данных, когда SO_OOBINLINE находится в состоянии выключено.
Использование соединителя несколькими процессами одновременно организовано следующим образом. Базовый процесс для получения специальной структуры WSAPROTOCOL_INFO вызывает WSPDuplicateSocket. Эта процедура для передачи структуры другому процессу использует межпроцессный механизм коммуникаций (IPC). Последний процесс использует структуру WSAPROTOCOL_INFO при обращении к WSPSocket. Дескриптор соединителя, полученный в результате этой операции, будет дополнительным дескриптором исходного соединителя, который с этого момента может использоваться двумя процессами.
Такой механизм разработан для того, чтобы удовлетворить как требованиям однопроцессной версии Windows 3.1, так и многопроцессным вариантам Windows 95 и NT. Следует иметь в виду, что совместное использование соединителей несколькими процессами возможно и без использования WSPDuplicateSocket, так как дескриптор соединителя доступен для всех процессов.
Когда формируется дескриптор нового соединителя IFS-провайдер должен вызвать WPUModifyIFSHandle, а не-IFS-провайдер должен вызвать WPUCreateSocketHandle (IFS - Installable File System).
Так как реально дублируются дескрипторы, а не сами соединители, все параметры соединения оказываются абсолютно идентичными.
Контроль состояния используемых совместно соединителей осуществляется посредством WSPAsyncSelect и WSPEventSelect. Вызов одного из указанных запросов с одним из дескрипторов соединителя в качестве параметра, аннулирует любую предшествующую регистрацию событий для указанного соединителя, вне зависимости от того, какой из дескрипторов использован для новой регистрации. Таким образом, нельзя для процесса A иметь FD_READ-события, а для процесса B получать FD_WRITE-события.
Процесс может вызвать WSPCloseSocket для дублирующего соединителя и старый дескриптор будет ликвидирован, в то время как сам соединитель, ему соответствующий, останется открытым вплоть до выполнения процедуры WSPCloseSocket.
Два или более дескрипторов могут соответствовать одному и тому же соединителю и использоваться независимо для операций ввода/вывода. Однако, интерфейс WinSock не осуществляет какого-либо контроля за доступом, задача координации совместного использования соединителя является объектом ответственности самих процессов.
Для простоты в дальнейшем термин “многоточечный” будет означать широковещательный или мультикастинг.
В настоящее время многоточечные приложения (напр., IP-мультикастинг, ST-II, T.120, ATM UNI, и т.д.) значительно различаются по способу подключения узла к многоточечной сессии. Для декларации различных многоточечных атрибутов протокола в WinSock 2 используется структура WSAPROTOCOL_INFO. Просматривая эти атрибуты, программист может узнать, какие соглашения должны быть реализованы.
В плоскости управления существует два типа различных сессий: rooted и non-rooted (корневые и некорневые). В случае корневого управления существует участник, называемый c_root, который отличается от всех остальных членов многоточечной сессии, которые называются c_leaf (периферийные члены группы). Участник сессии c_root должен оставаться в списке участников на протяжении всей многоточечной сессии, так как без его участия сессия будет прервана. c_root обычно инициирует многоточечную сессию путем установления связей с участниками типа c_leaf. c_root может вводить членов в группу, но c_leaf может подключиться к c_root позднее.
Для некорневой плоскости управления, все участники многоточечной сессии являются периферийными узлами и не существует какого-то выделенного узла. Каждый c_leaf должен подключиться к многоточечной сессии, которая либо существует всегда (как в случае IP-мультикастинг адреса), или создана за счет какого-то внешнего механизма. При другом подходе c_root по-прежнему существует, но принадлежит сети в целом (не является одним из участников сессии). Так как корневой узел существует, некорневая управляющая плоскость может рассматриваться как неявно корневая. Примерами такого рода неявно корневых схем являются система IP-мультикастинга многоточечные блоки управления (Multipoint Control Unit - MCU) в H.320-видеоконференциях и т.д.
В плоскости данных существует два стиля передачи информации: rooted и non-rooted (корневой и некорневой). В корневой плоскости данных существует выделенный участник, называемый d_root. Обмен данными происходит исключительно между d_root и остальными участниками многоточечной сессии, которые называются d_leaf. Трафик может быть однонаправленным или двунаправленным. Данные, посланные d_root, будут доставлены всем d_leaf, в то время как данные, отправленные d_leafs попадут только в d_root. В случае корневой плоскости данных не существует потока данных между периферийными узлами группы (d_leaf).
В некорневой плоскости данных, все участники эквивалентны и любая информация, посланная участником, будет доставлена всем членам группы (сессии). Аналогично каждый узел d_leaf может получать данные ото всех остальных узлов группы, а также от любых узлов, не участвующих в данной сессии.
В структуре WSAPROTOCOL_INFO имеется три поля атрибутов для выделения различных схем, используемых в плоскостях управления и данных:
XP1_SUPPORT_MULTIPOINT = 1 указывает на то, что этот протокол поддерживает многоточечные коммуникации, а последующие два поля имеют смысл.
XP1_MULTIPOINT_CONTROL_PLANE определяет, является ли плоскость управления корневой ( = 1) или не корневой ( = 0).
XP1_MULTIPOINT_DATA_PLANE указывает, является ли плоскость данных корневой ( = 1) или некорневой ( = 0).
В определенные моменты соединители, включенные в многоточечную сессию, могут по своему поведению отличаться от соединителей типа точка-точка. Так соединитель вида d_leaf в корневой плоскости данных может только посылать информацию участнику d_root. Это вызывает необходимость для клиента быть способным заявить об этом на стадии формирования соединителя. Делается это с помощью четырех многоточечных атрибутных флагов, которым присваивается определенное значение через параметр dwFlags в WSPSocket:
SA_FLAG_MULTIPOINT_C_ROOT служит для создания соединителя, работающего как c_root. Это разрешено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости управления.
WSA_FLAG_MULTIPOINT_C_LEAF предназначен для генерации соединителя, работающего как c_leaf. Это возможно, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.
WSA_FLAG_MULTIPOINT_D_ROOT предполагает формирование соединителя, работающего как d_root. Это позволено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости данных.
WSA_FLAG_MULTIPOINT_D_LEAF служит для создания соединителя, работающего как d_leaf. Это допускается, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.
Когда создается многоточечный соединитель, один из двух флагов плоскости управления и один из двух флагов плоскости данных должны быть заданы в параметре dwFlags WSPSocket. Таким образом, при создании многоточечного соединителя могут быть реализованы четыре возможности: c_root/d_root, c_root/d_leaf, c_leaf/d_root, или c_leaf /d_leaf.
Когда d_leaf-соединители используются в некорневой плоскости данных, обычно желательно управлять системой так, чтобы отправляемый трафик попадал назад в тот же соединитель. Команда SIO_MULTIPOINT_LOOP для WSPIoctl используется для разрешения или запрещения зацикливания многоточечного трафика.
При использовании мультикастинга обычно необходимо специфицировать способ реализации сессии. Среди параметров сессии важную роль играет число вовлеченных сетевых сегментов. Для регулирования этого числа используется команда SIO_MULTICAST_SCOPE WSPIoctl. Нулевое значение числа сетевых сегментов означает, что мультикастинг пакеты не покинут пределы ЭВМ и могут попадать только во внутренние соединители. Значение единица (число по умолчанию) указывает, что мультикастинг-пакеты не могут выйти за пределы маршрутизатора локальной сети. Большие величины позволят распространение сообщений, проходящих соответствующее число маршрутизаторов. Этот код идентичен параметру времени жизни (TTL) в IP-мультикастинге.
Многоточечный соединитель часто характеризуется его ролью в плоскости данных и управления. Следует иметь в виду, что один и тот же соединитель может иметь совершенно разную роль в разных плоскостях.
В схемах для корневой плоскости периферийные узлы добавляются в многоточечную группу одним из двух способов. В первом методе, корень использует WSPJoinLeaf для инициализации соединения с периферийным узлом и приглашает его быть участником сессии. Со стороны периферийного узла приложение должно создать c_leaf-соединитель и использовать WSPListen для установки его в режим ожидания (listen). Периферийный узел получит сообщение FD_ACCEPT, которое означает приглашение присоединиться к многоточечной сессии, и может объявить о своем желании подключиться путем вызова WSPAccept. Корневое приложения получит сообщение FD_CONNECT, когда операция подключения к группе завершена.
Во втором методе роли меняются. Корневой клиент создает соединитель c_root и переходит в режим ожидания (listen). Периферийный узел, желающий присоединиться к сессии, создает соединитель c_leaf и запускает WSPJoinLeaf, чтобы инициализировать соединение и доступ. Корневой клиент получает FD_ACCEPT, когда приходит запрос доступа, и принимает периферийный узел в группу посредством запроса WSPAccept. Периферийный узел получает FD_CONNECT, когда он принят в группу. Для случая IP-мультикастинга это эквивалентно опции соединителя IP_ADD_MEMBERSHIP. Читателей, знакомых с использованием несвязного UDP-протокола в IP-мультикастинге, может смутить семантика, ориентированная на соединение, присутствующая здесь. В частности указание на то, что используется запрос WSPJoinLeaf для соединителя UDP и ожидание сообщения FD_CONNECT могут вызвать недоразумение. Существуют уже, однако, прецеденты использования такой семантики для протоколов, не ориентированных на соединение. Разрешено и иногда полезно, например, использовать процедуру WSPConnect для UDP-соединителей. Общим результатом применения семантики, ориентированной на соединение для несвязных соединителей, является ограничение на то, как эти соединители могут использоваться. UDP-соединитель, используемый в WSPJoinLeaf, будет иметь определенные ограничения, а ожидание сообщения FD_CONNECT (которое в этом случае указывает на посылку соответствующего IGMP-сообщения) является одним из таких ограничений. Существует три случая, когда клиент может использовать WSPJoinLeaf:
При работе в качестве многоточечного сервера (root), приглашая новый периферийный узел принять участие в сессии.
При работе в качестве периферийного узла, выполняя запрос подключения к корневой многоточечной сессии.
При работе в качестве периферийного узла, запрашивая подключение к некорневой многоточечной сессии (например, IP-мультикастинг).
Как было упомянуто ранее, WSPJoinLeaf используется для присоединения периферийного узла к многоточечной сессии. WSPJoinLeaf имеет те же параметры и семантику, что и WSPConnect за исключением того, что он возвращает дескриптор соединителя (как и WSPAccept), и имеет дополнительный параметр dwFlags. Параметр dwFlags показывает, будет ли соединитель работать только в режиме чтения, только в режиме записи или в обоих режимах. Только многоточечный соединитель может использоваться в качестве входного параметра s этой процедуры. Если многоточечный соединитель находится в неблокирующем состоянии, полученный дескриптор соединителя нельзя будет использовать до тех пор, пока не будет получено FD_CONNECT. Корневое приложение в многоточечной сессии может вызвать WSPJoinLeaf один или более раз для того, чтобы добавить новые узлы к текущей многоточечной сессии.
Параметры дескриптора соединителя, присланного WSPJoinLeaf, варьируются в зависимости от того, является ли дескриптор c_root или c_leaf. Для c_root соединителя, параметр name означает имя определенного периферийного узла, который должен быть добавлен, а возвращенный дескриптор соединителя является c_leaf и соответствует вновь добавленному периферийному узлу. Некоторые многоточечные приложения могут позволять этому соединителю “постороннее” общение с корневым сервером.
При вызове WSPJoinLeaf для соединителя c_leaf, параметр name содержит адрес корневого приложения (для схемы корневого управления) или существующей многоточечной сессии (некорневая схема управления), и возвращенный дескриптор соединителя является тождественным по отношению ко входному дескриптору соединителя. В корневой схеме управления, корневой клиент должен поставить свой c_root соединитель в режим ожидания с помощью WSPListen. При запросе периферийного узла о присоединении к группе присылается стандартное сообщение FD_ACCEPT. Корневой клиент использует для подключения нового периферийного узла обычную процедуру WSPAccept. Запрос WSPAccept присылает дескриптор соединителя c_leaf, точно также как и WSPJoinLeaf.
Многоточечный корневой клиент является ответственным за прерывание сессии. Такое приложение может использовать WSPShutdown или WSPClosesocket для соединителя c_root, чтобы прислать всем членам группы соединителей c_leaf сообщение FD_CLOSE.
Рассмотрим семантическое отличие многоточечных и обычных соединителей. В плоскости управления имеется существенное семантическое отличие между соединителями c_root и обычными соединителями точка-точка:
Cоединитель c_root может использоваться в процедуре WSPJoinLeaf для подключения новых периферийных узлов;
Постановка соединителя c_root socket в режим ожидания (путем вызова WSPListen) не препятствует тому, чтобы соединитель c_root использовался оператором WSPJoinLeaf для добавления в список участников нового периферийного узла или для посылки или получения информации;
Закрытие соединителя c_root вызовет отправку всем сопряженным соединителям c_leaf сообщения FD_CLOSE.
Не существует какого-либо семантического различия между соединителем c_leaf и традиционным соединителем в плоскости управления, за исключением того, что соединитель c_leaf может использоваться процедурой WSPJoinLeaf, а использование соединителя c_leaf в WSPListen указывает на то, что должны восприниматься только запросы многоточечного соединения.
В плоскости данных семантическое отличие между соединителями d_root и традиционными соединителями заключается в следующем:
Данные, посланные на соединитель d_root, будут доставлены всем членам группы узлов, участвующих в многоточечном обмене;
Данные, полученные соединителем d_root, могут поступить от любого участника многоточечного обмена.
Соединитель d_leaf в корневой плоскости данных не имеет каких-либо семантических отличий от традиционных соединителей, однако, в некорневой плоскости данных информация, посланная на соединитель d_leaf, поступит ко всем периферийным узлам группы. Данные могут передаваться любым участником многоточечной сессии. Информация о том, находится ли соединитель d_leaf в корневой или некорневой плоскости данных, хранится в структуре соединителя WSAPROTOCOL_INFO.
Сводные данные по опциям Winsock 2 вместе с их значениями по умолчанию приведены в таблице 7.11 (см. также описания WSPGetSockOpt и WSPSetSockOpt). Сервис-провайдеры Windows должны распознавать все эти опции.
Таблица 7.11. Опции Winsock 2.
Опция |
Тип |
Назначение |
Значение по умолчанию |
| SO_ACCEPTCONN | BOOL | Соединитель в режиме WSPListen. | FALSE, если WSPListen не была выполнена |
| SO_BROADCAST | BOOL | Соединитель сконфигурирован для передачи широковещательных сообщений. | FALSE |
| SO_DEBUG | BOOL | Разрешен отладочный режим. | FALSE |
| SO_DONTLINGER | BOOL | Если истинно, опция SO_LINGER запрещена. | TRUE |
| SO_DONTROUTE | BOOL | Маршрутизация запрещена. | FALSE |
| SO_ERROR | int | Возвращает статус ошибки и осуществляет сброс. | 0 |
| SO_GROUP_ID | GROUP | Идентификатор группы, к которой принадлежит соединитель. | NULL |
|
SO_GROUP_ PRIORITY | int | Относительный приоритет для соединителей членов группы. | 0 |
| SO_KEEPALIVE | BOOL | Послано сообщение “еще жив”. | FALSE |
| SO_LINGER | struct linger | Возвращается текущее значение опции LINGER. | l_onoff = 0 |
| SO_MAX_MSG_SIZE | int | Максимальный размер сообщения для соединителей, ориентированных на обмен сообщениями. Не имеет смысла для соединителей, ориентированных на потоки данных. | Зависит от реализации |
| SO_OOBINLINE | BOOL | Приоритетная информация получена в потоке обычных данных. | FALSE |
| SO_PROTOCOL_INFO | struct WSAPROTOCOL_INFO | Описание протокола для заданного соединителя. | Зависит от протокола |
| SO_RCVBUF | int | Размер буфера для приема. | Зависит от реализации |
| SO_REUSEADDR | BOOL | Адрес, к которому подключен соединитель, может быть использован другими. | FALSE |
| SO_SNDBUF | int | Размер буфера для отправки | Зависит от реализации |
| SO_TYPE | int | Тип соединителя (т.е. SOCK_STREAM). | Как было при создании socket |
| PVD_CONFIG | char FAR * | Структурный объект, содержащий информацию о конфигурации сервис-провайдера. | Зависит от реализации |
| TCP_NODELAY | BOOL | Запрещает алгоритм Нагля. | Зависит от реализации |
/p> В таблице 7.12 приведен список ioctl-кодов команд для соединителей.
Таблица 7.12. ioctl-
коды команд для соединителей (Winsock 2)
Код операции |
Тип входа |
Тип выхода |
Значение |
| FIONBIO | unsigned long | Не использ. | Разрешает или запрещает неблокирующий режим соединителя. |
| FIONREAD | Не используется | unsigned long | Определяет объем информации, который может быть считан с соединителя автоматически. |
| SIOCATMARK | Не использ. | BOOL | Определяет, будут ли считаны все приоритетные данные. |
| SIO_ASSOCIATE_HANDLE | Зависит от API | Не использ. | Связывает соединитель с заданным дескриптором интерфейса-партнера. |
| SIO_ENABLE_CIRCULAR_QUEUEING | Не использ. | Не использ. | Разрешает организацию циклической очереди. |
| SIO_FIND_ROUTE | struct sockaddr | Не использ. | Запрашивает маршрут до указанного адреса. |
| SIO_FLUSH | Не использ. | Не использ. | Аннулирует содержимое выходной очереди. |
| SIO_GET_BROADCAST_ADDRESS | Не использ. | struct sockaddr | Возвращает протокольно-зависимый адрес, предназначенный для использования с WSPSendTo |
| SIO_GET_QOS | Не использ. | QOS | Возвращает текущую спецификацию QOS для соединителя. |
| SIO_GET_GROUP_QOS | Не использ. | QOS | Возвращает текущую спецификацию QOS для группы, к которой принадлежит соединитель. |
| SIO_MULTIPOINT_LOOKBACK | BOOL | Не использ. | Определяет, будут ли данные, посланные в ходе многоточечной сессии, получены соединителем на локальной ЭВМ. |
| SIO_MULTICAST_SCOPE | int | Не использ. | Определяет режим мультикастинг-обмена. |
| SIO_SET_QOS | QOS | Не использ. | Устанавливает новую спецификацию качества сервиса для соединителя. |
| SIO_SET_GROUP_QOS | QOS | Не использ. | Устанавливает новую спецификацию для группы, к которой принадлежит соединитель. |
| SIO_TRANSLATE_HANDLE | int | Зависит от API | Возвращает соответствующий дескриптор соединителя s, который верен для контекста интерфейса. |
Таблица 7.13.
Базовые SPI процедуры передачи данных Winsock 2
WSPAccept |
Входное соединение подтверждается и создается соединитель. Исходный соединитель возвращается в режим ожидания (listening). Эта процедура позволяет условное создание соединителей и их включение в группу. |
WSPAsyncSelect |
Выполняет WSPSelect в асинхронном режиме. |
WSPBind |
Присваивает локальное имя безымянному соединителю. |
WSPCancelBlockingCall |
Аннулирует блокирующую процедуру WinSock. |
WSPCloseSocket |
Удаляет соединитель из справочной таблицы. |
WSPConnect |
Инициализирует соединение для специфицированного соединителя. Эта процедура позволяет обмениваться данными о соединении и QOS. |
WSPDuplicateSocket |
Возвращает структуру WSAPROTOCOL_INFO, которая может быть использована для формирования нового дескриптора соединителя, используемого несколькими процессами. |
WSPEnumNetworkEvents |
Выявляет факт появления сетевых событий. |
WSPEventSelect |
Связывает сетевые события с объектами события. |
WSPGetOverlappedResult |
Сообщает состояние завершения процесса при совмещении операций ввода/вывода. |
WSPGetPeerName |
Возвращает имя партнера, подключенного к заданному соединителю. |
WSPGetSockName |
Возвращает локальный адрес, к которому подключен заданный соединитель. |
WSPGetSockOpt |
Возвращает опцию заданного соединителя. |
WSPGetQOSByName |
Сообщает параметры QOS на основе названия известной сетевой услуги. |
WSPIoctl |
Обеспечивает управление соединителем. |
WSPJoinLeaf |
Подключает периферийный узел к многоточечному обмену. |
WSPListen |
Организует процесс ожидания (Listen) на заданном соединителе. |
WSPRecv |
Получает данные от подключенного или неподключенного соединителя. Эта процедура реализует прием рассеянных данных или массивов для соединителей, работающих в режиме совмещения операций ввода/вывода, и использует flags в качестве параметра IN OUT. |
WSPRecvDisconnect |
Завершает операции приема для соединителя и возвращает информацию об отключении для соединителей, ориентированных на соединение. |
WSPRecvFrom |
Принимает данные от подключенного или неподключенного соединителя. Эта процедура позволяет работать с рассеянными данными в совмещенном режиме ввода/вывода, и использует flags в качестве параметра IN OUT. |
WSPSelect |
Выполняет синхронное мультиплексирование. |
WSPSend |
Посылает данные подключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещении операций ввода/вывода. |
WSPSendDisconnect |
Запускает процесс отключения соединителя и опционно посылает уведомление об отсоединении. |
WSPSendTo |
Посылает данные в подключенному или неподключенному соединителю. Эта процедура позволяет работать с рассеянными данными при совмещенных операциях ввода/вывода. |
WSPSetSockOpt |
Запоминает опции, соответствующие определенному соединителю. |
WSPShutdown |
Прерывает частично дуплексное соединение. |
WSPSocket |
Процедура формирования соединителя, которая использует в качестве входной структуру WSAPROTOCOL_INFO и позволяет использовать созданный соединитель для совмещенных операций. Позволяет создавать группы соединителей. |
WSPStartup |
Инициализирует сервис-провайдера WinSock. |
WPUCloseEvent |
Ликвидирует дескриптор объекта события |
WPUCloseSocketHandle |
Ликвидирует дескриптор соединителя, сформированный WinSock DLL |
WPUCreateEvent |
Формирует новый объект события |
WPUCreateSocketHandle |
Создает новый дескриптор соединителя для не-IFS провайдеров |
WPUGetProviderPath |
Присылает путь к DLL для специфицированного провайдера |
WPUModifyIFSHandle |
Присылает модифицированный дескриптор IFS из WinSock DLL |
WPUPostMessage |
Выполняет стандартную процедуру PostMessage так, чтобы обеспечить обратную совместимость |
WPUQueryBlockingCallback |
Присылает указатель на вход в цикл псевдоблокировки |
WPUQuerySocketHandleContext |
Присылает значение контекста соединителя (только для провайдеров, не поддерживающих IFS) |
WPUQueueApc |
Ставит пользователя в очередь APC для указанной сессии |
WPUSetEvent |
Устанавливает объект события |
WSCDeinstallProvider |
Отмена регистрации сервис-провайдера |
WSCEnumProtocols |
Получение информации о доступных транспортных протоколах |
WSCInstallProvider |
Регистрация нового сервис-провайдера |
WWW
4.5.6 WWW
Семенов Ю.А. (ГНЦ ИТЭФ)
Определения и понятия
Прежде чем передать что-то, надо это иметь. Люди общаются, используя естественные языки, ЭВМ обмениваются нуликами и единицами. Но даже в привычном для всех нас общении на родном языке иногда возникают проблемы, и тогда мы переспрашиваем партнера (это прием используют и коммуникационные системы). Когда же мы читаем, перед нами возникает последовательность символов из хорошо известного с детства алфавита. Символы эти могут существенно варьироваться по форме своего изображения, но мы их все равно без труда распознаем.
Получаемая нами информация поступает не только от общения с людьми, книгами или телевизором. Не мало крайне важных для жизни данных мы получаем о себе и окружающем мире по имеющимся у нас каналам органов чувств. Мы научились сопоставлять и перепроверять эти данные, когда это требуется. Успешное функционирование этих каналов передачи данных и средств их обработки позволяет нам прожить относительно долгую жизнь. Любые же сбои могут повлиять на нашу судьбу самым драматическим образом.
Человечество научилось усовершенствовать данные нам природой каналы информационного обмена. Сначала это были примитивные сигнальные системы типа костров на вершинах холмов (пропускная способность 0,5 бит/час). Появление письменности открыло возможность общения уже умерших людей с живыми, обеспечив процесс накопления знаний. Довольно большие объемы информации могли уже передаваться с использованием лошадей и кораблей на практически неограниченные расстояния. Но скорость такого обмена была ничтожна, доставка сообщения занимала часы, дни, а иногда и годы (никакого намека на работу современной почты я здесь не делаю).
Гигантским шагом вперед стало изобретение электрического телеграфа, а позднее радио. Сегодня же мы узнаем о землетрясении в 20000 км от нас максимум через час из очередного телевизионного сборника новостей. Люди объясняются в любви с использованием электронной почты и делают покупки, не выходя из дома.
На нас обрушилась лавина информации. Диабетик узнает о прелестях сникерса, мужчины маются, слушая информацию о потрясающих особенностях прокладок с крылышками, о несмываемой губной помаде и т.д. и т.д.
Мы стали получать слишком много совершенно ненужной информации. Миллионером станет человек, который предложит покупателям телевизор, отфильтровывающий информацию согласно требованиям зрителя. Таким образом, мы уже сталкиваемся с новыми информационными проблемами, хотя нельзя сказать, что мы решили все старые. Сплошь и рядом мы узнаем слишком поздно о своих болезнях, об угрозах стихийных бедствий или об истинных свойствах того или иного политика.
Эти же проблемы относятся и к Интернет. По электронной почте вы получаете сообщения от совершенно незнакомых людей, которые утверждают, что очень хотят вашего быстрого обогащения (хотя их цели диаметрально противоположны), или предлагающих вам какие-то товары или услуги, хотя вы их об этом не просили.
К Интернет получили доступ десятки миллионов людей. Если в издательствах редакторы, заботясь о доходах и избегая убытков, блокируют доступ графоманов к широким массам читателей, такого механизма в Интернет не существует. Таким образом, программные средства, фильтрующие поток данных на входе вашего почтового или web-сервера, здесь также весьма актуальны. Ниже даются некоторые определения понятий, используемых в разделах о протоколе http, www и информационном поиске.
Рассмотрим некоторые свойства информации, например структурированность и ценность. Структурированность – это свойство, которое позволяет принимающей стороне выделить информацию в виде некоторого сигнала, обладающего некоторыми свойствами. Ценность данных выражается через содержательность, полноту, оперативность и достоверность.
При обработке и передаче данных важную роль играют знаки и знаковые системы. Знак – это материальный объект, который служит для обозначения другого объекта и используется для передачи информации о последнем. Примерами знаков могут служить ноты, цифры, жесты азбуки глухонемых, знаки регулирования уличного движения и т.д. Одной из разновидностей знака является символ. Разновидностью знаковых систем являются языки, самым сложным из которых является естественный человеческий язык. Все проявления и применения знаков и знаковых систем изучает семиотика. Предметом семиотики является связь знаков друг с другом, с обозначаемыми ими объектами и явлениями, а также с субъектами их использующими для целей коммуникаций. Семиотика содержит в себе три раздела: семантика, синтактика и прагматика.
Семантика изучает отношения между знаком и тем, что он обозначает или замещает. Синтактика знаковых систем изучает их структуру и правила соединения знаков.Прагматика изучает законы функционирования знаковой системы, как средства коммуникации субъектов. С прагматикой связаны такие понятия как ценность и цель.
World Wide Web (всемирная сеть, WWW или 3W) представляет собой информационную систему, базирующуюся на использовании гипертекста. Разработка этой системы была начата Тимом Бернерс-Ли, которому в 1989 году пришла в голову мысль объединить гипертекст с Интернет. Идея впервые реализована в ЦЕРН (Женева). Доступ к WWW возможен только в рамках протоколов TCP/IP, но для использования 3w необязательно иметь сервер-клиент (browser) на вашей машине. С некоторыми ограничениями возможен доступ и через электронную почту (listserv@info.cern.ch). Если WWW-клиент-сервер не установлен, можно работать в режиме удаленного терминала. Весьма удобным программным интерфейсом для WWW является ms explorer, netscape и некоторые другие. Для подготовки документов в рамках HTML (Hypertext Markup Language) пригоден любой текстовый редактор (например, emacs в UNIX-машинах, ME в MS-DOS или Winword, в последних версиях которого уже допускаются гиперссылки). При подготовке гипертекстов вы можете использовать язык HTML или взять одно из множества доступных программных средств, которые позволяют преобразовать ваш документ в необходимый формат. Документы в гипертексте связываются друг с другом определенным набором слов. Пользователю не нужно знать, где находится тот или иной документ. Часто ссылки на серверы WWW начинаются с сокращения http:// (Hypertext Transfer Protocol). Гипертекст позволяет осуществлять ссылки-разъяснения на статьи, хранящиеся на удаленном сервере. Гипертекст подразумевает не только текстовые объекты (но и графические или звуковые), поэтому термин гиперсреда (hypermedia) более правилен. WWW может проводить поиск ключевых слов и в специфических документах-индексах, в этом случае выдаются указатели на искомые документы. WWW может использовать различные форматы документов и работать с разнообразными структурами информации, обеспечивая доступ к информационной вселенной. На рис. 4.5.6.1 показан рост числа WEB-серверов, базирующихся на разных программных продуктах (www.netcraft.com). В 2000 году скорость регистрации web-серверов достигла 1 в секунду.
Рис. 4.5.6.1. Рост числа web-серверов в период 1995-99 годов
На февраль 1999 года число www-серверов равнялось 4.301.512.
Что же такое гипертекст?
Прежде всего, следует отметить, что гипертекст – это текст, состоящий из ascii-символов. Для обеспечения верстки и организации перекрестных ссылок в гипертексте используются слова-метки. Основу гипертекста составляют HTML-элементы. Такой элемент включает в себя имя, атрибуты, текст или гипертекст. HTML-элемент записывается в документ в виде (более подробное описание смотри в статье о html):
<имя_метки> текст </имя_метки>
<имя_метки> имя_атрибута=аргумент текст </имя_метки>
html-документ состоит из одного элемента: <html>
.... </html>, который состоит из html-элементов: <head>
... </head> и <body> ... </body>, последние в свою очередь могут содержать различные списки, внутренние и внешние метки и т.д.. Элементы <html>, <head> и <body> для совместимости с более старыми текстами сделаны пока необязательными. В html имеется 6 уровней заголовков (<h1>, .... <h6>), из них первый - главный. В версии HTML+ (и более поздних версиях) предусмотрены операторы позиционирования текста, например, <p align="center">. head-элементы могут содержать в себе:
<isindex>
говорит о том, что данный документ допускает индексный поиск (база данных).
<title> . . . </title>
описывает заголовок документа, этот заголовок характеризует содержимое окна.
<base href="url">
сообщает имя файла, в котором хранится данный документ.
<link rev="relationship" rel="relationship" href="url">
этот элемент позволяет установить связь между документом, содержащим метку (якорь), и документом, указанным в URL (Uniform Resource Locator). Атрибут rel устанавливает связь между HTML-файлом и URL. Атрибут rev (reverse) описывает взаимоотношения между URL и HTML-файлом.
Элементы body могут содержать элементы:
Текстовые элементы:
<p> индицирует конец параграфа и начало нового.
<pre> . . . </pre>
выделяет текст, который уже был сформатирован ранее (таблицы, программы, стихи, ...).
<blockquote> . . . </blockquote>
ограничивает часть текста, который должен быть выделен кавычками.
Гиперсвязи или якоря
<a name="anchor_name"> . . . </a>
определяет заданную позицию в документе.
<a href="#anchor_name"> . . . </a>
описывает ссылку на определенное место текущего документа.
<a href="url"> . . . </a>
устанавливает связь с другим файлом или ресурсом.
<a href="url#anchor_name"> . . . </a>
устанавливает связь с заданным местом в другом документе.
<a href="url?search_word+search_word"> . . . </a>
посылает серверу эталонную строку для поиска.
Различные системы поиска могут интерпретировать эту строку по-разному. Для того чтобы читатель незнакомый с гипертекстом, получил некоторое представление о том, как он выглядит, приведу пример:
<title> Протоколы и ресурсы Интернет </title>
<h1> Это уровень первого заголовка </h1>
<h2> Уровень второго заголовка </h2>
<p> Начало параграфа ....
Вам уже ясно, что подготовка гипертекстов "вручную" изнурительная задача и вспомогательные программные средства не повредят, особенно если вы хотите, чтобы ваш текст выглядел привлекательно. Заметим, что управляющие слова-метки могут записываться как строчными, так и прописными буквами (<H1> = <H1>), но они могут восприниматься различными программами просмотра по-разному (могут и игнорироваться вовсе). HTML поддерживает нумерованные (OL), ненумерованные (UL), и описательные списки (DL). Пример нумерованного списка:
Записано в гипертексте |
Отображено на экране |
<ol>
<li> Белоруссия</li> |
1. Белоруссия |
<li> Россия</li> |
2. Россия |
<li> Украина</li> |
3. Украина |
</ol>
Примером описательного списка может служить:
<dl>
<dt> ИТЭФ
<dd> Институт Теоретической и Экспериментальной Физики, Москва, Россия.
<dt> ИФВЭ
<dd> Институт Физики Высоких Энергий, Протвино.
</dl>
На экране это будет выглядеть примерно так:
ИТЭФ
Институт Теоретической и Экспериментальной Физики, Москва.
ИФВЭ
Институт Физики Высоких Энергий, Протвино.
<dt> - метка определения, а <dd> - метка данных описания. Как <dt> так и <dd> могут содержать много параграфов, разделенных меткой <p>. Допускается вложение списков друг в друга, например <fsu.html>:
<ul>
<li> Белоруссия</li>
<li> Россия</li>
<dl>
<dt> ИТЭФ
<dd> Институт Теоретической и Экспериментальной Физики, Москва.
<dt> ИФВЭ
<dd> Институт Физики Высоких Энергий, Протвино.
</dl>
<li> Украина</li>
</ul>
Некоторые символы являются служебными для html и для их отображения на экране требуются определенные ухищрения. Например:
|
Символ |
записывается как |
< |
< |
> |
> |
& |
& |
| (неразрывный пробел) |
Символ ; (точка с запятой) является составной частью описания. Все предшествующее относилось к описанию представления текстов на экране. Теперь рассмотрим, как можно обозначить смысловые связи и ссылки друг на друга различных частей текста. Собственно именно ради этого и создавалась идеология гипертекстов. Метка, означающая наличие связи, имеет вид <a> и происходит от слова anchor (якорь). В общем виде ссылка имеет следующий формат:
<a href="url"> текст </a>
URL (universal resource locator) в простейшем случае может быть именем файла. Текст обозначает действительный текст в документе, который может быть подсвечен, выделен другим цветом или помечен цифрой. Этот текст говорит программе просмотра, что в URL можно найти связанную с данным документом информацию или изображение. При использовании программы типа MS IE (или Netscape) для вызова этой информации или изображения на экран достаточно указать мышкой на текст и нажать кнопку. Если URL указывает на объект, находящийся не в вашей сети эта процедура может занять некоторое время. Чтобы вас как-то развлечь, программа показывает вам вращающийся земной шар в верхнем правом углу экрана. Метка <A> может использоваться и для ссылки на определенный раздел документа:
<a name="refname"> текст </a>,
где refname является меткой в вашем документе. Пусть в файле fsu.html определена следующая ссылка-якорь:
<a name="итэф"> ИТЭФ </a>
тогда, находясь в пределах этого документа, можно попасть в нужную точку с помощью:
<a href=#итэф> У-10 </a> протонный синхротрон.
В другом документе может присутствовать встречная ссылка, например:
У-10 в <a href="fsu.html#итэф"> ИТЭФ>/a>
Теперь, при нажатии кнопки мышки на слове ИТЭФ, программа отобразит fsu.html и отметит позицию со словом ИТЭФ (ссылка name=итэф). Вообще говоря, вы можете ссылаться на метки-якоря в файлах, находящихся на другой машине (на другом конце земли :-) ), приводя полное наименование URL. В общем случае url указывает тип и место расположения ресурса:
сервер://host.domain[:port]/path/объект,
где в качестве сервера может стоять: FTP, Telnet, HTTP, Gopher, Wais, News. Path описывает проход к каталогу, где лежит объект. Если программа просмотра (Netscape) способна воспроизводить изображения, можно ввести ссылки на файлы, содержащие нужные для пояснения текста картинки, например:
<img src="имя_файла.gif">
Обратите внимание, что здесь используется графический стандарт gif (Graphics Interchange Format). Приемлемы также графические форматы tiff, jpeg, rgb и hdf. Читатели, желающие сформировать титульную страницу (home page) своего института, фирмы или проекта, должны изучить предмет более углубленно, обратившись, например по адресу:
http://info.cern.ch/hypertext/www/provider/overview.html.
После этого недолгого экскурса в гипертекст, который является основой многих поисковых систем, вернемся к проблематике www. Следует заметить, что публично доступные клиент-серверы существуют для сред MS-DOS, VMS, MVS, UNIX, X-windows, Macintosh, NEXT. Это математическое обеспечение доступно через анонимный FTP из депозитария info.cern.ch секции /pub/www (или www.earn.net gnrt/www.html). Графические клиент-серверы доступны для UNIX, Windows, Macintosh, X-windows, Next.
Режим удаленного терминала можно реализовать через telnet по адресу info.cern.ch (при этом не требуется иметь авторизацию на какой-либо ЭВМ ЦЕРН). Многие серверы при старте выходят на приглашение login. Обычно для входа в WWW при этом достаточно напечатать WWW. Никакого слова-пропуска не требуется. Программный пакет PCTCP (и некоторые другие) допускает настройку на эмуляцию того или иного терминала, например:
tn -x vt100 info.cern.ch, где info.cern.ch - адрес WWW-сервера, который предполагает работу с терминалом VT-100 (или его эмулятором). При работе в строчном режиме (режим меню) вам предлагается возможность выбора одного из пунктов меню. Для этого вы печатаете номер этого пункта и нажимаете клавишу <enter>. Если все меню на экране не помещается, вы можете перемещаться по нему в любом направлении. Пояснения, содержащиеся на экране, позволяют работать c системой даже новичку.
WWW-сервер в простом варианте выполняет лишь команды get имя_файла, приходящие от клиент-сервера пользователя. Остальная работа выполняется www-клиентом.
Существует достаточно много "удаленных" тематических серверов, например:
| Адрес | Тематика | Страна |
vms.huji.ac.il (128.139.4.3) |
Окружающая среда | Израиль |
info.cern.ch (128.141.201.74) |
Физика высоких энергий | Швейцария |
| fatty.law.cornell.edu (132.236.108.5) | Законодательство | США |
| ukanaix.cc.ukans.edu (129.237.1.30) | История | США |
www.njit.edu (128.235.163.2) |
США | |
| www.erg.abdn.ac.uk | Нейронные сети | Англия |
| www.mech.gla.ac.uk | Англия | |
| www.ai.univie.ac.at | Австрия | |
| kal-el.ugr.es | Испания | |
| opal.vcu.edu | Нанотехнология | США |
| galaxy.ph.tn.tudelft.nl | Распознавание образов | Нидерланды |
| info.funet.fi (128.214.6.102) | Финляндия | |
| fserv.kfki.hu (148.6.0.3) | Венгрия |
Список этот не является исчерпывающим, существуют клиент-серверы и в России. Появились и первые зеркальные www-депозитарии в России (например, xxx.itep.ru (“зеркало” сервера LANL – Лос-Аламос, США), store.in.ru (зеркальный сервер по Linux – Red Hat и RFC) и т.д.. Хотя в вышеприведенной таблице указана тематика серверов, не следует думать, что этим ограничивается содержимое депозитариев. ЦЕРН является базовой организацией для справочных запросов (здесь работают многие авторы этой системы, www-bug@info.cern.ch). Для получения нужного файла по электронной почте следует послать mail по адресу listserv@info.cern.ch с командой send. Команда send присылает документ с данным www-адресом. Но следует иметь в виду ряд ограничений. Гипертекстные документы имеют стандартную ширину в 72 символа. В конце документа обычно имеется список других адресов документов по данной или близкой тематике. Гипертекстный документ имеет связи, которые помещаются в квадратные скобки. Обратите внимание на то, что, несмотря на наличие имени listserv в начале, - это не listserv-сервер. Максимальное число строк, получаемое пользователем, при этом не превышает 1000 (хотя сегодня найдется немного желающих пользоваться такой услугой, если имеется прямой доступ в Интернет). Все запросы мониторируются. При работе с графикой выбор того или иного объекта производится мышкой. Работая со строчным сервером, следует набрать номер строки меню и нажать клавишу <enter>. В WWW доступны некоторые команды (параметры команд помещаются в угловые скобки <>, в квадратных скобках приведены сокращенные названия команд для построчного просмотра; используется полное или сокращенное имя команды.):
Команда |
Сокращение |
Назначение |
help |
[h] |
Выдает гипертекстный адрес текущего документа и список доступных команд, который является контекстно зависимым. |
manual |
[m] |
Отображает пояснительные тексты, если таковые имеются. |
quit |
Уход из www. |
|
up |
[u] |
Перемещает текущую страницу документа вверх [предшествующий экран]. |
down |
Перемещает текущую страницу документа вниз [следующий экран]. |
|
top |
[t] |
Устанавливает указатель в начало документа. |
bottom |
[bo] |
Устанавливает указатель в конец документа. |
back |
[b] |
Возвращает просмотр к предшествующему документу. |
home |
[ho] |
Возврат к первому документу. |
next |
[n] |
Осуществляет переход к просмотру следующего документа. |
previous |
[p] |
Осуществляет переход к просмотру предшествующего документа. |
list |
[l] |
Выдает пронумерованный список связей текущего документа, для отслеживания связей следует отпечатать соответствующий номер. |
recall |
[r] <number> |
Если число опущено, выдает пронумерованный список документов, которые вы просмотрели. Для просмотра определенного документа выполните команду с соответствующим номером. |
find |
[f] <ключевое слово> |
Поиск ключевых слов в индексе. Список находок отображается вместе со ссылками возможных дополнений. Ключевые слова отделяются пробелами. find можно и не печатать, если ключевое слово не совпадает ни с одной из команд www. Команда find выполнима не всегда. |
go |
[g] docaddress |
Просмотр документа с данным гипертекстным адресом. |
Команда доступна только из unix. Печатает текущий документ. По умолчанию команда печати имеет имя lpr, но ее имя может быть определено переменной www_print_command. |
Стандартная форма обращения к www имеет вид:
www <option> <docaddress <ключевое слово>>,
где docaddress - гипертекстный адрес документа, который вы хотите просмотреть; а ключевое слово - объект поиска в индексе, предоставляемом docaddress. По умолчанию на экран вызывается первый документ. В нижней части экрана отображается строка выполнимых команд. Команды могут набираться как строчными, так и заглавными буквами. Имеются следующие возможности (опции):
-n |
Неинтерактивный режим. Документ форматируется и отображается на экране. Страницы разделяются символами form feed (FF) |
-listrefs |
Добавляется список адресов всех ссылок вплоть до конца. Только не интерактивный режим |
-pn |
Устанавливает длину страницы равной n строк. По умолчанию длина страницы равна 24 строкам. Команда без числа делает страницу бесконечной |
-wn |
Устанавливает ширину страницы равной n колонкам. По умолчанию ширина равна 78, 79 или 80 |
-na |
Прячет ссылки в тексте, удобно при распечатке |
-version |
Отображает версию используемой программы |
Для перехода к следующей странице достаточно нажать клавишу <enter>. Ниже приведен пример меню World Wide Web (в настоящее время данный вид доступа представляет скорее исторический интерес):
the world-wide web virtual library: subject catalogue
the www virtual library
this is a distributed subject catalogue. see also arrangement by service type [1], and other subject catalogues of network information [2].
mail to maintainers of the specified subject or www-request@info.cern.ch to add pointers to this list, or if you would like to contribute to administration of a subject area.
see also how to put your data on the web [3]
aeronautics mailing list archive index [4]. see also nasa larc [5]
agriculture see agricultural info [6], almanac mail servers [7]
the agricultural genome [8] (national agricultural library, part of the u.s. department of agriculture)
archaeology [9] separate list
astronomy and astrophysics [10] separate list.
1-64, back, <return> for more, quit, or help:
Цифры в квадратных скобках представляют собой пункты меню. Для выбора одного из них достаточно напечатать его номер (после двоеточия) и нажать клавишу <enter>. Поиск возможен только в случае, когда в меню в нижней части экрана присутствует слово find. Рассмотренная выше версия является устаревшей, но она дает представление о том как работает WEB-сервер.
URL (uniform resource locator) идентифицирует ресурс Internet. В общем виде URL имеет вид:
access://host/path
где access = {FTP, Gopher, Telnet, ...}; host = имя ЭВМ-сервера; path = имя файла, имя каталога, или другая информация о ресурсе.
Например, url для анонимного FTP:
ftp.rpi.edu/pub/communications/internet-cmc.txt
означает:
Если вы не имеете WWW-клиент-сервера типа NetScape (где можно задать HTTP ресурс, который вы хотите получить), HTTP-ресурс может стать доступным для вас через электронную почту. Пошлите через e-mail запрос по адресу listserv@info.cern.ch с текстом в теле сообщения (вариант сегодня достаточно архаичный):
www URL
Например, URL для:
CNIDR Web Page: cnidr.org welcome.html
имеет форму:
http://cnidr.org/welcome.html
Пошлите сообщение:
$ mail listserv@info.cern.ch
www http://cnidr.org/welcome.html
и вы получите welcome.html страницу по электронной почте. Вы можете получить доступ к HTTP-документам с помощью telnet. Команда:
telnet info.cern.ch
вызовет базовую страницу WWW в ЦЕРН. Для того чтобы достичь нужного URL, введите команду:
go http://cnidr.org/welcome.html
В ЦЕРН WWW-команду возглавляет Tim Berners-Lee. Обнаруженные ошибки или предложения шлите по адресу www-bug@info.cern.ch. Почтовый подписной лист: www-talk@info.cern.ch. Для подписки пошлите запрос по адресу:
www-talk-request@info.cern.ch. В ЦЕРН работа WWW успешно дополняется другими информационными системами, например, библиотечной системой ALICE. Группа новостей в USENET: comp.infosystem.www.
Особенности гипертекста с его межуровневыми связями приводят к циклам при просмотре меню (возврат осуществляется по тому же маршруту, по какому вы пришли в данную точку). Это снижает эффективность поиска. Отчасти эти недостатки устранены в графическом интерфейсе NetScape. Графические интерфейсы требуют большой пропускной способности от информационных каналов (желательно > 64 Кб/с). Именно NetScape и MS Explorer стали наиболее популярными интерфейсами поисковых информационных систем и источником наибольших загрузок в телекоммуникационных каналах. Этот интерфейс наиболее естественно позволяет работать и с графическими объектами. Публично доступны версии NetScape для Windows, Unix и т.д. Если у вас уже работает WWW-сервер, нет необходимости заводить серверы GOPHER, Archie или WAIS - их услуги обычно доступны через WWW. Сейчас существует несколько разновидностей программ-надстроек типа NetScape, например MS Explorer, LYNX и некоторые другие.
Сегодня трудно найти какую- либо фирму, организацию или общественную группу, не представленную в Интернет своей Web-страницей. Эта технология широко используется в сфере рекламы и даже продажи товаров. Следствием этого стала актуальность проблем безопасности для Web-серверов. Большинство этих проблем происходят от несовершенства программ. Несмотря на общеизвестный совет не использовать программы версии 1.0, ошибки и “дыры” встречаются и в более поздних версиях (например, в Apache V.1.1.1 или Netscape Navigator 2.0, MS Internet Explorer 3.0 и т.д.). Хотя функция Web-сервера принципиально проста: найти запрошенный URL и послать его заказчику, реально практически все существующие сервера “обросли” конфигурационными опциями, интерфейсами для различных баз данных, снабжены адаптерами для разных версий HTTP и HTML, скриптами и модулями API. В результате исполняемый модуль WWW-сервера в несколько раз больше, чем для FTP-сервера, что оставляет достаточно пространства для ошибок и возможностей для реализации хакерских замыслов.
4.5.6.1 Программное обеспечение WEB
Существует достаточно широкий список программного обеспечения для формирования WEB-сервера. Структура и конфигурация этих серверов варьируется в широких пределах, но есть у них и немало общего. Рассмотрим основные каталоги, которые возникают при установке WEB-сервера.
Каталог конфигурации. Здесь содержатся файлы, которые определяют рабочие характеристики сервера. Этот каталог жизненно важен, и необходимо максимально возможно ограничить круг лиц, которым разрешено изменять здесь что-либо.
Инструментальный каталог администратора. Этот каталог содержит утилиты, которыми пользуется администратор сервера. Здесь могут располагаться программы управления доступом, генерации криптографических ключей и формирования поисковых индексов.
Каталог файла регистрации операций (LOG-файла). Здесь фиксируются все процедуры доступа к серверу, а также все происходящие сбои и ошибки.
Каталог CGI. В этом каталоге располагаются CGI-скрипты, которые используются для формирования документов с динамически изменяющимся содержимым, для организации доступа к базам данных и выполнения интерактивных задач. Здесь же могут находиться средства, которые позволяют администратору-программисту добавлять свои собственные функции сервера, расширяя его возможности.
Каталог документов (корневой каталог документов). Этот каталог составляет основу иерархического дерева каталогов документов сервера. Каталог может включать субкаталоги типа html, java, icons и т.д.
Помимо перечисленных может присутствовать каталог security, где лежат параметры доступа (имена и пароли) авторизованных клиентов сервера.
Современные WEB-серверы трудно себе представить без CGI-скриптов (Common Gateway Interface). Эти скрипты позволяют существенно расширить возможности сервера, обеспечить доступ к базам данных, работать с документами, содержимое которых изменяется динамически, организовать игры в реальном масштабе времени, обрабатывать запросы клиентов, посылать сообщения по электронной почте и многое другое. CGI-скрипты обеспечивают интерфейс между WEB-сервером и серверами GOPHER или FTP. Привлекательность CGI-скриптов и легкость их написания, к сожалению, дополняется тем, что совсем не просто написать их безошибочно.
CGI-скрипты (ISO 9636) представляют собой небольшие программы, которые являются независимыми от основной программы сервера. Когда удаленный пользователь запрашивает URL, который указывает на CGI-скрипт, сервер исполняет скрипт, передавая информацию о состоянии сессии. CGI-скрипт обрабатывает эти данные и выдает документ, который, вообще говоря, может быть и не только HTML-страницей. Среди информации, которую передает сервер CGI-скрипту, обычно присутствует строка запроса, содержащая данные, которые поступили от удаленного пользователя. Форма строки запроса произвольна. Она может содержать ключевые слова для поиска или SQL-предложение для обращения к серверу базы данных. Строка запроса может быть передана CGI-скрипту двумя способами. В первом случае она прикрепляется к URL. Например:
http://www.altavista.com/cgi-bin/query?pg=q&what=web&fmt=.&q=question
Все, что следует после знака вопроса, представляет собой строку запроса. В этой версии строка запроса должна следовать требованиям записи URL, т.е. пробелы должны заменяться символом + (ключевым словом в приведенном запросе является question). CGI-скрипт извлекает строку запроса с учетом переменной конфигурации (environment). Альтернативой этому является посылка строки запроса CGI методом HTTP POST. Этот метод обычно используется при заполнении пользователем форм и отправке их удаленному серверу. В этом случае WEB-сервер направляет строку запроса непосредственно на стандартный вход скрипта. Желательно пользоваться хорошо проверенными скриптами, а при написании новых следить за тем, чтобы они ни при каких обстоятельствах не допускали исполнения команд на машине сервера и не производили несанкционированной модификации файлов.
Пользователи WEB сервера, которые имеют доступ к документам и файлам поддержки обычно делятся на четыре категории: хозяин, автор, разработчик и администратор. Каждая их этих категорий имеет разные права доступа, показанные в таблице 4.5.6.1.
Таблица 4.5.6.1. Возможности различных категорий пользователей WEB-сервера
Пользователь |
Тип файла |
||||
Конфигурационный |
Инструментальный |
LOG-файл |
CGI |
Документы |
|
Хозяин |
RW |
R |
R |
RW |
RW |
Разработчик |
- |
- |
- |
RW |
RW |
Автор |
- |
- |
- |
R |
RW |
Клиент |
- |
- |
- |
R |
R |
R – разрешено чтение. W – разрешена запись и уничтожение.
Хозяином в данном случае считается администратор узла, где размещен WEB-сервер. Автор занимается подготовкой документов и рисунков. Разработчик имеет сходные функции с автором, но в его обязанности входит также разработка и модификация CGI-скриптов и модулей сервера. Клиент (посетитель) может запускать скрипты и читать любые документы. Приведенная иерархия возможностей для пользователей гарантирует устойчивую работу и безопасность WEB-сервера.
WWW Site Search
This search will allow you to search the contents of all the publicly available WWW documents at this site.
Match:
All Any Boolean
Format:
Long Short
Sort by:
Score Time Title Reverse Score Reverse Time Reverse Title
Search:
500 представляет собой протокол OSI
4.5.8.3 X500
Семенов Ю.А. (ГНЦ ИТЭФ)
X. 500 представляет собой протокол OSI для распределенных каталогов (индексов-оглавлений), разработанный CCITT. X.500 - протокол для работы с каталогами. X.500 предлагает распределенный каталог пользователей сети Интернет. X.500 поддерживает систему просмотра, а также добавления, модификации и удаления объектов в базе данных о людях (почтовый адрес, номер телефона, электронный адрес и пр.). Основным полем при поиске является фамилия, название организации, отдела, страны. Треугольные скобки служат для выделения имени параметра, а вертикальная черта - для указания значения параметра.
Каждая секция каталога содержит часть глобальной базы данных и является доступной через сервер (именуемый Directory System Agent - DSA). Каждая база данных поддерживается локально. Для пользователя же доступна вся база данных. Хотя информация, доступная через X.500, относится к людям и организациям, данная база пригодна для хранения и другой информации, например, о ресурсах сети, приложениях или оборудовании. Каждый вход в базу (объект хранения, запись) в X.500 описывает один объект (человека, конкретный ресурс сети, или организацию) и носит название Distinguished Name (неповторимый идентификатор). Это имя включает в себя следующие поля: фамилия, имя, организация, e-mail для людей. Информация в каталоге X.500 (Directory Information Base - DIB) организована иерархически и носит название информационное дерево каталога (Directory Information Tree - DIT). На верхнем уровне - корневая запись (the World), затем следует уровень страны, уровень организации и, наконец, человека (ресурса и т.д.).
X.500 доступна через локальный сервер, интерактивно через telnet или через электронную почту (или X.25). Возможен доступ и с помощью WWW или GOPHER.
Таблица 4.5.8.3.1
| Адрес сервера при доступе через Telnet (login) | Адрес X.25 (login) |
Страна |
| jethro.ucc.su.oz.au (fred) | Австралия | |
| elem4.vub.ac.be (dua) | 222100611 | Бельгия |
| x500.denet.dk (de) | Дания | |
| login.dkuug.dk (ds) | Дания | |
| nic.funet.fi (dua) | Финляндия | |
| 20800603053201 (login: dua, password: ucom.x) 26245050230303 |
Франция Франция Германия |
|
| x500.ieunet.ie (de) | 272432590024 | Ирландия |
| dir.ulcc.ac.uk (dua) | UK | |
| ashe.cs.tcd.ie (de) | Ирландия | |
| jolly.nis.garr.it (de or fred) | 22225010083212 | Италия |
| zoek.nic.surfnet.nl (zoek) | Нидерланды | |
| elc1.mat.torun.edu.pl (de или dish) | Польша | |
| chico.rediris.es (directorio) | 2142160234013 |
Испания |
| hypatia.umdc.umu.se (de) | 240374810306 | Швеция |
| nic.switch.ch (dua) | 22847971014540 | Швейцария |
| paradise.ulcc.ac.uk (dua) | 23421920014853 | Англия |
Локальный клиент-серверы (Directory User Agent - DUA) имеются в общедоступном и коммерческом вариантах. Для получения более полного списка DUA, их описаний и места расположения рекомендуется обратиться к RFC 1292 / FYI 11 - "A Catalog of Available X.500 Implementations".
Существует три варианта интерфейсов для доступа к X.500 в интерактивном режиме:
строчные (de, dish, fred);
управляемые через меню (sd, ранее известные как widget)
базирующиеся на X-Windows (Xdi, Xlookup (или xlu), pod)
Сервер de (directory enquiries) рекомендуется в силу своей простоты для начинающих пользователей. Выход из de по команде q. Приведем перечень команд X.500.
?<тема> |
Выдает справочную информацию по данной теме (help). |
^C |
(Ctrl-C) команда прерывания (например, поиска). |
* |
Выдает все записи для выбранного поля. Этот же символ представляет собой подстановку для строк по умолчанию. В том качестве * может появиться где угодно, например, smit* и *smit*. |
- |
Заменяет значение по умолчанию на пустую строку. |
После выдачи команды de пользователь должен заполнить четыре поля запроса (поиск не зависит от строчных или заглавных букв):
| Фамилия | Символ * может использоваться где угодно. При пробеле в этом поле поиск будет проводиться по полям подразделение (отрасль) или организация. |
| Наименование подразделения | Название или сокращенное имя подразделения в организации, где работает искомое лицо. Напечатав *, вы выберете все подразделения. Это поле может быть опущено для мелких организаций. |
| Название организации | Название или сокращение для организации, где работает искомое лицо. Напечатав *, вы выберете все организации. |
| Название страны | Напечатав *, вы выберете все страны. В качестве названия страны можно напечатать ее код из двух букв (см. приложение). |
Чтобы осуществить поиск с использованием электронной почты, следует послать запрос по адресу directory@uninett.no со словом find в поле Subject. В тексте сообщения размещается запрос (один на один e-mail) в форме:
find <фамилия> <:название организации <;название страны>> | <;название страны>
Если название организации и страны опущены, то берутся значения по умолчанию, которые извлекаются из вашего электронного адреса. Результат поиска будет прислан по электронной почте. Для получения файла help напечатайте help вместо find. Хотя использование e-mail кажется архаичным, в некоторых случаях не слишком экстренных оно оправдано. Вы посылаете запрос и не ждете отклика в интерактивном режиме.
Примеры использования X.500.
Введем команду: telnet nic.switch.ch и система свяжется с сервером:
Trying 130.59.1.40 ... (IP-адрес сервера)
Connected to nic.switch.ch.
Escape character is '^]'.
login: dua (здесь необходим ввод пароля)
*** Welcome to the Swiss X.500 Directory Service ***
*** Access to this service is exclusively allowed for ***
*** - Swiss universities, schools & organizations with a ***
*** SWITCH service contract ***
*** - foreign education & research organizations ***
Я опускаю процедуру выбора вида сервиса (позиция 1, как и в случае FRED).
SWITCHdirectory User Interfaces
[ 1 ] |
de (simple interface to find persons) |
[ 2 ] |
fred (simple white pages interface ('whois') |
[ 3 ] |
sd (menu oriented, only read functionality) |
[ 4 ] |
Dish (command line, full X.500 functionality) |
[ 5 ] |
Xdi (X window interface) |
[ 6 ] |
Xlu (X window interface) |
[ 7 ] |
XT-DUA (Commercial X window interface) |
[ 0 ] |
Leave this Menu (back to previous Menu) |
Снова вводим 1 (WHOIS-сервер) и получаем на экране:
invoking interface "de", please wait....
Welcome to the SWITCHdirectory Service
Connecting to the Directory - wait just a moment please...
You can use this directory service to look up telephone numbers and electronic mail addresses of people and organizations participating in the Pilot Directory Service.
The interface offers several MODES of usage. Type ?modes for an explanation about the modes. You can change the mode by typing one of the following option letters at the prompt for a PERSON's name.
s |
Simple queries - the original style of this interface |
p |
Powerful, multiple organization searches |
y |
Yellow pages queries (uses power searching) |
u |
Input queries in user-friendly name format |
m |
Menu to select modes or access help facilities |
At any prompt:
? |
for HELP with the current question you are being asked |
?? |
for HELP on HELP |
q |
to quit the Directory Service |
Control-C |
to abandon current query or entry of current query |
Simple query mode selected
Поищем "любые организации, известные в России", введя * в ответ на вопрос организации. Получаем:
Department name, <CR> to search, * to list, ? for help
:- *
Organisation name, <CR> to search, * to list orgs, ? for help
:- *
Country name, <CR> to search, * to list countries, ? for help
:- Russia (далее следует результат поиска по данному запросу)
Found the following entries. Please select one from the list by typing the number corresponding to the entry you want.
Russian Federation
1 J.S.C. Mineralnye Udobreniya
2 Moscow State University
3 Radom-Vostok
Organization name, <CR> to search, * to list orgs, ? for help
Не много, но все же..... (пример относится к 1994 году)
Печатаем 2 и получаем:
Russian Federation
Moscow State University
In the meantime, displaying organization details.
For information on people or departments, try again a little later.
Russian Federation
Moscow State University
postal address MSU
Moscow State University
University Park
Leninsky Gori
Simple query mode selected
Person's name, q to quit, * to list people, ? for help
|
:- q |
(прерываем сессию) |
Для получения дополнительной информации рекомендуется прочесть RFC-1292 (доступные реализации X.500), RFC-1308 (Введение в службу каталогов, использующую протокол X.500) и RFC-1309 (технический обзор по протоколу X.500). Рекомендации по использованию X.500 можно получить, послав команду GET ITU-5233 по адресу itudoc@itu.ch. (объем документа весьма велик!). Их других источников можно упомянуть:
FTP nic.merit.edu documents/fyi/fyi_13.txt (fyi_11.txt, fyi_14.txt).
telnet rs.internic.net.
gopher judgmentday.rs.itd.umich.edu :7777/;
WWW www.earn.net gnrt/x500.html;
http1.brunel.ac.uk :8080/wlu.html.
Автор признателен читателю, который прочел
8 Заключение
Семенов Ю.А. (ГНЦ ИТЭФ)
Автор признателен читателю, который прочел эти тексты до конца. Надеюсь, что это было не самое скучное и бесполезное занятие. Я являюсь свидетелем и участником развития Интернет в России с самого его начала и это внушает самые оптимистические надежды. В стране, где главным жизненным увлечением заметной части населения является воровство (во всяком случае для той ее части, которая имеет возможность и определенные способности), появление дорогостоящей общенациональной сети при полном отсутствии поддержки со стороны правительства (по крайней мере на начальном этапе) можно считать чудом двадцатого века. Причины этого явления еще предстоит понять и объяснить.
Существующая система Internet неидеальна, в ней не мало недостатков больших и малых. Наиболее серьезные трудности связаны с проблемой маршрутизации, не существует механизма выравнивания загрузки каналов в рамках внешних протоколов, механизмы управления не всегда удобны и безопасны, диагностика не совершенна. Система адресации Internet архаична и уже готов новый стандарт (расширение разрядности адресов до 128), многие сервисные услуги неудобны, например, не производится предупреждения об отключении связи при пассивности пользователя, telnet не имеет возможностей непосредственного копирования удаленных файлов, поисковые системы не всегда позволяют найти то, что нужно, если эта информация имеется и т.д. и пр. Но именно это должно привлечь новых молодых людей (возможно и из России), которые усовершенствуют систему. Ничто не идеально в этом мире, ведь совершенство означает прекращение развития и, следовательно, неизбежную гибель. Internet жив, возможно его идеи поменяют жизнь людей не меньше, чем это сделало радио или телевидение. Ведь именно Интернету мы обязаны появлением электронных журналов, всемирных дискуссионных клубов по интересам, глобальных баз данных, IP-телефонии, видеоконференций и прочих удивительных вещей, именно электронная почта помогла распространять правдивую информацию в незабвенные августовские дни 1991 года. Таким образом, телекоммуникационные сети могут стать гарантом демократии, можно блокировать телевидение и прессу, но чтобы остановить электронную почту, нужно выключить телефонную сеть по всей стране.
Попробую сделать некоторые конкретные прогнозы в этой области на будущее. Меня на это подталкивает стоящая у меня дома на полке книга "Космическая эра. Прогнозы на 2001 год" (Москва, "Мир", 1970), которая является переводом книги "Space Ege in Fiscal Year 2001", 1966. В этой книге дан прогноз развития науки и технологии до 2001-го года. Прогнозы этой книги в области космоса оказались чересчур оптимистичными (обитаемые станции на Луне, полеты человека к Марсу, коммерция в космосе и т.д.). Удивительно, что во время написания этой книги люди уже разрабатывали и испытывали технологии, которые легли в основу Интернет. Привожу цитату из этой книги:
"Устройства графической и буквенно-цифровой индикации будут использоваться не только как средство взаимодействия человека с машиной, но, по-видимому, с помощью таких быстродействующих устройств можно будет также осуществлять и связь между людьми".
За более чем 34 года сделан совершенно точный прогноз относительно цифровых телекоммуникаций. Полагаю, прогресс в этой области даже превзошел то, что себе представляли авторы этой книги. Я не решаюсь сделать столь далекие предсказания (это написано в 1998 году и я не намерен изменять что-либо в будущем).
К 2002 году появятся первые гибриды ЭВМ и телевизора, а к 2005 эти приборы станут массовыми.
В 2010 году в России во многих городах будут созданы общегородские сети кабельного цифрового телевидения с доступом к Интернет из любого дома, будут заложены основы общенациональной сети. Традиционная подписка на газеты и журналы будет заменена подпиской на отдельные статьи по вашему выбору (зачем оплачивать то, что вам не интересно, печатать и перевозить никому ненужную бумагу, да и сохранение лесов неплохой аргумент для этого) с возможностью чтения на экране телевизора и распечаткой при необходимости на принтере.
К 2010 году будут созданы электронные книги - переносные устройства для чтения текстов, записанных на CD, с возможностью звукового, а со временем и полномасштабного мультимедийного воспроизведения. Будет возможен и сетевой доступ к библиотекам.
К 2020 году будет создана всемирная информационная сеть, базирующаяся на широкополосных оптоволоконных каналах (телевидение, новости в аудио и видео форматах, полный информационный сервис). Россия здесь задержится на 5-10 лет из-за нынешнего провала в сфере образования.
К 2010 телефонные магнитные карты будут снабжены индивидуальными характеристиками голоса клиента, которые будут передаваться принимающей стороне при вызове. Процессор в телефонном аппарате будет преобразовывать голос в символьную последовательность (в текст). Это позволит передавать по каналу только текст, индивидуальность голосу будет придаваться на принимающей стороне при синтезе, что сократит на порядок требования к полосе канала.
Время покажет, был ли я пессимистом или оптимистом. В том, что все это будет, я уверен, могу ошибаться только в сроках. Предпосылками для этого должны стать снижение цен на отоволоконные кабели, принтеры и терминальное оборудование, разработки дешевых специализированных интегральных схем, часть из которых уже имеется, другие разрабатываются сегодня; аппаратные устройства сжатия информации и много другое. Создание широкой информационной сети с доступом в каждый дом породит немало новых проблем. Это прежде всего обеспечение защиты частной информации, предотвращение вторжения в личную жизнь. Огромную работу здесь предстоит выполнить программистам. Это и разработка более эффективных алгоритмов сжатия данных, шифрования/дешифрования информации, новых протоколов передачи, удобных пользовательских интерфейсов, более совершенных распределенных баз данных и поисковых систем. Буду счастлив, если среди людей, кто внесет свой вклад в это общее дело, окажутся и читатели этой книги. В следующем веке сети предоставят много новых рабочих мест для граждан планеты Земля. Желаю гражданам всемирного государства Интернет новых успехов и приятных приключений.
