Алгоритм авто выкладки
Если число колонок не специфицировано элементами col и colgroup, тогда агент пользователя должен использовать алгоритм автоматической выкладки. Он использует два прохода по данным таблицы и линейно масштабирует размеры таблицы.
При первом проходе запрещается разрыв строк и агент пользователя отслеживает минимальные и максимальные ширины для всех ячеек. Максимальная ширина задается самой длинной строкой. Так как разрыв строк запрещен, параграфы рассматриваются, как длинные строки, если не введены переносы строк с помощью элементов BR. Минимальная ширина задается наиболее широким текстовым элементом (словом, изображением, и т.д.) с учетом абзацев маркеров и пр. Другими словами необходимо определить минимальную ширину ячейки, которая необходима в пределах окна для того, чтобы ячейка не переполнилась. Допуская перенос слов, мы минимизируем необходимость горизонтального скролинга или обрубания содержимого ячейки.
Этот процесс применим к любым вложенным таблицам. Минимальные и максимальные ширины ячеек для вложенных таблиц используются для определения минимальной и максимальной ширины этих таблиц, и, следовательно, таблиц их прародителей. Алгоритм является линейным и не зависит от глубины вложения.
Минимальная и максимальная ширины ячейки используются для определения минимальной и максимальной ширины колонки. Эти значения в свою очередь служат для нахождения минимальной и максимальной ширины таблицы. Следует учитывать, что ячейки могут содержать вложенные таблицы, но это не усложняет программу сколько-нибудь значительно. Следующим шагом является определение ширин колонок в соответствии с доступным пространством (напр., зазором между левым и правым полями).
Внешние ограничители таблицы и внутренние разделительные линии должны учитываться при определении ширин колонок. Имеется три варианта:
Минимальная ширина таблицы равна или шире наличного пространства. В этом случае следует приписать минимальную ширину и разрешить агенту пользователя горизонтальный скролинг.
Максимальная ширина таблицы укладывается в имеющееся пространство.
В этом случае следует установить ширины колонок по максимуму.
Максимальная ширина таблицы больше наличного пространства, а минимальная - меньше.
Если ширина таблицы задана атрибутом width, агент пользователя пытается установить соответствующим образом ширины колонок.
Если с помощью элемента col указаны относительные длины колонок, алгоритм может быть модифицирован так, что ширина колонок может превысить минимально объявленное значение для того, чтобы удовлетворить требования относительных ограничений. Элементы col должны рассматриваться только как рекомендации и ширины колонок не должны делаться меньше их минимальной ширины. Аналогично, колонки не должны делаться настолько широкими, что таблица не поместится в отведенное ей окно. Если элемент col специфицирует относительную ширину нуль, ширина колонки должна быть выбрана равной минимальной ширине.
Если несколько ячеек в различных рядах одной и той же колонки используют выравнивание, тогда по умолчанию все такие ячейки должны быть выстроены в линию, вне зависимости от того, какой символ был использован для выравнивания.
Выбор имен атрибутов. Предпочтительно выбрать значения для атрибута frame, согласующееся с атрибутом rules и параметрами выравнивания. Например: none, top, bottom, topbot, left, right, leftright, all. К сожалению, sgml требует нумеровать значения атрибутов, чтобы обеспечить их уникальность для каждого элемента, вне зависимости от имени атрибута. Это сразу создает проблемы для "none", "left", "right" и "all". Значения для атрибута frame были выбраны для исключения конфликтов с атрибутами rules, align, и valign.
Аналитическое моделирование
Определение характеристик сети до того, как она будет введена в эксплуатацию, имеет первостепенное значение. Это позволяет отрегулировать характеристики локальной сети на стадии проектирования. Решение этой проблемы возможно путем аналитического или статистического моделирования.
Аналитическая модель сети представляет собой совокупность математических соотношений, связывающих между собой входные и выходные характеристики сети. При выводе таких соотношений приходится пренебрегать какими-то малосущественными деталями или обстоятельствами.
Телекоммуникационная сеть при некотором упрощении может быть представлена в виде совокупности процессоров (узлов), соединенных каналами связи. Сообщение, пришедшее в узел, ждет некоторое время до того, как оно будет обработано. При этом может образоваться очередь таких сообщений, ожидающих обработки. Время передачи или полное время задержки сообщения d равно:
D = Tp + S + W,
где Tp, S и W, соответственно, время распространения, время обслуживания и время ожидания. Одной из задач аналитического моделирование является определение среднего значения D. При больших загрузках основной вклад дает ожидание обслуживания W. Для описания очередей в дальнейшем будет использована нотация Д. Дж. Кенделла: A/B/C/K/m/z,
где А - процесс прибытия: В - процесс обслуживания; С - число серверов (узлов); К - максимальный размер очереди (по умолчанию -
D - постоянная вероятность;
M - марковское экспоненциальное распределение;
G - обобщенный закон распределения;
Ek - распределение Эрланга порядка k;
Hk - гиперэкспоненциальное распределение порядка k;
Наиболее распространенными схемами работы буферов являются FIFO (First-In-First-Out), LIFO (Last-In-First-Out) и FIRO (First-In-Random-Out). Например, запись M/M/2 означает очередь, для которой времена прихода и обслуживания имеют экспоненциальное распределение, имеется два сервера, длина очереди и число клиентов могут быть сколь угодно большими, а буфер работает по схеме FIFO.
Среднее значение длины очереди Q при заданной средней входной частоте сообщений l и среднем времени ожидания W определяется на основе теоремы Литла (1961):
Для варианта очереди M/G/1 входной процесс характеризуется распределением Пуассона со скоростью поступления сообщений l. Вероятность поступления k сообщений на вход за время t равно:
Пусть N - число клиентов в системе, Q - число клиентов в очереди и пусть вероятность того, что входящий клиент обнаружит j других клиентов, равна:
Пj = P[n=j], j=0,1,2,…
Тогда среднее время ожидания w:
s - среднеквадратичное отклонение для распределения времени обслуживания.
Для варианта очереди M/G/1 H(t) = P[xЈ t] = 1 - e-mt (H - функция распределения времени обслуживания). Откуда следует s2 = t2.
Для варианта очереди m/d/1 время обслуживания постоянно, а среднее время ожидания составляет:
Аналитическая модель для сетей Ethernet (CSMA-CD) разработана Лэмом (S.S.Lam: “A Carrier Sense Multiple Access Protocol for Local Networks,” Computer Networks, vol. 4, n. 1, pp. 21-32, January 1980). Здесь предполагается, что сеть состоит из бесконечного числа станций, соединенных каналами с доменным доступом. То есть станция может начать передачу только в начале какого-то временного домена. Распределение сообщений подчиняется закону Пуассона с постоянной скоростью следования l. Среднее значение времени ожидания для таких сетей составляет:
где е - основание натурального логарифма, t - задержка распространения сигнала в сети.
Рассмотрим вариант сети Ethernet на основе концентратора-переключателя с числом каналов N. При этом будет предполагаться, что сообщения на входе всех узлов имеют пуассоновское распределение со средней интенсивностью li, распределение сообщений по длине произвольно.
Сообщения отправляются в том же порядке, в котором они прибыли. Трафик в сети предполагается симметричным. Очередь имеет модель M/G/1. Среднее время ожидания в этом случае равно:
где
Среднее время распространения сообщения в сети равно
4.5.17.2 Симуляционное моделирование
Симуляционное (статистическое) моделирование служит для анализа системы с целью выявления критических элементов сети. Этот тип моделирование используется также для предсказания будущих характеристик системы. Такое моделирование может осуществляться с использованием специализированных языков симулирования и требует априорного знания относительно статистических свойств системы в целом и составляющих ее элементов. Процесс моделирования включат в себя формирование модели, отладку моделирующей программы и проверку корректности выбранной модели. Последний этап обычно включает в себя сравнение расчетных результатов с экспериментальными данными, полученными для реальной сети.
При статистическом моделировании необходимо задать ряд временных характеристик, например:
Системное время | Интервал от момента генерации сообщения до получения его адресатом, включая ожидание в очереди |
| Время ожидания | Промежуток от приема сообщения сетевым интерфейсом до обработки его процессором |
| Время распространения | Задержка передачи сообщения от одного сетевого интерфейса до другого |
| Время передачи | Задержка пересылки сообщения от одного процессора до другого |
Полный список таких временных характеристик включает в себя значительно больше величин.
В процессе моделирования рассчитываются следующие параметры:
| Статистика очередей |
| Средняя длина очереди |
| Пиковая длина очереди |
| Среднеквадратичное отклонение длины очереди от среднего значения |
| Статистика времени ожидания |
| Среднее время ожидания |
| Максимальное время ожидания |
| Среднеквадратичное отклонение времени ожидания |
| Статистика системного времени |
| Среднее системное время |
| Максимальное системное время |
| Среднеквадратичное отклонение системного времени |
| Полное число сообщений в статистике системного времени |
| Пиковое значение числа системных сообщений |
| Среднеквадратичное отклонение числа системных сообщений |
| Статистика потерь сообщений |
| Полное число потерянных сообщений |
| Частота потери сообщений |
| Доля потерь из-за переполнения очереди |
| Доля потерь из-за таймаутов |
Разумеется, реальный перечень вычисляемых параметров может быть существенно шире и определяется конкретными целями расчетов. Рассмотрим частную задачу определения среднего числа связей между процессорами (узлами). Предполагается, что полное число узлов равно N, а схема соединения узлов соответствует изображенной на рис. 4.5.7.1.
Рис. 4.5.7.1.
Среднее расстояние от произвольного узла до всех остальных узлов равно D(N+1)/3, где D - расстояние между соседними узлами (предполагается константой).
Возможны разные подходы к моделированию. Классический подход заключается в воспроизведении событий в сети как можно точнее и поэтапное моделирование последствий этих событий. В реальной жизни события могут происходить одновременно в различных точках сети. По этой причине для моделирования идеально подошел бы многопроцессорный компьютер, где можно воспроизводить любое число процессов одновременно. В любом случае необходимо выбрать некоторый постоянный временной интервал и считать, что события произошли одновременно, если расстояние между ними меньше этого интервала. Для сетей типа ethernet таким временным интервалом может быть бит-тайм (для 10-мегагбитного ethernet это 100нс). Понятно, что это уже отступление от реальности (ведь задержки в сетевом кабеле не кратны этому времени), но не слишком значительное. Надо сказать, что такого рода предположений при моделировании приходится делать много. По этой причине крайне важно сравнивать результаты моделирования с данными, полученными для реальной сети. Если отличия лежат в пределах 10-20%, можно считать, что сделанные предположения не увели программу слишком далеко от жизни и ею можно пользоваться для расчетов. Рассмотренный выше подход пригоден для моделирования сетевого коллапса, так как скорость расчетов здесь зависит от числа узлов и почти не зависит от сетевой загрузки.
Другим подходом может стать метод, где для каждого логического сегмента (зоны столкновений) сначала моделируется очередь событий. При этом в каждой рабочей станции моделируется последовательность пакетов, ожидающих отправки.
Эта очередь может время от времени модифицироваться, например, при получении ЭВМ пакета извне и необходимости послать на него отклик. После того как такая очередь для каждого сетевого объекта (сюда помимо ЭВМ входят мосты, переключатели и маршрутизаторы) построена, запускается программа отправки пакетов. При этом выбирается самый первый по времени пакет (ожидающий дольше других) и проверяются для него условия начала передачи (отсутствие несущей на входе сетевого интерфейса в данный момент и в течение 9,6 мксек до рассматриваемого момента - 96 тайм-битов). Если условия отправки выполнены, он “посылается” в сеть. Вычисляются моменты достижения им всех узлов данного логического сегмента, проверяются условия его столкновения с другими пакетами. Следует заметить, в этом подходе снимаются ограничения “дискретности” временной шкалы, использованной в предыдущем “классическом” подходе. Этот подход позволяет заметно ускорить расчеты при большом числе узлов, но малой загрузке сети. Проблемы реализации данной концепции моделирования связаны с обслуживанием довольно сложного списка, описывающего очередь пакетов, ожидающих отправки. В структуру этого списка включается и описание ситуации в сети на данный временной период. Дополнительные трудности сопряжены с поведением мостов, переключателей и маршрутизаторов, так как они могут вставлять в очередь дополнительные элементы, требующие немедленного обслуживания. Аналогичные вставки в очередь будут вызывать полученные станцией пакеты ICMP или TCP, требующие откликов. Причем такое вставление в очередь асинхронно по отношению к процедуре “отправки” пакетов. Очередь для всей локальной сети может быть единой, тогда пакеты разных логических сегментов должны быть помечены определенными флагами. При переходе из сегмента в сегмент флаг будет меняться. Возможно и построение независимых очередей для каждого из логических сетевых сегментов.
Данный метод был использован студентом ТСС МФТИ Алексеем Овчаровым в его магистрской диссертации (2000 год) для определения свойств фрагмента сети в условиях, близких к предельным (загрузка на уровне 70-100%).
Такие режимы трудно реализовать на практике без серьезного ущерба клиентам сети. Результаты расчета представлены на рис. 4.5.7.2.
Рис. 4.5.7.2. Зависимость вероятности потери пакета в процентах от загрузки фрагмента сети
Целью моделирования является определение зависимости пропускной способности сети и вероятности потери пакета от загрузки, числа узлов в сети, длины пакета и размера области столкновений.
Исходные данные о структуре и параметрах сети берутся из базы данных. Ряд параметров сети задаются конфигурационным файлом (профайлом). Сюда могут записываться емкость буфера интерфейса и драйвера, время задержки обработки запроса (хотя в общем случае эта величина может также иметь распределение) и т.д.. К таким параметрам относятся также: MTU, MSS, TTL, window, некоторые значения таймаутов и т.д.
Сеть разбивается на логические сегменты (зоны столкновений), в каждой из которых работает независимая синхронизация процессов (хотя эти процессы и влияют друг на друга через мосты, переключатели и маршрутизаторы).
Полное моделирование сети с учетом рабочих приложений предполагает использование следующих распределений:
Распределение по проценту времени использования каждого из узлов для того или иного вида приложений.
Распределение узлов сети по их активности.
Распределение по используемым протоколам
Распределение по длинам пакетов.
Последние два пункта существенным образом коррелированы с первым, так как используемые протоколы зависят от приложения, а активность узла может определяться, например длиной пересылаемого файла. По этой причине при полномасштабном моделировании сначала определяется, что собирается делать рабочая станция или сервер, (с учетом распределения по приложениям определяется характер задачи: FTP, MS explorer и т.д.). После этого разыгрываются параметры задания (длина файла, удаленность объекта и пр.), а уже на основе этого формируется фрагмент очереди пакетов.
Задача первого этапа: проверка пропускной способности при вариации загрузки и длин пакетов, подсчет числа столкновений, проверка влияния размера буфера сетевого интерфейса на пропускную способность (влияние размера буфера переключателей по пути до адресата).
Исходные данные для первого этапа:
частота посылки пакетов для каждого из узлов (в начале равная для всех) [d - интервал между пакетами]
длина пакета, посылаемого каждым узлом, (в начале равна для всех: минимальная [512 бит] и максимальная [12000 бит])
временное распределение моментов посылки пакетов (в начале равномерное)
Структура описания каждого из узлов включает в себя (формируется с учетом будущего расширения):
Номер узла (идентификатор)
Код типа узла (байт: рабочая станция, мост, переключатель, маршрутизатор, повторитель)
mac-адрес (для повторителя =0)
ip-адрес (для повторителя, обычного MAC-моста и переключателя =0)
Байт статуса (узел ведет передачу; до узла дошел чужой пакет,….)
d (среднее расстояние между концом предыдущего и началом очередного пакета в бит-тактах)
Дисперсия ширины пакетов
Дисперсия значения d (зазор между последовательными пакетами).
Код используемого протокола (IPv4 или IPv6; TCP, UDP, ICMP и т.д.).
Полная длина сообщения в байтах
Время обработки пакета (задержка посылки отклика в бит-тактах)
Длина очередного пакета
Байт типа адресации (unicast, broadcast, multicast)
Ширина окна (число отправляемых пакетов без подтверждения)
Объем входного буфера (число пакетов; может измеряться и в байтах, но тогда нужны специальные указатели)
Объем выходного буфера (число пакетов)
Байт режима работы (для мостов и переключателей: cut-through; store-and-forward и т.д.; для рабочей станции определяется типом используемого протокола и фазой его реализации)
Формат описания топологии сети (список)
Элемент списка:
Идентификатор узла (номер)
Код типа узла
Список узлов соседей (номер_соседа:задержка_до_него)
Процесс посылки пакета включает в себя (в соответствии с требованиями документа IEEE 802.3):
Проверку возможности начала (отсутствует чужая активность, ipg=9,6 мксек)
Последовательную передачу битов (каждый бит-такт)
Контроль состояния столкновений (на протяжении времени, соответствующего диаметру столкновений сегмента сети)
Обработка случаев столкновения (посылка jam)
При столкновении вычисление номера бит-такта попытки возобновления передачи
Попытка начала передачи предполагает проверку:
Осуществлялась ли передача на предыдущем бит-такте?
Контроль числа свободных от передачи бит-тактов (<96 ?)
Процесс приема предполагает:
Контроль окончания приема (бит-такт без данных в канале). Окончание приема может означать переход в режим анализа полученных данных.
Контроль наличия столкновения
Необходимо предусмотреть возможность (в некоторых режимах) контроля адресов (mac и ip) и содержимого пакета и т.д. (включая изменение режима работы узла, например, переход от чтения к передаче). Данный пункт абсолютно необходим для мостов и переключателей.
Центральный менеджер осуществляет:
Регистрацию начала передачи любым из узлов (номер узла и номер бит-такта)
Расчет положения начала пакета к началу очередного бит-такта для всех возможных путей распространения.
Запись в байты статуса узлов
Вариант 1 (равномерное распределение по времени)
Для каждого узла устанавливается определенная средняя частота посылки пакетов. Время посылки предполагается случайным. Средняя частота может быть задана равной для всех узлов. Так как минимальный размер пакета равен 64 байт (51.2 мксек=512 бит-тактов), максимальная частота посылки пакетов составляет ~19.5 кГц.
Минимальный средний период посылки пакетов определяется в бит-тактах и должен быть больше 512 бит-тактов. Понятно, что пока узел осуществляет передачу, он не может пытаться передать новый пакет (многозадачные, многопользовательские системы с несколькими сетевыми интерфейсами пока рассматривать не будем). По этой причине частота посылки пакетов однозначно определяется паузой между концом предыдущего пакета и началом нового (d). Среднее значение периода посылки пакетов равно Тпакета+96(бит-тактов)+d (значение d величина статистическая). Для каждого узла задается значение d (сначала равное для всех узлов). Если предположить равномерное распределение вероятности (передача пакета может начаться в любой бит-такт с равной вероятностью).
При определении того, пытаться ли начинать передачу в данный бит-такт будет проверка условия:
rndm<1/d (выполнение условия предполагает попытку начала передачи).
Если вероятность прихода n пакетов на время t распределена по закону Пуассона:
Результатами моделирования могут являться (фиксируются отдельно для каждого набора входных параметров):
| 1. | Вероятность потери пакета для логического сегмента и каждой из рабочих станций. |
| 2. | Пропускная способность серверов для каждого из логических сегментов (путь сервер -> логический сегмент) |
| 3. | Вероятность столкновения для каждого логического сегмента и каждой рабочей станции. |
| 4. | Распределение потоков по логическим сегментам (и рабочим станциям) независимо для каждого направления (вход и выход). |
| 5. | Распределение потоков для всех входов/выходов переключателей мостов и маршрутизаторов. |
| 6. | Доля вспомогательного трафика (ICMP, SNMP, отклики TCP, широковещательные запросы и т.д.) по отношению к информационному потоку для различных узлов сети (серверов, маршрутизаторов) |
| 7. | Уровень широковещательного трафика для каждого из логических сегментов |
Анализ работоспособности и стохастические потоки и длины путей
Предыдущие четыре главы касались мер связности. В контексте коммуникационных сетей базовым предположением для этих мер является то, что до тех пор, пока между двумя узлами имеется соединение, они беспрепятственно могут обмениваться данными. Во многих практических постановках задач это совсем не так. В частности, такие параметры как задержка, длина пути, полоса пропускания и прочее может иметь жизненную важность: сеть не просто должна быть связанной, она должна обеспечивать определенный уровень функциональности. Эта точка зрения ведет к разработке мер работоспособности. Чтобы изучать такие меры, нужна дополнительная информация, такая как длины, пропускные способности каналов, сопряженные с компонентами сети. Кроме того, возможно, что должна быть представлена информация, характеризующая загрузку сети, например, набор требований к трафику между определенными узлами сети. Вообще, объявление ценности такой информации изменяет природу проблемы надежности от вероятностной характеристики состояний типа “исправен/сломан” к оценке, включающей в себя множественные состояния системы и ее компонент. Во многих случаях это просто приводит к более комплексному варианту проблемы двух состояний, но это также включает задачи определения усредненного поведения и/или к введению “непрерывных” состояний и системных переменных, которые требуют существенно других методик решения. Мы обращаемся с этим более общим типом проблемы надежности, как с проблемой многих состояний и намерены ввести меры работоспособности, а также некоторые другие меры (метрики).
Общий формат для проблем сетей со многими состояниями рассматривается в данной статье следующим образом:
У нас есть сеть G=(V,E) с набором случайных переменных {Xe: eОE}, сопряженных со связями (ребрами) этой сети. Значение, присваиваемое случайной переменной ребра, представляет собой параметр, такой как длина пути, пропускная способность или задержка. В большей части данного раздела мы будем предполагать, что каждая случайная переменная связи может принимать q дискретных значений.
Во многих ситуациях случай, когда q=2 (система с двумя состояниями) представляет вполне реалистическую модель. Здесь является обычным называть состояния “плохим” и “хорошим”. В случае “хорошего” состояния связь работает со специфицированной пропускной способностью, длиной и т.д., а в случае “плохого” состояния - канал не работает, имеет нулевую пропускную способность, бесконечную длину и пр. (Случайные величины могут также быть приписаны вершинам графа сети, чтобы охарактеризовать требования в пропускной способности или задержке в узле сети. Мы не касаемся здесь этих моделей, за исключением упоминания того, что они часто моделируются как проблемы со стохастическими параметрами связей). Соответствие вектора
В контексте анализа работоспособности мы интерпретируем
Мы начнем главу с описания метода наиболее вероятных состояний, простого универсального метода вычисления верхней и нижней границ практически любых мер надежности.Эта методика часто используется для анализа работоспособности. В остальных подразделах дается более детальный анализ работы в трех сферах: кратчайшие пути, максимальные потоки и сети PERT. Мы рассматриваем эти проблемы как простейшие примеры в рамках трех важных классов задачи надежности систем с большим числом состояний. Наша точка зрения заключается в иллюстрации того, как всесторонняя работа с метриками связности может быть приспособлена к многопараметрическому контексту. Мы также ощущаем, что эта работа может служить основой для анализа более сложных многопараметрических метрик.
Архитектуры переключателей и компьютеров, устойчивые к сбоям
Компьютерная система называется устойчивой к сбоям, если при отказе одного из ее компонентов, она продолжает функционировать. В 1970-х годах такие компьютеры использовались в качестве переключателей в опорных телекоммуникационных сетях. И сегодня они широко используются во многих приложениях. Позже были разработаны параллельные вычислительные архитектуры. С целью повышения производительности параллельные ЭВМ собирались из множества однотипных элементов. Однако параллельные архитектуры имеют также и повышенные характеристики надежности. Обычно такие отказоустойчивые и параллельные компьютерные системы при анализе надежности моделировались как сети. Поскольку большая часть исследований по оценке сетевой надежности велась для сетей передачи данных, основной упор делался на алгоритмы анализа топологии сетей. Стимулом работ по сетевой надежности послужили компьютерные архитектуры, в основе работы которых лежат сильно структурированные сети, сопряженные с определенными архитектурами ЭВМ. Обычно используются меры, базирующиеся на связанности сети. Однако особенно в случае параллельных ЭВМ с большим количеством процессоров должны рассматриваться параметры надежности, которые учитывают соображения пропускной способности.
Атрибут Callback-Id
Этот атрибут содержит имя места вызова, которое должно быть интерпретировано сервером NAS. Атрибут может использоваться пакетами Access-Accept. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 20, а поле длина і 3.
Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут Callback-Number
Этот атрибут представляет собой телефонный номер, используемый для обратного дозвона. Атрибут может использоваться в пакетах Access-Accept, а также в Access-Request в качестве подсказки серверу о том, что желателен обратный дозвон, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 19, а поле длина і 3.
Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут Called-Station-Id
Этот атрибут позволяет NAS посылать в пакетах Access-Request телефонный номер, который вызывает пользователь. При этом используется техника DNIS (Dialed Number Identification) или ей подобная. Заметим, что это может быть не тот телефонный номер, через который пришел вызов. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 30, поле длина і 3.
Поле строка содержит один или более октетов, содержащих телефонный номер, через который пользователь дозвонился до системы. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут Calling-Station-Id
Этот атрибут позволяет NAS послать в пакете Access-Request телефонный номер, с которого пришел вызов, используя АОН (ANI - Automatic Number Identification) или другую технику. Атрибут используется только в пакетах Access-Request. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 31, поле длина і 3.
Поле строка содержит один или более октетов, где записан номер телефона, с которого позвонил пользователь. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Рекомендуется использование печатных ASCII-символов.
Атрибут CHAP-Challenge
Этот атрибут содержит сообщение CHAP Challenge, посланное сервером NAS в рамках диалога с пользователем CHAP PPP (Challenge-Handshake Authentication Protocol). Атрибут используется только в пакетах Access-Request. Если значение вызова CHAP содержит 16 октетов, оно может быть помещено в поле аутентификатора запроса, применение данного атрибута тогда уже не нужно. Формат записи атрибута показан на рис. .3. Поле тип = 60, а поле длина і 7. Поле строка содержит сообщение CHAP Challenge.
Атрибут CHAP-пароль
Этот атрибут характеризует значение отклика, полученного через протокол PPP CHAP (Challenge-Handshake Authentication Protocol) от пользователя в ответ на вызов. Атрибут используется только в пакетах Access-Request. Значение CHAP-вызова хранится в атрибуте CHAP-Challenge (60), если таковой имеется, в противном случае - в поле аутентификатор запроса. Формат атрибута CHAP-Password показан на рис. .4.
Рис. .4. Формат атрибута CHAP-Password
Поле CHAP ID имеет один октет и содержит идентификатор CHAP из CHAP-отклика пользователя. Поле строка имеет 16 октетов и содержит CHAP-отклик пользователя.
Атрибут Class
Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Accept, он должен быть переслан в неизменном виде клиентом серверу, куда планируется доступ, в пакете Accounting-Request. Клиент не должен интерпретировать этот атрибут. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 25, а поле длина і 3. Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут Filter-Id
Этот атрибут указывает на имя списка фильтра для данного пользователя. Нуль или более идентификаторов фильтра может быть переслано в пакете Access-Accept. Идентификация списка фильтра с помощью имени позволяет использовать фильтр с различными NAS вне зависимости от особенностей использования списка фильтра. Формат записи атрибута соответствует рис. .3. поле тип = 11, поле длина і 3.
Поле строка здесь имеет один или более октетов и его содержимое зависит от программной реализации. Содержимое должно иметь читабельный формат и не должно влиять на работу протокола. Рекомендуется, чтобы отображаемое сообщение содержало 32-126 ASCII-символов.
Атрибут Framed-AppleTalk-Link
Этот атрибут содержит сетевой номер AppleTalk, который должен быть использован для последовательного канала пользователя, являющимся маршрутизатором сети AppleTalk. Атрибут применяется только в пакетах Access-Accept. Он никогда не используется, когда пользователь не является маршрутизатором. Формат записи атрибута показан на рис. .6. Поле тип = 37, а поле длина =6.
Поле значение имеет 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что это ненумерованный последовательный канал. Значения 1-65535 обозначают, что последовательной линии между NAS и пользователем присвоен соответствующий сетевой номер AppleTalk.
Атрибут Framed-AppleTalk-Network
Этот атрибут представляет собой сетевой номер AppleTalk, который сервер NAS должен попытаться присвоить узлу AppleTalk. Атрибут используется только в пакетах Access-Accept. Атрибут никогда не используется, если пользователем является маршрутизатор. Многократное использование атрибута в пакете указывает на то, что NAS может попытаться использовать один из сетевых номеров, приведенных в атрибутах. Формат записи атрибута показан на рис. .6. Поле тип = 38, а поле длина =6.
Поле значение содержит 4 октета. Допустимый диапазон значений 0 - 65535. Специальное значение 0 указывает, что NAS должен назначить сеть для пользователя. Значения в интервале 1 - 65535 (включительно) указывает на сеть AppleTalk, адрес которой должен найти сервер NAS для пользователя.
Атрибут Framed-AppleTalk-Zone
Этот атрибут указывает на зону AppleTalk по умолчанию, которая должна использоваться для данного пользователя. Атрибут используется только в пакетах Access-Accept. Кратное использование атрибута в одном пакете не допускается. Формат записи атрибута показан на рис. .3. Поле тип = 39, а поле длина і 3. Поле строка содержит в себе имя зоны AppleTalk по умолчанию, которая должна использоваться для данного пользователя.
Атрибут Framed-Compression
Этот атрибут указывает на протокол сжатия, который следует использовать при передаче данных. Атрибут используется в пакетах Access-Accept. Атрибут используется в пакетах Access-Request в качестве подсказки серверу о том, какой вид компрессии предпочитает использовать NAS, но сервер не обязан следовать этой рекомендации.
Можно использоваться несколько атрибутов данного типа. Окончательное решение о применении того или иного метода компрессии принимает сервер NAS.
Формат атрибута аналогичен показанному на рис. 6. Поле тип = 13, а поле длина = 6. Возможные коды поля значение собраны в таблице .5.
Таблица .5. Возможные коды поля значение
| Код поля значение | Назначение |
| 0 | Никакого |
| 1 | Сжатие заголовка VJ TCP/IP [5] |
| 2 | Сжатие заголовка IPX |
Атрибут Framed-IP-Address
Этот атрибут указывает на адрес, который следует сконфигурировать для пользователя. Атрибут может использоваться пакетами Access-Accept. Он может использоваться в пакетах Access-Request в качестве подсказки NAS, указывающей на то, что сервер предпочитает данный адрес. Сервер не обязан следовать этой подсказке. Формат атрибута идентичен представлению атрибута NAS-IP-адрес (рис. .5).
Поле тип = 8, поле длина = 6.
Поле адрес содержит 4 октета. Значение 0xFFFFFFFF указывает, что NAS следует разрешить пользователю выбрать адрес. Значение 0xFFFFFFFE отмечает, что NAS следует выбрать адрес для пользователя (например, выбрать его из зарезервированного списка, имеющегося в NAS). Другие допустимые значения указывают, что NAS должен использовать этот код в качестве IP-адреса пользователя.
Атрибут Framed-IP-Netmask
Этот атрибут указывает на сетевую IP-маску, которая должна быть сконфигурирована для пользователя, когда он является маршрутизатором сети. Атрибут может использоваться в пакетах Access-Accept. Он может использоваться в пакете Access-Request в качестве подсказки NAS серверу относительно того, какую сетевую маску он предпочитает. Но сервер не обязан следовать этой подсказке. Формат записи атрибута аналогичен формату атрибута NAS-IP-адрес. Поле тип = 9, поле длина = 6. Поле адрес имеет 4 октета и определяет сетевую IP-маску.
Атрибут Framed-IPX-Network
Этот атрибут содержит сетевое число IPX, конфигурируемое для пользователя. Атрибут используется в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 23, а поле длина = 6.
Поле значение имеет 4 октета. Значение 0xFFFFFFFE указывает, что сервер NAS должен выбрать для пользователя сеть IPX (т.е. выбрать одну или более IPX-сетей из имеющегося списка). Остальные значения должны рассматриваться как IPX-сети, предназначенные для подключения.
Атрибут Framed-MTU
Этот атрибут указывает значение MTU, которое должно быть проставлено для пользователя, когда это не согласуется каким-либо другим образом (например, PPP). Атрибут используется только в пакетах Access-Accept. Формат атрибута аналогичен показанному на рис. 6. Поле тип = 12, а поле длина = 6. Поле значение имеет 4 октета и может принимать значения в интервале 64-65535.
Атрибут Framed-Protocol
Этот атрибут указывает на необходимость использования пакетного доступа. Атрибут может использоваться пакетами Access-Request и Access-Accept. Формат представления атрибута аналогичен формату атрибута NAS-порт (рис. .6). Поле тип = 7, поле длина = 6. Коды поля значение собраны в таблице .3.
Таблица .3. Коды поля значение
| Код поля значение | Назначение |
| 1 | PPP |
| 2 | SLIP |
| 3 | Протокол удаленного доступа AppleTalk (ARAP) |
| 4 | Gandalf владелец протокола SingleLink/MultiLink |
| 5 | Xylogics владелец IPX/SLIP |
Атрибут Framed-Route
Этот атрибут содержит маршрутную информацию, которая должна быть сконфигурирована сервером NAS для пользователя. Атрибут используется в пакетах Access-Accept и может присутствовать там несколько раз. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 22, а поле длина і 3.
Поле строка содержит один или более октетов, а его содержимое зависит от приложения. Текст должен быть читабельным и не должен влиять на работу протокола. Рекомендуется, чтобы сообщение содержало ASCII-символы с кодами в диапазоне 32 - 126.
Для IP-маршрутов, атрибут должен содержать префикс места назначения в десятично-точечном представлении (как IP-адрес). Далее опционно может следовать косая черта и число старших бинарных единиц, указывающее на количество разрядов префикса, которые следует использовать. Далее следует пробел, адрес шлюза, еще один пробел и один или более кодов метрики, разделенных пробелами. Например, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". Длина спецификатора может быть опущена, тогда для префикса класса А подразумевается длина в 8 бит, для класса В - 16 и для класса С - 24 бита. Например, "192.168.1.0 192.168.1.1 1". Если адрес шлюза равен "0.0.0.0", тогда в качестве IP-адреса шлюза следует использовать адрес пользователя.
Атрибут Framed-Routing
Этот атрибут указывает метод маршрутизация для пользователя, когда пользователем является маршрутизатор сети. Атрибут может использоваться в пакетах Access-Accept. Формат записи атрибута аналогичен показанному на рис. .6 (NAS-порт). Поле тип = 10, поле длина = 10. Допустимые коды и их назначения собраны в таблице .4
Таблица .4. Допустимые коды поля значение и их назначения
| Код поля значение | Назначение |
| 0 | Ничего не делать |
| 1 | Посылать маршрутные пакеты |
| 2 | Принимать маршрутные пакеты |
| 3 | Посылать и принимать |
Атрибут Idle-Timeout
Этот атрибут устанавливает максимальное число секунд (непрерывный временной отрезок), в течение которых пользователь может оставаться пассивным, прежде чем соединение с сервером будет разорвано или будет получен вызов. Этот атрибут передается сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 28, а поле длина = 6.
Поле значение содержит 4 октета и несет в себе 32-битовое целое число без знака, соответствующее максимальному времени пассивности клиента в секундах. По истечении этого времени соединение с сервером разрывается.
Атрибут Login-IP-Host
Этот атрибут указывает на систему, с которой соединяется пользователь при наличии атрибута Login-Service. Атрибут используется в пакетах Access-Accept, а также Access-Request в качестве подсказки серверу, какую из ЭВМ предпочитает NAS, но сервер не обязан следовать этой рекомендации. Формат записи атрибута аналогичен показанному на рис. .5. Поле тип = 14, а поле длина = 6.
Поле адрес имеет 4 октета. Значение 0xFFFFFFFF указывает на то, что NAS должен позволить пользователю выбор адреса. Значение 0 говорит, что NAS должен сам выбрать ЭВМ, с которой будет соединен пользователь. Любые другие значения указывают адрес, с которым сервер NAS должен соединить пользователя.
Атрибут Login-LAT-Group
Этот атрибут содержит строку, идентифицирующую групповой код LAT, который данный пользователь авторизован использовать. Атрибут может использоваться в пакетах Access-Accept, но только когда специфицирован LAT в качестве Login-Service. Он может быть использован в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. LAT поддерживает 256 различных групповых кодов, которые LAT использует как некую форму прав доступа. LAT преобразует эти групповые коды в 256 битовую карту соответствия (bitmap).
Администраторы могут приписать один или более бит группового кода сервис-провайдеру LAT. Он будет воспринимать соединения LAT, которые имеют установленные биты, соответствующие их групповым кодам. Администраторы присваивают битовую маску кодов авторизованных групп каждому пользователю. LAT получает эти маски-карты от операционной системы, и использует их в запросах к сервис-провайдерам. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 36, а поле длина = 34. Поле строка содержит 32-октетную маску-карту. Старший октет передается первым.
Атрибут Login-LAT-Node
Этот атрибут указывает на узел, с которым пользователь должен быть соединен автоматически LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда в качестве услуги подключения указан LAT. Он может быть применен в пакете Access-Request в качестве подсказки серверу, но сервер не обязан следовать этим рекомендациям. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 35, а поле длина і 3.
Поле строка имеет один или более октетов и содержит идентификатор узла LAT, с которым следует соединиться пользователю. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), числа, буквы нижнего и верхнего регистров, а также расширяющий символьный набор ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.
Атрибут Login-LAT-Port
Этот атрибут указывает порт, с которым должен быть соединен пользователь посредством LAT. Атрибут может использоваться в пакетах Access-Accept, но только когда LAT специфицирован в качестве услуг подключения. Он может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер может не следовать этой рекомендации. Формат записи атрибута показан на рис. .3. Поле тип = 63, а поле длина і 3.
Поле строка имеет один или более октетов и содержит идентификатор порта LAT, который следует использовать. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точку), _ (подчеркивание), цифры, буквы верхнего и нижнего регистра, а также расширенный набор символов ISO Latin-1. Все сравнения в LAT не зависят от регистра символов.
Атрибут Login-LAT-Service
Этот атрибут указывает на систему, с которой должен быть соединен пользователь посредством LAT (Local Area Transport). Он может использоваться в пакетах Access-Accept, но только когда в качестве услуги специфицирован LAT (локальный доступ). Атрибут может использоваться в пакетах Access-Request в качестве подсказки серверу, но сервер не обязан следовать этой рекомендации.
Администраторы используют атрибут сервиса, когда имеют дело с кластерными системами, такими как VAX или Alpha-кластер. В такой среде несколько процессоров совместно используют общие ресурсы (диски, принтеры и т.д.), и администраторы конфигурируют каждый из них для обеспечения к каждому из ресурсов. В этом случае каждая ЭВМ в кластере оповещает о предоставляемых услугах через широковещательные сообщения LAT.
Продвинутые пользователи часто знают, какие сервис-провайдеры (ЭВМ) обладают большим быстродействием и предпочитают использовать имя узла при установлении LAT-соединения. Некоторые администраторы хотели бы, чтобы определенные пользователи работали с определенными машинами, что представляет собой примитивную форму балансировки нагрузки (хотя LAT имеет собственную систему балансировки). Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 34, а поле длина і 3.
Поле строка имеет один или более октетов и содержит идентификатор LAT-сервиса. Архитектура LAT позволяет этой строке содержать $ (доллар), - (дефис), . (точка), _ (подчеркивание), числа, буквы верхнего и нижнего регистров, а также расширенный символьный набор ISO Latin-1 [6]. Все сравнения в LAT не зависят от регистра символов.
Атрибут Login-Service
Этот атрибут указывает на услугу, которая будет использоваться для соединения пользователя с ЭВМ. Атрибут применяются только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 15, а поле длина = 6. Возможные коды поля значение собраны в таблице .6.
Таблица .6. Возможные коды поля значение
| Код поля значение | Назначение |
| 0 | Telnet |
| 1 | Rlogin |
| 2 | Сброс TCP |
| 3 | PortMaster (собственник) |
| 4 | LAT |
Атрибут Login-TCP-Port
Этот атрибут указывает порт TCP, с которым следует соединить пользователя при наличии атрибута Login-Service. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 16, а поле длина = 6. Поле значение имеет четыре октета и может содержать величины в диапазоне 0 - 65535.
Атрибут NAS-идентификатор
Этот атрибут содержит строку, идентифицирующую запрос Access-Request, посланный сервером NAS. Атрибут используется только в пакетах Access-Request. В пакете Access-Request должен присутствовать атрибут NAS-IP-Address или NAS-Identifier. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 32, а поле длина і 3.
Поле строка содержит один или более октетов, и должна быть уникальной для NAS в области действия сервера RADIUS. Например, полное имя домена вполне подходит в качестве NAS-идентификатора. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут NAS-IP-Address
Этот атрибут указывает IP-адрес сервера NAS, который запрашивает аутентификацию пользователя. Атрибут применяется только в пакетах Access-Request. В пакете Access-Request должен присутствовать NAS-IP-адрес или NAS-идентификатор. Формат атрибута NAS-IP-Address представлен на рис. .5.
Рис. .5 Формат атрибута NAS-IP-Address
Поле адрес имеет протяженность 4 октета (IPv4).
Атрибут NAS-порт
Этот атрибут несет в себе номер порта NAS, который аутентифицируется пользователем. Атрибут применяется только в пакетах Access-Request. Заметим, что здесь термин порт определяет физическое соединение с NAS, а не используется в значении, принятом в протоколах TCP или UDP. NAS-порт или NAS-Port-Type (61) или оба эти атрибута должны присутствовать в пакете Access-Request, если NAS использует несколько портов. Формат атрибута NAS-порт представлен на рис. .6.
Рис. .6. Формат атрибута NAS-порт
Диапазон кодов в поле значение составляет 0 - 65535.
Атрибут NAS-Port-Type
Этот атрибут определяет тип физического порта NAS, где аутентифицируется пользователь. Атрибут может использоваться вместо или в добавление к атрибуту NAS-Port (5). Атрибут используется только в пакетах Access-Request. Атрибут NAS-Port (5) или NAS-Port-Type или оба должны применяться в пакетах Access-Request, если NAS различает порты. Формат записи атрибута показан на рис. .6. Поле тип = 61, а поле длина =6.
Поле значение имеет 4 октета. "Виртуальный" (в таблице 7) относится к соединению с NAS через некоторый транспортный протокол. Например, если пользователь осуществил удаленный доступ (telnet) в NAS, для того чтобы аутентифицировать себя как внешнего пользователя, запрос Access-Request может включать атрибут NAS-Port-Type = Virtual в качестве подсказки серверу RADIUS, что пользователь не является физическим портом.
Таблица .7. Код поля значение атрибута NAS-Port-Type
| Код поля значение | Назначение |
| 0 | Async |
| 1 | Sync |
| 2 | ISDN Sync |
| 3 | ISDN Async V.120 |
| 4 | ISDN Async V.110 |
| 5 | Виртуальный |
Атрибут Port-Limit
Этот атрибут устанавливает максимальное число портов, предлагаемых сервером NAS пользователю. Этот атрибут может быть послан сервером клиенту в пакете Access-Accept. Он предназначен для использования в среде многоканального PPP [7]. Он может также быть послан сервером NAS серверу в качестве подсказки того, что доступно большое число портов. Формат записи атрибута показан на рис. .6. Поле тип = 62, а поле длина = 6.
Поле значение имеет 4 октета и содержит 32-битовое целое число без знака, которое определяет максимальное число портов, к которым пользователь может быть подключен сервером NAS.
Атрибут Proxy-State
Этот атрибут предназначен для посылки прокси-сервером другому серверу при переадресации запроса Access-Request и должен быть возвращен в неизменном виде в сообщениях Access-Accept, Access-Reject или Access-Challenge. Этот атрибут должен быть удален прокси-сервером, до того как отклик будет переадресован серверу NAS. Использование атрибута Proxy-State зависит от реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 33, а поле длина і 3.
Поле строка содержит один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут Reply-Message
Этот атрибут содержит текст, который может быть отображен для пользователя. Если используется в пакете Access-Accept, это сообщение об успешном выполнении. При использовании с Access-Reject, это уведомление о неудаче. Это может быть элемент диалога с пользователем перед очередной попыткой послать запрос доступа (Access-Request).
Когда атрибут используется в Access-Challenge, он может содержать приглашение пользователю ввести отклик. Допускается применение нескольких атрибутов Reply-Message, в этом случае они должны отображаться в порядке из записи в пакете. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 18, а поле длина і 3.
Поле строка содержит один или более октетов. Его содержимое может зависеть от конкретной программной реализации. Содержимое должно быть читабельным и не должно влиять на работу протокола. Рекомендуется, чтобы текст состоял из печатных ASCII символов с кодами 10, 13 и 32 - 126.
Атрибут Session-Timeout
Этот атрибут устанавливает максимальное число секунд, в течение которых будет предоставляться услуга пользователю до завершения сессии или очередного вызова. Этот атрибут может быть послан сервером клиенту в сообщениях Access-Accept или Access-Challenge. Формат записи атрибута показан на рис. .6. Поле тип = 27, а поле длина = 6.
Поле значение содержит 4 октета, и несет в себе 32-битовое целое число (максимальное число секунд, в течение которых пользователь будет оставаться соединенным с сервером NAS).
Атрибут State
Этот атрибут предназначен для посылки сервером клиенту в сообщении Access-Challenge и должен быть передан немодифицированным от клиента к серверу в новом отклике Access-Request на исходный вызов, если таковой имеется.
Этот атрибут может быть послан сервером клиенту в сообщении Access-Accept, которое содержит также атрибут Termination-Action со значением RADIUS-Request. Если сервер NAS выполняет процедуру Termination-Action путем посылки сообщения Access-Request по завершении текущей сессии, атрибут должен включать в себя исходный код атрибута State из запроса Access-Request. В любом случае клиент не должен его интерпретировать. В пакете может содержаться только один атрибут State. Использование атрибута зависит от конкретной реализации. Формат записи атрибута следует схеме, показанной на рис. .3. Поле тип = 24, а поле длина і 3.
Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений.
Атрибут Termination-Action
Этот атрибут указывает, какие действия должен выполнить сервер NAS, когда процедура будет завершена. Атрибут используется только в пакетах Access-Accept. Формат записи атрибута показан на рис. .6. Поле тип = 29, а поле длина = 6. Поле значение имеет 4 октета. Ниже приведены разрешенные коды поля значения.
| 0 | Значение по умолчанию |
| 1 | RADIUS-Request |
Если поле значение соответствует RADIUS-Request, по завершении соответствующего сервиса NAS может послать новый запрос Access-Request серверу RADIUS, включив атрибут State, если он имеется.
Атрибут тип услуги (Service-Type)
Этот атрибут указывает на тип услуг, которые заказал или получит пользователь. Атрибут используется в пакетах Access-Request и Access-Accept. NAS не требует реализации всех типов услуг и должен обрабатывать атрибуты неизвестных или неподдерживаемых видов услуг, как запросы Access-Reject. Формат записи атрибута идентичен формату NAS-порт. Только поле тип=6. Коды поля значение перечислены в таблице .2..
Таблица .2. Коды поля значение
| Код поля значение | Назначение |
| 1 | Login |
| 2 | Framed |
| 3 | Callback Login |
| 4 | Callback Framed |
| 5 | Outbound |
| 6 | Administrative |
| 7 | NAS Prompt |
| 8 | Authenticate Only |
| 9 | Callback NAS Prompt |
Таково назначение кодов атрибута типа услуг при использовании в сообщениях Access-Accept. Когда они применяются в пакетах Access-Request, они должны рассматриваться как подсказки серверу RADIUS и говорят, что NAS имеет причины полагать, что пользователь предпочтет указанные услуги, но сервер не обязан следовать этим подсказкам.
| Login | Пользователь должен быть подключен к ЭВМ. |
| Framed | Для пользователя должен быть запущен пакетный протокол, такой как PPP или SLIP. |
| Callback Login |
Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего осуществлено соединение с ЭВМ. |
| Callback Framed |
Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего для пользователя запущен пакетный протокол типа PPP или SLIP. |
| Outbound |
Пользователю предоставляется доступ к выходным устройствам. |
| Administrative |
Пользователю предоставляется доступ к административному интерфейсу NAS, с которого могут выполняться привилегированные команды. |
| NAS Prompt |
Пользователю предоставляется возможность вводить непривилегированные команды NAS. |
| Authenticate Only |
Запрашивается только аутентификация, ненужно возвращать никакой авторизационной информации Access-Accept (обычно используется прокси-серверами, а не самим NAS). |
| Callback NAS Prompt |
Пользователь должен быть отсоединен, выполнен обратный дозвон, после чего ему предоставляется возможность ввода непривилегированных команд NAS. |
Атрибут Vendor-Specific
Этот атрибут служит для того, чтобы позволить производителям обеспечить поддержку их собственных атрибутов, непригодных для общего применения. Атрибут не должен влиять на работу протокола RADIUS.
Серверы, не приспособленные для интерпретации информации, специфической для производителя оборудования или программ, должны игнорировать эти атрибуты (хотя могут и оповещать об этом). Клиенты, которые не получили желательной информации, специфической для изготовителя, должны предпринять попытку работать без этих данных. При этом функциональность может быть сужена (о чем клиент может сообщить пользователю). Формат записи атрибута показан на рис. .7. Поле тип = 26, а поле длина і 7.
Рис. .7. Формат записи атрибута Vendor-Specific
Старший октет ID изготовителя равен нулю, а младшие три октета представляют собой код изготовителя, как это определено в RFC-1700 (SMI Network Management Private Enterprise Code [2]). Порядок октетов сетевой.
Поле строка имеет один или более октетов. Действительный формат информации может варьироваться от узла к узлу и отличаться для разных приложений. Строка должна кодироваться в виде последовательности тип производителя / длина / поля значений, специфические для производителя. Пример формата строки показан на рис. .8.
Рис. .8. Пример формата строки
Поле строка предназначено для записи параметров, специфических для данного производителя.
Атрибуты
Атрибуты RADIUS несут в себе специфическую аутентификационную и конфигурационную информацию для запросов и откликов. Некоторые атрибуты могут быть включены в список более одного раза. Воздействие такого использования зависит от типа атрибута.
Конец списка атрибутов определяется кодом, содержащимся в поле пакета длина. Формат записи атрибута показан на рис. .2.
Рис. .2. Формат записи атрибута
Поле тип имеет один октет. Возможные значения этого поля перечислены в документе RFC-1700 "Assigned Numbers" [3]. Значения 192-223 зарезервированы для экспериментального использования, значения 224-240 выделены для специальных реализаций, а значения 241-255 зарезервированы на будущее. Ниже в таблице 1. представлена спецификация стандартизованных значений атрибутов. Сервер и клиент RADIUS могут игнорировать атрибуты неизвестного типа.
Таблица .1. Cпецификация стандартизованных значений атрибутов
| Код | Назначение |
| 1 | Имя пользователя (User-Name) |
| 2 | Пароль пользователя (User-Password) |
| 3 | CHAP-пароль |
| 4 | NAS-IP-адрес |
| 5 | NAS-порт |
| 6 | Тип услуги (Service-Type) |
| 7 | Framed-Protocol |
| 8 | Framed-IP-адрес |
| 9 | Framed-IP-Netmask |
| 10 | Framed-Routing |
| 11 | Filter-Id |
| 12 | Framed-MTU |
| 13 | Framed-Compression |
| 14 | Login-IP-Host |
| 15 | Login-Service |
| 16 | Login-TCP-Port |
| 17 | (unassigned) |
| 18 | Сообщение-отклик (Reply-Message) |
| 19 | Callback-Number |
| 20 | Callback-Id |
| 21 | (не определено) |
| 22 | Framed-Route |
| 23 | Framed-IPX-Network |
| 24 | Состояние |
| 25 | Класс |
| 26 | Vendor-Specific |
| 27 | Таймаут сессии (Session-Timeout) |
| 28 | Idle-Timeout (таймаут пассивного состояния) |
| 29 | Termination-Action (процедура завершения) |
| 30 | Called-Station-Id |
| 31 | Calling-Station-Id |
| 32 | NAS-Идентификатор |
| 33 | Proxy-State |
| 34 | Login-LAT-Service |
| 35 | Login-LAT-Node |
| 36 | Login-LAT-Group |
| 37 | Framed-AppleTalk-Link |
| 38 | Framed-AppleTalk-Network |
| 39 | Framed-AppleTalk-Zone |
| 40-59 | (зарезервировано для акоунтинга) |
| 60 | CHAP-вызов (CHAP-Challenge) |
| 61 | NAS-Port-Type |
| 62 | Port-Limit |
| 63 | Login-LAT-Port |
Поле длина является однооктетным, оно определяет длину данного атрибута, включая субполя тип, длина и величина.
Если атрибут получен в запросе Access-Request, но с неверной длиной, следует послать сообщение Access-Reject. Если атрибут прислан в пакете Access-Accept, Access-Reject или Access-Challenge и имеет некорректную длину, пакет должен рассматриваться как Access-Reject или молча отбрасываться.
Поле значение содержит ноль или более октетов и содержит специфическую информацию атрибута. Формат и длина поля значение определяется полями тип и длина. Заметим, что строка в RADIUS не требует завершения символом ASCII NUL, так как имеется поле длины. Поле значение может иметь один из четырех форматов.
| строка | 0-253 октетов |
| адрес | 32 битовый код, старший октет передается первым. |
| целое | 32 битовый код, старший октет первый. |
| время | 32 битовый код (старший октет первый) равен числу секунд с момента 00:00:00 GMT, 1-го января, 1970. Стандартные атрибуты не используют этот тип данных, но он представлен здесь, так как может быть применен в атрибутах зависящих от производителя (Vendor-Specific). |
Базовые наблюдения
Первой целью введения полинома надежности является компактное представление информации о надежности, чтобы сравнивать топологических кандидатов. Кельманс [A.K.Kel’mans “The graph with the maximum probability of remaining connected depends on the edge-removal probability”, Graph theory newsletter, 9 (1979) 2-3; “On graph with randomly deleted edges”, Acta Math. Acad. Sci. Hung, 37 (1981), 77-78] доказал, что для заданного числа вершин и ребер, в определенных случаях не существует графа, который является наиболее надежным для всех вероятностей работоспособности ребер. Таким образом, надежность является больше чем просто параметр графа; она в действительности является функцией надежностей каналов (связей).
Будущие проекты
Данная спецификация определяет набор элементов и атрибутов, достаточно мощных, чтобы выполнить основные требования по генерации форм. Однако остается пространство для дальнейшего совершенствования. Например, следующие проблемы могут найти решение в будущем:
Диапазон типов полей формы слишком ограничен по сравнению с современными пользовательскими интерфейсами. Например, не существует возможности использования табуляции при вводе данных.
Серверы не могут корректировать поля в уже записанных формах, и вынуждены вместо этого передавать весь HTML-документ.
Другим возможным расширением может стать атрибут usemap элемента input для использования в качестве карты изображения на стороне клиента, когда "type=image". Элемент area, соответствующий позиции, где была нажата кнопка мыши, должен будет выдать информацию, передаваемую серверу. Чтобы избежать необходимости модифицировать скрипты сервера, может оказаться разумным расширить возможности area в отношении передачи значений координат x и y для использования их элементом input.
Булевы атрибуты
Разработчики должны учитывать, что многие агенты пользователя распознают не все булевы атрибуты. Например, разработчик может захотеть специфицировать:
<option selected>
вместо
<option selected="selected">
Диалог в локальных сетях и в Интернет
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Команды Talk (для SUN), Phone (для VAX/VMS) и другие служат для переговоров двух человек, работающих на одной и той же ЭВМ с удаленных терминалов в реальном масштабе времени. Хотя эти команды и не используют протоколы TCP/IP, они весьма удобны при работе, в частности при отладке новых телекоммуникационных каналов. Вызов осуществляется в соответствии с форматами: Talk bobyshev@ns.itep.ru или Phone <ID>, где <ID> - имя партнера (его ID, используемое при входе в ЭВМ), с которым вы хотите поговорить. При использовании этих процедур экран делится на две части по вертикали, верхняя часть предназначена для печати текста вызывающего, нижняя часть для его партнера.
Существует версия и Internet-Phone, которая обеспечивает голосовую двухстороннюю связь между пользователями сети. Этот вид услуг примыкает скорее к разновидностям сервиса, описанным в следующей главе. Для обеспечения работы такого канала связи достаточно ЭВМ PC-486SX с частотой 25МГц, памятью 8Мбайт и стандартной аудио-картой. Программы, поддерживающие этот вид сервиса, работают в рамках Windows, Winsock 1.1. При этом вы займете полосу канала шириной 7.7Кбит/c. При установке звуковой VC-платы c сжатием аудио-информации можно ограничить требования на полосу до уровня 6.72Кбит/c. Следует ожидать появления программ и на других платформах и в других средах. Общедоступное программное обеспечение для работы с аудио-версией Phone можно получить через анонимное FTP по адресу ftp.volcaltec.com (используйте ID-пользователя=ftp). Разговаривать можно только с одним партнером одновременно. Возможно совмещение разговора с другими процедурами Internet, что особенно привлекательно при диагностике и отладке каналов и сетевых программ. Internet-Phone контактирует с IRC (Internet Relay Chat, смотри подробнее в следующей главе), что позволяет получить необходимую справочную информацию. Используя возможности IRC, можно выбрать мышкой нужного вам партнера и начать беседовать с ним, если он конечно сидит у ЭВМ, которая оснащена необходимым аппаратным и программным обеспечением.
В рамках этого вида сервиса вы можете обсудить какой-то документ, отображенный на экране терминалов, отмечая нужные места с помощью манипуляторов мышь. Это дает возможность согласовать в реальном масштабе времени текст документа, обсудить элементы конструкции или схемы, не тратя деньги на командировку или на дорогостоящее оборудование для видеоконференций. Бесплатно поболтать с вашим приятелем в Рио-де-Жанейро - это ли не мечта многих россиян?
Если же специального оборудования в вашем распоряжении нет, можно воспользоваться текстовой версией Talk или Phone. Обращение к Talk имеет форму:
talk имя_пользователя [ ttyname ]
Если вы хотите поговорить с кем-то на вашей ЭВМ, достаточно в качестве параметра ввести имя_пользователя (login ID). Если же ваш партнер работает на другой машине, имя адресата может иметь вид: host!пользователь или host.пользователь, или host:пользователь, или пользователь@host, где host - это имя ЭВМ, на которой работает ваш партнер. Последняя форма используется чаще. При необходимости переговорить с человеком, работающем на определенном терминале, следует ввести имя этого терминала (ttyname). При получении запроса Talk выдает на экран следующее сообщение:
Message from TalkDaemon@his_machineattime...
talk: connection requested by ваше_имя@ваша_ЭВМ.
talk: respond with: talk ваше_имя@ваша_ЭВМ
Пользователь, желающий участвовать в диалоге, должен ответить:
talk ваше_имя@ваша_ЭВМ
Когда связь установлена, оба участника диалога могут печатать текст одновременно с отображением обоих текстов в верхней и нижней частях экрана. Нажатие комбинации СTRL-L переписывает заново содержание экрана. Для завершения диалога следует нажать CTRL-Y. Имя ЭВМ адресата можно найти в файле /etc/hosts, а имя терминала в файле /etc/utmp. В процессе общения с использованием терминала возникает проблема - "пальцы не поспевают за мыслью". Традиция англоязычного общения выработала некоторые общепринятые сокращения часто используемых слов и выражений, которые могут облегчить диалог:
Таблица 4.5.15.1. Общепринятые сокращения, используемые при диалоге
| Общепринятое сокращение выражения | Выражение | Перевод |
| BCNU | be seeing you | пока |
| BRB | be right back | возвращайся вовремя |
| BTW | by the way | кстати |
| BYE | goodbye | до свидания, я готов закончить диалог |
| BYE? | Goodbye? | вы готовы завершить диалог? |
| CU | see you | пока |
| CUL | see you later | увидимся |
| FYI | for your information | для вашего сведения |
| FWIW | for what it's worth | за чем это нужно |
| GA | go ahead and type | давай, продолжай |
| IMHO | in my humble opinion | по моему скромному мнению |
| IMO | in my opinion | по моему мнению |
| JAM | just a minute | минутку |
| O | over | ваша очередь говорить |
| OO | over and out | до свидания |
| OBTW | oh, by the way | а кстати |
| ROTFL | rolling on the floor laughing | кататься по полу от смеха |
| R U THERE? | are you there? | вы там? |
| SEC.. | wait a second | подождите секунду |
| WRT | with respect to | с уважением |
IRC
Семенов Ю.А. (ГНЦ ИТЭФ)
IRC - (Internet Relay Chat, RFC-1459) представляет собой систему переговоров в реальном времени. Она аналогична команде talk, которая используется на многих ЭВМ в Интернет. IRC делает все, что может talk, но позволяет также переговариваться более чем двум лицам одновременно. IRC предоставляет и много других удобных услуг.
Когда вы печатаете текст в IRC, все что вы напечатали будет немедленно передано другим пользователям, кто подключен к разговору. Причем они при желании могут вам ответить в реальном масштабе времени. Темы обсуждений в IRC варьируются в широких пределах. Обычно разговор идет по-английски, но существуют каналы для немецкого, японского, финского и других языков (русский язык здесь не является исключением, какой-же русский откажет себе в удовольствии поболтать, особенно в рабочее время). Клиенты и серверы для IRC доступны через анонимное FTP по адресу: . Некоторые узлы позволяют доступ к IRC через telnet, например, wbrt.wb.psu.edu и irc.demon.co.uk. В обоих узлах вход в систему осуществляется (login) как IRC.
В таблице 4.5.15.2 приведены основные команды IRC.
Таблица 4.5.15.2. Основные команды IRC
| Команда IRC | Описание |
| /a | Отбрасывание оставшегося выхода для текущей команды |
| /help | Отобразить список IRC-команд |
| /help команда | Выдает описание команды |
| /help intro | Отображает введение в IRC |
| /help newuser | Отображает информацию о новых пользователях |
| /join канал | Подключиться к соответствующему каналу |
| /leave канал | Покинуть соответствующий канал |
| /list | Выдать информацию о всех каналах. |
| /list канал | Отобразить информацию о конкретном канале |
| /list -min n | Отобразить каналы, которые имеют как минимум n человек |
| /list -max n | Отобразить каналы, в которых не более n человек |
| /me операция | Отобразить определенную операцию |
| /mode * +p | Делает текущий канал личным |
| /msg псевдоним текст | Посылка частного сообщения указанному человеку |
| /msg , текст | Посылка сообщения последнему корреспонденту, кто вам что-то прислал |
| /msg . текст | Посылка сообщения последнему корреспонденту |
| /nick | Отобразить ваш псевдоним |
| /nick псевдоним | Изменить ваш псевдоним |
| /query псевдонимы | Послать все ваши сообщения указанным лицам |
| /query | Прекратить посылку частных сообщений |
| /quit | Прервать работу IRC (quit). |
| /set novice off | Позволить некоторые операции, например, подключение ко многим каналам |
| /who канал | Определяет, кто подключен к определенному каналу |
| /who псевдоним | Выдает информацию о конкретном человеке |
| /who * | Определяет, кто подключен к каналу |
| /whois псевдоним | Выдает всю информацию об определенном человеке |
| /whois * | Выдает всю информацию о всех |
/p> Многие серверы системы IRC для соединения друг с другом используют древовидную схему. Некоторые серверы, взаимодействуя друг с другом, передают информацию о существовании других серверов, пользователей или других ресурсов. Фундаментальной для IRC является концепция канала. Все пользователи, когда они в системе IRC, находятся на одном канале. Сначала вы входите в нулевой канал. Вы не можете послать сообщение, пока вы не вошли в канал и не задали параметры этого канала. Число каналов не ограничено.
Когда вы находитесь в системе IRC и нуждаетесь в помощи, выдайте команду /help. При возникновении проблем можно контактировать с Кристофером Девисом (Christopher Davis, ckd@eff.org) или с Еленой Роуз (Helen Rose, hrose@eff.org). Можно запросить помощь у оператора каналов IRC, например, #twilight_zone и #eu-opers. Различные документы по IRC и архивы списков рассылки IRC доступны через анонимное FTP по адресу , cs.bu.edu irc/support/alt-irc-faq или dorm.rutgers.edu pub/Internet.documents/irc.basic.guide. Группа новостей:
alt.irc, alt.irc.recovery. Имеется возможность доступа к материалам по IRC и через WWW: ; eru.dd.chalmers.se home/f88jl/Irc; mistral.enst.fr ~pioch/IRC; alpha.acast.nova.edu IRC; cgi-bin/www2irc.
RELAY
RELAY представляет собой систему серверов в глобальной сети Bitnet/EARN, которая ретранслирует интерактивные сообщения от одного пользователя к другим, кто подписан на данный "канал" системы RELAY. Пользователь, подписанный на ближайший RELAY, виртуально подписан на всю систему RELAY. Большинство узлов RELAY отключаются в часы пик. Только некоторые из них работают 24 часа в сутки. Каждый RELAY-сервер обслуживает ограниченное число узлов, называемых сферой обслуживания. RELAY - это программа, которая позволяет нескольким людям общаться через сеть в реальном масштабе времени. Для того чтобы начать, вы должны подписаться на RELAY, для чего поместить ваш ID в текущий список пользователей. Взаимодействие с RELAY осуществляется также, как с обычным пользователем.
Команды RELAY начинаются с символа /, все что не начинается с / считается сообщением и пересылается всем текущим пользователям.
RELAY доступна по следующим адресам EARN/Bitnet. В скобках приведено условное имя RELAY-ЭВМ.
| RELAY@AUVM (Wash_DC) | RELAY@PURCCVM (Purdue) |
| RELAY@BEARN (Belgium) | RELAY@SEARN (Stockholm) |
| RELAY@ITESMVF1 (Mexico) | RELAY@TAUNIVM (Israel) |
| RELAY@CEARN (Geneva) | RELAY@TECMTYVM (Monterrey) |
| RELAY@CZHRZU1A (Zurich) | MASRELAY@UBVM (Buffalo) |
| RELAY@DEARN (Germany) | RELAY@UFRJ (RioJaneiro) |
| RELAY@DKTC11 (Copenhagen) | RELAY@UIUCVMD (Urbana_IL) |
| RELAY@FINHUTC (Finland) | RELAY@USCVM (LosAngeles) |
| RELAY@GITVM1 (Atlanta) | RELAY@UTCVM (Tennessee) |
| RELAY@GREARN (Hellas) | RELAY@UWAVM (Seattle) |
| RELAY@HEARN (Holland) | RELAY@VILLVM (Philadelph) |
| RELAY@JPNSUT00 (Tokyo) | RELAY@YALEVM (Yele) |
| RELAY@NDSUVM1 (No_Dakota) | RELAY@WATDCS (Waterloo) |
Система RELAY доступна пользователям сетей EARN/Bitnet через интерактивный обмен (SEND-команда в VMS/JNET, или PHONE в VAX/VMS). Все ЭВМ-серверы RELAY - это IBM VM/CMS системы, но вам не нужно быть пользователем VM, для того чтобы использовать RELAY. Если вы не в сети EARN/Bitnet, доступ к системе RELAY для вас закрыт. CHART доступен на любом NETSERV.
При регистрации клиенту посылаются файлы RELAY INFO и RELAY USERGUIDE, которые содержат подробное описание RELAY.
Краткое руководство по применению RELAY доступно из списка файлов документов EARN. Пошлите e-mail по адресу LISTSERV@EARNCC.BITNET. В теле сообщения напечатайте: GET RELAY MEMO.
Динамическое реформатирование
Главным соображением при выработке модели таблиц HTML является то, что разработчик не должен заботиться о вариации размера таблиц пользователем или о его выборе шрифтов. Это делает рискованным задание ширины колонки в абсолютных единицах (пикселях). Вместо этого таблицы должны быть способны динамически приспосабливать размер таблицы к размерам имеющегося окна и к выбранным шрифтам. Разработчик может сформулировать пожелания относительно ширин колонок, но агент пользователя может и не следовать этим пожеланиям. Он должен обеспечить размер ячейки, достаточный для размещения самого крупного элемента.
Dir и элементы menu
<!element (dir|menu) - - (li)+ - (%blocklevel)>
| <!attlist dir %attrs; | -- %coreattrs, %i18n, %events -- | |
| compact (compact) #implied > | ||
| <!attlist menu %attrs; | -- %coreattrs, %i18n, %events -- | |
| compact (compact) #implied > | ||
Элемент DIR предназначен для формирования многоколоночного текста каталога. Элемент Menu предназначен для работы с одноколонными текстами каталогов. Оба элемента имеют структуру, аналогичную UL. Рекомендуется использовать UL вместо DIR и Menu.
Доступность
Модель таблиц HTML включает атрибуты для пометки каждой ячейки с целью высококачественного преобразования текста в голос. Те же самые атрибуты могут использоваться для поддержки автоматического обмена с базами данных и электронными таблицами.
Фиксированные алгоритмы верстки
Для этого алгоритма предполагается, что число колонок известно. Ширины колонок по умолчанию делаются равными. Разработчики могут поменять эти установки, задав относительные или абсолютные значения колонок с помощью элементов colgroup или col. Значение ширины по умолчанию равно расстоянию от левого до правого поля, но оно может быть скорректировано с помощью атрибута width в элементе table, или определено из абсолютных ширин колонок. Для того чтобы работать со смесью абсолютных и относительных ширин, сначала нужно выделить место для колонок с заданной абсолютной шириной. После этого, оставшееся пространство делится между колонками с учетом их относительных ширин.
Сам по себе синтаксис таблицы не гарантирует взаимосогласованности значений атрибутов. Например, число элементов col и colgroup может не совпадать с числом колонок, используемых в таблице. Дополнительные проблемы возникают, когда колонки слишком узки и может произойти переполнение ячейки. Ширина таблицы, как это специфицировано элементами table или col может вызвать переполнение ячейки таблицы. Рекомендуется, чтобы агенты пользователя умели выходить из этого положения, например, путем переноса слов.
В случае, когда переполнение ячейки вызывается словом, которое не может быть поделено, агент пользователя может рассмотреть возможность изменения ширин колонок и повторного отображения таблицы. В худшем случае, можно допустить обрубание слов, если вариации ширин колонок и скроллинг оказались невозможными. В любом случае, если содержимое ячейки разделено или обрублено, об этом должно быть сообщено пользователю соответствующим способом.
Finger
Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru
Finger является простым протоколом (RFC-1288), который служит для получения информации о пользователях узлов Internet. Протокол использует TCP-порт 79. Команда Finger может дать вам данные о списке пользователей, которые работают в данный момент на интересующей вас ЭВМ, о конкретном пользователе (дата последнего сеанса входа в систему и т.д.), о списке загруженных задач, о типах интерфейсов (например, терминалов). Данный протокол обеспечивает интерфейс для удаленной информационной программы пользователя (RUIP - Remote User Information Program).
Первоначальная версия такой программы была написана Les Earnest. Окончательная версия протокола была подготовлена Earl Killian из Мессачусетского Технологического Института и Brian Harvey (SAIL).
Протокол Finger базируется на TCP. Локальная ЭВМ осуществляет TCP-соединение с удаленным узлом через указанный порт. После этого становится доступной программа RUIP и пользователь может посылать ей свои запросы. Каждый запрос представляет собой строку текста. RUIP, получив запрос, анализирует его и присылает ответ, после чего соединение закрывается.
Любые пересылаемые данные должны иметь формат ASCII, не иметь контроля по четности и каждая строка должна завершаться последовательностью CRLF (ASCII 13, за которым следует ASCII 10).
Программа RUIP должна воспринимать любые запросы Finger. Такие запросы могут иметь следующий формат:
{Q1} ::= [{W}|{W}{S}{U}]{C}
{Q2} ::= [{W}{S}][{U}]{H}{C}
где {U} ::= имя_пользователя
{H} ::= @hostname | @hostname{H}
{W} ::= /W
{S} ::= | {S}
{C} ::=
{H}, является рекурсивным, по этой причине не существует каких-либо ограничений на число лексем типа @hostname в запросе. В примере спецификации {Q2}, число лексем @hostname не может превышать двух.
Следует иметь в виду, что в случае запросов "finger user@host". Программа RUIP в действительности получит "user".
Запрос {Q2} требует переадресации запроса другой программе RUIP. Программа RUIP может либо осуществить эту процедуру, либо отказать в переадресации.
В случае выполнения запроса она должна это подтвердить:
Сообщая, что:
ЭВМ <H1> открывает соединение Finger <F1-2> с RUIP на ЭВМ <H2>.
<H1> выдает <H2> RUIP запрос <Q1-2> типа {Q2} (например, FOO@HOST1@HOST2).
При этом следует извлечь информацию о том, что:
ЭВМ <H2> является самой правой ЭВМ в запросе <Q1-2> (например, HOST2)
Запрос <Q2-3> является остатком запроса <Q1-2> после удаления правой части "@hostname" (например, FOO@HOST1)
Таким образом:
<H2> RUIP должна открыть соединение <F2-3> с <H3>, используя <Q2-3>.
<H2> RUIP должна прислать любую информацию, посланную от <F2-3> к <H1> через <F1-2> .
<H2> RUIP должна закрыть <F1-2> в нормальных обстоятельствах только когда <H3> RUIP закрывает <F2-3> .
По большей части вывод RUIP не следует каким-либо жестким регламентациям, так как он предназначен для чтения людьми, а не программами. Главное требование - информативность может ограничиваться только соображениями безопасности.
Запрос {C} требует выдачи списка всех работающих пользователей. RUIP должна либо ответить, либо активно отказаться. Если она отвечает, тогда она должна выдать, по крайней мере, полные имена пользователей. Системный администратор может включить в выдачу и другую полезную информацию, такую как:
Положение терминала
Расположение офиса
Рабочий номер телефона
Должность
Время пребывания в пассивном состоянии (число минут с момента ввода последнего символа или со времени завершения последней сессии).
Запрос {U}{C} является требованием присылки информации о статусе определенного пользователя {U}. Если вы не хотите выдавать такую информацию, тогда следует заблокировать работу Finger.
Ответ должен включать в себя полное имя пользователя. Если пользователь активно работает в сети, то присылаемые данные должны включать, по крайней мере, тот же объем информации что и при запросе {C}.
Так как это запрос информации об отдельном пользователе, администратор может добавить определенную информации об этом человеке, например:
Расположение офиса
Рабочий номер телефона
Номер домашнего телефона
Статус работы в системе ( not logged in, logout time, и т.д.)
Информационный файл пользователя
Информационный файл пользователя может содержать короткое сообщение, которое оставляет пользователь для передачи по запросу Finger. (Это иногда называется "plan" файлом). Это легко реализуется путем поиска программой в корневом каталоге (или в специально выделенном каталоге) пользователя файла с заданным именем. Системному администратору должно быть разрешено включать и выключать эту опцию.
При запросе Finger существует возможность запуска определенной программы пользователя. Если такая опция предусмотрена, системному администратору должно быть позволено запрещать эту процедуру. Данная опция, создавая определенные угрозы, практически беспредельно расширяет возможности Finger (см. примеры в конце раздела).
В командной строке допустимо имя пользователя или имя, под которым он входит в систему. Если имя неопределенно, реакция системы определяется системным администратором.
Лексема /W в запросе типа {Q1} или {Q2} в лучшем случае интерпретируется последней RUIP и означает требование выдачи максимально возможной информации о пользователе, в худшем случае она игнорируется.
Продающие автоматы должны реагировать на запрос {C} выдачей списка всех предметов, предлагаемых для продажи в данный момент Продающие автоматы должны откликаться на запросы {U}{C}, сообщая число различных продуктов или отделений для размещения продуктов.
Корректная реализация Finger крайне важна. В частности, RUIP должна защищать себя от некорректного ввода. Конкретная реализация программы должна проходить столь же тщательную проверку, как Telnet, FTP или SMTP.
Следует учитывать, что Finger раскрывает информацию о пользователях. Лица, ответственные за сетевую безопасность, должны решить разрешать или нет работу Finger, и какую информацию о пользователях следует рассылать.
Сетевой администратор должен иметь возможность разрешать и запрещать прохождение запросов {Q2}.
Если обработка запросов {Q2} RUIP заблокировано, программа должна отсылать соответствующее сообщение (например, "Finger forwarding service denied"). По умолчанию обработка запросов {Q2} должна быть запрещена.
Программа RUIP при отправке данных должна отфильтровывать все символы вне диапазона (ASCII 32 - ASCII 126), за исключением TAB (ASCII 9) и CRLF. Такая мера обезопасит получателя.
Примеры реализации запросов.
Узел: elbereth.rutgers.edu
Командная строка: <CRLF>
Login Name TTY Idle When Office
rinehart Mark J.Rinehart p0 1:11 Mon 12:15 019 Hill x3166
greenfie Stephen J.Greenfiel p1 Mon 15:46 542 Hill x3074
rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
brisco Thomas P.Brisco pe 2:09 Mon 13:37 h055 x2351
laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413
Узел: dimacs.rutgers.edu
Командная строка: pirmann<CRLF>
Login name: pirmann In real life: David Pirmann
Office: 016 Hill, x2443 Home phone: 989-8482
Directory: /dimacs/u1/pirmann Shell: /bin/tcsh
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
No unread mail
Project:
Plan:
Work Schedule, Summer 1990
Rutgers LCSR Operations, 908-932-2443
Monday 5pm - 12am
Tuesday 5pm - 12am
Wednesday 9am - 5pm
Thursday 9am - 5pm
Saturday 9am - 5pm
larf larf hoo hoo
Login name: surak In real life: Ron Surak
Office: 000 OMB Dou, x9256
Directory: /u2/surak Shell: /bin/tcsh
Last login Fri Jul 27 09:55 on ttyq3
No Plan.
Login name: etter In real life: Ron Etter
Directory: /u2/etter Shell: /bin/tcsh
Never logged in.
No Plan.
Узел: dimacs.rutgers.edu
Командная строка: hedrick@math.rutgers.edu@pilot.njin.net
[pilot.njin.net]
[math.rutgers.edu]
Login name: hedrick In real life: Charles Hedrick
Office: 484 Hill, x3088
Directory: /math/u2/hedrick Shell: /bin/tcsh
Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
No unread mail
No Plan.
Формат применения команды Finger:
finger [ опции ] имя...
По умолчанию finger отображает информацию обо всех активно работающих пользователях, включая имя-идентификатор, полное имя, имя терминала и т.д. В качестве имени может использоваться имя-идентификатор, фамилия или имя пользователя. Ниже приводится краткий перечень допустимых опций.
| -l | Запрос подробной информации |
| -s | Запрос краткой информации |
| -q | Запрос имени-идентификатора, имени терминала и времени входа в систему |
| -i | Запрос, аналогичный -q, но выдается и время пребывания терминала в пассивном состоянии |
| -w | Блокирует печать полного имени для -s |
| -h | Блокирует печать файла .project в режиме -l |
| -p | Блокирует печать файла .plan в режиме -l |
Список работающих пользователей хранится в файле /etc/utmp, полный список имен пользователей размещен в файле /etc/passwd, времена и даты входа в систему записаны в файле /var/adm/lastlog, имена и расположение терминалов можно найти в файле /etc/ttytab, для записи информации о планах и проектах используются файлы ~/.plan и ~/.project, соответственно.
Ниже приведен пример отклика на команду finger -l (запрос подробной информации, ЭВМ SUN):
| Login name: Ivanov | In real life: Andrey Bobyshev |
| Directory: /u1/SunITEP/bobyshev | Shell: /bin/csh |
On since Aug 10 10:16:35 on ttyp0 from x4u2.desy.de
1 minute 37 seconds Idle Time
Mail last read Thu Aug 10 12:06:20 1995
| No Plan. | (Никаких планов) |
| Login name: Petrov | In real life: Yuri Semenov |
Directory: /u1/SunITEP/semenov Shell: /bin/csh
On since Aug 10 12:14:19 on ttyp3 from semenov.itep.ru
33 seconds Idle Time
No unread mail
No Plan.
| Login name: Sidorov In real life: UU | Ekatirin |
Directory: /var/spool/uucppublic Shell:
/usr/local/lib/uucp/uucico
On since Aug 10 12:16:04 on ttyy01 57 minutes Idle Time
Mail last read Wed Nov 16 18:17:50 1994
No Plan.
В общем случае при обращении к finger может использоваться символьный Интернет-адрес:
Finger <имя_адресата>@Internet_адрес.
Возможности команды Finger варьируются в широких пределах в зависимости от конкретной реализации. Так команда (PCTCP): finger semenov@vxdesy.desy.de выдаст на экран:
[vxdesy.desy.de]
SEMENOV Semenov, Yuri SEMENOV not logged in (и это истинная правда)
Last login Thu 5-Jan-95 2:35PM-CET
[No plan]
Дополнительную информацию о команде finger можно получить:
| Описание протокола | ftp nic.merit.edu | documents/rfc/rfc1288.txt |
| pub/fingerinfo | ||
| Информация по электронной почте | dlangley@netcom.com | в поле subject:"#finger USER@HOST.DOMAIN" |
| Через удаленный доступ | telnet rpi.edu :79 | |
| Через WWW | http www.dlr.de cgi-greving/mfinger http sundae.triumf.ca fingerinfo.html | |
| Через finger | finger help@dir.su.oz.au |
Цифра после двоеточия - номер порта. Последняя строка говорит о некоторых необычных возможностях Finger. Опция выдачи содержимого файла пользователя и исполнения программы пользователя расширяет возможности Finger почти беспредельно. Так, выдав команду finger help@dir.su.oz.au (Австралия), получим:
[extra.ucc.su.OZ.AU]
**** This is an experimental service offered free of charge by ****
**** The University Computing Service, University of Sydney. ****
**** Please mail support@is.su.edu.au if you have any queries. ****
Finger offers these additional services (Finger предлагает некоторые дополнительные возможности):
Access to a database facility (доступ к базе данных)
Usage (использование): finger %@dir.su.edu.au
is usually an "egrep" regular expression and can be (в качестве обычно используется стандартное "egrep"-выражение, а вместо можно записать):
| Aarnet | resources available on AARNet (ресурсы AARNet) |
| Buildings | buildings and their codes at Sydney Uni (коды зданий сиднейского университета) |
| Archie | query anonymous FTP databases (анонимный поиск по FTP-депозитариям) |
| Internet | resources available on the Internet (ресурсы Internet) |
| Library | library access available via AARNet (доступ к библиотечным базам данных) |
| Newsgroups | find NetNews newsgroups (поиск новостей) |
| Phone | The Sydney Uni Phone Book (телефонная книга Сиднейского университета) |
| Postcodes | Australian Postcodes (австралийские почтовые коды) |
| Shop | prices at the UCS shop (цены в университетском магазине) |
Usage (использование):
| Finger help@dir.su.edu.au | this help (данный справочный материал) |
| Finger help%@dir.su.edu.au | on a particular database facility |
| Finger copyright@dir.su.edu.au | please read this copyright notice |
| Finger egrep@dir.su.edu.au | a manual on egrep regular expressions (справочные материалы по допустимым egrep-выражениям). |
Замечание. Задавая ключевые слова, избегайте применения специальных символов, пробелы относятся к их числу.
Выдав команду:
| Finger 2%AArnet@dir.su.edu.au | (запрос содержимого второй раздела базы данных aarnet); |
получим:
[extra.ucc.su.oz.au]
Index for Chapter 2 (список библиотек):
Australian Defense Force Academy Library
The Australian National University Library
Curtin University Of Technology T.L. Robertson Library
Deakin University Library
Griffith University, Division of Information Services
La Trobe University Library
Macquarie University Library
Murdoch University Library
R.M.I.T. Library - MATLAS Library Catalogue.
Swinburne Library
The University of Adelaide, Barr Smith Library
The University of Melbourne Baillieu Library
The University of New England Library
The University of New South Wales
The University of Newcastle Libraries
The University of Queensland Libraries
The University of Western Australia, Reid Library
The University of Wollongong Library
University College of Central Queensland Library
University of South Australia Library Systems Dept
Victoria University of Wellington
Таким образом, даже с помощью Finger можно организовать доступ к базам данных. Finger не сработает для узлов, не имеющих IP-адресов (например, электронный почтовый адрес). Эта команда всегда позволит руководителю проекта узнать, например, когда последний раз тот или иной участник проекта работал на ЭВМ. :-)
