Бесклассовая интердоменная маршрутизация (CIDR)
4.4.11.5 Бесклассовая интердоменная маршрутизация (CIDR)
Вряд ли отцы-создатели Интернет предполагали, что когда-либо, тем более при их жизни возникнет дефицит IP-адресов. Уже в 1996 году было зарегистрировано более 100000 сетей. Разбивка сетей на три класса A, B и С уже не может отвечать современным требованиям. Сеть класса А с ее 16000000 адресов слишком велика, а класса С с 254 адресами, как правило, слишком мала. Сети класса B с 65536 машинами может показаться оптимальными, но на практике каждая из этих сетей не обеспечивает оптимального использования адресного пространства и всегда остаются неиспользованные адреса (для классов B и A количество пустующих адресов оказывается обычно значительным). Адресные блоки заказываются администраторами, которые полагают, что однажды их организация или фирма станет великой с тысячами ЭВМ (пока же у них есть всего несколько машин). Надо сказать, что такие оптимистические прогнозы сбываются крайне редко. Проблема маршрутизации может быть решена путем реализации более глубокой структурной иерархии, где каждый IP-адрес имеет код страны, региона, города, сети, но при этом размер адреса должен существенно превышать 32 разряда, так как адреса неизбежно будут использоваться крайне не эффективно - ведь Китаю и Монако будут выделены равные адресные зоны. Это может стать возможным при внедрении технологии IPv6.
Если бы в адресах класса С для кода номера ЭВМ было выделено 10 или 11 бит (1024-2048), ситуация была бы более приемлемой. Маршрутизатор рассматривает IP-адресную среду на двух уровнях - адрес сети и адрес ЭВМ, при этом практически они работают только с адресами сетей. Число записей в маршрутной таблице должно будет быть равным половине миллиона записей (по числу блоков С-адресов).
Проблема может быть решена, если забыть про разбиение всей совокупности IP-адресов на классы. Такая модель реализуется в рамках протокола CIDR (Classless InterDomain Routing). В этой модели каждой сети ставится в соответствие определенное число смежных блоков по 256 адресов. Далее используется известное географическое зонное распределение IP-адресов (см. Ethernet в Интернет, а также RFC-1519). Протокол при просмотре маршрутных таблиц предполагает применение специальных масок и индексных механизмов.
– Центральный проводник; – изолятор; – проводник-экран; внешний изолятор
Рисунок 3.1.1. 1 – центральный проводник; 2 – изолятор; 3 – проводник-экран; внешний изолятор
Коаксиальная система проводников из-за своей симметричности вызывает минимальное внешнее электромагнитное излучение. Сигнал распространяется по центральной медной жиле, контур тока замыкается через внешний экранный провод. При заземлении экрана в нескольких точках по нему начинают протекать выравнивающие токи (ведь разные “земли” обычно имеют неравные потенциалы). Такие токи могут стать причиной внешних наводок (иной раз достаточных для выхода из строя интерфейсного оборудования), именно это обстоятельство является причиной требования заземления кабеля локальной сети только в одной точке. Наибольшее распространение получили кабели с волновым сопротивлением 50 ом. Это связано с тем, что эти кабели из-за относительно толстой центральной жилы характеризуются минимальным ослаблением сигнала (волновое сопротивление пропорционально логарифму отношения диаметров внешнего и внутреннего проводников). Но по мере развития технологии скрученные пары смогли вытеснить из этой области коаксиальные кабели. Это произошло, когда полоса пропускания скрученных пар достигла 200-350 МГц при длине 100м (неэкранированные и экранированные скрученные пары категории 5 и 6), а цены на единицу длины сравнялись. Скрученные пары проводников позволяют использовать биполярные приемники, что делает систему менее уязвимой (по сравнению с коаксиальными кабелями) к внешним наводкам. Но основополагающей причиной вытеснения коаксиальных кабелей явилась относительная дешевизна скрученных пар. Скрученные пары бывают одинарными, объединенными в многопарный кабель или оформленными в виде плоского ленточного кабеля. Применение проводов сети переменного тока для локальных сетей и передачи данных допустимо для весьма ограниченных расстояний. В таблице 3.1.1 приведены характеристики каналов, базирующихся на обычном и широкополосном коаксиальном кабелях.
Частотное преобразование
Рисунок 2.1. Частотное преобразование
Получение исходного сигнала из преобразованного достигается путем обратного преобразования, которое сводится к умножению полученного сигнала на sin(wнt), где wн = 2 p*fн. При таком обратном преобразовании мы получим сигнал с исходным частотным диапазоном. Помимо этого будет получен сигнал с полосой от (2fн - fм) до (2fн+ fм). Так как fн обычно много больше fм, серьезных проблем это не вызывает - достаточно воспользоваться соответствующим фильтром. Этому методу обратного преобразования присущи некоторые недостатки. Если сигнал fн имеет фазовый сдвиг q
по отношению к тому, что имел сигнал, использованный при прямом преобразовании, то амплитуда выходного сигнала будет пропорциональна cosq. Понятно, что при вариации фазы амплитуда будет меняться, а при q=p/2 станет нулевой. По этой причине должны быть предприняты специальные меры для синхронизации этих сигналов (fн. передатчика и fн приемника).
Соотношение [1.1] используется при реализации амплитудной, частотной или фазовой модуляции. Так в случае амплитудной модуляции при временной вариации A1 (=Авх) будет изменяться и амплитуда выходного сигнала (А2=Aн - амплитуда несущей частоты при этом остается постоянной; w1=w н при этом может также варьироваться). Форма сигнала на выходе такого преобразователя имеет вид: Авых = Ан[1+Авх(t)] sin wнt. Для получения формы исходного сигнала на принимающей стороне используется схема детектора (например, диодного), на выходе которого получается сигнал, пропорциональный модулю огибающей функции входного сигнала. Существуют и другие методы демодуляции амплитудно-модулированного сигнала. Главным недостатком метода амплитудной модуляции является возможность нелинейных искажений из-за перемодуляции (когда амплитуда модулирующего сигнала слишком велика).
При частотной и фазовой модуляции амплитуда передаваемого сигнала остается почти постоянной, что исключает нелинейные искажения, связанные с широким динамическим амплитудным диапазоном. Выходной сигнал для этого вида модуляции имеет вид: Авых = Ан
sin[wнt + q(t)], где q(t) зависит от формы преобразуемого входного сигнала. Часто используется комбинация амплитудной и фазовой модуляции, которая носит название квадратурной модуляции.
Системы передачи данных с амплитудной или частотной модуляцией являются аналоговыми системами и по этой причине весьма чувствительны к шумам на входе приемника. Применение цифровых методов пересылки информации увеличивает вероятность корректной доставки. Если для аналоговой передачи требуется отношение сигнал/шум на уровне 40-60 дБ, то при цифровой передаче достаточно 10-12 дБ. Выбор типа модуляции зависит от стоящей задачи и от характеристик канала (полосы пропускания, ослабления сигнала и т.д.). Частотная модуляция менее чувствительна к амплитудным флуктуациям сигнала. Ослабление сигнала может варьироваться во времени из-за изменений в транспортной среде, это довольно типично для коммутируемых телефонных сетей. В сетях, использующих выделенные каналы, это также возможно благодаря применению динамических протоколов маршрутизации, когда длина пути может изменяться в пределах одного сеанса связи. В любом случае на передающей стороне необходим модулятор, а на принимающей демодулятор. Так как обмен обычно двунаправлен, эти устройства объединяются в одном приборе, который называется модемом (см. также раздел “4.3.7. Модемы").
В модемах применимы несколько видов модуляции:
| FSK | (Frequency Shift Keying) - ступенчатое переключение частоты синусоидального сигнала от f1 к f2 при неизменной амплитуде, частоте f1 ставится в соответствие логический нуль, а f2 - логическая единица. |
| BPSK | (Binary Phase-Shift Keying) - скачкообразное переключение фазы синусоидального сигнала на p при неизменной амплитуде, при этом фазе 0 ставится в соответствие логический нуль, а p- логическая единица. |
| DPSK | (Differential Phase Shift Keying) - метод, при котором изменяется фаза несущей частоты при постоянной амплитуде и частоте. Разновидность PSK, при которой кодируется лишь изменение сигнала. |
| QAM | (Quadrature Amplitude Modulation) - комбинация амплитудной и фазовой модуляции, позволяет осуществить кодирование 8 бит на бод. |
| QPSK | (Quadrature Phase-Shift Keying) - квадратурная фазовая модуляция. Использует 4 фиксированных значения фазы 0, p/2, p и 3p/2. Требует в два раза более узкую полосу, чем PSK, и по этой причине весьма популярна. |
| TCM | (Trellis Coded Modulation) - метод предполагает использование избыточности, каждый бод несет дополнительный бит, который позволяет более точно восстановить информационную битовую последовательность. При кодировании сигнала используется метод QAM. Метод реализован в современных высокоскоростных модемах и позволяет снизить требования к отношению сигнал/шум на 4-5 дБ. |
Форматы специальных сообщений
4. Форматы специальных сообщений
Далее описывается формат сообщений CyberCash версии 0.8. Предполагается, что читатель знаком с такими терминами как "получатель" (acquirer), "PAN" (первичный номер счета), и т.д., определенными в документе ISO 8583, и назначение валюты (currency designations), как это определено в ISO 4217. Некоторые несущественные поля для упрощения удалены. В последующих примерах сообщений подписи, хэши и шифрованные секции не имеют никакого реального смысла.
4.1. Регистрация персоны и нахождение приложения
Первым шагом, который должен сделать клиент, чтобы использовать CyberCash, является регистрация персоны с помощью своего приложения. Это делается с помощью сообщения R1, описанного ниже. Сервер CyberCash откликается сообщением R2.
Когда приложение покупателя узнает, что оно устарело, оно может воспользоваться запросом GA1, посылаемым серверу, и получить в отклике GA2 подписанную версию самого себя.
4.1.1. R1 – регистрация
Описание: Это исходное сообщение, посылаемое для формирования новой персоны CyberCash.
#########################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
FrYOQrD16lEfrvkrqGWkajM1IZOsLbcouB43A4HzIpV3/EBQM5WzkRJGzYPM1r3noBUc
MJ4zvpG0xlroY1de6DccwO9j/0aAZgDi9bcQWV4PFLjsN604j3qxWdYn9evIGQGbqGjF
vn1qI1Ckrz/4/eT1oRkBBILbrWsuwTltFd84plvTy+bo5WE3WnhVKsCUJAlkKpXMaX73
JRPoOEVQ3YEmhmD8itutafqvC90atX7ErkfUGDNqcB9iViRQ7HSvGDnKwaihRyfirkgN
+lhOg6xSEw2AmYlNiFL5d/Us9eNG8cZM5peTow==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ: Сгенерирован с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
#####################################################################
Содержимое скрытой секции:
type: registration
swversion: 0.8win
content-language: en-us
requested-id: MyRequestedCCID
email: myemail@myemailhost.com
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
signature:
v6JGmxIwRiB6iXUK7XAIiHZRQsZwkbLV0L0OpVEvan9l59hVJ3nia/cZc/r5arkLIYEU
dw6Uj/R4Z7ZdqO/fZZHldpd9+XPaqNHw/y8Arih6VbwrO5pKerLQfuuPbIom
#####################################################################
подпись покрывает следующие поля: transaction, date, cyberkey, type, swversion, content-language, requested-id, email, pubkey
#####################################################################
Объяснение:
content-language (язык содержимого) берется из поля заголовка MIME (смотри RFC-1766) и соответствует языку, на котором должно быть написано сообщение (в настоящее время допустимо пока только en-us). swversion используется для проверки, не является ли приложение клиента устаревшим.
4.1.2 R2 – отклик регистрации
Это сообщение предоставляет отклик об успехе или неудаче R1.
#####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950121100505.nnn
opaque:
r1XfjSQt+KJYUVOGU60r7voFrm55A8fP5DjJZuPzWdPQjGBIu3B6Geya8AlJfHsW11u8
dIv1yQeeYj/+l9TD1dXW21/1cUDFFK++J2gUMVv8mX1Z6Mi4OU8AfsgoCliwSkWmjSOb
kE62sAlZTnw998cKzMFp70TSlI3PEBtvIfpLq5lDCNbWidX8vFZV0ENUmMQ9DTP3du9w
fsFGvz1mvtHLT/Gj8GNQRYKF4xiyx4HYzTkSMhgU5B/QDLPS/SawIJuR86b9X0mwsr0a
gbGTzECPJTiKkrhxxMG/eymptsVQSLqNaTCx6w==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Тот же самый, что и ключ сессии для R1 в случае той же транзакции и того же соединения (ID может отсутствовать).
#####################################################################
Содержимое скрытой секции:
type: registration-response
server-date: 19950121100506.nnn
requested-id: MyRequestedCCID
response-id: CyberCashHandle
>email: myemail@myemailhost.com
response-code: success/failure/etc.
pubkey:
0VdP1eAUZRrqt3Rlg460Go/TTs4gZYZ+mvI7OlS3l08BVeoms8nELqL1RG1pVYdDrTsX
E5L+wcGCLEo5+XU5zTKkdRUnGRW4ratrqtcte7e94F+4gkCN06GlzM/Hux94
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя [присутствует только, если имеется SWSeverity].
message;
Произвольный текст уведомления об успехе или неудаче.
Этот текст должен быть отображен для владельца приложения CyberCash...
В принципе текст включает в себя: duplicate-id (дублированный ID), bad-signature (ошибочная подпись) или ill-formed-registration (некорректная регистрация).
Объяснение:
responseid |
применяется для предоставления уникального ID, если в результате ошибки потерян ID, использованный ранее. Если причина неудачи не связана с дублированным ID, это поле может быть опущено. |
| responseid | предоставляет действительный ID с присоединенными контрольными символами в случае успеха. |
| swseverity | может предупредить пользователя о том, что приложение устарело или о наличии в нем известных ошибок. |
Используется CyberApp, чтобы получить обновленную версию.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 123123213
date: 19950121100505.nnn
cyberkey: CC1001
opaque:
VHMS611wGkUmR6bKoI+ODoSbl7L5PKtEo6aM88LCidqN+H/8B4xM3LxdwUiLn7rMPkZi
xOGb+5d1lRV7WeTp21QYlqJr8emc6FAnGd5c0csPmcnEpTFh9xZDJaStarxxmSEwm2mw
l2VjEUODH6321vjoMAOFQWn7ER0o
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Скрытый ключ. Генерируется с использованием общедоступного ключа CyberCash, идентифицированного в CyberKey.
#####################################################################
Содержимое скрытой секции:
type: get-application
swversion: 0.8win
Объяснение:
Может не существовать персоны покупателя и поэтому ID может отсутствовать. Может не быть пары ключей покупателя (общедоступный/секретный) и поэтому не быть подписи. swversion является обязательным, так что сервер мог сказать, что следует возвратить.
4.1.4. GA2 – отклик получения приложения (get-application-response)
Возвращает в случае успеха URL копии современного приложения CyberApp или флаг неудачи.
#####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
transaction: 12312313
date: 19950110102333.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Скрытый ключ: ключ сессии от GA1
#####################################################################
Содержимое скрытой секции:
type: get-application-response
server-date: 19950110102334.nnn
response-code: success/failure/etc.
message; Текст сообщения отображается пользователю, предоставляя дополнительную информацию об успехе или неудаче.
swversion: 0.8win
application-url: http://foo.cybercash.com/server/0.8WIN.EXE
>application-hash: lSLzs/vFQ0BXfU98LZNWhQ==
В качестве хэша приложения используется MD5.
application-url и application-hash при ошибке опускаются.
swversion является версией, подлежащей передаче покупателю.
4.2. Привязка кредитных карт (Binding Credit Cards)
Система CyberCash сконструирована так, чтобы предоставить организации, выпустившей кредитную карту, возможность определить, может ли она использоваться через CyberCash.
Покупатель, после регистрации персоны в CyberCash, как это описано выше, может связать каждую кредитную карту по своему желанию с персоной в системе CyberCash. Это делается с помощью сообщения BC1, посылаемого покупателем своему серверу CyberCash, и отклика BC4, приходящего от сервера.
4.2.1. BC1 – подключение кредитной карты (Bind-Credit-card)
Это начальное сообщение в процессе установления соответствия между кредитной картой и персоной CyberCash.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Формируется из ключа шифрования CyberCash идентифицированного в CyberKey
#####################################################################
Содержимое скрытой секции:
type: bind-credit-card
swversion: 0.8win
card-number: 1234567887654321
card-type: mastercard
card-salt: 46735210
card-expiration-date: 05/99
card-name: John Q. Public
card-street:
card-city:
card-state:
card-postal-code:
card-country:
signature:
tX3odBF2xPHqvhN4KVQZZBIXDveNi0eWA7717DNfcyqh2TpXqgCxlDjcKqdJXgsNLkY7
GkyuDyTF/m3SZif64giCLjJRKg0I6mqI1k/Dcm58D9hKCUttz4rFWRqhlFaj
#####################################################################
Подпись покрывает следующие поля: id, date, transaction, cyberkey, type, swversion, card-number, card-salt, card-expiration-date, card-name, card-street, card-city, card-state, card-postal-code, card-country
#####################################################################
Объяснение:
salt необходимо из- за того, что хэш, запомненный сервером, является менее информативным. Сервер лишь запоминает префикс номера кредитной карты и хэш комбинации номера кредитной карты и salt. Если бы он хэшировал лишь номер кредитной карты, появилась бы возможность выяснить номер кредитной карты путем простого перебора всех возможных номеров. Запись номеров кредитных карт в файлы сервера могут сделать систему весьма уязвимой.
4.2.2. BC4 – отклик подключения кредитной карты (bind-credit-card-response)
Отмечает, что процесс подключения кредитной карты завершился. Присылает флаг успеха или неудачи.
#####################################################################
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: mycybercashid
transaction: 12312314
date: 19950121100505.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Ключ сессии от BC1 и ID
#####################################################################
Содержимое скрытой секции:
type: bind-credit-card-response
server-date: 19950121100506.nnn
swseverity: fatal/warning [absent if ok]
swmessage; message about obsoleteness of customer software to be shown to the customer. [only resent if SWSeverity present]
response-code: success/failure/etc.
card-number: 1234567887654321
card-type: visa
card-salt: 47562310
card-expiration-date: 01/99
card*: [other card* lines to also be given in CH.1 message]
message; Простой текст для пользователя может содержать много строк.
Все строки card* могут быть спасены в виде единого блока для последующего предоставления в CH.1. card-expiration-date, card-number, card-salt и card-type должны присутствовать всегда. В зависимости от причины неудачи не все поля могут быть представлены в сообщении отклике.
4.3. Сообщения покупателя о покупке, содержащие данные о кредитной карте
Вообще, подключение CyberCash к покупке с помощью кредитной карты происходит после того как пользователь определит, что же он, в конце концов, покупает. Когда клиент нажимает клавишу CyberCash “payment”, продавец посылает покупателю сообщение PR1 в виде тела типа MIME риложение/cybercash.
Если покупатель желает продолжить процедуру, он отвечает продавцу сообщением CH1. Продавец реагирует, послав отклик CH2. В паузе между посылкой CH1 и получением CH2, продавец обычно контактирует с сервером CyberCash посредством сообщений CM*.
4.3.1. PR1 – запрос платежа (payment-request)
Это сообщение является первым, которое определено CyberCash в процессе торговой сделки со стороны продавца. Собственно покупка произведена, так как мы собираемся ее оплатить.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: payment-request
merchant-ccid: ACME-012
merchant-order-id: 1231-3424-234242
merchant-date: 19950121100505.nnn
note;
Товары ACME
Покупка 4 пар "Rocket Shoes" по цене $39.95 каждая.
Доставка и вручение $5.00
Общая цена: 164.80
Доставить по адресу: Wily Coyote 1234 South St. Somewhere, VA 12345
merchant-amount: usd 164.80
accepts: visa:CC001, master:CC001,amex:CC001,JCPenny:VK005,macy:VK006
url-pay-to: http://www.ACME.com/CybercashPayment
>url-success: http://www.ACME.com/ordersuccess
>url-fail: http://www.ACME.com/orderfail
merchant-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
$$-CyberCash-End-lSLzs/vFQ0BXfU98LZNWhQ==-$$
Скрытая секция здесь отсутствует.
#####################################################################
При формировании подписанного продавцом хэша используется секретный ключ продавца. Хэш формируется для полей: type, merchant-ccid, merchant-order-id, date, note, merchant-amount, accepts, url-pay-to, url-success, url-fail
#####################################################################
Это сообщение подписывается продавцом, но покупатель не может непосредственно проверить эту подпись. Когда платеж произведен, Покупатель подписывает хэш (полученный непосредственно покупателем) платежа. Если соответствия не будет, CyberCash блокирует платежную операцию.
accepts: Программа клиента распознает только одно слово имени карты из поля accepts сообщения PR1. Например,
MasterCard
AmericanExpress
Распознаны как
Master card
American express
Не распознаны. MasterCard и masterCard распознаются оба как master card.
За типом карты следует указатель ключа. Для основного ряда кредитных карт это будет CC*. Клиент может использовать или игнорировать * номер по своему выбору. Для личной карты это будет VK*, где * представляет собой ключ CheckFree, который следует использовать. Карты разделяются запятыми, указатель ключа следует за типом карты и двоеточием.
url-pay-to указывает, куда следует послать CH1.
url-fail и url-success несут информацию о том, где броузер должен искать данные в случае успеха или неудачи.
4.3.2. CH1 – платеж через кредитную карту (credit-card-payment)
Это сообщение осуществляет представление кредитной карты для выполнения платежа. ####################################################################
Отправитель: CyberApp
Получатель: MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: card-payment
id: myCyberCashID
order-id: 1231-3424-234242
merchant-ccid: ACME-012
transaction: 78784567
date: 19950121100505.nnn
pr-hash: c77VU/1umPKH2kpMR2QVKg==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
cyberkey: CC1001
opaque:
iff/tPf99+Tm5P7s3d61jOWK94nq9/+1jOWK9+vr9+b+94n3tYzmiveJ9/+09/334ubg
3rWM5Ir3ier3/7WM5Ir36+v35v73ife1jOWK94n3/7T3/ffm5uD+7N339/f39/eq3ff3
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
3ard3Q==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ. Создан с использованием общедоступного ключа шифрования CyberCash, на который указывает CyberKey.
#####################################################################
Содержимое скрытой секции:
swversion: 0.8win
>amount: usd 10.00
card*: [из успешно прошедшего BC4 (включает в себя время действительности кредитной карты, ее номер, тип и card-salt)]
Подпись:
meO38aULnoP09VhTS2E56tnuZBRRlGfbwqaleZ9zNnv7YjExJKBFxuaqYTUDEj427HHh
mm9BVmHRwCq6+8ylZXixGHI1I9A/ufAMrpqMIi6DS3PRlc8WC3CCWoAHyAqr
#####################################################################
type, id, order-id, merchant-ccid, transaction, date, pr-hash, pr-signed-hash, cyberkey, swversion, amount, card*
#####################################################################
Поле pr-signed-hash тождественно полю подписанного продавцом хэша (merchant-signed-hash) в сообщении PR1.
4.3.3. CH2 – отклик оплаты с помощью карты (charge-card-response)
Отклик покупателю на CH1-попытку оплатить покупку с помощью кредитной карты. Индицирует успех или неудачу.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: charge-card-response
merchant-ccid: ACME-012
id: myCyberCashID
transaction: 78784567
date: 1995121100500.nnn
merchant-date: 19950121100505.nnn
merchant-response-code: failure/success/etc.
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
merchant-message; Это сообщение от продавца следует отобразить пользователю. Может иметь много строчек и не имеет защиты.
opaque: [может отсутствовать, смотри объяснение]
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
>rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ. Ключ сессии покупателя, взятый из CH1 и переданный через CM1 для ID и транзакции.
#####################################################################
Закрытая секция содержит (из CM.6):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [из успешного BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Ujdjhbn CyberApp, что это закрытая часть. Этот текст отображается для пользователя [присутствует только, когда присутствует SWSeverity].
message;
Свободный комментарий причины неудачи или успеха. Этот текст должен быть отображен для покупателя приложением CyberCash.
Закрытая секция является опционной, так как сообщение CH1 продавцу может не пройти, из-за неверного идентификатора заказа (order-id), даты, ошибочного идентификатора продавца (merchant-ccid) и т.д.. Таким образом, сервер не может быть вовлечен, так как в данной ситуации не существует безопасного механизма генерации закрытой секции сообщения.
Если транзакция осуществляет эту процедуру посредством сервера (через CM*), тогда код отклика на верхнем уровне должен быть зеркальным по отношению к коду-отклику сервера, посланного продавцу.
Заметим, что могут быть два сообщения, одно от продавца и одно от сервера.
4.4. Сообщения продавца о покупке, связанные с кредитной картой
Продавец представляет покупки через кредитную карту, делает корректировки и выражает предпочтения через последовательность CM*. Вообще, цикл, сопряженный с кредитной картой включает авторизацию для покупки, включение покупки в перечень на оплату и собственно осуществление оплаты. Имеется возможность удалить определенную позицию из перечня или аннулировать всю сделку (смотри раздел 5.1.). Авторизации всегда осуществляется клиентом через отклики-сообщения CM1 или CM2. Если приобретение выполняется получателем (acquirer) или каким-то другим объектом между сервером CyberCash и получателем, это делается посредством сообщений CM3 или CM2 в зависимости от соглашения между продавцом и объектом, осуществляющим приобретение. Возвраты обрабатываются с помощью сообщений CM5. Сообщение CM4 служит для возврата покупки или возврата до оплаты сделки. CM6 является форматом сообщения, используемого для откликов на все другие CM*-сообщения.
Последовательности MM* были также применены для оплат, осуществляемых продавцом, как описано в разделе 3.4.7
Современные система оплаты предполагают, что продавец знает номер кредитной карточки. Таким образом, чтобы работать с этими системами, предусмотрены специальные обходные сообщения, которые позволяют снабдить продавца нужной информацией, в противном случае CyberCash делает все, чтобы скрыть номер кредитной карты от продавца. Смотри разделы 3.4.8 и 3.4.9. Это делает получение такой информации контролируемым.
Многие современные продавцы работают в режиме "terminal capture", где авторизации получаются продавцом.
4.4.1. CM1 - auth-only (аутентификация)
Это сообщение используется продавцом для выполнения операции авторизации кредитной карты покупателя.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: auth-only
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:
v4qZMe2d7mUXztVdC3ZPMmMgYHlBA7bhR96LSehKP15ylqR/1KwwbBAX8CEqns55UIYY
GGMwPMGoF+GDPM7GlC6fReQ5wyvV1PnETSVO9/LAyRz0zzRYuyVueOjWDlr5
#####################################################################
Ключ продавца закрытой части генерируется из общедоступного ключа CyberCash, на который указывает merchant-cyberkey. Закрытую часть сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой части и подпись: (в точности как в CH1)
swversion: 0.8win
amount: usd 10.00
card*: [from successful BC4 (includes card-expiration-date, card-number, and card-salt)]
Подпись:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля:
merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
Подпись покупателя: смотри CH1
#####################################################################
Пояснение:
Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что закрытая часть сообщения покупателя не была повреждена или заменена.
4.4.2. CM2 - auth-capture
Осуществляет авторизацию и вводит сумму оплаты сделки. Сообщение аналогично CM1, хотя и имеет другой код типа.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
[exactly the same as CM1 except
type: auth-capture
]
4.4.3. Сообщение CM3 - post-auth-capture
Сообщение аналогично CM1 за исключением того, что оно имеет другой тип и снабжено полем кода авторизации (которое включено в подпись).
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: post-auth-capture
authorization-code: a12323
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
a/0meaMHRinNVd8nq/fKsYg5AfTZZUCX0S3gkjAhZTmcrkp6RZvppmDd/P7lboFLFDBh
Ec0oIyxWeHfArb3OtkgXxJ7qe0Gmm/87jG5ClGnpBnw0dY7qcJ6XoGB6WGnD
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
merchant-signature:
vxyEF1ZHn5Rgmtms3H3t/+UB6RAvZQA1AdddjvlS0H75N1x83FyJuh8V9Ok6t4EUQQZ6
Mnptzc6phJi3Ar0s0oumELsdc8upJdXpNpJV021PGJXfDKfHP0heJIWLodXr
#####################################################################
Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в merchant-cyberkey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1)
swversion: 0.8win
amount: usd 10.00
card*: [в случае успешного BC4 (включает в себя card-salt, номер карты и срок действия карты)]
Подпись:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля:
merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, authorization-code, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
#####################################################################
Подпись продавца гарантирует целостность большей части сообщения. Проверка подписи покупателя гарантирует, что закрытая секция сообщения не была повреждена или заменена.
4.4.4. Сообщение об удалении CM4
Аннулирует возврат денег, если сообщение получено до окончательного расчета. Сообщение аналогично сообщению CM1 за исключением того, что оно имеет другой код типа и снабжено полем номера ссылки возврата (retrieval-reference-number field) (которое включается в подпись).
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: void
retrieval-reference-number: 432112344321
order-id: 1231-3424-234242
merchant-amount: usd 10.00
pr-hash: WATCQuH2q17lRuoxD78YBg==
pr-signed-hash:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Подпись продавца:
lkjladjslkjflsakjflkjsdljflsakjflkjsdljflsakjflkj flsakjflkjsdljflsakjflkjsdljflsajflksdjflksdjflsdjssf=
#####################################################################
Ключ закрытой секции продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицируемого в Merchant-CyberKey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1)
swversion: 0.8win
amount: usd 10.00
card*: [из успешного bc4 (содержит card-salt, номер карты и срок ее действия)]
Подпись:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, retrieval-reference-number, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
#####################################################################>
Подпись продавца гарантирует целостность большей части сообщения. Проверка корректности подписи покупателя гарантирует, что невидимая часть сообщения клиента не была изменена или замещена.
4.4.5. CM5 - возврат
Возврат полученного ранее платежа. В реальности оплата отрицательной суммы. Сообщение совпадает с CM1 за исключением поля тип.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
[в точности как и CM1, только поле type: return]
4.4.6. CM6 – отклик на операцию оплаты (charge-action-response)
Это квитанция, предоставляемая продавцу в качестве уведомления о выполнении платежной операции. Индицирует успех, неудачу или предоставляет какую-то иную информацию.
#####################################################################
Отправитель: CyberServer
Получатель: MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ продавца. Ключ сессии, который совпадает с CM1/2/3/4/5 для той же транзакции и CCID продавца.
Скрытый ключ. Тот же ключ сессии покупателя, что и в сообщении CH1 переданном через CM* для данного ID и транзакции
#####################################################################
Содержимое скрытой секции продавца:
type: charge-action-response
server-date: 19950121100706.nnn
action-code: XXX [per ISO 8583]
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
retrieval-reference-number: 432112344321
authorization-code: a12323
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
{
card-prefix: nnxxxx [ Returned if merchant is not full-PAN]
}
или
{
card-number: 1234567890123456 [Returned if merchant is full-PAN]
}
expiration-date: 12/34 [всегда присутствует]
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца об устаревшем номере протокола в стартовой $$-строке сообщения продавца.
merchant-message;
Свободный текст, поясняющий причины неудачи или успеха.
Этот текст направляется сервером продавцу...
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Содержимое скрытой секции (покупателя):
server-date: 19950121100706.nnn
amount: usd 10.00
order-id: 1231-3424-234242
card*: [from successful BC4]
response-code: failure/success/etc.
swseverity: fatal/warning
swmessage; Говорит CyberApp, что оно является устаревшим. Этот текст отображается для пользователя. [присутствует только, когда имеется SWSeverity]
message;
Свободный текст, поясняющий причины неудачи или успеха. Этот текст следует отобразить покупателю с помощью приложения CyberCash.
retrieval-reference-number |
необходимо для аннулирования. |
| authorization-code | необходим для post-auth-capture. Оба эти поля присутствуют только в сообщении CM6, если оно было присланы банком. Все зависит от выполняемой операции. |
| card-prefix | (префикс карты) представляет собой первые две и последние четыре цифры номера кредитной карты. По усмотрению банка продавца присылается номер кредитной или ее префикс. |
| card-hash | является в действительности хэшем всего номера кредитной карты и salt, представленной покупателем. card-hash необходим для того, чтобы продавец мог, если хочет, сортировать транзакции покупателя по его кредитным картам, не зная их номеров. |
| card* | представляет собой поля card*, полученные вместе с сообщениями CM*, присланными в качестве отклика. Они появляются в алфавитном порядке. |
| server-date | дублируется в целях безопасности в закрытой секции покупателя. |
| [] | комментарии, появляющиеся после некоторых полей. |
/p> 4.4.7. Последовательности сообщений MM*
Последовательности сообщений CM* представляют собой первичную систему покупок с помощью кредитных карт CyberCash для безопасной обработки денежных оплат клиентами системы. Однако продавцы, которые авторизованы их банком для получения оплаты товаров и услуг, могут также получать оплату по телефону, по почте или наличными. Чтобы исключить для продавца необходимость иметь вторую параллельную систему обработки этих платежей, определены последовательности сообщений MM1 - MM6, которые служат для организации таких менее безопасных транзакций. Сообщения MM* очень похожи на последовательность сообщений CM*, но закрытая секция покупателя на самом деле подписана продавцом, при этом не требуется какого-либо дополнительного CyberCash ID покупателя или ссылки на его кредитную карту.
4.4.8. CD1 – запрос данных о кредитной карте
Используется продавцом для получения номера карты и т.д., если нужна информация для разрешения сомнений.
#####################################################################
Отправитель: MerchantApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-69
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-cyberkey: CC1001
cyberkey: CC1001
opaque:
EDD+b9wAfje5f7vscnNTJPkn1Wdi7uG3mHi8MrzLyFC0dj7e0JRjZ2PmjDHuR81kbhqb
nX/w4uvsoPgwM5UJEW0Rb9pbB39mUFBDLPVgsNwALySeQGso0KyOjMxNs1mSukHdOmDV
4uZR4HLRRfEhMdX4WmG/2+sbewTYaCMx4tn/+MNDZlJ89Letbz5kupr0ZekQlPix+pJs
rHzP5YqaMnk5iRBHvwKb5MaxKXGOOef5ms8M5W8lI2d0XPecH4xNBn8BMAJ6iSkZmszo
QfDeWgga48g2tqlA6ifZGp7daDR81lumtGMCvg==
merchant-opaque:
6BVEfSlgVCoGh1/0R+g1C143MaA6QLvKpEgde86WWGJWx45bMUZvaAu4LVeqWoYCqSGf
aWKUF7awol0h1i1jtgieyAcXB8ikvRJIsupSAwsRMyoNlekR6tucvfv/622JY7+n7nGO
dGbMzP0GJImh2DmdPaceAxyOB/xOftf6ko0nndnvB+/y2mFjdUGLtFQP/+3bTpZttZXj
j7RO1khe1UrAIk2TGQJmNw+ltsu0f42MgsxB8Q31vjPtoiPi5LEmD0Y4jlpJ7Jg2Ub84
F9vJhYpmzNkdiJUe83Hvo/xfJRbhafJpXFEsUZwQK0jU1ksU6CQd2+CPBB+6MxtsHoxJ
mjD6ickhd+SQZhbRCNerlTiQGhuL4wUAxzGh8aHk2oXjoMpVzWw2EImPu5QaPEc36xgr
mNz8vCovDiuy3tZ42IGArxBweasLPLCbm0Y=
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Содержимое скрытой секции продавца:
type: card-data-request
password: xyzzy
server-date: 19950121100505.nnn [optional]
order-id: 12313424234242
merchant-amount: usd 10.00
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Подпись продавца:
8zqw0ipqtLtte0tBz5/5VPNJPPonfTwkfZPbtuk5lqMykKDvThhO0ycrfT7eXrn/hLUC
kXoSctahEVdw1KBJbp0EVr1zVzcN9Aa7m2fJgxNfiisTgIRW+PMaa78rn+Ov
#####################################################################
Скрытый ключ продавца генерируется из общедоступного ключа шифрования CyberCash, идентифицированного в merchant-cyberkey.
Закрытая секция сообщения покупателя (Opaque) - смотри CH1.
#####################################################################
Содержимое закрытой секции и подпись: (в точности как в CH1)
swversion: 0.8win
amount: usd 10.00
card*: [от успешного BC4 (включает в себя время действия карты, номер карты и card-salt)]
Подпись:
48SBKUfojyC9FDKCwdCYNvucgiDxYO9erZW4QndIXZRyheTHXH8OeIhwUkyLmgQSD/UK
+IX9035/jUkdNPOxUQq9y/beHS1HU9Fe0wlzfXYRtnjlqvQX+yUfQ4T7eNEs
#####################################################################
Подпись продавца покрывает следующие поля: merchant-ccid, merchant-transaction, merchant-date, merchant-cyberkey, type, password, server-date, order-id, merchant-amount, pr-hash, pr-signed-hash, id, transaction, date, cyberkey
Подпись покупателя: смотри CH1
#####################################################################
[смотри также объяснения для CM1]
Продавцу может быть нужно знать, какая карта используется, и некоторую другую информацию, для того чтобы разрешить определенные проблемы, возникающие при транзакции.
Вся эта информация содержится в исходном сообщении CH1, вложенном в CM1 для реализации транзакции. Если продавец сохраняет CM1 и другую информацию транзакции, то он может послать это CD1-сообщение серверу.
Пароль является дополнительным уровнем безопасности, он предназначен для ручного ввода со стороны продавца, чтобы авторизовать какую-то необычную операцию. Сервер запоминает хэш CCID продавца и пароля.
4.4.9. CD2 – отклик на данные кредитной карты
Отклик на CD1 с указанием на успешный или нет прием данных о кредитной карте.
#####################################################################
Отправитель: CyberServer
Получатель: MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: ACME-012
merchant-transaction: 123123
merchant-date: 19950121100705.nnn
merchant-opaque:
t731/86R72ZLrqHLIf0VG6m3ybvs+dG6K705L8LFKEXgCti0NGjK83CwDsUdiso7U1JP
2Z0BClVHLmhIBY7+QXx5iCEGHy8JKC9IWyNNi2O/OOIDgLeJAkMSZYbNQrSKViY34imS
0s7Q6uDk9wV0fixjvRBuNO2B7urWWsqfkLOYDnHy0RvhyUzYxLrMaTX+/6IkyU5Z0lH3
BXYBUNV8DgitEjgLXmyWuXRDlEBN02yeZgsFRm9GmuBHfCTySm2XqnifizpmKMUa9UiH
onNx9W86fuBdcJF7CJgH5Gct2M/dx/f2VpoRkmeSmWxFrYi8wgtvddSXF9my40NZ8WZz
CEUEvQhcmruopwEeehv+bejc3fDDZ23JKrbhlZ17lSvFR14PKFsi32pXFqTO0ej9GTc5
L6c8nM3tI1qdHNCe0N5f7ASdKS0tYSxAYJLIR6MqPrXjNJEaRx7Vu1odMlkgrzGOV1fo
5w33BQHK3U2h+1e5zYBeHY3ZYG4nmylYYXIye4xpuPN4QU0dGrWZoImYE44QOwjd5ozl
xulPBjj6cpEI/9wTwR3tpkBb4ZfYirxxnoj9JUkPK9Srv9iJ
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
Скрытый ключ: ключ сессии из CD1.
#####################################################################
Содержимое скрытой секции:
type: card-data-response
server-date: 19950121100706.nnn
response-code: failure/success/etc.
order-id: 1231-3424-234242
pr-hash: 7Tm/djB05pLIw3JAyy5E7A==
pr-signed-hash:
IV8gWHx1f8eCkWsCsMOE3M8mnTbQ7IBBcEmyGDAwjdbaLu5Qm/bh06OX1npe2d3Hijxy
+X8vKcVE6l6To27u7A7UmGm+po9lCUSLxgtyqyn3jWhHZpc5NZpwoTCf2pAK
card-hash: 7Tm/djB05pLIw3JAyy5E7A==
card-number: 4811123456781234
card-type: visa
card-name: John Q. Public
expiration-date: 01/99
merchant-swseverity: fatal/warning
merchant-swmessage; Сообщение для продавца о том, что номер информационного протокола в стартовой строке $$ сообщения продавца устарел.
merchant-message;
Свободный текст, поясняющий ошибку или успех операции. Этот текст предназначен сервером для продавца.
id: myCyberCashID
transaction: 78784567
date: 19950121100505.nnn
Сообщение в норме возвращает выбранные поля из дешифрованной закрытой части CH1, в том формате, в каком они были посланы серверу в CD1.
4.5. Прикладные сообщения и уведомления об ошибках
Оказалось необходимо ввести в систему CyberCash сообщения номера утилиты, статуса запроса, и специального уведомления об ошибке.
Желательно иметь возможность проверять коннективность, с некоторой точностью синхронизовать часы и определять версии протокола и приложения клиента. Это сделано с помощью сообщения P1, посылаемого клиентом серверу и отклика P2, возвращаемого сервером клиенту.
Клиенты должны быть способны определить состояние предшествующих транзакций, когда клиент или продавец закрэшился во время сессии или произошла потеря информации в ходе или по завершении транзакции. Определены два сообщения-запроса о транзакции TQ1 и TQ2. Один из них осуществляет запрос, а второй аннулирует транзакцию, если она не завершена. Откликом на оба эти запроса является сообщение TQ3, посылаемое сервером.
Так как система работает в режиме запрос-отклик, имеется две ситуации, когда необходимы специальные сообщения об ошибках. Если запрос оказался не интерпретируемым или имеет неизвестный код типа, посылается уведомление об ошибке UNK1. Если отклик оказался не интерпретируемым или имеет неизвестный код типа или имела место какая-то другая ошибка, которая должна быть зафиксирована в журнале событий сервера CyberCash. Клиент или продавец направляют серверу диагностические сообщения DL1 или DL2.
4.5.1.
P1 - ping
Простая проверка доступности сервера со стороны клиента. Здесь для минимизации избыточности не используется никаких криптографических методов.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: ping
id: myCyberCashID [optional]
transaction: 123123213
date: 19950121100505.nnn
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
id является опционным, так как персона может быть еще не установлена.
4.5.2. P2 – отклик на ping
Отклик на ping P1. Для минимизации избыточности здесь не используется никаких криптографических методов.
#####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: ping-response
id: myCyberCashID [если присутствует в P1]
transaction: 12312313
date: 19950121100505.nnn
server-date: 19950121100506.nnn
swseverity: fatal/warning [отсутствует, если все в порядке]
swmessage; Говорит CyberApp, что оно использует устаревший протокол.
Данный текст отображается для пользователя. [Присутствует только при наличии SWSeverity.]
response-code: success/failure/etc.
message;
Свободный текст комментария об ошибке или успехе.
Этот текст должен быть отображен отправителю его прикладной программой CyberCash.
supported-versions: 08.win, 0.81win, 0.8mac
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
#####################################################################
swversion не включается в P1 по соображениям секретности, по этой причине swseverity и swmessage присутствуют, только если сервер может сказать, что эти вещи устарели.
supported-versions позволяет клиенту знать как можно быстрее, какие версии поддерживаются приложением, а какие нет.
4.5.3. TQ1 – запрос транзакции
Запрос клиента серверу о состоянии транзакции.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
>21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Генерируется ключом шифрования CyberCash, идентифицированным CyberKey
#####################################################################
Содержимое скрытой секции:
type: transaction-query
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
Подпись:
jJfFsKvOxLaV87gxu7lIPet3wIDwh1H2F61reYC9jmUrS6WAtUVFG9aCNuTEBoMixF0X
vD5oPfyheJRIlnL6i0c4o/bfyO3edKAacmWjTmKt6/4y9p3qgvKkSX8r9aym
#####################################################################
Подпись содержит в себе поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Объяснение:
Это запрос клиента сообщить ему о состоянии предшествующей транзакции или транзакций.
begin-transaction и end-transaction могут совпадать.
4.5.4. TQ2 – аннулирование транзакции
Запрос клиента серверу в связи с аннулированием транзакции.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 12312314
cyberkey: CC1001
opaque:
VFaztHuj757Jrv+JxZFsHORy/zgkrxhBCu9cPdE04c1NnXzVlGOHygpSl+UGbUvnhkYl
21QQaHkaE3geccRk03cqFYoLNRCclImcsyeIZCgVt+2dJTj1V+E7R7ePQtCj+0gY42+V
L5BWhVtmDQFyg1DdJ6n3S/er6ZuObAjpcAogG+T1Na5dJmrTA1wRMiYVkqhXi2KMYdur
3U47P8ZGUza7W0MST3DgvviN0kVhtmHEnm515mo6NTQdfdxw9WZpy6vMqrBGk2nTgi2c
bnf+muO0+kiNPXVvEzRrO8o=
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ: полученный из ключа шифрования CyberCash, заданного CyberKey
#####################################################################
Содержимое скрытой секции:
type: transaction-cancel
swversion: 0.8win
begin-transaction: 1234
end-transaction: 4321
Подпись:
kD7DEav2uLQIYMtP9gbhYaBUpB2a5whNwnK2eXbbyTCf56F6dl3DIVf7D8Z4WxbY2YZn
ByRIKeqlhmss7fbdnBiDYmKfOuc+I4bi/Oslml5riaciQhTd2JdHG+PCcHwZ
#####################################################################
Подпись защищает следующие поля: id, date, transaction, cyberkey, type, swversion, begin-transaction, end-transaction
#####################################################################
Объяснение:>
Это попытка клиента аннулировать предыдущую транзакцию или транзакции.>
begin-transaction и end-transaction могут совпадать.
Запрос аннулирования транзакции (TQ.2) определен для взаимодействия клиента с сервером. Этот запрос позволяет клиенту запросить состояние операции и предотвратить операцию, если она еще не осуществлена.
4.5.5. TQ3 – отклик транзакции (transaction-response)
Отклики, генерируемые TQ1 или TQ2
#####################################################################
Отправитель: CyberServer
Получатель: CyberApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: mycybercashid
date: 19950121100505.nnn
transaction: 12312314
server-date: 19950121100505.nnn
opaque:
eFXRL+H0J5q318M21wRdtcbhu9WCyLysQkeF9oIcjtbstymx343bbt0EAtU1gcJaUKJZ
3skgvwrhcxU4bFcE68OPlUXAvLq10I3MczPYPsiGrsU0K4bZtQvDZmn727QQAfONBm5s
s1yjIha+Fj481BJQs0CTYc3ju90lAjCYgirXtnnR6yJXoDO75b7UjthvHSnrTWVZvktX
PvTuUCYzbXSFoYvwFM3Y+yHqSHlmWutYKQpYze8zbUSDQfmwTCJyw3aY2JasZ+xMP/CD
JWbCA+gCLBYCnvzM/ExKTZTFD3xr5JBfNbV4p6CiK6lsfRFD7maAK6TSVnWjwCEJNpOv
fyllfWD04fT7LINQcjJiQK1Pk/912Tk6Q35eRaQZorwv2hnY/7By2OkPyFdAqFL+D0H6
TqzxmdEjEFKxi/PPT1+Cs/Nszy8wZzaGg8iWATfARY6stl+02dDhwOoFXSBNvchlVrcI
IlvhumSIQs29Pntj3DbkYo4IEmmN/qi1vnzld22q7lA1q/CQakyc7jlQUFISx76buqwy
35XiC9Yn8flE4Va14UxMf2RCR1B/XoV6AEd64KwPeCYyOYvwbRcYpRMBXFLyYgWM+ME1
+yp7c66SrCBhW4Q8AJYQ+5j5uyO7uKyyq7OhrV0IMpRDPjiQXZMooLZOifJPmpvJ66hC
VZuWMuA6LR+TJzWUm4sUP9Zb6zMQShedUyOPrtw1vkJXU1vZ5aI8OJAgUcLEitcD+dsY
Df4CzA00fC10POkJ58HZB/pSBfUrHAa+IqMHyZkV/HBi9TjTwmktJi+8T9orXS0jSvor
dMTGWn0ifETy2VXt
$$-CyberCash-End-0QXqLlNxrn4GNQPPk9AO1Q==-$$
#####################################################################
Скрытый ключ. Ключ сессии из TQ1/TQ2 для текущих значений транзакции и ID.
#####################################################################
Содержимое скрытой секции:
type: transaction-response
response-code: success/failure/etc.
message; текстовое сообщение, посылаемое сервером покупателю.
swseverity: fatal/warning
swmessage; Сообщение, указывающее, что программа CyberApp является устаревшей. Может содержать несколько строк.
report-fee: usd 0.15 [если не равно нулю]
transaction-1: old-transaction-number
transaction-status-1: success/failure/pending/cancelled/etc.
server-date-1: 19951212125959.nnn
date-1: 19950121100505.nnn
type-1: auth-only/etc.
Оплата отчета (Report-fee) представляет собой уведомление о том, что данный отчет имеет цену и его предоставление зависит от оплаты. Транзакции с заданным номером может соответствовать несколько транзакций (аутентификация, оплата и т.д.).
Термины
| "исходная транзакция" | относится к платежу или другой транзакции, которая была запрошена или аннулирована. Заметим, что эта транзакция в действительности не является резидентной для сервера. | |
| "request" | относится к запрашивающим сообщениям TQ.2 или TQ.1. | |
| id: | идентификатор сообщения-запроса | |
| date: | дата сообщения-запроса | |
| transaction: | транзакция сообщения-запроса | |
| server-date: | текущая дата/время | |
| type: | Отклик транзакции | |
| response-code: | код отклика для сообщения-запроса, может быть одним из: | |
| "success" | означает, сообщение прошло успешно. Не подразумевает требования присылки состояния запроса. | |
| "failure-hard" | означает, что сообщение-запрос не прошло из-за некорректного формата или по какой-то другой причине. | |
| "failure-swversion" | означает, что запрос не был обработан из-за проблем ревизии программного обеспечения. | |
| message: | сообщение используется только для транзакции TQ, а не к состоянию транзакций, статус или аннулирование которых были запрошены. Сообщение формируется на основании кода отклика: | |
| "success" | сообщение проигнорировано. | |
| "failure-hard" | используется стандартное сообщение уведомление о неудаче. | |
| "failure-swversion" | в случае фатальной ошибки используется стандартное сообщение типа swversion | |
| swseverity: | относится к сообщению-запросу | |
| swmessage: | относится к сообщению-запросу - для полей запрос/отмена ('N' берется из ряда от 1 до N) | |
| transaction-N: | номер исходной транзакции, или, если исходной транзакции на сервере нет, то номер транзакции запроса состояния транзакции с заданным номером. Состояние исходной транзакции может быть одним из: | |
| "success" | исходная транзакция была успешно проведена. Если запросом было сообщение TQ.2, аннулирование не производится. | |
| "failure" | исходная транзакция не была реализована. Если запросом было сообщение TQ.2, аннулирование не производится. | |
| "pending" | исходная транзакция все еще обрабатывается и окончательный результат пока не известен. | |
| "canceled" | исходная транзакция была аннулирована сервером. Последующий приход исходной транзакции не будет обрабатываться, но будет послан отклик "failure-canceled". | |
| server-date-1: | поле server-date из исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует. | |
| date-1: | поле даты исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует. | |
| type-1: | поле типа исходной транзакции. Опускается, если исходная транзакция на сервере отсутствует. |
/p> 4.5.6. UNK1 – неизвестная ошибка
Это отклик, который посылается, когда запрос так плох, что вы не можете определить его тип или этот тип не известен. Отклик посылается Продавцом Клиенту или Сервером Продавцу, или Сервером Клиенту.
#####################################################################
Отправитель: MerchantApp или CyberServer
Получатель: CyberApp или MerchantApp
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
type: unknown-error
unknown-error-message:
Текст сообщения о причинах ошибки, которое следует представить пользователю. (Не найден CyberCash-обработчик, проверка целостности обработчика не прошла, специфицирована неизвестная версия протокола, специфицирован неизвестный тип и т.д.)
{
server-date: 19950121100506.nnn [если послано сервером]
}
или
{
merchant-date: 19950121100506.nnn [если послано продавцом]
}
x-id: mycybercashID
x-transaction: 123123213
x-date: 19950121100505.nnn
x-cyberkey: CC1001
x-opaque:
2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-7Tm/djB05pLIw3JAyy5E7A==-$$
Это сообщение посылается в качестве отклика, когда не удается найти или понять тип сообщения. Оно всегда имеет в начале поля типа и unknown-error-message. Любые поля запроса, которые удается распознать, копируются с префиксами "x-" в сообщение UNK1, посылаемое в качестве отклика. Таким образом, если появляется x-opaque, это означает, что в исходном запросе было поле opaque и т.д.
Так как покупатель инициирует обмен с продавцом и сервером, а продавец запускает обмен с сервером, это сообщение будет послано только покупателю продавцом или сервером покупателю или продавцу.
Оно должно быть записано для отладочных целей. Вам может быть нужно отслеживать отказы обслуживания посредством сообщений UNK1.
4.5.7. DL1 – диагностическая запись
Клиентская диагностическая запись о плохом сообщении от продавца или сервера.
#####################################################################
Отправитель: CyberApp
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
id: MyCyberCashID
date: 19950121100505.nnn
transaction: 1234
cyberkey: CC1001
opaque:
2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Генерируется из ключа шифрования CyberCash, идентифицируемого в CyberKey
#####################################################################
Содержимое скрытой секции:
type: diagnostic-log
message: incorrect order-id
swversion: 0.8win
x-type: original-message-type
x-transaction: original-transaction-number
x-opaque: [ели нельзя дешифровать]
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
#####################################################################
Приложение клиента не ожидает отклика на это сообщение. Если дешифрация прошла успешно, дешифрованное исходное сообщение будет заключено в закрытую секцию. Если дешифровка не прошла, не дешифрованная закрытая секция берется из исходного сообщения.
4.5.8. DL2 – диагностические журнальные записи продавца (merchant-diagnostic-log)
Диагностическая запись продавца о плохом сообщении от сервера.
#####################################################################
Отправитель: CyberMerchant
Получатель: CyberServer
#####################################################################
Пример сообщения:
$$-CyberCash-0.8-$$
merchant-ccid: MyCyberCashID
merchant-transaction: 1234
merchant-date: 19950121100505.nnn
merchant-cyberkey: CC1001
merchant-opaque:
2DqiOQfGRZjzddWpEZwGsJnoTsp9Yiri8DE9cPUMPsJ7lTFuE4XHi4QfN2cAipDB2G/G
9hr7Hj4u4xfMky7nPvJurClZejkI8eNp8iXLtrfS4DhR4yCFQjCiKk0dh83p+DDsFVV7
TI3Du2B15sQS+SdaoPwkfVDnJv4Y+b7vu2cN7bG7exCkBapBcJZbReNaWX5sf+U8ypfw
5V6QdMOzNXpef3z+cTTWfGOtmn9T1Pwo1Yi9ObyIf/wiK+IPb+bBZ9UwLZSB+qVMfJmX
GnHXO3AnA/PD+jKYCtsm2Gxv2WB3CuezOyzPtORuqLp5ubgnLBF9aBBjxwLdbn+cp5sm
lw51IHbmo1Jj7H6wyNnRpEjy4tM73jcosBfGeQDHxgyH1uaiFNr2D+WvmuYo7eun2dsy
Wve2O/FwicWHvkg5aDPsgOjzetsn1JCNZzbW
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
#####################################################################
Скрытый ключ. Генерируется из ключа шифрования CyberCash, заданного в CyberKey
#####################################################################
Содержимое скрытой секции:
type: merchant-diagnostic-log
server-date: 19950121100505.nnn [optional]
message: incorrect order-id
x-type: original-message-type
x-transaction: original-transaction-number
x-opaque: [если невозможно дешифровать]
9/eFiJK5tLizsoeSmpW7uLS8/7iio7Wisfv38biio7uyufv3tfv35uH+7N3d9/exuKX3
5+z3vuu4oqO7srnsvvz8/venoqO0v7al/7iio7WisYy+iv7s3ff3p6KjtL+2pf/wi7nw
#####################################################################
Приложение продавца не ждет отклика на это сообщение. Дешифрованное исходное сообщение будет размещено в закрытой части, если только дешифрование произошло успешно. Если шифрование осуществить не удалось, будет послано не дешифрованное сообщение.
4.6.
Кабельные каналы связи
3.1 Кабельные каналы связи
Кабельные каналы для целей телекоммуникаций исторически использовались первыми. Да и сегодня по суммарной длине они превосходят даже спутниковые каналы. Основную долю этих каналов, насчитывающих многие сотни тысяч километров, составляют телефонные медные кабели. Эти кабели содержат десятки или даже сотни скрученных пар проводов. Полоса пропускания таких кабелей обычно составляет 3-3,5 кГц при длине 2-10 км. Эта полоса диктовалась ранее нуждами аналогового голосового обмена в рамках коммутируемой телефонной сети. c учетом возрастающих требованиям к широкополосности каналов скрученные пары проводов пытались заменить коаксиальными кабелями, которые имеют полосу от 100 до 500 МГц (до 1 Гбит/с), и даже полыми волноводами. Именно коаксиальные кабели стали в начале транспортной средой локальных сетей ЭВМ (10base-5 и 10base-2; см. Рисунок 3.1.1).
Каналы передачи данных
3 Каналы передачи данных
| Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
| 3 | Каналы передачи данных | 1 | 1 |
| 3.1 | Кабельные каналы связи | 7 | 106 |
| 3.2 | Оптоволоконные каналы | 10 | 8 |
| 3.3 | Беспроводные (радио) каналы и сети | 11 | 8 |
| 3.4 | Протокол SLIP | 2 | 20 |
| 3.5 | Протокол PPP | 9 | 8 |
| 3.6 | Протокол G.703 | 1 | 21 |
За последние двадцать лет пропускная способность каналов выросла с 56 кбит/c до 1 Гбит/с. Разработаны технологии, способные работать в случае оптических кабелей со скоростью 50 Тбит/с. Вероятность ошибки при этом сократилась с 10-5 на бит до пренебрежимо низкого уровня. Современный же лимит в несколько Гбит/с связан главным образом с тем, что люди не научились делать быстродействующие преобразователи электрических сигналов в оптические.
Коды протоколов в Ethernet II
10.2 Коды протоколов в Ethernet II
|
Десятичный код |
Hex |
Описание |
| 0-05DC | Поле длины IEEE 802.3 | |
| 512 | 0200 | XEROX PUP (PARC Universal Packet) |
| 513 | 0201 | Трансляция адреса для пакетов PUP |
| 1536 | 0600 | XEROX NS IDP |
| 2048 | 0800 | Internet протокол (IPv4) |
| 2049 | 0801 | X.75 Internet |
| 2050 | 0802 | NBS Internet |
| 2051 | 0803 | ECMA Internet |
| 2052 | 0804 | Chaosnet |
| 2053 | 0805 | X.25 уровень 3 |
| 2054 | 0806 | Протокол трансляции адреса (ARP) |
| 2055 | 0807 | XNS совместимость |
| 2560 | 0A00 | Xerox IEEE-802.3 PUP |
| 4096 | 1000 | Berkley Trailer |
| 21000 | 5208 | BBN Simnet |
| 24577 | 6001 | DEC MOP Dump/Load |
| 24578 | 6002 | DEC MOP удаленный терминал |
| 24579 | 6003 | DEC DECnet фаза IV |
| 24580 | 6004 | DEC LAT (Local Area Transport) |
| 24582 | 6005 | Диагностический протокол DEC |
| 24583 | 6006 | Протокол пользователя DEC |
| 24586 | 6010-6014 | Корпорация 3Com |
| 28720 | 7030 | Proteon |
| 32773 | 8005 | HP Probe |
| 32776 | 8008 | AT&T |
| 32784 | 8010 | Excelan |
| 32787 | 8013 | Диагностика SGI |
| 32788 | 8014 | Сетевые игры SGI |
| 32793 | 8019 | Apollo Computers |
| 32821 | 8035 | Реверсивный протокол ARP (RARP) |
| 32824 | 8038 | DEC LANbridge |
| 32829 | 803D | Ethernet шифрование DEC |
| 32831 | 803F | Сетевой монитор трафика DEC |
| 32872 | 8068 | General Dynamics |
| 32873 | 8069 | AT&T |
| 32923 | 809B | AppleTalk |
| 33011 | 80F3 | AppleTalk AARP |
| 33072 | 8130 | Heyes Microcomputers |
| 33079 | 8137-8138 | NetWare IPX/SPX |
| 33100 | 814C | SNMP |
| 818D | Motorola Computer | |
| 81A5-81AE | RAD Network Devices | |
| 36865 | 9001 | 3Com(Bridge) XNS Sys Mgmt(Системное управление XNS) |
| 36866 | 9002 | 3Com(Bridge) TCP-IP System |
Конфигурирование сетевых систем
5.5 Конфигурирование сетевых систем
От корректности конфигурации сети зависит ее эффективная работа, надежность и безопасность. К сожалению набор параметров, определяющих конфигурацию, сильно зависит от используемой операционной системы и конкретного сетевого программного обеспечения. Большинство локальных сетей сегодня строятся вокруг серверов, которые работают под ОС UNIX (если не считать одноранговых сетей MS Windows). По этой причине ниже будут описаны конфигурационные файлы именно этой ОС. Название конфигурационных файлов и их назначения приведены в таблице 5.5.1.
Коррекция ошибок
2.8 Коррекция ошибок
Исправлять ошибки труднее, чем их детектировать или предотвращать. Процедура коррекции ошибок предполагает два совмещенные процесса: обнаружение ошибки и определение места (идентификация сообщения и позиции в сообщении). После решения этих двух задач, исправление тривиально – надо инвертировать значение ошибочного бита. В наземных каналах связи, где вероятность ошибки невелика, обычно используется метод детектирования ошибок и повторной пересылки фрагмента, содержащего дефект. Для спутниковых каналов с типичными для них большими задержками системы коррекции ошибок становятся привлекательными. Здесь используют коды Хэмминга или коды свертки.
Код Хэмминга представляет собой блочный код, который позволяет выявить и исправить ошибочно переданный бит в пределах переданного блока. Обычно код Хэмминга характеризуется двумя целыми числами, например, (11,7) используемый при передаче 7-битных ASCII-кодов. Такая запись говорит, что при передаче 7-битного кода используется 4 контрольных бита (7+4=11). При этом предполагается, что имела место ошибка в одном бите и что ошибка в двух или более битах существенно менее вероятна. С учетом этого исправление ошибки осуществляется с определенной вероятностью. Например, пусть возможны следующие правильные коды (все они, кроме первого и последнего, отстоят друг от друга на расстояние 4):
00000000
11110000
00001111
11111111
При получении кода 00000111 не трудно предположить, что правильное значение полученного кода равно 00001111. Другие коды отстоят от полученного на большее расстояние Хэмминга.
Рассмотрим пример передачи кода буквы s = 0x073 = 1110011 с использованием кода Хэмминга (11,7).
| Позиция бита: | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Значение бита: | 1 | 1 | 1 | * | 0 | 0 | 1 | * | 1 | * | * |
Символами * помечены четыре позиции, где должны размещаться контрольные биты. Эти позиции определяются целой степенью 2 (1, 2, 4, 8 и т.д.). Контрольная сумма формируется путем выполнения операции XOR (исключающее ИЛИ) над кодами позиций ненулевых битов.
В данном случае это 11, 10, 9, 5 и 3. Вычислим контрольную сумму:
| 11 = | 1011 |
| 10 = | 1010 |
| 09 = | 1001 |
| 05 = | 0101 |
| 03 = | 0011 |
| s = | 1110 |
| Позиция бита: | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
| Значение бита: | 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 0 |
| 11 = | 1011 |
| 10 = | 1010 |
| 09 = | 1001 |
| 08 = | 1000 |
| 05 = | 0101 |
| 04 = | 0100 |
| 03 = | 0011 |
| 02 = | 0010 |
| s = | 0000 |
|
|
В общем случае код имеет N=M+C бит и предполагается, что не более чем один бит в коде может иметь ошибку. Тогда возможно N+1 состояние кода (правильное состояние и n ошибочных). Пусть М=4, а N=7, тогда слово-сообщение будет иметь вид: M4, M3, M2, C3, M1, C2, C1. Теперь попытаемся вычислить значения С1, С2, С3. Для этого используются уравнения, где все операции представляют собой сложение по модулю 2:
С1 = М1 + М2 + М4
С2 = М1 + М3 + М4
С3 = М2 + М3 + М4
Для определения того, доставлено ли сообщение без ошибок, вычисляем следующие выражения (сложение по модулю 2):
С11 = С1 + М4 + М2 + М1
С12 = С2 + М4 + М3 + М1
С13 = С3 + М4 + М3 + М2
Результат вычисления интерпретируется следующим образом.
| С11 | С12 | С13 | Значение |
| 1 | 2 | 4 | Позиция бит |
| 0 | 0 | 0 | Ошибок нет |
| 0 | 0 | 1 | Бит С3 не верен |
| 0 | 1 | 0 | Бит С2 не верен |
| 0 | 1 | 1 | Бит М3 не верен> |
| 1 | 0 | 0 | Бит С1 не верен> |
| 1 | 0 | 1 | Бит М2 не верен |
| 1 | 1 | 0 | Бит М1 не верен |
| 1 | 1 | 1 | Бит М4 не верен |
/p> Описанная схема легко переносится на любое число n и М.
Число возможных кодовых комбинаций М помехоустойчивого кода делится на n классов, где N – число разрешенных кодов. Разделение на классы осуществляется так, чтобы в каждый класс вошел один разрешенный код и ближайшие к нему (по расстоянию Хэмминга) запрещенные коды. В процессе приема данных определяется, к какому классу принадлежит пришедший код. Если код принят с ошибкой, он заменяется ближайшим разрешенным кодом. При этом предполагается, что кратность ошибки не более qm.
Можно доказать, что для исправления ошибок с кратностью не более qmm (как правило, оно выбирается равным D = 2qm +1). В теории кодирования существуют следующие оценки максимального числа N n-разрядных кодов с расстоянием D.
| d=1 | n=2n | ||||||||||||||||||||||||||||
| d=2 | n=2n-1 | ||||||||||||||||||||||||||||
| d=3 |
n 2n /(1+n) |
||||||||||||||||||||||||||||
| d=2q+1 |
Методы сжатия информации
| ||||||||||||||||||||||||||||
 Полагаю, что все читатели знакомы с архиваторами файлов, вероятно, многие из вас неоднократно ими пользовались. Целью архивации файлов является экономия места на жестком или гибком магнитном диске. Кому не приходилось время от времени задумываться над тем, войдет ли данный файл на дискету? Существует большое число программ-архиваторов, имеются и специальные системные программные средства типа Stacker или Doublespace и т.д., решающие эту проблему. Первые теоретические разработки в области сжатия информации относятся к концу 40-х годов. В конце семидесятых появились работы Шеннона, Фано и Хафмана. К этому времени относится и создание алгоритма FGK (Faller, Gallager, Knuth), где используется идея "сродства", а получатель и отправитель динамически меняют дерево кодов (смотри, например, http://www.ics.uci.edu/~dan/plus/DC-Sec4.html). Пропускная способность каналов связи более дорогостоящий ресурс, чем дисковое пространство, по этой причине сжатие данных до или во время их передачи еще более актуально. Здесь целью сжатия информации является экономия пропускной способности и в конечном итоге ее увеличение. Все известные алгоритмы сжатия сводятся к шифрованию входной информации, а принимающая сторона выполняет дешифровку принятых данных. Существуют методы, которые предполагают некоторые потери исходных данных, другие алгоритмы позволяют преобразовать информацию без потерь. Сжатие с потерями используется при передаче звуковой или графической информации, при этом учитывается несовершенство органов слуха и зрения, которые не замечают некоторого ухудшения качества, связанного с этими потерями. Более детально эти методы рассмотрены в разделе "Преобразование, кодировка и передача информации". Сжатие информации без потерь осуществляется статистическим кодированием или на основе предварительно созданного словаря. Статистические алгоритмы (напр., схема кодирования Хафмана) присваивают каждому входному символу определенный код. При этом наиболее часто используемому символу присваивается наиболее короткий код, а наиболее редкому - более длинный. Таблицы кодирования создаются заранее и имеют ограниченный размер. Этот алгоритм обеспечивает наибольшее быстродействие и наименьшие задержки. Для получения высоких коэффициентов сжатия статистический метод требует больших объемов памяти. Альтернативой статистическому алгоритму является схема сжатия, основанная на динамически изменяемом словаре (напр., алгоритмы Лембеля-Зива). Данный метод предполагает замену потока символов кодами, записанными в памяти в виде словаря (таблица перекодировки). Соотношение между символами и кодами меняется вместе с изменением данных. Таблицы кодирования периодически меняются, что делает метод более гибким. Размер небольших словарей лежит в пределах 2-32 килобайт, но более высоких коэффициентов сжатия можно достичь при заметно больших словарях до 400 килобайт. Реализация алгоритма возможна в двух режимах: непрерывном и пакетном. Первый использует для создания и поддержки словаря непрерывный поток символов. При этом возможен многопротокольный режим (например, TCP/IP и DECnet). Словари сжатия и декомпрессии должны изменяться синхронно, а канал должен быть достаточно надежен (напр., X.25 или PPP), что гарантирует отсутствие искажения словаря при повреждении или потере пакета. При искажении одного из словарей оба ликвидируются и должны быть созданы вновь. Пакетный режим сжатия также использует поток символов для создания и поддержания словаря, но поток здесь ограничен одним пакетом и по этой причине синхронизация словарей ограничена границами кадра. Для пакетного режима достаточно иметь словарь объемом, порядка 4 Кбайт. Непрерывный режим обеспечивает лучшие коэффициенты сжатия, но задержка получения информации (сумма времен сжатия и декомпрессии) при этом больше, чем в пакетном режиме. При передаче пакетов иногда применяется сжатие заголовков, например, алгоритм Ван Якобсона (RFC-1144). Этот алгоритм используется при скоростях передачи менее 64 Kбит/с. При этом достижимо повышение пропускной способности на 50% для скорости передачи 4800 бит/с. Сжатие заголовков зависит от типа протокола. При передаче больших пакетов на сверх высоких скоростях по региональным сетям используются специальные канальные алгоритмы, независящие от рабочих протоколов. Канальные методы сжатия информации не могут использоваться для сетей, базирующихся на пакетной технологии, SMDS (Switched Multi-megabit Data Service), ATM, X.25 и Frame Relay. Канальные методы сжатия дают хорошие результаты при соединении по схеме точка-точка, а при использовании маршрутизаторов возникают проблемы - ведь нужно выполнять процедуры сжатия/декомпрессии в каждом маршрутизаторе, что заметно увеличивает суммарное время доставки информации. Возникает и проблема совместимости маршрутизаторов, которая может быть устранена процедурой идентификации при у становлении виртуального канала. Иногда для сжатия информации используют аппаратные средства. Такие устройства должны располагаться как со стороны передатчика, так и со стороны приемника. Как правило, они дают хорошие коэффициенты сжатия и приемлемые задержки, но они применимы лишь при соединениях точка-точка. Такие устройства могут быть внешними или встроенными, появились и специальные интегральные схемы, решающие задачи сжатия/декомпрессии. На практике задача может решаться как аппаратно, так и программно, возможны и комбинированные решения. Если при работе с пакетами заголовки оставлять неизмененными, а сжимать только информационные поля, ограничение на использование стандартных маршрутизаторов может быть снято. Пакеты будут доставляться конечному адресату, и только там будет выполняться процедура декомпрессии. Такая схема сжатия данных приемлема для сетей X.25, SMDS, Frame Relay и ATM. Маршрутизаторы корпорации CISCO поддерживают практически все режимы сжатия/декомпрессии информации, перечисленные выше. Сжатие информации является актуальной задачей, как при ее хранении, так и при пересылке. Сначала рассмотрим вариант алгоритма Зива-Лемпеля. |
Национальные коды доменов в Интернет
10.12 Национальные коды доменов в Интернет
Обычно завершающий код Internet-адреса определяет государственную принадлежность узла, сервера или ЭВМ (информация взята на сервере RIPE Network Coordination Center (X.500 в ISO 3166)). Информация упорядочена согласно англоязычным названиям стран.
|
Страна |
Английское название |
Двухбуквенный код |
Трехбуквенный код |
Числовой код |
| Афганистан | AFGHANISTAN | AF | AFG | 004 |
| Албания | ALBANIA | AL | ALB | 008 |
| Алжир | ALGERIA | DZ | DZA | 012 |
| Американское Самоа | AMERICAN SAMOA | AS | ASM | 016 |
| Андорра | ANDORRA | AD | AND | 020 |
| Ангола | ANGOLA | AO | AGO | 024 |
| ANGUILLA | AI | AIA | 660 | |
| Антарктика | ANTARCTICA | AQ | ATA | 010 |
| Антигуа и Барбуда | ANTIGUA AND BARBUDA | AG | ATG | 028 |
| Аргентина | ARGENTINA | AR | ARG | 032 |
| Армения | ARMENIA | AM | ARM | 051 |
| Аруба | ARUBA | AW | ABW | 533 |
| Австралия | AUSTRALIA | AU | AUS | 036 |
| Австрия | AUSTRIA | AT | AUT | 040 |
| Азербайджан | AZERBAIJAN | AZ | AZE | 031 |
| Багамские острова | BAHAMAS | BS | BHS | 044 |
| Бахрейн | BAHRAIN | BH | BHR | 048 |
| Бангладеш | BANGLADESH | BD | BGD | 050 |
| Барбадос | BARBADOS | BB | BRB | 052 |
| Беларусь | BELARUS | BY | BLR | 112 |
| Бельгия | BELGIUM | BE | BEL | 056 |
| Белиз | BELIZE | BZ | BLZ | 084 |
| Бенин | BENIN | BJ | BEN | 204 |
| Бермудские острова | BERMUDA | BM | BMU | 060 |
| Бутан | BHUTAN | BT | BTN | 064 |
| Боливия | BOLIVIA | BO | BOL | 068 |
| Босния и Герцеговина | BOSNIA AND HERZEGOWINA | BA | BIH | 070 |
| Ботсвана | BOTSWANA | BW | BWA | 072 |
| BOUVET ISLAND | BV | BVT | 074 | |
| Бразилия | BRAZIL | BR | BRA | 076 |
| Британская территория в Индийском океане | BRITISH INDIAN OCEAN TERRITORY | IO | IOT | 086 |
| Бруней | BRUNEI DARUSSALAM | BN | BRN | 096 |
| Болгария | BULGARIA | BG | BGR | 100 |
| Буркина Фасо | BURKINA FASO | BF | BFA | 854 |
| Бурунди | BURUNDI | BI | BDI | 108 |
| Камбоджа | CAMBODIA | KH | KHM | 116 |
| Камерун | CAMEROON | CM | CMR | 120 |
| Канада | CANADA | CA | CAN | 124 |
| CAPE VERDE | CV | CPV | 132 | |
| Каймановы острова | CAYMAN ISLANDS | KY | CYM | 136 |
| Центрально Африканская Республика | CENTRAL AFRICAN REPUBLIC | CF | CAF | 140 |
| Чад | CHAD | TD | TCD | 148 |
| Чили | CHILE | CL | CHL | 152 |
| Китай | CHINA | CN | CHN | 156 |
| Остров Рождества | CHRISTMAS ISLAND | CX | CXR | 162 |
| Кокосовые острова | COCOS (KEELING) ISLANDS | CC | CCK | 166 |
| Колумбия | COLOMBIA | CO | COL | 170 |
| Каморы | COMOROS | KM | COM | 174 |
| Конго | CONGO | CG | COG | 178 |
| Острова Кука | COOK ISLANDS | CK | COK | 184 |
| Коста-Рика | COSTA RICA | CR | CRI | 188 |
| Кот де Вуар | COTE D'IVOIRE | CI | CIV | 384 |
| Хорватия | CROATIA | HR | HRV | 191 |
| Куба | CUBA | CU | CUB | 192 |
| Кипр | CYPRUS | CY | CYP | 196 |
| Чешская республика | CZECH REPUBLIC | CZ | CZE | 203 |
| Дания | DENMARK | DK | DNK | 208 |
| Джибути | DJIBOUTI | DJ | DJI | 262 |
| Доминика | DOMINICA | DM | DMA | 212 |
| Доминиканская республика | DOMINICAN REPUBLIC | DO | DOM | 214 |
| Восточный Тимор | EAST TIMOR | TP | TMP | 626 |
| Эквадор | ECUADOR | EC | ECU | 218 |
| Египет | EGYPT | EG | EGY | 818 |
| Сальвадор | EL SALVADOR | SV | SLV | 222 |
| Экваториальная Гвинея | EQUATORIAL GUINEA | GQ | GNQ | 226 |
| Эритрея | ERITREA | ER | ERI | 232 |
| Эстония | ESTONIA | EE | EST | 233 |
| Эфиопия | ETHIOPIA | ET | ETH | 231 |
| Фолклендские острова | FALKLAND ISLANDS | FK | FLK | 238 |
| Острова Фаро | FAROE ISLANDS | FO | FRO | 234 |
| Фиджи | FIJI | FJ | FJI | 242 |
| Финляндия | FINLAND | FI | FIN | 246 |
| Франция | FRANCE | FR | FRA | 250 |
| Франция, метрополия | FRANCE, METROPOLITAN | FX | FXX | 249 |
| Французская Гвинея | FRENCH GUIANA | GF | GUF | 254 |
| Французская Полинезия | FRENCH POLYNESIA | PF | PYF | 258 |
| Французские Южные территории | FRENCH SOUTHERN TERRITORIES | TF | ATF | 260 |
| Габон | GABON | GA | GAB | 266 |
| Гамбия | GAMBIA | GM | GMB | 270 |
| Грузия | GEORGIA | GE | GEO | 268 |
| Германия | GERMANY | DE | DEU | 276 |
| Гана | GHANA | GH | GHA | 288 |
| Гибралтар | GIBRALTAR | GI | GIB | 292 |
| Греция | GREECE | GR | GRC | 300 |
| Гренландия | GREENLAND | GL | GRL | 304 |
| Гренада | GRENADA | GD | GRD | 308 |
| Гваделупа | GUADELOUPE | GP | GLP | 312 |
| Гуам | GUAM | GU | GUM | 316 |
| Гватемала | GUATEMALA | GT | GTM | 320 |
| Гвинея | GUINEA | GN | GIN | 324 |
| Гвинея-Биссау | GUINEA-BISSAU | GW | GNB | 624 |
| Гайана | GUYANA | GY | GUY | 328 |
| Гаити | HAITI | HT | HTI | 332 |
| HEARD AND MC DONALD ISLANDS | HM | HMD | 334 | |
| Гондурас | HONDURAS | HN | HND | 340 |
| Гонконг | HONG KONG | HK | HKG | 344 |
| Венгрия | HUNGARY | HU | HUN | 348 |
| Исландия | ICELAND | IS | ISL | 352 |
| Индия | INDIA | IN | IND | 356 |
| Индонезия | INDONESIA | ID | IDN | 360 |
| Иран | IRAN | IR | IRN | 364 |
| Ирак | IRAQ | IQ | IRQ | 368 |
| Ирландия | IRELAND | IE | IRL | 372 |
| Израиль | ISRAEL | IL | ISR | 376 |
| Италия | ITALY | IT | ITA | 380 |
| Ямайка | JAMAICA | JM | JAM | 388 |
| Япония | JAPAN | JP | JPN | 392 |
| Иордания | JORDAN | JO | JOR | 400 |
| Казахстан | KAZAKHSTAN | KZ | KAZ | 398 |
| Кения | KENYA | KE | KEN | 404 |
| Кирибати | KIRIBATI | KI | KIR | 296 |
| КНДР | KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF | KP | PRK | 408 |
| Корея | KOREA | KR | KOR | 410 |
| Кувейт | KUWAIT | KW | KWT | 414 |
| Киргизстан | KYRGYZSTAN | KG | KGZ | 417 |
| Лаос | LAO PEOPLE'S DEMOCRATIC REPUBLIC | LA | LAO | 418 |
| Латвия | LATVIA | LV | LVA | 428 |
| Леван | LEBANON | LB | LBN | 422 |
| Лесото | LESOTHO | LS | LSO | 426 |
| Либерия | LIBERIA | LR | LBR | 430 |
| Ливия | LIBYAN ARAB JAMAHIRIYA | LY | LBY | 434 |
| Лихтенштейн | LIECHTENSTEIN | LI | LIE | 438 |
| Литва | LITHUANIA | LT | LTU | 440 |
| Люксембург | LUXEMBOURG | LU | LUX | 442 |
| Макао | MACAU | MO | MAC | 446 |
| Македония | MACEDONIA, | MK | MKD | 807 |
| Мадагаскар | MADAGASCAR | MG | MDG | 450 |
| Малави | MALAWI | MW | MWI | 454 |
| Малайзия | MALAYSIA | MY | MYS | 458 |
| Мальдивские острова | MALDIVES | MV | MDV | 462 |
| Мали | MALI | ML | MLI | 466 |
| Мальта | MALTA | MT | MLT | 470 |
| Маршалловы острова | MARSHALL ISLANDS | MH | MHL | 584 |
| Мартиника | MARTINIQUE | MQ | MTQ | 474 |
| Мавритания | MAURITANIA | MR | MRT | 478 |
| Маврикий | MAURITIUS | MU | MUS | 480 |
| MAYOTTE | YT | MYT | 175 | |
| Мексика | MEXICO | MX | MEX | 484 |
| Микронезия | MICRONESIA | FM | FSM | 583 |
| Молдова | MOLDOVA | MD | MDA | 498 |
| Монако | MONACO | MC | MCO | 492 |
| Монголия | MONGOLIA | MN | MNG | 496 |
| MONTSERRAT | MS | MSR | 500 | |
| Марокко | MOROCCO | MA | MAR | 504 |
| Мозамбик | MOZAMBIQUE | MZ | MOZ | 508 |
| MYANMAR | MM | MMR | 104 | |
| Намибия | NAMIBIA | NA | NAM | 516 |
| Остров Науру | NAURU | NR | NRU | 520 |
| Непал | NEPAL | NP | NPL | 524 |
| Нидерланды | NETHERLANDS | NL | NLD | 528 |
| Нидерландские Антиллы | NETHERLANDS ANTILLES | AN | ANT | 530 |
| Новая Каледония | NEW CALEDONIA | NC | NCL | 540 |
| Новая Зеландия | NEW ZEALAND | NZ | NZL | 554 |
| Никарагуа | NICARAGUA | NI | NIC | 558 |
| Нигер | NIGER | NE | NER | 562 |
| Нигерия | NIGERIA | NG | NGA | 566 |
| NIUE | NU | NIU | 570 | |
| Остров Норфолк | NORFOLK ISLAND | NF | NFK | 574 |
| Северные Марианские острова | NORTHERN MARIANA ISLANDS | MP | MNP | 580 |
| Норвегия | NORWAY | NO | NOR | 578 |
| Оман | OMAN | OM | OMN | 512 |
| Пакистан | PAKISTAN | PK | PAK | 586 |
| Остров Палау | PALAU | PW | PLW | 585 |
| Панама | PANAMA | PA | PAN | 591 |
| Папуа Новая Гвинея | PAPUA NEW GUINEA | PG | PNG | 598 |
| Парагвай | PARAGUAY | PY | PRY | 600 |
| Перу | PERU | PE | PER | 604 |
| Филиппины | PHILIPPINES | PH | PHL | 608 |
| Остров Питкэрн | PITCAIRN | PN | PCN | 612 |
| Польша | POLAND | PL | POL | 616 |
| Португалия | PORTUGAL | PT | PRT | 620 |
| Пуэрто-Рико | PUERTO RICO | PR | PRI | 630 |
| Катар | QATAR | QA | QAT | 634 |
| Реюньон | REUNION | RE | REU | 638 |
| Румыния | ROMANIA | RO | ROM | 642 |
| Россия | RUSSIAN FEDERATION | RU | RUS | 643 |
| Руанда | RWANDA | RW | RWA | 646 |
| Сант Китс и Невис | SAINT KITTS AND NEVIS | KN | KNA | 659 |
| Сент-Люсия | SAINT LUCIA | LC | LCA | 662 |
| Сент-Винсент и Гренадины | SAINT VINCENT AND THE GRENADINES | VC | VCT | 670 |
| Самоа | SAMOA | WS | WSM | 882 |
| Сан-Марино | SAN MARINO | SM | SMR | 674 |
| Сан Томе и Принсипи | SAO TOME AND PRINCIPE | ST | STP | 678 |
| Саудовская Аравия | SAUDI ARABIA | SA | SAU | 682 |
| Сенегал | SENEGAL | SN | SEN | 686 |
| Сейшельские острова | SEYCHELLES | SC | SYC | 690 |
| Сиерра-Леоне | SIERRA LEONE | SL | SLE | 694 |
| Сингапур | SINGAPORE | SG | SGP | 702 |
| Словакия | SLOVAKIA | SK | SVK | 703 |
| Словения | SLOVENIA | SI | SVN | 705 |
| Соломоновы острова | SOLOMON ISLANDS | SB | SLB | 090 |
| Сомали | SOMALIA | SO | SOM | 706 |
| Южная Африка | SOUTH AFRICA | ZA | ZAF | 710 |
| Южная Георгия и Южные Сэндвичевы острова | SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS | GS | SGS | 239 |
| Испания | SPAIN | ES | ESP | 724 |
| Шри-Ланка | SRI LANKA | LK | LKA | 144 |
| Св. Елена | ST. HELENA | SH | SHN | 654 |
| Сен-Пьер и Микелон | ST. PIERRE AND MIQUELON | PM | SPM | 666 |
| Судан | SUDAN | SD | SDN | 736 |
| Суринам | SURINAME | SR | SUR | 740 |
| Острова Свалбард и Ян-Майена | SVALBARD AND JAN MAYEN ISLANDS | SJ | SJM | 744 |
| Свазиленд | SWAZILAND | SZ | SWZ | 748 |
| Швеция | SWEDEN | SE | SWE | 752 |
| Швейцария | SWITZERLAND | CH | CHE | 756 |
| Сирия | SYRIAN ARAB REPUBLIC | SY | SYR | 760 |
| Тайвань | TAIWAN, PROVINCE OF CHINA | TW | TWN | 158 |
| Таджикистан | TAJIKISTAN | TJ | TJK | 762 |
| Танзания | TANZANIA | TZ | TZA | 834 |
| Таиланд | THAILAND | TH | THA | 764 |
| Того | TOGO | TG | TGO | 768 |
| Острова Токелау | TOKELAU | TK | TKL | 772 |
| Тонга | TONGA | TO | TON | 776 |
| Тринидад и Тобаго | TRINIDAD AND TOBAGO | TT | TTO | 780 |
| Тунис | TUNISIA | TN | TUN | 788 |
| Турция | TURKEY | TR | TUR | 792 |
| Туркменистан | TURKMENISTAN | TM | TKM | 795 |
| TURKS AND CAICOS ISLANDS | TC | TCA | 796 | |
| Тувалу | TUVALU | TV | TUV | 798 |
| Уганда | UGANDA | UG | UGA | 800 |
| Украина | UKRAINE | UA | UKR | 804 |
| Объединенные арабские Эмираты | UNITED ARAB EMIRATES | AE | ARE | 784 |
| Великобритания | UNITED KINGDOM | GB | GBR | 826 |
| Соединенные Штаты | UNITED STATES | US | USA | 840 |
| UNITED STATES MINOR OUTLYING ISLANDS | UM | UMI | 581 | |
| Уругвай | URUGUAY | UY | URY | 858 |
| Узбекистан | UZBEKISTAN | UZ | UZB | 860 |
| Вануату | VANUATU | VU | VUT | 548 |
| Ватикан | VATICAN CITY STATE (HOLY SEE) | VA | VAT | 336 |
| Венесуэла | VENEZUELA | VE | VEN | 862 |
| Вьетнам | VIET NAM | VN | VNM | 704 |
| Виргинские острова (ВБ) | VIRGIN ISLANDS (BRITISH) | VG | VGB | 092 |
| Виргинские острова (США) | VIRGIN ISLANDS (U.S.) | VI | VIR | 850 |
| Острова Эллис и Футуна | WALLIS AND FUTUNA ISLANDS | WF | WLF | 876 |
| Западная Сахара | WESTERN SAHARA | EH | ESH | 732 |
| Йемен | YEMEN | YE | YEM | 887 |
| Югославия | YUGOSLAVIA | YU | YUG | 891 |
| Заир | ZAIRE | ZR | ZAR | 180 |
| Замбия | ZAMBIA | ZM | ZMB | 894 |
| Зимбабве | ZIMBABWE | ZW | ZWE | 716 |
Общие операции
4. Общие операции
4.1. Согласование уровня безопасности и номера по порядку
Безопасность сообщения COPS согласуется один раз на соединение и работает для всего последующего обмена через это соединение. Если требуется определенный уровень безопасности COPS, он должен быть согласован во время начального обмена сообщениями Client-Open/Client-Accept, специфицирующего тип клиента равный нулю (который зарезервирован для согласования уровня соединения и верификации соединения).
Если PEP не конфигурировался для использования средств безопасности COPS, он просто пошлет PDP сообщения Client-Open для поддерживаемых типов клиента, как это задано в разделе 4.3 и не будет включать объект Integrity в какие-либо сообщения COPS.
В противном случае, средства безопасности могут быть инициализированы PEP, если он посылает PDP сообщение Client-Open с Client-Type=0 до открытия любого другого типа клиента (Client-Type). Если PDP получает Client-Open с Client-Type=0, после того как другой тип клиента уже успешно открыт, он должен прислать сообщение Client-Close (для Client-Type=0) к PEP. Это первое сообщение Client-Open должно специфицировать Client-Type=0 и должно предоставить объекты PEPID и COPS Integrity. Этот объект Integrity будет содержать начальный порядковый номер, который PDP должен инкрементировать в дальнейшем, после исходного обмена Client-Open/Client-Accept и Key ID, идентифицирующего алгоритм и ключ, которые используются для вычисления дайджеста.
Аналогично, если PDP принимает ключ безопасности PEP и алгоритм путем проверки дайджеста сообщения с использованием идентифицированного ключа, PDP должен послать PEP сообщение Client-Accept с Client-Type =0, содержащего объект Integrity. Этот объект Integrity будет включать исходный порядковый номер, идентификатор ключа (Key ID), задающий ключ и алгоритм, использованные для вычисления дайджеста.
Если PEP, от перспективного PDP, который требует безопасности, потерпит неудачу или вообще не выполнит согласование требований безопасности, не послав исходное сообщение Client-Open с Client-Type=0, содержащее корректный объект Integrity, PDP должен послать PEP сообщение Client-Close с Client-Type=0, специфицирующее соответствующий код ошибки.
Аналогично, если PDP, в процессе диалога с PEP, который требует безопасности, не выполнил согласования параметров, не послав сообщение Client-Accept со значением Client-Type=0 и корректным объектом Integrity, PEP должен послать PDP сообщение Client-Close со значением Client-Type=0, специфицируя соответствующий код ошибки. Такое сообщение Client-Close не должно нести в себе объект integrity (так как согласование безопасности еще не завершено).
Инициализация безопасности может потерпеть неудачу по одной из следующих причин:
| 1. | Партнер, получающий сообщение требует обеспечения уровня безопасности COPS, но объект Integrity не прислан. |
| 2. | Объект Integrity COPS был прислан, но с неизвестным или неприемлемым C-Type (код ошибки Unknown COPS Object, специфицирующий неподдерживаемые C-Num и C-Type). |
| 3. | Дайджест сообщения или идентификатор ключа в присланном объекте Integrity был некорректен и, следовательно, сообщение не может быть аутентифицировано с помощью ключа (код ошибки - Authentication Failure). |
Следующее сообщение, которое посылает PEP в направлении PDP, будет иметь порядковый номер 12 и т.д. Если любое последующее сообщение содержит неверный порядковый номер, неопределенный Key ID, некорректный дайджест сообщения, или не имеет объекта Integrity при условии, что параметры безопасности согласованы, то для Client-Type=0 должно быть сгенерировано сообщение Client-Close, содержащее корректный объект Integrity, где специфицируется соответствующий код ошибки. После этого соединение должно быть разорвано.
4.2. Работа с ключами
Процедура работы с ключами находится за пределами данного документа, но реализации COPS должны, по крайней мере, предоставить возможность ручной конфигурации ключей и задания их параметров. Ключ, используемый для формирования дайджеста сообщения с объектом Integrity, идентифицируется с помощью поля Key ID. Таким образом, параметр Key ID используется для идентификации одного из множества ключей, используемых совместно PEP и PDP. Key ID имеет отношение к определенному PEPID для PDP, или к определенному PDP для PEP. Для каждого ключа должны быть также определены параметры времени действия и параметры, задающие криптографический алгоритм. Как минимум, все реализации COPS должны поддерживать криптографический алгоритм HMAC-MD5-96 [HMAC][MD5] для вычисления дайджеста сообщения, который включается в объект Integrity (Keyed Message Digest), присоединяемый к сообщению.
Регулярное изменение ключей является хорошей практикой. Ключи должны быть конфигурируемы так, чтобы их время действия перекрывались, обеспечивая плавный переход с одного набора на другой. В середине периода действия ключа отправитель должен запустить процедуру перехода на следующий ключ. Тем временем, получатели просто воспринимают любой идентифицированный ключ, полученный в пределах его периода существования (lifetime) и отклоняют любые другие ключи.
4.3. Инициализация PEP
Спустя некоторое время после установления соединения между PEP и удаленным PDP, после согласования условий обеспечения безопасности (если это требуется), PEP пошлет удаленному PDP одно или более сообщение Client-Open, по одному для каждого поддерживаемого PEP типов клиента.
Сообщение Client- Open должно содержать адрес последнего PDP, с которым PEP хранит полный набор решений. Если не поступило ни одного решения от предыдущего PDP, объект LastPDPAddr не должен быть включен в сообщение Client-Open (смотри раздел 2.5). Каждое сообщение Client-Open должно, по крайней мере, содержать общий заголовок, указывающий на один тип клиента, который поддерживает PEP. Удаленный PDP откликнется сообщениями Client-Accept для каждого типа клиента, запрошенного PEP и поддерживаемого PDP.
Если какой-то конкретный тип клиента не поддерживается PDP, PDP будет реагировать с помощью Client-Close, специфицируя неподдерживаемый тип клиента, и возможно предлагая альтернативный PDP-адрес и номер порта. В противном случае, PDP пошлет Client-Accept, специфицируя временную выдержку между сообщениями keep-alive, а PEP может начать посылку запросов PDP.
4.4. Нестандартные операции
Когда PEP сталкивается с ситуацией, которая требует нового политического решения, он посылает удаленному PDP сообщение-запрос. То, что квалифицируется как случай определенного типа клиента, должно быть специфицировано в соответствующем документе, посвященном этому client-type. Удаленный PDP принимает решение и посылает сообщение-решение PEP. Так как запрос определяет состояние, запрос будет запомнен или инсталлирован на удаленном PDP. Уникальный дескриптор (уникальный для TCP-соединения и типа клиента), специфицированный в запросе и соответствующем ему решении идентифицирует состояние запроса. PEP отвечает за удаление этого состояния запроса, если запрос уже более не применим.
PEP может актуализовать ранее инсталлированное состояние запроса путем повторной посылки запроса для соответствующего дескриптора. Удаленный PDP примет новые решения и пошлет сообщения-решения к PEP. Аналогично, сервер может изменить принятое ранее решение на любое инсталлированное состояние запроса в любое время путем посылки не запрошенного сообщения-решения. В любое время модуль PEP ожидает решения PDP и уведомляет PDP о любых изменениях.
4.5. Операции конфигурирования
В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.
В любом случае, PEP может уведомить удаленный PDP о локальном статусе инсталлированного состояния, используя сообщение-отклик. Это сообщение, если нужно, может содержать специфическую информацию клиента.
4.6. Операции Keep-Alive
Сообщение Keep-Alive используется для проверки соединения между клиентом и сервером, чтобы проверить функциональность соединения даже в отсутствие обмена сообщениями между PEP и PDP. PEP должен формировать COPS KA-сообщение случайным образом в диапазоне от одной четвертой до 3/4 минимальной величины выдержки KA таймера, заданной PDP в сообщении Client-Accept. При получении сообщения Keep-Alive от PEP, PDP должен реагировать на это сообщение Keep-Alive посылкой отклика Keep-Alive к PEP. Если любая из сторон не получит сообщение Keep-Alive или любого другого сообщения COPS за время выдержки KA-таймера, соединение должно считаться разорванным.
4.7. Закрытие PEP/PDP
Наконец, сообщения Client-Close используются для аннулирования влияния соответствующих сообщений Client-Open, оповещающих партнера о том, что специфицированный тип клиента не поддерживается или не является активным. Когда PEP регистрирует потерю связи, связанную с таймаутом keep-alive он должен послать сообщение Client-Close для каждого открытого типа клиента, специфицирующего код ошибки разрыва соединения.Затем PEP может разорвать соединение с PDP, попытаться восстановить связь или использовать альтернативный PDP. Когда PDP завершает работу, он должен послать сообщения Client-Close всем PEP для всех типов клиента, при этом может специфицироваться альтернативный PDP, который может заменить прежний.
Подписи и хэши
3. Подписи и хэши
Входные сообщения-запросы CyberCash обычно имеют подпись всех полей. Эта подпись передается в пределах скрытой части сообщения. Она позволяет серверу аутентифицировать источник сообщения.
Сообщения от продавца клиенту, инициализирующие процедуру покупки, имеют поля подписанные продавцом. Эти поля и эта подпись включаются клиентом в скрытую часть сообщения продавцу, так что когда все передается серверу, он может проверить, что клиент получил именно ту информацию, которую ему передал продавец.
3.1. Цифровые подписи
Цифровые подписи являются средством аутентификации. В сообщениях CyberCash, они вычисляются с привлечением хэша данных, подлежащих аутентификации, после чего хэш шифруется посредством секретного ключа RSA.
Любой, кто владеет соответствующим общедоступным ключом, может дешифровать хэш и сравнить его с хэшем сообщения. Если они совпадают, вы можете быть уверены, что подпись была сформирована хозяином секретного ключа, соответствующего общедоступному ключу, которым вы воспользовались, и что сообщение не было искажено при транспортировке.
В системе CyberCash, клиенты, продавцы и сервер имеют пары ключей (общедоступный/секретный). Сохраняя в тайне свой секретный ключ и регистрируя на сервере свой общедоступный ключ (для продавца или клиента), можно обеспечить высокое качество аутентификации с помощью подписи определенных частей сообщения.
Цифровая подпись RSA имеет размер практически равный длине используемого модуля. Например, если модуль содержит 768 бит, то двоичная электронная подпись будет содержать столько же бит, что равно 96 байт. В представлении base64 это займет 128 байт.
3.2. Хэш-коды
Хэши, используемые в сообщениях CyberCash представляют собой дайджесты сообщений. То есть, некоторое компактное отображение сообщения, которое изменяется неузнаваемо при любых искажениях исходного сообщения. Таким образом, относительно небольшой хэш может использоваться для контроля целостности достаточно большого сообщения. Если вы уверены в аутентичности хэша, и получили сообщение, которое соответствует этому хэшу, вы можете тогда быть уверены, что это оригинальное сообщение.
Хэш вычисляется с использованием алгоритма MD5 (смотри RFC-1321) для комбинированного сообщения. Комбинированное сообщение составляется из меток и значений, специфицированных в списке для конкретного хэша. Так как хэш чувствителен к порядку поступающих данных, существенно, чтобы пары метка-значение были сгруппированы в правильной последовательности.
До хэширования из текста комбинированного сообщения удаляются все пробелы (SP, TAB, LF и CR) и все коды меньше 32 и больше 127. Таким образом, все формы обозначения начала новой строки, пустые строки, завершающие пробелы и прочее, удаляются.
Хэши MD5 имеют по 16 байт. Это означает, что кодировка base64 такого хэша занимает 24 символа (последние два будут всегда заполнителями).
Преобразование, кодировка и передача информации
2 Преобразование, кодировка и передача информации
| Номер раздела | Название раздела | Объем в страницах | Объем в кбайт |
| 2 | Преобразование, кодировка и передача информации | 4 | 3 |
| 2.1 | Передача сигналов по линиям связи | 8 | 6 |
| 2.2 | Представление электрических сигналов в цифровой форме | 10 | 7 |
| 2.3 | Цифровые каналы T1 и Е1 | 2 | 1 |
| 2.4 | Методы преобразования и передачи звуковых сигналов | 6 | 5 |
| 2.5 | Методы преобразования и передачи изображения | 14 | 12 |
| 2.6 | Методы сжатия информации | 3 | 3 |
| 2.7 | Обнаружение ошибок | 2 | 2 |
| 2.8 | Коррекция ошибок | 6 | 6 |
| 2.9 | Видеоконференции по каналам Интернет и ISDN | 8 | 97 |
| 2.10 | Статистическая теория каналов связи | 10 | 145 |
Для передачи информации на большие расстояния в настоящее время используются исключительно электромагнитные волны (акустические волны пригодны лишь для ограниченных расстояний). При этом пересылка может осуществляться по медным проводам, оптоволоконному кабелю или непосредственно, по схеме передатчик-приемник. В последнем случае используются антенны. Для того чтобы антенна была эффективна, ее размеры должны быть сравнимы с длиной передаваемой волны. Чем шире динамический диапазон передаваемых частот, тем труднее сделать антенну, пригодную для решения этой задачи. Именно по этой причине для передачи используются частоты, начиная с многих сотен килогерц и выше (длина волн сотни метров и меньше). Передача сигнала непосредственно по лучу лазера ограничена расстояниями 100-3000м и становится неустойчивой при наличии осадков даже для инфракрасных длин волн. Между тем человек воспринимает акустические колебания в диапазоне 20-12000 Гц и для целей пересылки звука (например, телефония) требуется именно этот диапазон частот. Динамический диапазон частот в этом случае равен 600, а для высококачественного воспроизведения звука он в два раза шире. При решении этой проблемы используется преобразование частот и различные методы модуляции. Так тот же частотный диапазон, лежащий в пределах (100 - 100,012) Мгц, соответствует динамическому диапазону 0,012%, что позволяет сделать компактную антенну и упростить частотное выделение сигнала.
Для преобразования частот используется перемножение сигналов. Пусть мы имеем два синусоидальных сигнала: A1*sin(w1
t) и A2*sin( w2t). Из тригонометрии известно, что:
A1*sin( w1t)*A2*sin( w2
t)=1/2*A1*A2*[sin( w1+w2)t + sin( w1-w2)t]. [1.1]
Это означает, что в результате перемножения вместо двух частот f1=w1/2p
и f2= w2/2p мы имеем две новые частоты (w1+w2)/2p и (w1-w2)/2p
с амплитудой 1/2*A1*A2. Если входной сигнал имеет полосу 0 - fм, то после перемножения с сигналом, имеющим частоту fн (несущая частота), получим сигнал с полосой в интервале от (fн - fм) до (fн+ fм). Это преобразование проиллюстрировано на Рисунок 2.1. (по вертикальной оси отложена спектральная плотность сигнала f(jw )). На практике это преобразование выполняется с помощью смесителей или гетеродинов, частота fн называется сигналом гетеродина или несущей.
Причины циклов пакетов и осцилляции маршрутов
5.4 Причины циклов пакетов и осцилляции маршрутов
Для рядового пользователя информация данного раздела не может представлять никакого интереса. Некоторые продвинутые пользователи иногда могут обратить внимание на то, что программа traceroute начинает (вместо нормального отображения пути до цели) выдавать попеременно имена двух соседних узлов. Это может позабавить, если конечно не влияет на решение пользователем его текущих задач. Но в любом случае вмешаться и исправить что-либо он не в силах. О причинах такого поведения сети можно прочесть в разделах, посвященных вопросам маршрутизации.
Начнем с локальных сетей. В разделе о мостах 4.1.1.4, там где говорилось об алгоритме “расширяющееся дерево” отмечалась недопустимость того, чтобы две ЭВМ в локальной сети могли соединяться друг с другом различными путями. Здесь подразумевается соединение через систему мостов, повторителей/концентраторов и переключателей. Такого рода соединение через маршрутизаторы допустимо, но и там следует к этому относиться с определенной осторожностью. Рассмотрим фрагмент сети, изображенный на Рисунок 5.4.1.
Пример ошибочной топологии локальной сети
Рисунок 5.4.1. Пример ошибочной топологии локальной сети
Пакеты от машины 1 через концентратор 1 и 2 попадут в концентратор 2, эти же пакеты попадут туда через мост. В результате возникнет встречное кольцевое движение идентичных пакетов. Кроме того, переключатели и мост попытаются разобраться с этим безобразием и начнут посылать широковешательные пакеты, чтобы выяснить с каким из портов на самом деле связаны эти ЭВМ. Они от рождения убеждены, что одна и та же ЭВМ может быть доступна только через один порт. Таким образом, всплески загрузки сети, особенно широковещательной, должны привлекать внимание администратора. В данном примере, если система переключателей и мостов не поддерживает алгоритма “расширяющееся дерево”, администратор сам должен разорвать эту кольцевую структуру.
Зацикливание пакетов возможно также при использовании внутреннего протокола маршрутизации IGRP, где некорректный выбор параметра вариация приводит к тому, что система при распределении потоков по нескольким направлениям воспринимает путь “назад”, как вполне приемлемый.
Еще один вариант циклов пакетов возникает при использовании маршрутов по умолчанию (более детально это описано в разделе, посвященном маршрутизации 4.4.11). Так при наличии канала между сетями А и Б внешние маршрутизаторы этих сетей сконфигурированы так, что в сети А пакет адресованный не А, направляется в Б, а в сети Б все пакеты с местом назначения не Б, направляются сети А. Такая конфигурация возможна и она будет работать нормально до тех пор, пока в одной из сетей не появится пакет с ошибочным адресом, не соответствующем ни сети А, ни Б. Такой пакет будет двигаться между сетями А и Б до тех пор пока не выработает свой ресурс по TTL.
Похожие проблемы возникают при реализации, например, протокола маршрутизации RIP (см. раздел 4.4.11.1), что сильно замедляет там процедуру установления равновесного маршрута.
Протоколы маршрутизации работают с системами, где имеют место огромные задержки. И как всякая система управления с задержанной обратной связью такие системы склонны к осцилляциям. Допустим некоторый узел, оценив метрику нескольких маршрутов, принял решение перейти на новый маршрут. Если он это сделает, об этом окружающие маршрутизаторы узнают с заметной задержкой и соответствующим образом изменят свои оценки метрик фрагментов пути. Когда (снова с задержкой) исходный маршрутизатор получит информацию об этих оценкам, может случится, что старый маршрут окажется предпочтительнее нового, и все начнется сначала.
Рассмотренные в данном разделе относительно экзотические явления (кроме примера из локальных сетей, здесь имеет место не экзотика, а стихийное бедствие) встречаются не так часто, но администратор сети должен принимать в расчет и такие возможности. Любой из упомянутых эффектов может сильно ухудшить эксплуатационные параметры сети, а то и вовсе вывести ее из строя.
Пример с несколькими PDP
Рисунок .2. Пример с несколькими PDP.
Когда TCP-соединение разорвано, PDP ожидает, что необработанное состояние запроса, соответствующее обмену запрос/решение, будет удалено. Когда PEP регистрирует потерю соединения из-за таймаута, он должен послать сообщение Client-Close каждому открытому типу клиенту, содержащему объект <Error>, который указывает на код ошибки "Communication Failure". Кроме того, PEP должен постоянно пытаться контактировать с первичным PDP или, если не удается, с любым известным запасным PDP. В частности PEP должен проверить все доступные PDP, с которыми он был сконфигурирован до того, как он сможет установить соединение. Если PEP соединен с запасным PDP, а первичный PDP становится доступным, запасной PDP является ответственным за переадресацию PEP на первичный PDP (через сообщение <Client-Close>, содержащее объект <PDPRedirAddr>, идентифицирующий первичный PDP для каждого из типов клиента). В разделе 2.5 рассмотрены детали синхронизации PEP и PDP.
2.4. Использование дескриптора клиента (Client Handle)
Дескриптор клиента служит для идентификации уникального состояния запроса для каждого из типов клиента для одного PEP. Дескрипторы клиента выбираются PEP и являются недоступными для PDP. PDP просто использует дескриптор запроса, чтобы однозначно идентифицировать состояние запроса для конкретного типа клиента, для конкретного TCP-соединения, и тем самым связать его решения с соответствующим запросом. Дескрипторы клиента инициализируются в сообщениях запроса и используются в последующих сообщениях запроса, решения и отчета для ссылки на то же состояние запроса. Когда PEP готов удалить состояние локального запроса, он посылает сообщение удаления (delete) PDP для соответствующего дескриптора клиента. Дескрипторы, относящиеся к различным состояниям запроса, должны быть уникальны в рамках контекста конкретного TCP-соединения и типа клиента.
2.5. Синхронизация
При отсоединении от PDP, PEP должен перейти к принятию локальных решений.
При восстановлении соединения PEP информирует PDP обо всех событиях, которые произошли под локальным управлением. Кроме того, удаленный PDP может потребовать, чтобы внутренние состояния всех PEP были заново синхронизованы (все ранее поступившие запросы были заново посланы) путем передачи сообщения синхронизации состояний (Synchronize State).
После неудачи и до полного установления нового соединения, ухудшение сервиса может быть минимизировано, если PEP кэширует переданные ранее решения и продолжает использовать их в течение некоторого времени.
PEP, который кэширует состояние предыдущего обмена PDP, должен сообщить о факте разрыва соединения любому PDP, с которым он может восстановить соединение. Это выполняется путем включения адреса и номера TCP-порта последнего PDP, для которого PEP кэширует состояние в сообщении Client-Open. Объект <LastPDPAddr> будет включен для последнего PDP, с которым PEP был полностью синхронизован. Если прерывание обслуживания было временным и PDP все еще содержит полное состояние для PEP, PDP может выбрать вариант, когда не все состояния синхронизованы. PEP ответственен за актуализацию всех состояний PDP, которые изменились за время прерывания обслуживания. Если PEP выходит из строя и теряет все кэшированные состояния для некоторого типа клиента, он просто не включает <LastPDPAddr> в свое сообщение Client-Open.
Протокол
2. Протокол
2.1. Общий заголовок
Далее рассматриваются форматы сообщений и объекты, которыми обмениваются PEP и удаленный PDP. Каждое сообщение COPS состоит из заголовка, за которым следует некоторое число типизованных объектов.
| 0 | 1 | 2 | 3 |
| Версия | Флаги | Код операции | Тип клиента |
| Длина сообщения |
//// далее обозначает зарезервированное поле и должно содержать 0.
В заголовке имеются поля:
| Версия: 4 бита | Номер версии COPS. Текущее значение версии 1. |
| Флаги: 4 бита | Определенные значения флага (все другие флаги должны быть установлены в нулевое состояние): 0x1 Solicited Message Flag Bit. Этот флаг устанавливается, когда поступает запрос COPS. Этот флаг не должен устанавливаться (значение=0), если только не специфицировано обратное в разделе 3 |
Ниже в таблице представлены значения поля код операции.
| Код операции (8 бит) |
Функция | Название операции |
| 1 | Запрос | REQ |
| 2 | Решение | DEC |
| 3 | Отчет о состоянии | RPT |
| 4 | Стереть состояние запроса | DRQ |
| 5 | Синхронизовать состояние запроса> | SSQ |
| 6 | Client-Open | OPN |
| 7 | Client-Accept | CAT |
| 8 | Client-Close | CC |
| 9 | Keep-Alive | KA |
| 10 | Завершить синхронизацию | SSC |
Поле Тип клиента: 16 бит
Тип клиента идентифицирует клиента политики. Интерпретация всех инкапсулированных объектов Типы клиента, которые устанавливают старший бит в поле тип клиента, зависят от производителя (enterprise specific; это типы клиентов 0x8000 - 0xFFFF). Для сообщений KA тип клиента в заголовке должен быть установлен равным 0, так как KA используется для проверки связи.
Длина сообщения: 32 бит
Размер сообщения в октетах, который включает в себя стандартный заголовок COPS и все инкапсулированные объекты. Сообщения должны иметь длину кратную 4 октетам.
2.2. Форматы специфических объектов COPS
Все объекты имеют один и тот же формат; каждый объект состоит из одного или более 32-битных слов с 4-октетным заголовком. Формат показан на рисунке:
| 0 | 1 | 2 | 3 |
| Длина (октеты) | C-Num | C-Type | |
| (Содержимое объекта) |
Длина характеризуется двухоктетной величиной, которая описывает число октетов (включая заголовок), которые образуют объект.
Если длина в октетах не попадает на границу слова, кратную 32-бит, должно использоваться заполнение вплоть до конца объекта, так чтобы обеспечивать выравнивание, прежде чем объект будет послан. На принимающей стороне соответствующая граница объекта определяется округлением объявленной ранее длины объекта до значения кратного ближайшим 32-бит.
Обычно, C-Num идентифицирует класс информации в объекте, а C-тип идентифицирует субтип или версию информации, содержащейся в объекте.
C-num: 8 бит
| 1 | Дескриптор (Handle) |
| 2 | Контекст |
| 3 | Входной интерфейс |
| 4 | Выходной интерфейс |
| 5 | Код причины |
| 6 | Решение |
| 7 | LPDP решение |
| 8 | Ошибка |
| 9 | Специфические данные клиента |
| 10 | Таймер Keep-Alive |
| 11 | Идентификация PEP |
| 12 | Тип отчета |
| 13 | Адрес переадресации PDP |
| 14 | Последний PDP-адрес |
| 15 | Таймер аккоунтинга |
| 16 | Целостность сообщения |
2.2.1. Объект дескриптор (Handle)
Объект Handle (дескриптор) содержит уникальную величину, которая идентифицирует инсталлированное состояние. Эта идентификация используется большинством операций COPS. Состояние, соответствующее дескриптору, должно быть непосредственно удалено, когда оно более не применимо.
C-Num = 1
C-Type = 1, дескриптор клиента.
Поле дескриптора имеет переменную длину, дескриптор должен отличаться от других дескрипторов клиента того же самого PEP (соединение COPS TCP)для определенного типа клиента. Он всегда выбирается PEP в исходный момент и ликвидируется, когда он более не нужен. Дескриптор клиента используется, чтобы осуществить ссылку на состояние запроса инициализированного некоторым PEP и инсталлированным для типа клиента PDP. PEP специфицирует дескриптор клиента в своих сообщениях запроса (Request), отклика (Report) и ликвидации (Delete), посланных к PDP. Во всех случаях, дескриптор клиента служит для однозначной идентификации конкретного запроса PEP для данного типа клиента.
Значение дескриптора клиента устанавливается PEP и является непрозрачным для PDP.
PDP просто выполняет побайтовое сравнение со значением этого объекта с учетом значений дескрипторов объектов других поступивших запросов.
2.2.2. Объект Context
Специфицирует тип события(ий), которое вызвало запрос. Этот объект необходим для сообщений-запросов. Запросы управления доступом, выделения ресурсов, и переадресации зависят от типов клиентов. Для допустимых типов клиента PEP может также послать запрос PDP с целью получения именованной конфигурационной информации. Эта именованная конфигурационная информация может иметь форму, полезную для установления системных атрибутов в PEP, или она может иметь форму правил политики, которые могут быть непосредственно проверены PEP.
В одном запросе может присутствовать несколько флагов. Это, однако, допустимо, только если набор специфической информации клиента в комбинированном запросе идентичен набору, который был бы специфицирован в случае посылки отдельного запроса для каждого из флагов.
C-num = 2, C-тип = 1
| 0 | 1 | 2 | 3 |
| R-Type | M-Type |
| 0x01 | Запрос входящего сообщения/Управления доступом (Incoming-Message/Admission Control) |
| 0x02 | Запрос выделения ресурсов |
| 0x04 | Запрос исходящего сообщения |
| 0x08 | Запрос конфигурации |
2.2.3. Объект In-Interface (IN-Int)
Объект In-Interface используется для идентификации входного интерфейса, к которому относится запрос, и PEP, используется обратный адрес и ifindex.
Объект Interface используется также для идентификации принимающего интерфейса через его ifindex. Поле ifindex может быть использовано, чтобы отличать субинтерфейсы от ненумерованных интерфейсов (смотри, например RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.
Поле ifindex специфицированное в In-Interface обычно имеет отношение к ниже лежащему потоку протокольных сообщений.
Поле ifindex является интерфейсом, через который получаются протокольные сообщения.
C-Num = 3
C-Type = 1, IPv4-адрес + Интерфейс
| 0 | 1 | 2 | 3 |
| IPv4 Address format | |||
| ifindex |
C-Type = 2, IPv6-адрес + Интерфейс
| 0 | 1 | 2 | 3 |
|
IPv6 Address format |
|||
| ifindex |
2.2.4. Объект Out-Interface (OUT-Int)
Объект Out-Interface используется для идентификации выходного интерфейса, которому адресован запрос, и адреса, куда должен быть переправлено сообщение. Для потоков или сообщений, направляемых локальной ЭВМ PEP, используется обратный адрес и ifindex. Out-Interface >имеет те же форматы, что и объект In-Interface. Этот интерфейсный объект используется также для идентификации выходного интерфейса через его ifindex. Поле ifindex может быть использовано для отличия субинтерфейсов от ненумерованных интерфейсов (смотри, например, RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.
Поле ifindex специфицированное в Out-Interface обычно связано с потоком протокольных сообщений. Поле ifindex определяет один из адресов, куда протокольное сообщение может быть переадресовано.
C-Num = 4
C-Type = 1, IPv4-адрес + интерфейс
Некоторые форматы C-типа выступают в качестве объекта In-Interface. IPv4-адрес специфицирует адрес, куда направлено исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.
C-Type = 2, IPv6-адрес + интерфейс
Тот же формат C-типа, что и в случае объекта In-Interface. Для этого типа объекта интерфейса, адрес IPv6 специфицирует IP-адрес, которому адресовано исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.
2.2.5. Объект Reason
Этот объект специфицирует причину, почему состояние запроса было стерто. Объект появляется в запросах стирания (DRQ). Поле субкода причины зарезервировано для более подробного описания причины, специфической для клиента и описанной в соответствующих документах.
C-Num = 5, C-тип = 1
| 0 | 1 | 2 | 3 |
| Reason-Code | Reason Sub-code |
| Код причины | |
| 1 | Не специфицировано |
| 2 | Управление |
| 3 | Preempted (Другое состояние запроса получает предпочтение) |
| 4 | Tear (Используется для сообщения об удалении указанного состояния) |
| 5 | Таймаут (время локального состояния истекло) |
| 6 | Route Change (Изменение делает некорректным состояние запроса) |
| 7 | Недостаточные ресурсы (локальные ресурсы исчерпаны) |
| 8 | Директива PDP (решение PDP вызвало аннулирование) |
| 9 | Неподдерживаемое решение (решение PDP не поддерживается) |
| 10 | Synchronize Handle Unknown (дескриптор не известен) |
| 11 | Промежуточный дескриптор (stateless event) |
| 12 | Malformed Decision (восстановление не возможно) |
| 13 | Неизвестный объект COPS от PDP: Субкод (октет 2) содержит неизвестный C-Num объекта (октет 3) содержит неизвестный C-тип объекта |
2.2.6. Объект Decision
Решение, принятое PDP. Присутствует в откликах. Специфические необязательные объекты решения необходимы в решениях для определенных запросов в зависимости от типа клиента.
C-Num = 6
C-тип = 1, флаги решения (обязательные)
| 0 | 1 | 2 | 3 |
| Код команды | Флаги |
0 = Решение NULL (Конфигурационные данные недоступны)
1 = Инсталлировать (Admit request/Install configuration)
2 = Удалить (запрос/конфигурацию)
Флаги:
0x01 = Trigger Error (сообщение об ошибке срабатывания, если установлена)
Trigger Error применима для типов клиентов, которые могут посылать уведомления об ошибках для сигнальных сообщений.
Значения поля флаги не применимые для данного контекста R-типа или типа клиента должны игнорироваться PEP.
C-тип = 2, Stateless Data
Этот тип объекта решения несет в себе дополнительную информацию (stateless), которая может быть использована PEP локально.
Этот объект имеет переменную длину и его внутренний формат должен специфицироваться для данного типа клиента в соответствующем расширительном документе COPS. Этот объект для сообщений-решений является опционным и интерпретируется согласно текущему контексту.
Ожидается, что даже посторонние PEP могут принимать некоторые простые политические решения в рамках их LPDP
Так как этот набор хорошо известен и используется повсеместно, PDP обслуживает и его (обычным образом, через конфигурацию, или используя сообщение Client-Open). PDP может также включать эту информацию в свои решения, а PEP должен использовать ее в случае запросов выделения ресурсов.
C-тип = 3, Данные замещения
Этот тип объекта решения несет в себе информацию замещения, которая призвана заменить существующие данные в указанном сообщении. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе-расширении COPS. Он является опционным в сообщениях решениях и интерпретируется согласно текущему контексту.
C-тип = 4, Данные решения, специфические для клиента
Дополнительные типы решений могут быть введены с помощью информационного объекта специфического решения клиента (Client Specific Decision Data Object). Он имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе расширения COPS. Он является опционным в сообщениях-решениях и интерпретируется в соответствии с данным контекстом.
C-тип = 5, именованные данные решения
Информация об именованной конфигурации инкапсулируется в поле версии объекта решения, это делается в ответ на запрос конфигурации. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован в соответствующих документах расширения COPS для данного типа клиента. Для сообщений решения этот объект является опционным и интерпретируется в зависимости от контекста и флагов решения.
2.2.7. Объект LPDP-решение (LPDPDecision)
Решение принятое LPDP PEP ( Local Policy Decision Point) может присутствовать в запросах. Эти объекты имеют формат, идентичный формату объектов специфических решений клиента, описанному выше.
C-Num = 7
C-тип = (тот же C-Type что и для объектов решения)
2.2.8. Объект Error
Этот объект используется для идентификации конкретных протокольных ошибок COPS. Поле субкода ошибки содержит дополнительную спецификацию ошибки, характерную для данного клиента. Субкоды ошибки для конкретного типа клиента должны специфицироваться в соответствующем документе расширения.
C-Num = 8, C-тип = 1
| 0 | 1 | 2 | 3 |
| Код ошибки | Субкод ошибки |
| Код ошибки | Причина |
| 1 | Плохой дескриптор |
| 2 | Неверный указатель ссылки (Invalid handle reference) |
| 3 | Плохой формат сообщения (Malformed Message) |
| 4 | Невозможна обработка (сервер не может обслужить запрос) |
| 5 | Отсутствует обязательная информация, специфическая для клиента |
| 6 | Неподдерживаемый тип клиента |
| 7 | Отсутствует обязательный объект COPS |
| 8 | Отказ клиента |
| 9 | Коммуникационный отказ (Communication Failure) |
| 10 | Не специфицировано |
| 11 | Закрытие сессии |
| 12 | Переадресация на предпочтительный сервер |
| 13 |
Неизвестный объект COPS: Субкод (октет 2) содержит C-Num и C-Type (октет 3) неизвестного объекта. |
| 14 | Неуспех аутентификации |
| 15 | Необходима аутентификация |
2.2.9. Объект специфической информации клиента (ClientSI)
Для запросов необходимы различные типы этого объекта, он используется в откликах и, когда необходимо, в процедурах open. Объект содержит специфическую информацию для клиента данного типа.
C-Num = 9,
C-Type = 1, Signaled ClientSI.
Поле переменной длины. Все объекты/атрибуты, специфичные для сигнального протокола клиента или внутреннего состояния, инкапсулируются в один или более информационных объектов, специфических для клиента. Формат данных, инкапсулированных в объект ClientSI, определяется типом клиента.
C-Type = 2, Именованный ClientSI.
Поле переменной длины. Содержит именованную конфигурационную информацию, полезную для передачи специфических данных о PEP, запросе, или сконфигурированном состоянии серверу PDP.
2.2.10. Объект Keep-Alive-таймер (KATimer)
Значение времени кодируются в виде 2-октетных целых чисел и измеряются в секундах. Время выдержки таймера рассматривается как приращение.
C-Num = 10,
C-Type = 1, значение таймера Keep-alive
Объект таймер используется для спецификации максимального временного интервала, в течение которого сообщение COPS должно быть послано или получено. Диапазон значений таймаутов лежит в пределах 1 - 65535 секунд. Значение нуль соответствует бесконечности.
| 0 | 1 | 2 | 3 |
| ////////////// | Значение таймера KA |
2.2.11. Объект идентификации PEP (PEPID)
Объект идентификации PEP используется, для того чтобы идентифицировать PEP-клиента удаленному PDP. Это необходимо для сообщений Client-Open.
C-Num = 11, C-Type = 1
Поле переменной длины. Это ASCII-строка, завершающаяся нулем, которая дополняется нулями до границы, кратной 32 бит. Идентификатор PEPID должен содержать ASCII-строку, однозначно идентифицирующую PEP в пределах политической области PEP. Например, он может быть статически приписанным IP-адресом PEP или DNS-именем. Этот идентификатор может использоваться PDP в качестве дескриптора для идентификации PEP в его политических правилах.
2.2.12. Объект тип отчета (Report-Type)
Тип отчета, соответствующий запросу состояния для данного дескриптора:
C-Num = 12, C-Type = 1
| 0 | 1 | 2 | 3 |
| Report-Type | ///////////// |
1 = Success : Решение было успешным для PEP
2 = Failure : Решение не могло быть реализовано PEP
3 = Accounting: Актуализация аккоунтинга для инсталлированного состояния.
2.2.13. Адрес пересылки PDP (PDPRedirAddr)
PDP при закрытии PEP-сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP:
C-Num = 13,
C-Type = 1, IPv4-адрес+ TCP порт
| 0 | 1 | 2 | 3 |
| Формат IPv4-адреса | |||
| ///////////////////////// | TCP Port Number |
| 0 | 1 | 2 | 3 |
|
Формат IPv6-адреса |
/p>
2.2.14. Последний адрес PDP (LastPDPAddr)
Когда PEP имеет определенный тип клиента, он должен специфицировать последний PDP, который он успешно открыл (им получено сообщение Client-Accept) со времени, когда PEP последний раз перезагружался. Если со времени последней загрузки не использовалось никакого PDP, PEP просто не включит этот объект в сообщение Client-Open.
C-Num = 14,
C-Type = 1, IPv4-адрес (тот же формат, что и для PDPRedirAddr)
C-Type = 2, IPv6-адрес (имеет тот же формат, что и PDPRedirAddr)
2.2.15. Объект Accounting-таймер (AcctTimer)
Время кодируется в виде двухоктетых целых чисел и измеряется в секундах. Значение таймера рассматривается как временной интервал между двумя событиями.
C-Num = 15,
C-Type = 1, Значение таймера аккоунтинга
Значение опционного таймера используется для определения минимального интервала между периодическими отчетами о типах аккоунтинга. Оно используется PDP для того чтобы охарактеризовать PEP приемлемое значение интервала между не запрошенными аккоунтинг-актуализациями через сообщения-отчеты, когда это применимо. Он обеспечивает для PDP метод управления объемом аккоунтинг-трафика в сети. Диапазон конечных значений времени лежит в пределах 1 - 65535 секунд (два октета). Значение нуль означает, что не должно быть не запрошенных аккоунтинг-актуализаций.
| 0 | 1 | 2 | 3 |
| ////////////// | ACCT Timer Value |
2.2.16. Объект целостность сообщения (Message Integrity)
Объект целостности (integrity) включает в себя порядковый номер и дайджест сообщения, полезный для аутентификации и проверки целостности сообщения COPS. Когда используется этот объект, он размещается в самом конце сообщения COPS. Дайджест вычисляется для всего сообщения COPS за исключением самого дайджеста. Отправитель сообщения COPS вычисляет и заполняет дайджест-секцию объекта Integrity. Получатель сообщения вычисляет дайджест для этого сообщения и сравнивает его с тем, что хранится в объекте Integrity.
C-Num = 16,
C-Type = 1, HMAC дайджест
Объект HMAC-целостности для вычисления дайджеста сообщения привлекает HMAC (ключевое хэширование для аутентификации сообщения) [HMAC], при этом используется ключ, общий для PEP и PDP.
Объект Integrity специфицирует 32- битовый ID ключа, который определяет специфический ключ, используемый конкретным PEP и его PDP, а также используемый криптографический алгоритм. Для заданного PEPID ID ключа допускает существование одновременно нескольких ключей для PEP и оответствующих ключей PDP. Ключ, идентифицированный ID ключа, используется для вычисления дайджеста сообщения в объекте Integrity. Все программные реализации, как минимум должны поддерживать HMAC-MD5-96, который реализует алгоритм MD5 [MD5] вычисляющий дайджест сообщения длиной 96-бит.
Этот объект включает в себя также порядковый номер, который представляет собой 32-битовое целое число без знака, которое служит для предотвращения атак откликов. Порядковый номер инициируется на фазе обмена сообщениями Client-Open, Client-Accept и инкрементируется каждый раз при посылке очередного сообщения тому же получателю через существующее TCP-соединение. Если порядковый номер достигает значения 0xFFFFFFFF, следующим номер будет равен нулю и процесс продолжится.
Дайджест сообщения COPS вычисляется для области, начиная с заголовка, и вплоть до объекта Integrity (который должен быть последним объектом в сообщении COPS). В эту область попадают заголовок объекта Integrity, ID ключа и порядковый номер (Sequence Number). В случае HMAC-MD5-96, HMAC-MD5 выдает 128-битовый дайджест, который далее укорачивается до 96 бит.
| 0 | 1 | 2 | 3 |
| Key ID | |||
| Sequence Number | |||
|
...Keyed Message Digest... |
2.3. Коммуникация
Протокол COPS использует одно устойчивое TCP соединение между PEP и удаленным PDP. Реализация PDP на сервере должна прослушивать стандартный номер TCP-порта (COPS=3288 [IANA]). PEP ответственен за инициативу TCP-соединения с PDP. Положение удаленного PDP может быть сконфигурировано или получено с помощью механизма локации услуг [SRVLOC].
Если один PEP может поддерживать несколько типов клиентов, он может посылать соответствующее число сообщений Client-Open, адресованных PDP, через одно или более TCP-соединений.Аналогично, PDP с заданным адресом и номером порта может поддерживать один или более типов клиента. Для заданного набора поддерживаемых типов клиентов PDP может в каждом конкретном случае независимо воспринять или отвергнуть любой тип клиента. Если тип клиента отвергнут, PDP может перенаправить PEP на альтернативный PDP-адрес и TCP-порт для данного типа клиента через COPS. Различные TCP-порты могут использоваться для перенаправления PEP на другие программные реализации PDP, работающие на том же сервере.
Один PEP может сформировать соединения с несколькими PDP. Это может происходить, когда физически различные PDP поддерживают разные типы клиентов (как это показано на Рисунок ).
Протокол COPS (Common Open Policy Service)
4.4.9.7 Протокол COPS (Common Open Policy Service)
| 1. | Протокол использует модель клиент-сервер, где PEP посылает запросы, осуществляет актуализацию данных, отправляет сообщения о ликвидации удаленным PDP, а PDP возвращает отклики-решения узлам PEP. |
| 2. | Протокол использует TCP для надежного обмена сообщениями между клиентами и сервером. Следовательно, не нужно никакого дополнительного механизма для обеспечения надежного взаимодействия между сервером и клиентами. |
| 3. | Протокол является расширяемым и может работать с любой специфической информацией клиентов без модификации самого протокола COPS. Протокол был создан для общего администрирования, конфигурации и реализации политики. |
| 4. | COPS предоставляет безопасность на уровне сообщений для целей аутентификации, защиты отклика и целостности сообщения. COPS может также использовать для цели безопасности существующие протоколы, такие как IPSEC [IPSEC] или TLS для осуществления аутентификации и безопасного канала между PEP и PDP. |
| 5. | COPS представляет собой протокол состояний. (1) Состояние запрос/решение является общим для системы клиент-сервер. (2) Состояние различных событий (пар запрос/решение) могут ассоциироваться. Под пунктом (1) подразумевается, что запросы клиента PEP инсталлируются или запоминаются удаленным PDP до тех пор, пока они не будут аннулированы PEP. В то же время, для заданного состояния запроса решения удаленного PDP могут генерироваться асинхронно. Под пунктом (2) подразумевается, что сервер может реагировать на новые запросы по-разному в зависимости от поступивших ранее запросов/решений. |
| 6. | Кроме того, COPS является протоколом состояний, так как он позволяет серверу конфигурировать клиента, а затем аннулировать это состояние, если оно более не нужно. |
с кредитными картами CyberCash версия
4.6.3 Протокол для работы с кредитными картами CyberCash версия 0.8
Протокол CyberCash (RFC-1898, D. Eastlake, CyberCash Credit Card Protocol Version 0.8. February 1996) предназначен для осуществления платежей через Интернет посредством кредитных карточек.
CyberCash Inc. представляет собой компанию, базирующуюся в штате Вирджиния и основанную в августе 1994. Целью компании является посредничество в сфере платежей через Интернет. CyberCash выполняет функцию посредника, через которого осуществляются финансовые операции между покупателем, продавцом и их банками. Важно то, что до начала операции участники могут не иметь никаких отношений друг с другом.
CyberCash является третьей стороной, которая гарантирует надежную проводку платежа от одного партнера к другому.
1.1. Обзор системы
Система CyberCash предназначена для обеспечения нескольких платежных услуг в Интернет. Чтобы получить доступ к услугам CyberCash, клиенту нужен только персональная ЭВМ, имеющая доступ к сети. Соответственно, продавцы и банкиры должны лишь незначительно изменить свои операционные процедуры, чтобы реализовать транзакции CyberCash.
Вначале покупатель должен загрузить общедоступное программное обеспечение CyberCash из Интернет. Эта программа устанавливает соединение между покупателями, продавцами и их банками. Доступ к системе CyberCash еще проще, кнопки CyberCash "PAY" могут быть вставлены в популярные программы реального времени, позволяя клиенту войти в систему CyberCash, когда он пожелает осуществить оплату товара или услуги. Покупатель может не иметь до этого каких-либо отношений с CyberCash. Клиент идентифицирует свою личность через сеть.
Транзакции используют информацию, введенную клиентом в свою ЭВМ, никакого ручного ввода данных для аутентификации не требуется. Покупатель лишь запускает платежную процедуру для каждой транзакции путем выбора одной из опций. Безопасность транзакций обеспечивается криптографически. Конфиденциальная информация о покупателе по каналам связи (например, продавцу) не пересылается.
QAM-модуляция с битами на бод (слева) и битами на бод (справа)
Рисунок 2.2. QAM-модуляция с 3 битами на бод (слева) и 4 битами на бод (справа)
Расширенный информационный кадр CAN
Рисунок 4.1.4.2. Расширенный информационный кадр 2.0b CAN
Однобитовое субполе SRR (substitute remote request) включено в поле арбитража (идентификатора кадра) и всегда содержит код 1, что гарантирует преимущество стандартного информационного кадра (2.0a) случае его соревнования с расширенным кадром (2.0b) (при равных 11 битах идентификатора). Субполе IDE (identifier extension) служит для идентификации расширенного формата и для этого типа кадра всегда имеет уровень логической 1. Вслед за IDE следует 18-битовое поле (биты имеют имена id-17, ..., id-0; первым передается бит id-28) расширения идентификатора кадра. Контроллеры 2.0b полностью совместимы с кадрами 2.0a и могут посылать и принимать пакеты обоих типов. Идентификаторы в пределах одной сети должны быть уникальными. Следует иметь в виду, что 18-битное поле расширения идентификатора можно при определенных условиях использовать и для передачи информации. Идентификатор не является адресом места назначения, а определяет назначение передаваемых данных (адресация по содержанию). По этой причине пакет может быть принят отдельным узлом, группой узлов, всеми узлами сети или не воспринят вообще. Предельное число различных идентификаторов для версии 2.0a составляет 2032, а для 2.0b превышает 500 миллионов.
Послав кадр-запрос другому узлу, отправитель может затребовать присылку определенной информации. Удаленный узел должен откликнуться информационным кадром с тем же идентификатором, что и запрос.
Если несколько узлов начнут передачу одновременно, право передать кадр будет предоставлено узлу с более высоким приоритетом, который задается идентификатором кадра. Механизм арбитража гарантирует, что ни информация, ни время не будут потеряны. Если одновременно начнется передача запроса и информационного кадра с равными идентификаторами, предпочтение будет дано информационному пакету. В процессе арбитража каждый передатчик сравнивает уровень передаваемого сигнала с реальным уровнем на шине. Если эти уровни идентичны, он может продолжить передачу, в противном случае передача прерывается и шина остается в распоряжении более приоритетного кадра.
Протокол can имеет развитую систему диагностики ошибок. В результате вероятность не выявленной ошибки составляет менее 4.7ґ 10-11. При выявлении ошибки кадр отбрасывается и его передача повторяется.
Число узлов, подключенных к каналу, протоколом не лимитируется. Практически такое ограничение налагается задержкой или предельной нагрузкой канала.
Любой модуль can может быть переведен в пассивный режим (“состояние сна”), при котором внутренняя активность прекращается, а драйверы отключаются от канала. Выход из этого режима возможен либо по внутренним причинам, либо вследствие сетевой активности. После “пробуждения” модуль ждет, пока стабилизируется его внутренний тактовый генератор, после чего производится синхронизация его работы с тактами канала (11 тактов). Благодаря синхронизации отдельные узлы не могут начать передачу асинхронно (со сдвигом на часть такта). Протокол предусматривает использование четырех типов кадров:
Информационный.
Удаленный запрос (требование присылки информационного кадра с тем же идентификатором, что и запрос).
Сообщение об ошибке.
Уведомление о перегрузке канала (требует дополнительной задержки до и после передач информационных кадров и удаленных запросов).
Информационные кадры и удаленные запросы могут использовать как стандартные, так и расширенные форматы кадров (2.0a и 2.0b).
Кадр удаленного запроса может иметь стандартный и расширенный форматы. В обоих случаях он содержит 6 полей: SOF, поле арбитража, поле управления, CRC, поля ACK и EOF. Для этого типа кадров бит RTR=1, а поле данных отсутствует вне зависимости от того, какой код содержится в субполе длины.
Кадр сообщения об ошибке имеет только два поля - суперпозиция флагов ошибки и разграничитель ошибки. Флаги ошибки бывают активными и пассивными. Активный флаг состоит из шести нулевых бит, а пассивный - из шести единиц. Суперпозиция флагов может содержать от 6 до 12 бит. Разграничитель ошибки состоит из восьми единичных бит.
Кадр перегрузки включает в себя два поля - перпозиция флагов перегрузки и разграничитель перегрузки (8 бит =1).
В поле флаг ерегрузки записывается 6 бит, равных нулю (как и в поле флаг активной ошибки). Кадры ошибки или перегрузки не требуют межкадровых разделителей. Существует ряд условий перегрузки, каждое из которых вызывает посылку такого кадра:
внутренние обстоятельства приемника, которые требуют задержки передачи следующего кадра данных или запроса.
Детектирование доминантного бита в начале поля int.
Обнаружение узлом доминантного восьмого бита в поле разграничителя ошибки или разграничителя перегрузки.
Время пребывания канала в пассивном состоянии не нормировано. Появление доминантного бита на шине, пребывающей в пассивном состоянии, воспринимается как начало очередного кадра. Предусматривается возможность установления масок в узле на отдельные двоичные разряды идентификатора, что позволяет игнорировать их значения. Маскирование делает возможным мультикастинг-адресацию.
Поля SOF, идентификатор, управляющее поле, данные и CRC кодируются таким образом, что при появлении пяти идентичных бит подряд, в поток вставляется бит противоположного уровня. Так 0000000 преобразуется в 00000100, а 1111110 в 11111010. Это правило не распространяется на CRC-разделители, поля ACK и EOF, а также на кадры сообщения об ошибке или переполнении. Существует 5 разновидностей ошибок (таблица 3.3.4.1).
Разводка разъема интерфейса
Разводка разъема интерфейса RS-232
Номер контакта
Сторона ЭВМ (DTE) Разъем DB25M
Устройство передачи данных (DCE) Разъем DB25F
1
Экран
Экран
2
Выход передачи данных (TD)
Вход приема данных (RD)
3
Вход приема данных (RD)
Выход передачи данных (TD)
4
Запрос передачи данных (RTS)
Запрос приема данных (CTS)
5
Запрос приема данных (CTS)
Запрос передачи данных (RTS)
6
Вход готовности (DSR)
Выход готовности (DTR)
7
Земля сигнала
Земля сигнала
8
Вход CD (Carrier Detect)
Выход CD (Carrier Detect)
20
DTE готов (DTR)
DCE готов (DSR)
22
Индикатор вызова (RI)
Индикатор вызова (RI)
Интерфейс V.24/RS-232 (9-контактный)
Разводка разъемов
10.17 Разводка разъемов
RJ-11 (6 контактов)
| Контакт | Назначение |
| 1 | Не используется (иногда земля) |
| 2 | Прием + |
| 3 | Передача + |
| 4 | Передача - |
| 5 | Прием - |
| 6 | Не используется (иногда земля) |
Телефонный разъем
Применение неэкранированных скрученных пар
| Использование | Ножки разъема | |||
| 1-2 | 3-6 | 4-5 | 7-8 | |
| Аналоговая передача голоса | - | - | TR/RX | - |
| 10BASE-T | TX | RX | - | - |
| 100BASE-TX | TX | RX | - | - |
| 100BASE-T4 | TX | RX | - | - |
| 100BASE-VG | BI | BI | BI | BI |
| ISDN | Питание | TX | RX | Питание |
| Token Ring | - | TX | RX | - |
| ATM-пользователь | TX | RX | ||
| ATM-разветвитель | RX | TX |
TX – передача; RX – прием; BI – двунаправленная передача/прием.
Сети управления и сбора данных в реальном масштабе времени (CAN)
4.1.4 Сети управления и сбора данных в реальном масштабе времени (CAN)
Стандарт CAN (Controller Area Network - http://www.kvaser.se/can/protocol/index.htm или http://www.omegas.co.uk/can/canworks.htm, а также www.can-cia.de) был разработан в Германии компанией Robert Bosch gmbh для автомобильной промышленности (1970 годы). Сеть CAN ориентирована на последовательные каналы связи, выполненные из скрученных пар проводов (или оптических волокон), стандарт определяет протоколы физического уровня и субуровеней MAC и LLC. Все узлы сети равноправны и подключаются к общему каналу. Уровни сигналов протоколом не нормированы. В CAN использована кодировка типа NRZ (Non Return to Xero). Для распознавания сигнатур начала (SOF) и конца (EOF) кадра используется бит-стафинг. В настоящее время в ЕС разрабатывается новый протокол для сети автомобиля, который бы позволял передачу высококачественного стерео аудио и видео сигналов, обеспечивал работу с мобильными телефонными сетями и Интернет. Предполагается, что пропускная способность протокола составит 45 Мбит/c
Высокая надежность и дешевизна сделала сети CAN привлекательными для промышленности и науки. Сеть предназначена для сбора информации и управления в реальном масштабе времени, но может быть использована и для других целей. Канал can реализует принцип множественного доступа с детектированием столкновений (CSMA/CD - Carrier Sense Multiple Access with Collision Detection, аналогично Ethernet). Сеть может содержать только один сегмент. В соответствии со стандартом ISO 11898 сеть способна работать при обрыве одного из проводов, при закоротке одного из проводов на шину питания или на землю. Скорость работы канала программируется и может достигать 1 Мбит/с. Недиструктивная схема арбитража позволяет сделать доступ к общему каналу существенно более эффективным, чем в случае Ethernet. В настоящее время действуют две версии стандарта с полями арбитража длиной в 11 бит (2.0a) и 29 бит (расширенная версия, 2.0b). Код арбитража одновременно является идентификатором кадра и задается на фазе инициализации сети. При одновременной попытке передачи кадров двумя узлами арбитраж выполняется побитно с использованием схемы проволочного “И”, при этом доминантным состоянием является логический “0”. Выигравший соревнование узел продолжает передачу, а проигравший ждет момента, когда канал освободится. Код-адрес объекта (узла CAN) задается с помощью переключателей на плате CAN при формировании сети.
Когда канал свободен, любой из подключенных узлов, может начать передачу. Кадры могут иметь переменную, но конечную длину. Формат информационного кадра сети CAN, содержащего семь полей, показан на Рисунок 4.1.4.1.
Схема взаимодействия различных частей COPS
Рисунок .1. Схема взаимодействия различных частей COPS.
На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP.
Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики.
PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером.
После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет.
Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента.
Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики.
Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет >PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным.
Наконец, допустимость ошибки ( fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive (“еще жив?”). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности.
Схема взаимодействия субъектов сделки
Рисунок .1. Схема взаимодействия субъектов сделки
1.2. Соображения безопасности
В системе CyberCash особое внимание уделяется вопросам безопасности. Система использует самые современные технологии шифрования и способна адаптировать любые новые схемы шифрования, которые появятся в будущем.
1.2.1. Аутентификация и идентификация личности
Аутентификация сообщений базируется на применении общедоступного ключа, как это делается в алгоритме RSA. Сервер CyberCash содержит записи общедоступных ключей для “персон” покупателя и продавца. Таким образом, можно аутентифицировать любую информацию подписанную покупателем или продавцом, вне зависимости от пути, которым эта информация попала на сервер. Соответствующий секретный ключ, который необходим для формирования цифровых подписей, хранится покупателем и продавцом и никогда не раскрывается. В программе клиента секретный ключ хранится в зашифрованном виде, защищенный парольной фразой.
В то время как истинная идентичность покупателя или продавца определяется парой ключей (общедоступный/секретный), для человека эти ключи запомнить слишком сложно (более 100 шестнадцатеричных цифр). Поэтому, пользовательский интерфейс использует короткие алфавитно-цифровые идентификаторы, выбранные пользователем, для того чтобы специфицировать себя. CyberCash добавляет контрольные цифры к запрошенному ADDS ID, с тем чтобы минимизировать вероятность неверного выбора персоны. IDU персоны является общедоступной информацией. Владение ID персоны без соответствующего секретного ключа в данной системе не предоставляет каких-либо преимуществ.
Отдельные лица или организации могут образовать одного или несколько CyberCash клиентов. Таким образом, отдельному лицу может соответствовать несколько несвязанных друг с другом CyberCash-клиентов, а разным лицам может соответствовать общий CyberCash-клиент. Этот подход предоставляет уровень конфиденциальности, согласующийся с Интернет и с требованиями финансовых операций. Однако, персона, желающая воспользоваться кредитной карточкой для покупки в рамках системы CyberCash должна сначала идентифицировать себя, как это требует организация, выпустившая эту карту.
Контроль над персоной CyberCash доступен только субъекту, владеющему секретным ключом данной персоны. В то же время, для каждой CyberCash-персоны предусмотрена аварийная парольная фраза блокировки. По получении этой парольной фразы, даже в случае использования небезопасного канала, такого как телефон или обычная электронная почта, CyberCash отложит любые операции для данной CyberCash-персоны. Эта парольная фраза может быть записана отдельно и храниться менее строго по сравнению с секретным ключом, так как она не может быть использована для передачи денег. Это обеспечивает некоторую защиту против потери секретного ключа или пароля, с помощью которого он был зашифрован.
1.2.2. Конфиденциальность
Сообщения шифрования работают со стандартом DES (Digital Encryption Standard), обычно используемым в настоящее время при осуществлении электронных платежей. Планируется применение супершифрования (т.e., более чем одноуровневое шифрование) особо чувствительной информации, такой как PIN-коды, и обрабатывать их так, что они никогда не появляются в виде простого текста, за исключением короткого времени перед поступлением на специальное оборудование внутри сервера перед перекодировкой с помощью нового ключа.
Обработка платежа через кредитную карточку посредством системы CyberCash организована так, что продавец никогда не узнает номер кредитной карточки покупателя, если только банк не решит выдать ему эту информацию. Кроме того, сервер не хранит у себя в памяти эту информацию постоянно. Номер кредитной карточки присутствует там только во время непосредственного выполнения платежной операции.
1.3. Работа с кредитной картой
При использовании системы CyberCash для транзакций с применением кредитной карточки, покупателю, решившему произвести покупку, достаточно кликнуть на клавише CyberCash "PAY" панели продавца. Продавец посылает покупателю счет, который содержит информацию о покупке, отображаемую на экране дисплея покупателя. (Смотри описание сообщения PR1). Покупатель добавляет номер своей кредитной карточки и другую информацию путем выбора соответствующих пунктов из списка кредитных карт, зарегистрированных на его CyberCash-персону.
Вся эта информация снабжается электронной подписью покупателя, реализуемой посредством программы СyberCash, шифруется, и передается продавцу вместе с хэш-кодом счета. (Смотри описание сообщения CH1.)
При получении этого сообщения, продавец добавляет туда информацию авторизации, которая шифруется, снабжается электронной подписью продавца и пересылается серверу CyberCash. (Смотри описание сообщений CM1 & CM2). Сервер CyberCash может аутентифицировать все подписи для подтверждения того, что покупатель и продавец согласились с корректностью счета и правильностью суммы стоимости сделки. Сервер CyberCash переадресует соответствующую информацию в банк, сопровождая ее запросом на производство платежа в пользу продавца, включая его авторизацию. Банк дешифрует и обрабатывает полученную информацию, после чего осуществляет соответствующую операцию с кредитной карточкой. Отклик банка передается серверу CyberCash, который присылает продавцу электронную квитанцию (смотри описание сообщения CM6) часть которой продавец переадресует покупателю (смотри описание сообщения CH2). На этом транзакция завершается.
2. Формат заголовка общего сообщения
Версия 0.8 внешнего формата для кодирования сообщений CyberCash описана ниже. Сообщения CyberCash представляют собой стилизованные документы для передачи финансовой информации по Интернет.
В то время как существует множество схем передачи данных по Интернет (HTTP, SMTP и прочие), каждая из них привязывается к определенному механизму передачи. Так как сообщения CyberCash могут передаваться через любую из названных сред (да и через некоторые не названные), должна быть обеспечена независимость от механизма обмена.
2.1. Формат сообщения
Сообщения CyberCash состоят из следующих компонентов:
Заголовок – определяет начало сообщения CyberCash и включает информацию о версии.
Прозрачная часть – содержит данные, которые не являются конфиденциальными.
Невидимые части – содержат финансовую информацию сообщения и защищены от разглашения или искажения.
Невидимая часть может отсутствовать в некоторых сообщениях. Если она присутствует, она обеспечивает защиту от искажения прозрачной части.
Завершающая секция – определяет конец сообщения CyberCash и содержит контрольный код, который позволяет судить о том, что сообщение дошло без искажений. Заметим, что этот код призван детектировать случайные искажения сообщения.
В CyberCash сообщении запрещены нулевые символы (значение нуль) или символы, характеризуемые восемью битами. "Двоичные" значения, которые могут содержать такие коды, представляются с помощью base64, описанного в документе RFC-1521.
2.2. Детали формата
Заголовок содержит одну строку, которая выглядит следующим образом
$$-CyberCash-0.8-$$
или
$$-CyberCash-1.2.3-Extra-$$
Он содержит в себе несколько полей, разделенных символом минус "-"
| 1. | "$$" - литерная строка со значением $ в колонке 1. |
| 2. | "CyberCash" - литерная строка (регистр не существенен) |
| 3. | x.y или x.y.z – номер версии формата сообщения. x – первичный номер версии. y – номер субверсии. z, если присутствует, номер субсубверсии. |
| 4. | "Extra" – опционная дополнительная алфавитно-цифровая строка. |
| 5. | "$$" - литерная строка. |
Строка "Extra" используется в безопасной среде так чтобы один компонент мог что-то сообщить другому без существенных издержек. Например, Firewall-сервер может записать здесь "HTTP" или "SMTP", прежде чем переадресовывать сообщение базовому серверу в пределах периметра Firewall.
2.3. Части тела
Части тела сообщения (как открытые, так и скрытые) состоят из пар атрибут-значение в формате, который напоминает формат стандартного заголовка почтового сообщения (RFC-822). Однако здесь имеются некоторые трудности.
Имена атрибутов начинаются с и в основном состоят из букв и лишь иногда содержат в конце дефис, за которым следует число. Такое завершающее число используется, когда имеется индексированный вектор значений. Имена атрибутов часто называют метками (label).
Если метка завершается ":", тогда производится обработка согласно требованиям документа RFC-822. Когда важно наличие завершающего пробела (SP, TAB, LF), все лидирующие пробелы на последующих строках удаляются. Такие строки укорачиваются до 64 символов, не считая завершающего символа.
Однако если метка завершается ";", это указывает на поле произвольной формы, где символы начала новой строки и любые лидирующие пробелы после начального пробела, который отмечает продолжение строки, являются существенными. Такие строки не должны разрываться за исключением того, что для исключения проблем обработки, они принудительно ограничиваются 200 символами. Пустые строки игнорируются и не означают изменения режима обработки строк.
Другим способом решения проблемы может быть следующее: после обнаружения начальной последовательности $$ в стартовой строке, вы можете обрабатывать любые последующие строки в соответствии с первым символом. Если он является алфавитно-цифровым, это новая метка, которая должна завершаться символами ":" или ";", а это указывает на новую пару метка-значение. Если он является пробелом (SP, TAB, LF или CR), это указывает на продолжение предыдущей строки метки. (Как конкретно обрабатывается продолжение, зависит от завершающего символа метки). Если это "$", то строка должна быть оконечной строкой сообщения. Если это #, тогда это строка комментария и должна игнорироваться. Другие начальные символы не определены. На данный момент программные продукты CyberCash не поддерживают комментариев.
2.4. Открытая часть
Открытая часть сообщения включает любые текстовые данные, связанные с финансовой транзакцией, а также информацию, необходимую CyberCash и другим, для того чтобы дешифровать скрытую часть.
Она всегда включает поле транзакции, которое представляет собой номер транзакции, сформированный источником запроса, это поле копируется в отклик. Открытая часть всегда включает поле даты, которое представляет собой местную дату и время, переносимые без изменений в соответствующие поля отклика. Во всех случаях кроме начальной регистрации открытая часть содержит ID персоны источника запроса.
В сообщениях, подготовленных для сервера, существует киберключ (cyberkey:) поле, которое идентифицирует, какой из общедоступных ключей сервера был использован для шифрования ключа сессии.
2.5. Скрытая часть
Скрытая часть сообщения состоит из одного блока символов, представленных в кодировке base64 (смотри RFC-1521). Данные в закрытой секции всегда сначала шифруются, а затем кодируются.
Скрытая часть сообщения выделяется метками "opaque" или "merchant-opaque" в зависимости оттого, клиент или продавец зашифровал эти данные.
Для сообщений, приходящих на сервер, скрытые данные шифруются согласно алгоритму DES CBC с помощью случайного ключа транзакции, при этом ключ DES шифруется посредством алгоритма RSA с привлечением одного из общедоступных ключей сервера. Зашифрованный с помощью RSA ключ DES размещается в первой части поля, закодированного с помощью base64. Соответствующий исходящий отклик сервера может быть зашифрован с помощью DES с применением ключа транзакции. В этом случае достаточно открытых данных, чтобы идентифицировать транзакцию, а покупатель и продавец имеют ключ транзакции, полученный вместе с входным сообщением.
Подпись необязательна в скрытой части сообщения отклика. Знание ключа транзакции является достаточным для аутентификации. Для формирования отклика необходимо знать секретный ключ сервера, чтобы заполучить ключ транзакции. Предполагается, что если кто-то исказил скрытую часть отклика, вероятность того, что это будет незамечено пренебрежимо мала. Кто-то может повредить открытую часть сообщения, но это не окажет никакого воздействие, так как все сообщение будет просто отвергнуто.
2.6. Завершающая часть
Завершающая секция служит для выделения конца сообщения. Она содержит несколько полей разделенных "-".
| 1. | "$$" - строка литералов. |
| 2. | "CyberCash" - строка литералов (не чувствительна к регистру). |
| 3. | "End" - строка литералов (не чувствительна к регистру). |
| 4. | Контрольная сумма передачи. |
| 5. | "$$" – строка литералов. |
2.7. Примеры сообщений
Простое сообщение от клиента:
$$-CyberCash-0.8-$$
id: DONALD-69
transaction: 918273645
date: 199512250102
cyberkey:CC1001
opaque:
GpOJvDpLH62z+eZlbVkhZJXtTneZH32Qj4T4IwJqv6kjAeMRZw6nR4f0OhvbTFfPm+GG
aXmoxyUlwVnFkYcOyTbSOidqrwOjnAwLEVGJ/wa4ciKKI2PsNPA4sThpV2leFp2Vmkm4
elmZdS0Qe350g6OPrkC7TKpqQKHjzczRRytWbFvE+zSi44wMF/ngzmiVsUCW01FXc8T9
EB8KjHEzVSRfZDn+lP/c1nTLTwPrQ0DYiN1lGy9nwM1ImXifijHR19LZIHlRXy8=
$$-End-CyberCash-End-jkn38fD3+/DFDF3434mn10==-$$
Сообщение от продавца:
$$-CyberCash-a.b.c-extra-$$
merchant-ccid: acme-69
merchant-date: 19951231115959
merchant-transaction: 987654321
label: value
labelx: multiple line
value...
# Комментарий
# еще одна строка комментария
label; text with a real
multi-line
format !
merchant-cyberkey: CC1001
merchant-opaque:
C1Q96lU7n9snKN5nv+1SWpDZumJPJY+QNXGAm3SPgB/dlXlTDHwYJ4HDWKZMat+VIJ8y
/iomz6/+LgX+Dn0smoAge7W+ESJ6d6Ge3kRAQKVCSpbOVLXF6E7mshlyXgQYmtwIVN2J
66fJMQpo31ErrdPVdtq6MufynN8rJyJtu8xSNolXlqIYNQy5G2I3XCc6D3UnSErPx1VJ
6cbwjLuIHHv58Nk+xxt/FyW7yAMwUb9YNcmOj//6Ru0NiOA9P/IiWczDe2mJRK1uqVpC
sDrWehG/UbFTPD26trlYRnnY
$$-CyberCash-End-kchfiZ5WAUlpk1/v1ogwuQ==-$$
Системы шифрования
6.4 Системы шифрования
Проблема сокрытия содержания послания при его транспортировке волновала людей с древних пор. Известно, что еще Цезарь (100-44 годы до нашей эры) при переписке использовал шифр, получивший его имя. В 1518 году Джоанес Тритемиус написал первую книгу по криптографии, где впервые были описаны многоалфавитные подстановочные шифры. Лишь в 1918 году во время первой мировой войны в Германии была применена шифровальная система ADFGVX. Позднее в 1933-45 годах в Германии была разработана и применена первая шифровальная машина (на этом принципе работает система crypt в UNIX). Мощное развитие криптография получила в период второй мировой войны. С этой шифровальной машиной связан и первый успех в области вскрытия сложных шифров.
Чаще всего шифруются тексты документов, но в последнее время шифрованию подвергаются и изображения, голосовые данные и даже тексты программ.
Шифрование предполагает преобразование исходного текста Т с использованием ключа К в зашифрованный текст t. Симметричные криптосистемы для шифрования и дешифрования используется один и тот же ключ К. Появившиеся в последние годы системы с открытым ключом, осуществляют шифрование с помощью общедоступного ключа, для дешифрования в этом случае необходим секретный ключ, который порождается совместно с открытым. Как шифрование, так и дешифрование может реализоваться программно или аппаратно. При этом должны выполняться определенные требования:
Знание использованного алгоритма не должно снижать надежность шифрования.
Длина зашифрованного текста должна быть равна длине исходного открытого текста (это требование относится к числу желательных и выполняется не всегда).
Зашифрованный текст не может быть прочтен без знания ключа.
Каждый ключ из многообразия ключей должен обеспечивать достаточную надежность.
Изменение длины ключа не должно приводить к изменению алгоритма шифрования.
Если известен зашифрованный и открытый текст сообщения, то число операций, необходимых для определения ключа, не должно быть меньше полного числа возможных ключей.
Дешифрование путем перебора всех возможных ключей должно выходить далеко за пределы возможностей современных ЭВМ.
Если при шифровании в текст вводятся дополнительные биты, то алгоритм их внесения должен быть надежно скрыт.
Не должно быть легко устанавливаемой зависимости между последовательно используемыми ключами.
Алгоритм может быть реализован аппаратно.
В симметричных криптосистемах могут использоваться одно- или многоалфавитные подстановки (например, одно-алфавитная подстановка Цезаря), при этом производится замена символов исходного текста на другие с использованием достаточно сложных алгоритмов. Многоалфавитные подстановки несравненно более надежны. К числу простых методов шифрования относится способ перестановок символов исходного текста (этот метод эффективен только лишь при достаточно большой длине исходного текста). Множество перестановок символов для текста из N символов равно N!, что до какой-то степени гарантирует надежность процедуры. Несколько большую надежность предлагает метод гаммирования, когда на исходный текст накладывается псевдослучайная последовательность бит, генерируемая на основе ключа шифрования, например, с использованием операции исключающего ИЛИ. Обратное преобразование (дешифрование) выполняется генерацией точно такой же псевдослучайной последовательности и наложением ее на зашифрованной текст. Гаммирование уязвимо для случая, когда злоумышленнику становится известен фрагмент исходного текста. В этих обстоятельствах он без труда восстановит фрагмент псевдослучайной последовательности, а по нему и всю последовательность. Так если достаточно большое число сообщений начинается со слов "Секретно", а в конце ставится дата сообщения, расшифровка становится вопросом времени и терпения.
Ключ может быть одноразового и многоразового использования. Одноразовый ключ достаточно большой длины (или бесконечный) может обеспечить сколь угодно высокую надежность, но его использование создает неудобства, связанные с его транспортировкой (ключ должен быть как-то доставлен получателю зашифрованного послания).В табличке 6.4.1 приведен пример использования такого вида ключа.
Содержимое сообщения
3. Содержимое сообщения
Объект Integrity, если он включен, должен всегда быть последним объектом сообщения. Если необходимо обеспечить безопасность, а полученное сообщение не содержит корректного объекта Integrity, получатель должен послать сообщение Client-Close для Client-Type=0, определяющее соответствующий код ошибки.
3.1. Запрос (REQ) PEP -> PDP
PEP устанавливает дескриптор состояния запроса клиента, для которого PDP может обеспечить нужное состояние. Удаленный PDP затем использует дескриптор, для ссылки на информацию и решения, переданные по TCP-каналу конкретному PEP для данного типа клиента.
Раз для нового запроса определен дескриптор, любые последующие модификации запроса могут производиться с помощью сообщения REQ, специфицирующего инсталлированный дескриптор. PEP ответственен за уведомление PDP всякий раз, когда изменения его локального состояния отслеживает состояния PEP. Формат сообщения-запроса имеет вид:
<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LPDPDecision(s)> ::= <LPDPDecision> | <LPDPDecision(s)> <LPDPDecision>
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
Объект context используется для определения контекста, в рамках которого следует интерпретировать все другие объекты. Он также служит для определения вида решения, которое должен послать сервер, определяющий политику. Это решение может относиться к управлению доступом, размещению ресурсов, переадресации или замене объектов, а также в конфигурации.
Объекты interface используются, чтобы определить соответствующий интерфейс, через который было получено или предполагается послать протокольное сообщение.
Они обычно используются, если клиент запрашивает конфигурационные данные для какого-то конкретного интерфейса.
ClientSI является информационным объектом клиента и содержит в себе специфическую информацию, для которой должно быть принято политическое решение. В случае конфигурации именованное ClientSI может включать в себя именованные данные о модуле, интерфейсе или функции, которые следует конфигурировать. Порядок следования для кратных ClientSI не существенен.
Наконец, объект LPDPDecision содержит информацию согласно локальному решению, принятому LPDP.
Сообщения Request с неверным форматом должны вызывать сообщения Decision PDP с соответствующим кодом ошибки.
3.2. Решение (DEC) PDP -> PEP
PDP реагирует посредством REQ с сообщением DEC, которое включает в себя ассоциированный дескриптор клиента и один или более объектов решения, сгруппированные относительно пар типов объектов Context и флагов решения (Decision Flags). Если имела место протокольная ошибка, вместо этого присылается объект ошибки.
Требуется, чтобы первое сообщение решения для нового или актуализованного запроса имело флаг требования в заголовке COPS равный 1. Это исключает отслеживание того, какому модифицированному запросу соответствует конкретное решение (т.е., запрос посылается повторно для того же самого дескриптора). Важно, чтобы для данного дескриптора существовало одно предпочтительное решение, соответствующее определенному запросу. Это по существу означает, что PEP не должен посылать более одного REQ (для данного дескриптора), прежде чем он получит соответствующий DEC с заданным набором флагов сообщения. PDP должен всегда посылать решения для запросов в порядке их получения и каждому запросу должно соответствовать решение.
Чтобы избежать тупиков, PEP может делать выдержку после посылки запроса, пока не будет получено решение. Он должен аннулировать дескриптор, для которого время выдержки истекло, а решение не получено, новая попытка может быть осуществлена с новым дескриптором.
Формат сообщения Decision представлен ниже:
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
Сообщение Decision может включать либо объект Error, либо один или более объекта context и соответствующего объекта decision. О проблемах протокола COPS сообщается в объекте Error. Объект Decision зависит от контекста и типа клиента.
3.3. Состояние отчета (RPT) PEP -> PDP
Сообщение RPT используется PEP, чтобы сообщить PDP об успехе или неудаче реализации решения PDP, или уведомить об изменении состояния. Report-Type специфицирует вид отчета и опционный ClientSI и может содержать дополнительную информацию для типа клиента.
Для каждого сообщения DEC, содержащего контекст конфигурации, которое получено PEP, он должен сформировать соответствующее сообщение-отчет о состоянии с флагом запрошенного сообщения (Solicited Message flag), который указывает на то успешно или нет реализовано конфигурационное решение. RPT-сообщения, запрошенные решением для данного дескриптора клиента, должны устанавливать флаг запрошенного сообщения и должны быть посланы в том же порядке, к каком получены соответствующие сообщения решения. Не должно быть более одного сообщения отчета о состоянии, соответствующему флагу-требованию, установленному для заданного решения.
Состояние отчета может также использоваться для реализации периодических модификаций специфической информации клиента для целей мониторирования состояния, зависящего от типа клиента. В таких случаях тип аккоунтинг-отчета должен специфицироваться с помощью соответствующего информационного объекта клиента.
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
3.4. Состояние аннулирования запроса DRQ (Delete Request State) PEP -> PDP
При посылке это сообщение PEP указывает, что удаленный PDP, чье состояние идентифицируется дескриптором клиента, более недоступно или неверно. Эта информация будет затем использоваться удаленным PDP для инициации соответствующих служебных операций. Объект кода причины интерпретируется с учетом типа клиента и определяет причину аннулирования. Формат сообщения Delete Request State представлен ниже:
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
Важно, что когда состояние запроса окончательно удаляется из PEP, сообщение DRQ для состояния запроса посылается PDP, так что соответствующее состояние может быть также удалено в PDP. Состояния запроса, не удаленные явно PEP, будут поддерживаться PDP, пока не будет закрыта сессия или пока не будет разорвано соединение.
Сообщения Decision с неверным форматом должны запустить DRQ, специфицирующее соответствующий код ошибки (Bad Message Format) и любое ассоциированное состояние PEP должно быть либо удалено, либо повторно запрошено. Если Decision содержится в неизвестном объекте COPS Decision, PEP должен аннулировать его запрос, специфицирующий код причины объекта COPS Unknown, так как PEP будет неспособен работать с информацией, содержащейся в неизвестном объекте. В любом случае, после отправки DRQ, PEP может попытаться послать соответствующий запрос повторно.
3.5. Запрос состояния синхронизации (SSQ) PDP -> PEP
Сообщение запроса состояния синхронизации имеет следующий формат:
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
Это сообщение указывает, что удаленный PDP хочет, чтобы клиент повторно прислал свое состояние. Если имеется опционный дескриптор клиента, только состояние, ассоциированное с этим дескриптором, синхронизуется. Если PEP не распознает запрошенный дескриптор, он должен немедленно послать сообщение DRQ PDP для дескриптора, специфицированного в SSQ-сообщении. Если в SSQ-сообщении не специфицировано никакого дескриптора, все активные состояния клиента должны быть синхронизованы с PDP.
Клиент выполняет синхронизацию состояний путем повторной посылки запросов специфицированного типа клиента для существующего состояния PEP. Когда синхронизация завершена, PEP должен направить завершающее сообщение синхронизованного состояния в PDP.
3.6. Client-Open (OPN) PEP -> PDP
Сообщение Client-Open может использоваться PEP, для того чтобы специфицировать PDP типы клиента, которые PEP может поддерживать, и последний PDP, с которым PEP устанавливал соединение при данном типе клиента. Сообщение Client-Open может быть послано PDP в любое время, допускаются множественные сообщения Client-Open для одного и того же типа клиента (в случае общих изменений состояния).
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
PEPID является символическим именем с переменной длиной, которое однозначно идентифицирует клиента для PDP (смотри раздел 2.2.11).
Именованный объект ClientSI может быть включен для передачи дополнительной глобальной информации о PEP к PDP, когда необходимо (как это специфицировано в соответствующем расширении документа для заданного типа клиента).
PEP может также предоставить объект Last PDP Address в его сообщении Client-Open, специфицирующий последний PDP (для заданного типа клиента), для которого он кэширует решения с момента последней перезагрузки (reboot). PDP может использовать эту информацию, чтобы определить подходящий режим синхронизации (смотри раздел 2.5).
Если PDP получает сообщение Client-Open с неверным форматом, он должен сформировать сообщение Client-Close, специфицирующее соответствующий код ошибки.
3.7. Client-Accept (CAT) PDP -> PEP
Сообщение Client-Accept используется для позитивного отклика на сообщение Client-Open. Это сообщение пришлет PEP объект таймера, заключающий в себе максимальный временной интервал между сообщениями keep-alive. Опционно, если нужно, может быть добавлен таймер, специфицирующий минимально допустимый интервал между аккоунтинг-сообщениями-отчетами.
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
Если PDP отказывает клиенту, он пошлет сообщение Client-Close.
Таймер KA соответствует максимальному приемлемому времени между сообщениями, посылаемыми от PDP к PEP. Время выдержки таймера определяется PDP и измеряется в секундах. Значение времени выдержки 0 означает, что не требуется верификации вторичного соединения.
Опционный таймер ACCT позволяет PDP проинформировать PEP о том, что периодические аккоунтинг-отчеты не должны превышать специфицированный временной интервал для каждого дескриптора клиента. Это позволяет PDP контролировать частоту, с которой PEP посылает аккоунтинг-отчеты. Вообще, сообщения Report типа аккоунтинг посылаются PDP, когда определен соответствующий PEP. Аккоунтинг-таймер по большей части используется PDP, чтобы поддерживать частоту актуализаций на приемлемом уровне (т.e. предотвращать перегрузку PEP под действием аккоунтинг-отчетов от PDP). Не включение этого объекта в сообщение означает, что не существует для PDP каких-либо ограничений на частоту аккоунтинг-актуализации.
Если PEP получает сообщение Client-Accept с неверным форматом, он должен сгенерировать сообщение Client-Close, где специфицирован соответствующий код ошибки.
3.8. Client-Close (CC) PEP -> PDP, PDP -> PEP
Сообщение Client-Close может быть послано как PDP, так и PEP с тем, чтобы обратить внимание противоположной стороны на то, что указанный тип клиента более не поддерживается.
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
Объект Error включен, чтобы описать причину закрытия (например, запрошенный тип клиента не поддерживается удаленным PDP или отказ в работе клиента).
PDP может опционно включать PDP-объект адреса перенаправления, для того чтобы проинформировать PEP об альтернативном PDP, который он должен использовать для типа клиента, специфицированного в общем заголовке.
3.9. Keep-Alive (KA) PEP -> PDP, PDP -> PEP
Сообщение keep-alive должно передаваться PEP в пределах периода, определенного минимальным значением выдержки KA-таймера, которая определяется в сообщениях CAT для данного соединения. Сообщение KA должно генерироваться случайным образом в пределах между 1/4 и 3/4 этого минимального интервала KA-таймера. Когда PDP получает сообщение keep-alive от PEP, он должен откликнуться таким же сообщением, адресованным PEP. Это сообщение обеспечивает подтверждение для каждой из сторон того, что соединение функционирует даже в случае, когда нет никаких других сообщений.
Тип клиента в заголовке должен всегда быть установлен равным 0, так как KA используется для верификации соединения (а не для верификации сессии клиента).
<Keep-Alive> ::= <Common Header>
[<Integrity>]
Как клиент, так и сервер могут предполагать, что TCP-соединение недостаточно для типа клиента с минимальным значением времени (специфицировано в сообщении CAT), если не зарегистрировано никакой телекоммуникационной активности в течение периода времени, превосходящего выдержку таймера. При этом PEP предполагает, что удаленный PDP или соединение не работает и PEP должен пытаться использовать альтернативный/запасной PDP.
3.10. Завершение состояния синхронизации (SSC) PEP -> PDP
Сообщение завершения состояния синхронизации (Synchronize State Complete) посылается от PEP к PDP, после того как PDP пошлет запрос синхронизации состояния PEP и PEP завершит синхронизацию. Полезно, чтобы PDP знал, когда все старые состояния клиента успешно повторно запрошены и, таким образом, PEP и PDP полностью синхронизованы. Объект дескриптора клиента (Client Handle) следует включать только тогда, когда соответствующее сообщение синхронизации состояний (Synchronize State Message) непосредственно ссылается на определенный дескриптор (handle).
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
Соображения безопасности
5. Соображения безопасности
Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP.
Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров.
Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности.
TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности.
Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS.
Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS].
Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу “первым пришел – первым обслужен”, как это определено в [IANA-CONSIDERATIONS].
6. Соображения безопасности
Система CyberCash для работы с кредитными картами версии 0.8 предоставляет достаточную защиту платежных сообщений, как это описано в разделах 1.2, 2.2.4 и 2.2.5. Система не обеспечивает достаточной защиты от нечестного продавца (здесь вне конкуренции протокол SET). Следует не выпускать из внимания ЭВМ, на которых работают различные части системы, в противном случае нельзя добиться приемлемого уровня безопасности.
Ссылки
|
[ISO 4217] |
Codes for the representation of currencies and funds |
|
[ISO 8583] |
Financial transaction card originated messages - Interchange message specifications, 1993-12-15. |
|
[RFC-822] |
Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC- 822, UDEL, August 1982. |
|
[RFC-1521] |
Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC- 1521, Bellcore, Innosoft, September 1993. |
|
[RFC-1766] |
Alvestrand, H., "Tags for the Identification of Languages", UNINETT, March 1995. |
Ссылки
6. Ссылки
|
[RSVP] |
Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC-2205, September 1997. |
|
[WRK] |
Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000. |
|
[SRVLOC] |
Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC-2608, June 1999. |
|
[IPSEC] |
Atkinson, R., "Security Architecture for the Internet Protocol", RFC-2401, August 1995. |
|
[HMAC] |
Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. |
|
[MD5] |
Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992. |
|
[RSVPPR] |
Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC-2209, September 1997. |
|
[TLS] |
Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999. |
|
[IANA] |
http://www.isi.edu/in-notes/iana/assignments/port-numbers |
|
[IANA-CONSIDERATIONS] |
Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998 |
Стандартный информационный кадр CAN
Рисунок 4.1.4.1 Стандартный информационный кадр 1 2.0a CAN
Кадр начинается с доминантного бита начала кадра (логический нуль, SOF - start of frame). Далее следует поле арбитража (идентификатор кадра), содержащее 11 бит (эти разряды носят имена id-28, ..., id-18) и завершающееся битом RTR (remote transmission request) удаленного запроса передачи. В информационном кадре RTR=0, для кадра запроса RTR=1. Семь наиболее значимых бит id-28 - id-22 не должны быть никогда все одновременно равными 1. Первым передается бит id28. Доминантные биты r0 и r1 (=0) зарезервированы для будущего использования (в некоторых спецификациях бит r1 называется IDE и относится для стандартных кадров к полю управления). Поле DLC (Data Length Code; биты поля имеют имена dcl3 - dcl0) несет в себе код длины поля данных в байтах. Поле данных, размещенное вслед за ним, может иметь переменную длину или вообще отсутствовать. CRC - циклическая контрольная сумма. В качестве образующего полинома при вычислении CRC используется x15 + x14 + x10 + x8 + x7 + x4 + x3 + 1. Формально, следующий за контрольной суммой бит-разграничитель (=1) принадлежит полю CRC. Поле отклика (ack) содержит два бита, первый из которых первоначально имеет уровень 1, а узлы получатели меняют его значение на доминантное (логический 0). Бит используется для сообщения о корректности контрольной суммы. Второй бит поля всегда имеет уровень логической 1. Завершающее поле EOF (end of frame) содержит семь единичных бит. За этим полем следует поле-заполнитель (INT) из трех единичных бит, после него может следовать очередной кадр. Формат расширенного информационного кадра сети can показан на Рисунок 4.1.4.2.
с одним или более устройств
Таблица 3.1.1
| Стандартный кабель | Широкополосный | |
| Максимальная длина канала | 2 км | 10 – 15 км |
| Скорость передачи данных | 1 – 50 Мбит/с | 100 – 140 Мбит/с |
| Режим передачи | полудуплекс | дуплекс |
| Ослабление влияния электромагнитных и радиочастотных наводок | 50 дБ | 85 дБ |
| Число подключений | < 50 устройств | 1500 каналов с одним или более устройств на канал |
| Доступ к каналу | CSMA/CD | FDM/FSK |
На Рисунок 3.1.2 показана зависимость ослабления кабеля (внешний диаметр 0,95 см) от частоты передаваемого сигнала.
При диагностировании сетей не всегда под руками может оказаться настоящий сетевой тестер типа WaveTek, и часто приходится довольствоваться обычным авометром. В этом случае может оказаться полезной таблица 3.1.2, где приведены удельные сопротивления используемых сетевых кабелей. Произведя измерение сопротивления сегмента, вы можете оценить его длину.
и поперечное” контрольное суммирование предаваемого
Таблица 2.8.2
| Число полезных бит М | Число избыточных бит (n-m) | ||
| 6 | 7 | 8 | |
| 32 | 48% | 74% | 89% |
| 40 | 36% | 68% | 84% |
| 48 | 23% | 62% | 81% |
Другой блочный метод предполагает “продольное и поперечное” контрольное суммирование предаваемого блока. Блок при этом представляется в виде N строк и M столбцов. Вычисляется биты четности для всех строк и всех столбцов, в результате получается два кода, соответственно длиной N и M бит. На принимающей стороне биты четности для строк и столбцов вычисляются повторно и сравниваются с присланными. При выявлении отличия в бите i кода битов четности строк и бите j – кода столбцов, позиция неверного бита оказывается определенной (i,j). Понятно, что если выявится два и более неверных битов в контрольных кодах строк и столбцов, задача коррекции становится неразрешимой. Уязвим этот метод и для двойных ошибок, когда сбой был, а контрольные коды остались корректными.
Применение кодов свертки позволяют уменьшить вероятность ошибок при обмене, даже если число ошибок при передаче блока данных больше 1.
Линейные блочные коды
Блочный код определяется, как набор возможных кодов, который получается из последовательности бит, составляющих сообщение. Например, если мы имеем К бит, то имеется 2К возможных сообщений и такое же число кодов, которые могут быть получены из этих сообщений. Набор этих кодов представляет собой блочный код. Линейные коды получаются в результате перемножения сообщения М на порождающую матрицу G[IA]. Каждой порождающей матрице ставится в соответствие матрица проверки четности (n-k)*n. Эта матрица позволяет исправлять ошибки в полученных сообщениях путем вычисления синдрома. Матрица проверки четности находится из матрицы идентичности i и транспонированной матрицы А. G[IA] ==> H[ATI].
| I | A | AT
[ZEBR_TAG_/table> Если ТаблицаТаблица 6.4.1.
Зашифрованный текст получается здесь из исходного добавлением значения очередного кода ключа (сложение может быть заменено вычитанием или операцией исключающее ИЛИ). Исходный текст в данном случае невозможно восстановить без знания ключа. Примером шифрования с использованием секретного ключа является метод Видженера (Vigenere; www.massconfusion.com/crypto/lecture/method6.shtml), относящийся к числу много алфавитных подстановок. Здесь берется небольшое целое число m и алфавит после каждой символьной подстановки сдвигается на m символов. Например, для m=4 1. abcdefghijklmnopqrstuvwxyz ghijklmnopqrstuvwxyzabcdef 2. opqrstuvwxyzabcdefghijklmn 3. lmnopqrstuvwxyzabcdefghijk 4. fghijklmnopqrstuvwxyzabcde Ключ = golf (смотри левую вертикальную колонку символов). Исходный текст разбивается на группы по m символов (в рассмотренном случае по 4). Для каждой группы первый символ заменяется соответствующей буквой первого алфавита, вторая – из второго и т.д. Например, фраза "get me out of here please" будет преобразована следующим образом: getm eout ofhe repl ease mser kcfy utsj xsaq kohj. Наибольшее распространение в последнее время получило блочное шифрование, где последовательность процедур воздействует на блок входного текста. Одним из наиболее известных таких методов стал DES (Data Encryption Standard), который работает с блоками данных по 64 байта (1998 год). Существует четыре режима работы:
Из-за того, что алгоритм DES в настоящее время представляется устаревшим и не обеспечивает достаточной надежности, довольно часто исходный текст последовательно шифруется трижды с помощью различных ключей. Шифрование и дешифрование базируются на использовании ключей. ТаблицаТаблица 3.1.7.
Подводя итоги можно сказать, что при расстояниях до 100 метров с успехом могут использоваться скрученные пары и коаксиальные кабели, обеспечивая полосу пропускания до 150 Мбит/с, при больших расстояниях или более высоких частотах передачи оптоволоконный кабель предпочтительнее. Следует заметить, что работа с кабелями предполагает необходимость доступа к системе канализации (иногда это требует специальных лицензий; а там часто размещаются усилители-повторители). Кабельное хозяйство требует обслуживания. В этом отношении радиоканалы предпочтительнее, ведь случаев коррозии электромагнитных волн не зарегистрировано, да и крысы их не грызут. Справедливости ради отмечу, что здесь серьезную угрозу представляют корыстолюбивые бюрократы, ответственные за выдачу лицензий, а они пострашнее крыс. |
цветов, их имен и кодов
| Образец | Код | Название CSS | Название | Образец | Код | Название CSS | Название |
| #F0F8FF | aliceblue | блекло-голубой | #A52A2A | brown | коричневый | ||
| #FAEBD7 | antiquewhite | античный белый | #DEB887 | burlywood | старого дерева | ||
| #00FFFF | aqua | синий | #5F9EA0 | cadetblue | блеклый серо-голубой | ||
| #7FFF00 | chartreuse | фисташковый | #FF7F50 | coral | коралловый | ||
| #F5F5DC | azure | лазурь | #D2691E | chocolate | шоколадный | ||
| #F5F5DC | beige | бежевый | #6495ED | cornflowerblue | васильковый | ||
| #FFE4C4 | bisque | бисквитный | #000000 | black | черный | ||
| #FFF8DC | cornsilk | темно-зеленый | #DC143C | crimson | малиновый | ||
| #FFEBCD | blanchedalmond | светло-кремовый | #00FFFF | cyan | циан | ||
| #0000FF | blue | голубой | #00008B | darkblue | темно-голубой | ||
| #8A2BE2 | blueviolet | светло-фиолетовый | #008B8B | darkcyan | темный циан | ||
| #B8860B | darkgoldenrot | темный красно-золотой | #A9A9A | darkgray | темно-серый | ||
| #006400 | darkgreen | темно-зеленый | #BDB76B | darkkhaki | темный хаки | ||
| #8B008B | darkmagenta | темный фуксин | #556B2F | darkolivegreen | темно-оливковый | ||
| #FF8C00 | darkorange | темно-оранжевый | #9932CC | darkorchid | темно-орхидейный | ||
| #8B0000 | darkred | темно-красный | #E9967A | darksalmon | темно-оранжево-розовый | ||
| #8FBC8F | darkseagreen | темный морской волны | #483D8B | darkslateblue | темный сине-серый | ||
| #2F4F4F | darkslategray | темный сине-серый | #00CED1 | darkturqueise | темно-бирюзовый | ||
| #9400D3 | darkviolet | темно-фиолетовый | #FF1493 | deeppink | темно-розовый | ||
| #00BFFF | deepskyblue | темный небесно-голубой | #696969 | dimgray | тускло-серый | ||
| #1E90FF | dodgerblue | тускло-васильковый | #B22222 | firebrick | огнеупорного кирпича | ||
| #FFFAF0 | floralwhite | цветочно-белый | #228B22 | forestgreen | лесной зеленый | ||
| #FF00FF | fuchsia | фуксии | #F8F8FF | ghostwhite | туманно-белый | ||
| #DCDCDC | gainsboro | гейнсборо | #FFD700 | gold | золотой | ||
| #DAA520 | goldenrod | красного золота | #808080 | gray | серый | ||
| #008000 | green | зеленый | #ADFF2F | greenyellow | желто-зеленый | ||
| #F0FFF0 | honeydew | свежего меда | #FF69B4 | hotpink | ярко-розовый | ||
| #CD5C5C | indianred | ярко-красный | #4B0082 | indigo | индиго | ||
| #FFFFF0 | ivory | слоновой кости | #F0E68C | khaki | хаки | ||
| #E6E6FA | lavender | бледно-лиловый | #FFF0F5 | lavenderblush | бледный розово-лиловый | ||
| #7CFC00 | lawngreen | зеленой лужайки | #FFFACD | lemonchiffon | лимонный | ||
| #ADD8E6 | lightblue | светло-голубой | #F08080 | lightcoral | светло-кораловый | ||
| #E0FFFF | lightcyan | светло-циановый | #FAFAD2 | lightgoldenrodyellow | светлый золотисто-желтый | ||
| #90EE90 | lightgreen | светло-зеленый | #D3D3D3 | lightgrey | светло-серый | ||
| #FFB6C1 | lightpink | светло-розовый | #FFA07A | lightsalmon | светлый оранжево-розовый | ||
| #20B2AA | lightseagreen | светлый морской волны | #87CEFA | lightskyblue | светлый небесно-голубой | ||
| #778899 | lightslategray | светлый сине-серый | #B0C4DE | lightsteelblue | светло-стальной | ||
| #FFFFE0 | lightyellow | светло-желтый | #00FF00 | lime | цвета извести | ||
| #32CD32 | limegreen | зеленовато-известковый | #FAF0E6 | linen | льняной | ||
| #FF00FF | фуксин | blanchedalmond | #800000 | maroon | оранжево-розовый | ||
| #66CDAA | mediumaquamarine | умеренно-аквамариновый | #0000CD | mediumblue | умеренно-голубой | ||
| #3CB371 | mediumseagreen | умеренный морской волны | #7B68EE | mediumslateblue | умеренный серо-голубой | ||
| #BA55D3 | mediumorchid | умеренно-орхидейный | #9370DB | mediumpurple | умеренно-пурпурный | ||
| #00FA9A | mediumspringgreen | умеренный сине-серый | #48D1CC | mediumturquose | умеренно-бирюзовый | ||
| #0C71585 | mediumvioletred | умеренный красно-фиолетовый | #191970 | midnightblue | полуночный синий | ||
| #0F5FFFA | mintcream | мятно-кремовый | #FFE4E1 | mistyrose | туманно-розовый | ||
| #FFE4B5 | moccasin | болотный | #FFDEAD | navajowhite | грязно-серый | ||
| #000080 | navy | морской | #FDF5E6 | oldlace | старого коньяка | ||
| #808000 | olive | оливковый | #6B8E23 | olivedrab | |||
| #FFA500 | orange | оранжевый | #FF4500 | orangered | оранжево-красный | ||
| #DA70D6 | orchid | орхидейный | #EEE8AA | palegoldenrod | бледно-золотисный | ||
| #98FB98 | palegreen | бледно-зеленый | #AFEEEE | paleturquoise | бледно-бирюзовый | ||
| #DB7093 | palevioletred | бледный красно-фиолетовый | #FFEFD5 | papayawhip | дынный | ||
| #FFDAB9 | peachpuff | персиковый | #CD853F | peru | коричневый | ||
| #FFC0CB | pink | розовый | #DDA0DD | plum | сливовый | ||
| #B0E0E6 | powderblue | туманно-голубой | #800080 | purple | пурпурный | ||
| #FF0000 | red | красный | #BC8F8F | rosybrown | розово-коричневый | ||
| #4169E1 | royalblue | королевский голубой | #8B4513 | saddlebrown | старой кожи | ||
| #FA8072 | salmon | оранжево-розовый | #F4A460 | sandybrown | рыже-коричневый | ||
| #2E8B57 | seagreen | морской зеленый | #FFF5EE | seashell | морской пены | ||
| #A0522D | sienna | охра | #C0C0C0 | silver | серебристый | ||
| #87CEEB | skyblue | небесно-голубой | #6A5ACD | slateblue | серо-голубой | ||
| #708090 | slategray | сине-серый | #FFFAFA | snow | снежный | ||
| #00FF7F | springgreen | весенне-зеленый | #4682B4 | steelblue | сине-стальной | ||
| #D2B48C | tan | желто-коричневый | #008080 | teal | чайный | ||
| #D8BFD8 | thistle | чертополоха | #FF6347 | tomato | томатный | ||
| #40E0D0 | turquoise | бирюзовый | #EE82EE | violet | фиолетовый | ||
| #F5DEB3 | wheat | пшеничный | #FFFFFF | white | белый | ||
| #F5F5F5 | whitesmoke | белый дымчатый | #FFFF00 | yellow | желтый | ||
| #9ACD32 | yellowgreen | желто-зеленый | #7FFFD4 | aquamarine | аквамарин |
Конфигурационные файлы
Таблица 5.5.1. Конфигурационные файлы
|
Название файла |
Назначение |
/etc/hosts |
База данных имен ЭВМ и их IP-адресов (ею пользуются такие утилиты, как ping и ifconfig) |
/etc/networks |
База данных имен ЭВМ и их MAC-адресов (адресов сетевых карт) |
/etc/ethers |
Опционный файл, который содержит имена субсетей, их сетевые маски или сетевые адреса доменов |
/etc/protocols |
Конфигурационный файл, где содержится перечень имен поддерживаемых протоколов и их кодов. Первое поле содержит официальное название протокола, далее следует код протокола, третье поле содержит псевдоним протокола. |
/etc/services |
Файл, определяющий взаимодействие в системе клиент-сервер. Первое поле содержит название процесса (Echo, tcpmux, systat, netstat, chargen, TFTP, NNTP, POP-3, login, talk и т.д.), второе поле хранит номер порта и имя протокола. |
/etc/syslog |
Определяет типы сообщений и проход к log-файлу |
/etc/inetd.conf |
Содержит последовательность записей, определяющих работу протоколов Интернет: имя услуги (из файла /etc/services); тип сокета (stream, dgram, raw или rdm); протокол (из файла /etc/protocols); статус ожидания (wait-status); пользователь; проход к серверу. |
/etc/routed |
Используется при загрузке системы, определяет взаимодействие с другими машинами |
/etc/passwd |
Содержит информация для идентификации пользователей и их паролей |
/etc/hosts.equiv |
Содержит имена машин и пользователей, что позволяет авторизованному пользователю входить в другие машины, не вводя пароль. |
/etc/bootptab |
Определяет адреса и загрузочные файлы |
/etc/snmp.conf |
Определяет содержимое поля community и допустимые адреса |
/etc/resolv.conf |
Служба имен. Определяет имя локального домена и следующего вышестоящего сервера имен. |
/etc/named.boot |
Определяет положение баз данных, других серверов имен и доменов, обслуживаемых named. |
/usr/local/domain/named.fwd |
База данных имен для обычных запросов. Проход может быть и иным, он указывается в named.boot. |
/usr/local/domain/named.rev |
База данных сервера имен для запросов в IN-ADDR.ARPA. Замечание о проходе в предшествующем пункте справедливо и здесь. |
/usr/local/domain/named.ca |
База данных сервера имен для инициализации кэша. Замечание о проходе для named.fwd справедливо и здесь. Смотри также документ RFC-1033. Содержимое файла можно прочитать с помощью процедуры nslookup. |
Файл /etc/ passwd содержит записи аутентификационных параметров пользователей. Каждая запись содержит 7 полей. В первом поле записано имя пользователя (LOGIN ID) в представлении ASCII. Второе поле содержит зашифрованный пароль пользователя. Шифрование осуществляется с добавлением символов, что делает обратную дешифровку невозможной. Причем одно и то же слово при таком методе может быть зашифровано различным способом. Третье поле является числовым номером пользователя (UID). В четвертом поле записывается код группы пользователей, к который принадлежит данный клиент. Пятое поле содержит комментарий администратора. В шестом поле хранится имя базового каталога пользователя. В заключительном поле записывается имя командного интерпретатора, который будет использоваться по умолчанию. В новейших версиях UNIX файл /etc/passwd содержит только "x" во втором поле записи для каждого пользователя, что указывает на использование файла /etc/shadow, где в зашифрованном виде содержатся пароли пользователей. Доступ к этому файлу имеет только администратор. Информация о членах групп пользователей хранится в файле /etc/group/.
Файл /usr/lib/aliases используется для создания почтовых ящиков, которым не соответствуют какие-либо аккоунты. Здесь прописываются псевдонимы, которым система пересылает поступающие почтовые сообщения. Строка переадресации в этом файле имеет форму:
alias: имя_пользователя или
alias: имя_пользователя_1, имя_пользователя_2, ..., имя_пользователя_N.
В первом случае вся почта приходящая alias переадресуется пользователя с указанным именем. Во втором - всем пользователям, имена которых представлены в списке. Если список не умещается в одной строке, перед вводом "возврата каретки" следует напечатать символ "/". В качестве аккоунтов могут использоваться как локальные так и стандартные почтовые адреса. Для особо длинных списков можно ввести специальную строку в файл /usr/lib/aliases:
authors:":include:/usr/local/lib/authors.list", где authors - псевдоним, а authors.list - файл, содержащий список адресатов, кому следует переслать сообщение.
Наиболее мощной и по этой причине наиболее опасной возможностью файла псевдонимов является переадресация входной почты программе, указанной в псевдониме. Когда первым символом имени аккоунта в псевдониме является вертикальная черта (|), то управление будет передано программе, чье имя следует за этим символом, а входные почтовые сообщения будут передаваться этой программе, например строка:
listserv: "|/usr/local/bin/listserv -l"
обеспечит пересылку почты программе listserv, как если бы исполнялась команда cat mailfile|listserv -l. Эта техника используется для интерпретации содержимого поля subject или тела сообщения в качестве команд управления подписными листами.
Файл named.boot, который служит для инициализации сервера имен, имеет следующую структуру. Строки, начинающиеся с точки с запятой являются комментариями. Строка sortlist определяет порядок, в котором выдаются адреса сервером, если их число в отклике превышает 1. Запись directory, описывает положение информационных файлов (имя проход/каталога). Строка cashe, служит для инициализации кэша сервера имен с использованием файла named.ca. Этот также как и другие файлы должны находиться в каталоге, указанном в записи directory. Записи primary указывают, в каких файлах размещена информация таблиц соответствия имен и IP-адресов. Последняя запись primary содержит информацию для локальной ЭВМ. В записях secondary специфицируется данные, которые должны считываться с первичного сервера и из локальных файлов.
В файле named.local содержится локальный интерфейс обратной связи сервера имен. Файл включает в себя только одну запись SOA (Start of Authority) и две ресурсных записи. Запись SOA определяет начало зоны. Символ @ в начале первого поля записи задает имя зоны. Четвертое поле этой записи содержит имя первичного сервера имен данного субдомена, а следующее поле хранит имя администратора, ответственного за данный субдомен (его почтовый адрес). Запись SOA включает в себя список из 5 чисел, заключенный в скобки.
Версия или серийный номер. Первое число в списке увеличивается каждый раз при актуализации файла. Вторичные серверы имен проверяют и сравнивают номер версии файла первичного сервера с имеющимся у них кодом, для того чтобы определить, следует ли копировать базу данных DNS.
Время обновления (refresh time). Определяет время в секундах, задающее период запросов вторичного DNS к первичному.
Время повторной попытки. Задает время в секундах, когда вторичный сервер имен может повторить запрос в случае неудачи предыдущего.
Время истечения пригодности (expiration time). Верхний предел временного интервала в секундах по истечении которого база данных вторичного DNS считается устаревшей без проведения актуализации.
Минимум. Значение по умолчанию для таймера TTL для экспортируемых ресурсных записей.
Файл /etc/hosts.equiv позволяет составить список ЭВМ, объединенных в группу. Пользователь, находящийся в одной из ЭВМ этой группы, может установить связь с другой, не вводя своего пароля. Понятно, что применение этого метода входа, предоставляя некоторые удобства, создает и определенные угрозы с точки зрения сетевой безопасности.
Файл .rhosts, который размещается в корневом каталоге пользователя, позволяет ему описать список ЭВМ, куда он имеет доступ. При этом появляется возможность войти из данной ЭВМ в любую из названных машин без ввода пароля. Замечания об использовании файла hosts.equiv в полном объеме справедливы и в данном случае.
Если к ЭВМ подключены модемы, необходимо применение так называемого dialup-пароля. Удаленный пользователь помимо своего ID и пароля должен ввести еще и dialup-пароль, который является общим для всех работающих на данной ЭВМ. Если все три параметра аутентификации корректны, доступ будет разрешен. При ошибке в любом из трех компонентов ЭВМ попросит повторить их ввод, не указывая, где совершена ошибка. Файл /etc/dpasswd является исполняемым и может реализовать ряд опций.
a [список] характеризует список терминалов, который добавляется к /etc/dialups. Пользователь при входе с такого терминала должен будет ввести пароль dialup. Элементы в списке заключаются в кавычки и разделяются пробелами или запятыми.
d [список] определяет список терминалов, которые должны быть удалены из /etc/dialups и пользователю будет не нужно в будущем вводить пароль dialup при входе с этих терминалов.
r [список] меняет login shell на /bin/sh для каждого из пользователей, перечисленных в списке.
s [shell] модифицирует запись в файле /etc/d_passwd или добавляет новую запись.
u [список] создает новое ядро (shell) для имен, указанных в списке. Добавляются записи в etc/d_passwd для нового ядра, а пароль работает для всех пользователей из списка, если не оговорено обратного.
x [shell] удаляет shell и пароль из файла /etc/d_passwd
Новые европейские стандарты
Таблица 3.1.3A. Обзор категорий кабелей со скрученными парами проводов (ISO/IEC 11801 = EN 50173)
|
Категория |
Полоса пропускания |
Применения |
|
3 |
до 16 МГц |
Ethernet, Token Ring, телефон |
|
4 |
до 20 МГц |
Ethernet, Token Ring, телефон |
|
5 |
до 100 МГц |
Ethernet, ATM, FE,Token Ring, телефон |
|
6 |
до 200/250 МГц |
GigaEthernet,Ethernet, FE, ATM, Token Ring |
|
7 |
до 600 МГц |
GigaEthernet,Ethernet, FE, ATM, Token Ring |
Новые европейские стандарты на разъемы для скрученных пар (CENELEC)
Таблица 3.1.3Б. Новые европейские стандарты на разъемы для скрученных пар (CENELEC)
|
Стандарт |
Экран |
Полоса пропускания |
|
EN 60603-7-2 |
- |
< 100 МГц (кат. 5) |
|
EN 60603-7-3 |
+ |
< 100 МГц (кат. 5) |
|
EN 60603-7-4 |
- |
< 250 МГц (кат. 6) |
|
EN 60603-7-5 |
+ |
< 250 МГц (кат. 6) |
|
EN 60603-7-7 |
+ |
< 600 МГц (кат. 7) |
Конкретные зависимости ослабления сигнала от частоты и длины кабеля в децибелах представлены в таблице ниже (LANline Special IV/2002 p/26).
|
Частота |
Ослабление для кабеля категории 5 [дБ] |
Ослабление для кабеля категории 6 [дБ] |
||||
|
Кабель 2 м |
Кабель 5 м |
Кабель 10 м |
Кабель 2 м |
Кабель 5 м |
Кабель 10 м |
|
|
1 |
72.9 |
71.6 |
70.1 |
65.0 |
65.0 |
65.0 |
|
4 |
61.0 |
59.7 |
58.4 |
65.0 |
65.0 |
65.0 |
|
16 |
49.1 |
48.0 |
46.9 |
62.0 |
60.5 |
59.0 |
|
62.5 |
37.6 |
36.8 |
36.0 |
50.4 |
49.2 |
48.1 |
|
100.0 |
33.7 |
33.0 |
32.5 |
46.4 |
45.3 |
44.4 |
|
200.0 |
|
|
43.0 |
42.1 |
41.4 |
|
|
250.0 |
|
|
|
38.8 |
38.1 |
37.6 |
Данные, приведенные в таблице 3.1.2, могут использоваться для оперативной предварительной оценки качества кабельного сегмента (соответствует стандарту EIA/TIA 568, 1991 год). Частотные характеристики неэкранированных пар категории 6 представлены в табл. 3.1.5`.
Обзор классов соединений согласно требованиям ISO/IEC (EN
Таблица 3.1.3A1. Обзор классов соединений согласно требованиям ISO/IEC 11801 (EN 50173)
|
Класс |
Применение |
|
A |
Голос и сетевые приложения до 100 кГц |
|
B |
Информационные приложения до 1 МГц |
|
С |
Информационные приложения до 16 МГц |
|
В |
Информационные приложения до 100 МГц |
|
E |
Информационные приложения до 200/250 МГц |
|
F |
Информационные приложения до 600 МГц |
|
LWL |
Информационные приложения от 10 МГц |
описанных сообщений
Таблица описанных сообщений
C = Приложение Покупателя, M = Приложение Продавца, S = Сервер CyberCash
|
FLOW |
Раздел |
Имя |
C->S |
4.2.1 |
BC.1 bind-credit-card |
S->C |
4.2.2 |
BC.4 bind-credit-card-response |
C->M |
4.3.2 |
CH.1 credit-card-payment |
M->C |
4.3.3 |
CH.2 credit-card-response |
M->S |
4.4.8 |
CD.1 запрос данных о кредитной карте |
S->M |
4.4.9 |
CD.2 отклик на запрос о кредитной карте |
M->S |
4.4.1 |
CM.1 только аутентификация |
M->S |
4.4.2 |
CM.2 auth-capture |
M->S |
4.4.3 |
CM.3 post-auth-capture |
M->S |
4.4.4 |
CM.4 void |
M->S |
4.4.5 |
CM.5 возврат |
S->M |
4.4.6 |
CM.6 отклик на платеж |
C->S |
4.5.7 |
DL.1 диагностическая запись |
M->S |
4.5.7 |
DL.2 диагностическая запись продавца |
C->S |
4.1.3 |
GA.1 получение приложения |
S->C |
4.1.4 |
GA.2 получение отклика приложения |
M->S |
4.4.7 |
MM.1 только аутентификация продавца |
M->S |
4.4.7 |
MM.2 merchant-auth-capture |
M->S |
4.4.7 |
MM.3 merchant-post-auth-capture |
M->S |
4.4.7 |
MM.4 merchant-void |
M->S |
4.4.7 |
MM.5 merchant-return |
S->M |
4.4.7 |
MM.6 отклик продавца на процедуру оплаты |
C->S |
4.5.1 |
P.1 ping |
S->C |
4.5.2 |
P.2 отклик на ping |
M->C |
4.3.1 |
PR.1 запрос платежа |
C->S |
4.1.1 |
R.1 регистрация |
S->C |
4.1.2 |
R.2 отклик на регистрацию |
C->S |
4.5.3 |
TQ.1 запрос о состоянии транзакции |
C->S |
4.5.4 |
TQ.2 аннулирование транзакции |
S->C |
4.5.5 |
TQ.3 отклик на транзакцию |
S->C, S->M, M->C |
4.5.6 |
UNK.1 неизвестная ошибка |
5. Дальнейшие разработки
Список возможностей, которые доступны в системе CyberCash, расширяется. В настоящее время реализована универсальная система расчетов, включающая эффективную пересылку небольших сумм денег, планируются различные дальнейшие улучшения.
5.1. Процесс авторизации кредитной карты и расчета
Существует шесть шагов обработки кредитной карты, как это описано ниже. Первые четыре присутствуют всегда, если транзакция завершена. Пятый и шестой являются опционными.
|
(1) |
авторизация: продавец контактирует со своим покупателем, который в свою очередь получает от банкира, выпустившего кредитную карту, подтверждение или отрицание своей кредитоспособности. Эти данные он пересылает продавцу. |
(2) |
приобретение (capture): платежная информация для покупки вводится продавцом в расчетный документ. |
(3) |
оплата (clearance): обработка перечня товаров. Это вызывает появление товаров из перечня в записи о покупке для данной кредитной карты. Эта запись посылается банку, предоставившему кредитную карту покупателю. |
(4) |
урегулирование (settlement): межбанковская операция по пересылке денежных средств. |
(5) |
удаление (void): продавец отменяет шаг 2 (или 6), сумма оплаты удаляется из расчетного документа. Операция должна быть выполнена до осуществления оплаты. |
(6) |
кредит (credit): продавец вводит отрицательную сумму оплаты в расчетный документ. Эта сумма появится в записи о покупке владельца кредитной карты. |
Четвертый шаг (settlement) реализуется исключительно в банковской среде. CyberCash 0.8 формирует сообщения для реализации шагов 1, 1&2, 2, 5 и 6. это справедливо для систем работы с кредитными картами, где данные о сделке накапливаются в банке или в системе продавец-банк. CyberCash 0.8 поддерживает такие системы. Другие системы работы с кредитными картами требуют того, чтобы все данные о сделке хранились у продавца. Такие системы часто называются “терминальными покупками” ("terminal capture"). Это делает операции 2, 5 и 6 внутренними для продавца, но требует сообщений для выполнения операции 3. Такие сообщения о денежных расчетах будут включены в будущие версии CyberCash для приложений продавца и сервера.
изготовленные из скрученных пар категории
Таблица 3.1.5. Параметры неэкранированных пар категории 6
| Частота, МГц | Затухание, дБ/100м | NEXT, дБ | ACR, дБ/100м |
| 1 | 2,3 | 62 | 60 |
| 10 | 6,9 | 47 | 41 |
| 100 | 23,0 | 38 | 23 |
| 300 | 46,8 | 31 | 4 |
ACR - Attenuation-to-Crosstalk Ratio.
NEXT - Near End CrossTalk.
Кабели, изготовленные из скрученных пар категории 5 (волновое сопротивление 100,15 Ом), с полосой 100 Мгц обеспечивают пропускную способность при передаче сигналов ATM 155 Мбит/с. При 4 скрученных парах это позволяет осуществлять передачу до 622 Мбит/с. Кабели категории 6 сертифицируются до частот 300 Мгц, а экранированные и до 600 Мгц (волновое сопротивление 100 Ом). В таблице 3.1.6 приведены данные по затуханию и перекрестным наводкам. Приведены характеристики такого кабеля с 4-мя скрученными экранированными парами (S-FTP).
Разновидности ошибок
Таблица 4.1.4.1 Разновидности ошибок.
|
Тип ошибки |
Описание |
bit error |
Передающий узел обнаружил, что состояние шины не соответствует тому, что он туда передает |
stuff error |
Нарушено правило кодирования (вставка бита противоположного значения после 5 идентичных бит, см. абзац выше). |
CRC error |
Приемник обнаружил ошибку в контрольной сумме. |
form error |
Обнаружено нарушение формата кадра |
|
acknowledgment error |
Выявлен неверный уровень первого бита поля ack. |
Любой узел CAN должен регистрировать и по запросу сообщать число ошибок при передаче и приеме.
Номинальное время, выделенное для передачи одного бита, включает в себя четыре временные области: sync_seg, prop_seg, phase_seg1, phase_seg2 (Рисунок 3.4.4.3).
содержит зависимость m от N и K для кодов ВСН
Таблица 2.8.1 содержит зависимость m от N и K для кодов ВСН.
Сопротивление кабеля по постоянному току
Таблица 3.1.2 Сопротивление кабеля по постоянному току
Коаксиал |
Ом/сегмент |
Максимальная длина сегмента |
10BASE5 |
5 |
500 м |
10BASE2 |
10 |
185 м |
Эти данные взяты из Handbook of LAN Cable Testing. Wavetek Corporation, California
.
|
Скрученная пара |
Ом/100 м |
|
24 AWG |
18,8 |
|
22 AWG |
11,8 |
Стандартный массив для кодов (
Таблица 2.8.3. Стандартный массив для кодов (6,3)
|
000000 |
001101 |
010011 |
100110 |
011110 |
101011 |
110101 |
111000 |
000001 |
001100 |
010010 |
100111 |
011111 |
101010 |
110100 |
111001 |
000010 |
001111 |
010001 |
100100 |
011100 |
101001 |
110111 |
111010 |
000100 |
001001 |
010111 |
100010 |
011010 |
101111 |
110001 |
111100 |
001000 |
000101 |
011011 |
101110 |
010110 |
100011 |
111101 |
110000 |
010000 |
011101 |
000011 |
110110 |
001110 |
111011 |
100101 |
101000 |
100000 |
101101 |
110011 |
000110 |
111110 |
001011 |
010101 |
011000 |
001001 |
000100 |
011010 |
101111 |
010111 |
100010 |
111100 |
011001 |
Предположим, что верхняя строка таблицы содержит истинные значения переданных кодов. Из таблицы 2.8.3 видно, что, если ошибки случаются в позициях, соответствующих битам кодов из левой колонки, можно определить истинное значение полученного кода. Для этого достаточно полученный код сложить с кодом в левой колонке посредством операции XOR.
Синдром равен произведению левой колонки (CL "coset leader") стандартного массива на транспонированную матрицу контроля четности HT.
|
Синдром = CL . HT |
Левая колонка стандартного массива |
000 |
000000 |
001 |
000001 |
010 |
000010 |
100 |
000100 |
110 |
001000 |
101 |
010000 |
011 |
100000 |
111 |
001001 |
Чтобы преобразовать полученный код в правильный, нужно умножить полученный код на транспонированную матрицу проверки четности, с тем чтобы получить синдром. Полученное значение левой колонки стандартного массива добавляется (XOR!) к полученному коду, чтобы получить его истинное значение. Например, если мы получили 001100, умножаем этот код на HT:
этот результат указывает на место ошибки, истинное значение кода получается в результате операции XOR:
www.cs.ucl.ac.uk/staff/S.Bhatti/D51-notes/node33.html (Saleem Bhatti).
типов кадров управления доступом для сети Token Ring
10.6 Таблица типов кадров управления доступом для сети Token Ring
|
Код команды |
Наименование |
Класс адресата |
Класс отправителя |
| 0x0 | Отклик (является реакцией на команды управления доступом) | Источник запроса | Рабочая станция |
| 0x2 | Аварийный сигнал (используется станциями для восстановления работоспособности после устойчивой ошибки) | Рабочая станция кольца | Рабочая станция кольца |
| 0x3 | Запрос маркера (используется для выбора активного монитора) | Рабочая станция | Рабочая станция |
| 0x4 | Очистка кольца (посылается активным монитором для повторного запуска маркерного доступа) | Рабочая станция | Рабочая станция |
| 0x5 | Активное мониторирование (используется активным монитором для опроса кольца) | Рабочая станция | Рабочая станция |
| 0x6 | Резервное мониторировние (используется дополнительным монитором для опроса кольца) | Рабочая станция | Рабочая станция |
| 0x7 | Проверка дублирования адреса (посылается станцией самой себе после подключения к кольцу) | Рабочая станция | Рабочая станция |
| 0x8 | Проверка среды ответвителя (проверяется целостность адаптера станции и ответвителя) | Рабочая станция | Рабочая станция |
| 0x9 | Пересылка вперед (служит для проверки наличия пути между станциями) | Рабочая станция | Сервер конфигурации |
| 0xB | Удаление станции из кольца (если станция получает кадр с таким кодом и своим адресом получателя, она должна отключиться от сети) | Рабочая станция | Сервер конфигурации |
| 0xC | Изменение параметров (используется сервером конфигурации для информирования станций об изменении параметров адаптера) | Рабочая станция | Сервер конфигурации |
| 0xD | Инициализация станции (используется сервером параметров для пересылки данных в адаптер станции при ее инициализации) | Рабочая станция | Сервер параметров кольца |
| 0xE | Запрос адреса станции (посылается серверу конфигурации в ответ на запрос) | Рабочая станция | Сервер конфигурации |
| 0xF | Запрос состояния станции (Посылается сервером конфигурации для получения данных о состоянии станции) | Рабочая станция | Сервер конфигурации |
| 0x10 | Запрос подключения станции (используется станцией в ответ на запрос сервера конфигурации о подключении) | Рабочая станция | Сервер конфигурации |
| 0x20 | Запрос инициализации (используется для получения данных от сервера параметров) | Сервер параметров кольца | Рабочая станция |
| 0x22 | Запрос об адресе станции (посылается сервером конфигурации стации с целью определения ее адреса) | Сервер конфигурации | Рабочая станция |
| 0x23 | Запрос о состоянии станции (запрос о состоянии станции, посылаемый сервером конфигурации) | Сервер конфигурации | Рабочая станция |
| 0x24 | Запрос о подключении станции (используется сервером конфигурации для получения данных об адаптере станции) | Сервер конфигурации | Рабочая станция |
| 0x25 | Сообщение нового активного монитора (используется новым активным монитором для информирования о себе сервера конфигурации) | Сервер конфигурации | Рабочая станция |
| 0x26 | Сообщение об изменении адреса предшественника (используется станцией для сообщения серверу конфигурации об изменении ближайшего активного предшественника) | Сервер конфигурации | Рабочая станция |
| 0x27 | Сообщение о незавершенном опросе кольца (используется активным монитором для передачи монитору ошибок сообщений о нарушении порядка опроса) | Монитор ошибок | Рабочая станция |
| 0x28 | Сообщение об ошибке монитора (используется станцией для оповещения монитора ошибок о сбоях) | Монитор ошибок | Рабочая станция |
| 0x29 | Сообщение об ошибке (используется станциями для передачи серверу ошибок содержимого счетчиков нестабильных ошибок) | Монитор ошибок | Рабочая станция |
| 0x2A | Отклик на передачу вперед (используется станцией для передачи серверу конфигурации результата передачи вперед) | Сервер конфигурации | Рабочая станция |
Зависимость пропускной способности канала от его длины
Таблица 4.1.4.2 Зависимость пропускной способности канала от его длины
|
Длина канала в метрах |
Пропускная способность сети в Кбит/с |
|
100 |
500 |
|
200 |
250 |
|
500 |
125 |
|
6000 |
10 |
В сетях CAN используются 9-, 6- и 5-контактные разъемы. Тип разъема, или какие либо его характеристики стандартом не регламентируются. Разъем определяется протоколом HLP (High Layer Protocol).
Временные зоны периода передачи одного бита
Рисунок 4.1.4.3 Временные зоны периода передачи одного бита
Первая временная область (SYNC_SEG) служит для синхронизации работы различных узлов сети. Область PROP_SEG предназначена для компенсации временных задержек в сети и равна сумме времени распространения сигнала по каналу и задержки во входных компараторах. PHASE_SEG1 и PHASE_SEG2 служат для компенсации фазовых ошибок и могут увеличиваться или уменьшаться после синхронизации. T0 - минимальный квант времени, используемый для формирования временной шкалы в пределах периода передачи одного бита (длительность внутреннего такта может быть значительно короче). Момент стробирования определяет момент времени, когда проверяется состояние канала. Этот момент должен быть синхронным для всех узлов сети. Длительность этих временных областей может задаваться программно. Чем длиннее канал, тем меньшую скорость передачи информации он может обеспечить (см. табл. 3.3.4.2).
Автор признателен читателю, который прочел
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 телефонные магнитные карты будут снабжены индивидуальными характеристиками голоса клиента, которые будут передаваться принимающей стороне при вызове. Процессор в телефонном аппарате будет преобразовывать голос в символьную последовательность (в текст). Это позволит передавать по каналу только текст, индивидуальность голосу будет придаваться на принимающей стороне при синтезе, что сократит на порядок требования к полосе канала.
Время покажет, был ли я пессимистом или оптимистом. В том, что все это будет, я уверен, могу ошибаться только в сроках. Предпосылками для этого должны стать снижение цен на отоволоконные кабели, принтеры и терминальное оборудование, разработки дешевых специализированных интегральных схем, часть из которых уже имеется, другие разрабатываются сегодня; аппаратные устройства сжатия информации и много другое. Создание широкой информационной сети с доступом в каждый дом породит немало новых проблем. Это прежде всего обеспечение защиты частной информации, предотвращение вторжения в личную жизнь. Огромную работу здесь предстоит выполнить программистам. Это и разработка более эффективных алгоритмов сжатия данных, шифрования/дешифрования информации, новых протоколов передачи, удобных пользовательских интерфейсов, более совершенных распределенных баз данных и поисковых систем. Буду счастлив, если среди людей, кто внесет свой вклад в это общее дело, окажутся и читатели этой книги. В следующем веке сети предоставят много новых рабочих мест для граждан планеты Земля. Желаю гражданам всемирного государства Интернет новых успехов и приятных приключений.
Зависимость наводок NEXT от частоты передаваемого сигнала
Рисунок 3.1.3. Зависимость наводок NEXT от частоты передаваемого сигнала.
На Рисунок 3.1.4 представлена зависимость ослабления сигнала в неэкранированной скрученной паре (именно такие кабели наиболее часто используются для локальных сетей) от частоты передаваемого сигнала. Следует иметь в виду, что при частотах в области сотен мегагерц и выше существенный вклад начинает давать поглощение в диэлектрике. Таким образом, даже если проводники изготовить из чистого золота, существенного продвижения по полосе пропускания достичь не удастся.
Зависимость ослабления сигнала от частоты для неэкранированной скрученной пары
Рисунок 3.1.4. Зависимость ослабления сигнала от частоты для неэкранированной скрученной пары
Для неэкранированной скрученной пары 5-ой категории зависимость отношения сигнал-шум от длины с учетом ослабления и наводок NEXT показана на Рисунок 3.1.5.
Зависимость ослабления сигнала в кабеле от его частоты
Рисунок 3.1.2. Зависимость ослабления сигнала в кабеле от его частоты
Зависимость отношения сигнал/шум от частоты с учетом ослабления и наводок на ближнем конце кабеля
Рисунок 3.1.5 Зависимость отношения сигнал/шум от частоты с учетом ослабления и наводок на ближнем конце кабеля
Характеристики неэкранированных скрученных пар американского стандарта 24 AWG (приведены характеристики кабелей, используемых при построении локальных сетей) для кабелей различной категории собраны в таблице 3.1.7.
