Интегрированные сети ISDN

         

Бесклассовая интердоменная маршрутизация (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 дБ.
В QAM-модуляции используется 8/16 комбинаций амплитуда-фаза (см. Рисунок 2.2). Понятно, что такой тип модуляции более уязвим для шумов.




Форматы специальных сообщений



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 может предупредить пользователя о том, что приложение устарело или о наличии в нем известных ошибок.
4.1.3. GA1 - get-application (получение приложения)



Используется 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
Ну а теперь рассмотрим два случая ошибок в одном из битов посылки, например, в бите 7 (1 вместо 0) и в бите 5 (0 вместо 1). Просуммируем коды позиций ненулевых бит еще раз.

11 = 1011
10 = 1010
09 = 1001
08 = 1000
07 = 0111
05 = 0101
04 = 0100
03 = 0011
02 = 0010
s = 0111
 
11 = 1011
10 = 1010
09 = 1001
08 = 1000
04 = 0100
03 = 0011
02 = 0010
s = 0101
В обоих случаях контрольная сумма равна позиции бита, переданного с ошибкой. Теперь для исправления ошибки достаточно инвертировать бит, номер которого указан в контрольной сумме. Понятно, что если ошибка произойдет при передаче более чем одного бита, код Хэмминга при данной избыточности окажется бесполезен.

В общем случае код имеет 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

Методы сжатия информации



2.6 Методы сжатия информации

Номер раздела Название раздела Объем в страницах Объем в кбайт
2.6 Методы сжатия информации 3 3
2.6.1 Алгоритм Зива-Лемпеля 3 3
2.6.2 Локально адаптивный алгоритм сжатия 2 2
2.6.3 Сжатие данных с использованием преобразования Барроуза-Вилера 1 1
2.6.4 Метод Шеннона-Фано 1 3
2.6.5 Статический алгоритм Хафмана 1 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, а PDP знает, какие порядковые номера ожидает PEP. Все сообщения COPS должны включать согласованный объект Integrity, специфицирующий корректный порядковый номер с соответствующий дайджест сообщения (включая сообщения Client-Open/Client-Accept для специфических типов клиента). Все последующие сообщения от PDP к PEP должны вызывать инкрементацию порядкового номера, осуществляемую PEP в объекте Integrity исходного сообщения Client-Open. Аналогично, все последующие сообщения от PEP к PDP должны вызывать инкрементацию порядкового номера, осуществляемую PDP в объекте Integrity исходного сообщения Client-Accept. Порядковые номера увеличиваются на 1, начиная с исходного значения. Например, если порядковый номер задан для PEP в исходном сообщении Client-Accept равным 10, следующее сообщение PEP посылаемое к PDP, предоставит объект Integrity с порядковым номером 11.


Следующее сообщение, которое посылает 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 Целостность сообщения
C-type: 8 бит. Значения, определенные для C-num.



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
R-тип (флаг типа запроса)

0x01 Запрос входящего сообщения/Управления доступом (Incoming-Message/Admission Control)
0x02 Запрос выделения ресурсов
0x04 Запрос исходящего сообщения
0x08 Запрос конфигурации
M-Type (Тип сообщения специфичные для клиента (Client Specific) 16-битовые значения типов протокольного сообщения.



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
Для этого типа объекта интерфейса, IPv4-адрес специфицирует адрес, откуда пришло сообщение.

C-Type = 2, IPv6-адрес + Интерфейс

0 1 2 3
IPv6 Address format

ifindex
Для данного типа объекта интерфейса, IPv6-адрес специфицируетIP-адрес, откуда пришло входное сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II PEP, как это описано выше.



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 /////////////
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
C-Type = 2, IPv6-адрес + TCP порт

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)

Протокол COPS предназначен для обмена информации о политике между серверами политики (Policy Decision Point или PDP) и их клиентами (Policy Enforcement Points или PEP). Примером клиента политики является RSVP-маршрутизатор, который должен реализовывать управление доступом, базирующееся на определенной политике [RSVP]. Мы предполагаем, что существует, по крайней мере, один сервер, определяющий политику в каждом из доменов. Базовая модель взаимодействия между сервером политики и клиентом совместима с документом по управлению доступом [WRK]. Характеристики протокола COPS содержат следующие моменты (RFC-2748):

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. "$$" - литерная строка.
Номера версии начинаются с 0.7. ".z" опускается, если z = 0. 0.7 и 0.8 являются тестовыми и начальными версиями поставки системы для кредитных карт. 0.9 и 1.0 представляют собой улучшенные версии этой системы.

Строка "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. "$$" – строка литералов.
Контрольная сумма передачи вычисляется согласно алгоритму MD5. Номер версии в начальной строке содержит исключительно печатные символы и размещается после второго $$ этой строки и до первого $$ завершающей строки. Заметим, что все пробелы (SP, TAB, LF и CR) не включаются в этот хэш. Терминаторы меток (: или ;) включаются туда, также как любые строки #-комментариев. Заметим также, что опционная символьная строка "Extra" в начальной $-строке в хэш не включается. Основной идеей является обеспечение корректности передачи, избегая зависимости от шлюзов (gateways) или любой обработки, которая может изменить завершающую строку или преобразовать символы табуляции, пробелы или символы разрыва строки.



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.


Исходный текст 9 5 18 1 3 19 20 3 21 11 20 6
Используемый ключ 23 5 13 14 10 17 5 1 13 9 27 11
Зашифрованный текст 32 10 31 15 13 36 25 4 34 20 47 17

Зашифрованный текст получается здесь из исходного добавлением значения очередного кода ключа (сложение может быть заменено вычитанием или операцией исключающее ИЛИ). Исходный текст в данном случае невозможно восстановить без знания ключа.
Примером шифрования с использованием секретного ключа является метод Видженера (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 год). Существует четыре режима работы:

ECB electronic code book.
CBC cipher block chaining
CFB cipher feedback
OFB output feedback.

Из-за того, что алгоритм DES в настоящее время представляется устаревшим и не обеспечивает достаточной надежности, довольно часто исходный текст последовательно шифруется трижды с помощью различных ключей.
Шифрование и дешифрование базируются на использовании ключей.

Таблица



Таблица 3.1.7.


Категория кабеля Сопротивление по постоянному току (L=300м) Ослабление [дБ] NEXT [дБ]
III 28,4 17 @ 4 МГц

30 @ 10 МГц

40 @ 16 МГц
32 @ 4 МГц

26 @ 10 МГц

23 @ 16 МГц
IV 28,4 13 @ 4 МГц

22 @ 10 МГц

27 @ 16 МГц

31 @ 20 МГц
47 @ 4 МГц

41 @ 10 МГц

38 @ 16 МГц

36 @ 20 МГц
V 28,4 13 @ 4 МГц

20 @ 10 МГц

25 @ 16 МГц

28 @ 20 МГц

67 @ 100 МГц
53 @ 4 МГц

47 @ 10 МГц

44 @ 16 МГц

42 @ 20 МГц

32 @ 100 МГц

Подводя итоги можно сказать, что при расстояниях до 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
Смотри www.osp.ru/lan/lan_6_96/source/57.htm

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.