Коды завершения операции

Таблица 4.6.2.62. Коды завершения операции

meanonglessRatio	PurchAmt=0; отношение не может быть вычислено
orderRejected	Продавец не может обработать заказ
orderReceived	Процессы авторизации отсутствуют
orderNotReceived	Информационный запрос получен до заказа
authorizationPerformed	См. AuthStatus
capturePerformed	См. CapStatus
creditPerformed	См. CreditStatus

Владелец карты обрабатывает полученный отклик PRes следующим образом.

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Чтобы проверить подпись продавца, производится обращение к Received Signed Data,
3	На основе Trans.LID-C ищется запись транзакции. Если запись не найдена: Посылается сообщение Error c ErrorCode равным unknownLID Прерывается обработка PRes
4	Сравнить значения TransIDs.XID с XID из записи транзакции. Если равенства нет: Посылается сообщение Error c ErrorCode равным unknownXID Прерывается обработка PRes
5	Сравнить значения RRPID из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным unknownRRPID Прерывается обработка PRes
6	Сравнить значения Chall-C из сообщения и записи транзакции. Если совпадения нет: Посылается сообщение Error c ErrorCode равным challengeMismatch Прерывается обработка PRes
7	Запомнить BrandCRLIdentifier и проверить, что перечисленные CRL содержаться в кэше. Если это не так, и перечисленные CRL относятся к элементам, чьи сертификаты использовались для верификации подписи, сообщение игнорируется, так как подпись может быть некорректной.
8	Для каждого PResPayload из PresPayloadSeq выполняются следующие действия: Если CompletionCode указывает на реализацию кредита, для каждой информационной структуры в CreditSeq представить пользователю CreditAmount (PurchAmount*CredRatio) и дату кредита вместе с полученным объемом платежа (PurchAmount*CapRatio). В противном случае, если CompletionCode указывает на завершение процесса платежа, представить пользователю CapCode вместе с вычисленным Capture Amount (PurchaseAmount*CapRatio). В противном случае, если CompletionCode указывает на завершение процесса авторизации, представить пользователю AuthCode вместе с вычисленным Authorization Amount (PurchaseAmount*AuthRatio). В противном случае сообщить результат транзакции на основе CompletionCode. Если присутствует AcqCardMsg, дешифровать и представить владельцу карты. Если там имеется URL, программа может выдать содержимое соответствующей WEB-страницы. Здесь может потребоваться обработка, зависящая от вида платежной системы.

Команды SNMP

Таблица 4.4.13.1 Команды SNMP

Команда SNMP	Тип PDU	Назначение
GET-request	0	Получить значение указанной переменной или информацию о состоянии сетевого элемента;
GET_next_request	1	Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB);
SET-request	2	Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено;
GET response	3	Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные);
TRAP	4	Отклик сетевого объекта на событие или на изменение состояния.
GetBulkRequest	5	Запрос пересылки больших объемов данных, например, таблиц.
InformRequest	6	Менеджер обращает внимание партнера на определенную информацию в MIB.
SNMPv3-Trap	7	Отклик на событие (расширение по отношению v1 и v2).
Report	8	Отчет (функция пока не задана).

Краткое описание сообщений об ошибках

Таблица 7.10. Краткое описание сообщений об ошибках

WinSock-код	Berkeley-эквивалент	Код ошибки	Значение
WSAEINTR	EINTR	10004	Как в стандартном C
WSAEBADF	EBADF	10009	Как в стандартном C
WSAEACCES	EACCES	10013	Как в стандартном C
WSAEFAULT	EFAULT	10014	Как в стандартном C
WSAEINVAL	EINVAL	10022	Как в стандартном C
WSAEMFILE	EMFILE	10024	Как в стандартном C
WSAEWOULDBLOCK	EWOULDBLOCK	10035	Как в BSD
WSAEINPROGRESS	EINPROGRESS	10036	Эта ошибка возникает, если какая-либо процедура WinSock вызвана во время исполнения блокирующей операции.
WSAEALREADY	EALREADY	10037	Как в BSD
WSAENOTSOCK	ENOTSOCK	10038	Как в BSD
WSAEDESTADDRREQ	EDESTADDRREQ	10039	Как в BSD
WSAEMSGSIZE	EMSGSIZE	10040	Как в BSD
WSAEPROTOTYPE	EPROTOTYPE	10041	Как в BSD
WSAENOPROTOOPT	ENOPROTOOPT	10042	Как в BSD
WSAEPROTONOSUPPORT	EPROTONOSUPPORT	10043	Как в BSD
WSAESOCKTNOSUPPORT	ESOCKTNOSUPPORT	10044	Как в BSD
WSAEOPNOTSUPP	EOPNOTSUPP	10045	Как в BSD
WSAEPFNOSUPPORT	EPFNOSUPPORT	10046	Как в BSD
WSAEAFNOSUPPORT	EAFNOSUPPORT	10047	Как в BSD
WSAEADDRINUSE	EADDRINUSE	10048	Как в BSD
WSAEADDRNOTAVAIL	EADDRNOTAVAIL	10049	Как в BSD
WSAENETDOWN	ENETDOWN	10050	Как в BSD. Ошибка возникает в любое время, когда приложение WinSock обнаруживает ошибку на нижележащем уровне.
WSAENETUNREACH	ENETUNREACH	10051	Как в BSD
WSAENETRESET	ENETRESET	10052	Как в BSD
WSAECONNABORTED	ECONNABORTED	10053	Как в BSD
WSAECONNRESET	ECONNRESET	10054	Как в BSD
WSAENOBUFS	ENOBUFS	10055	Как в BSD
WSAEISCONN	EISCONN	10056	Как в BSD
WSAENOTCONN	ENOTCONN	10057	Как в BSD
WSAESHUTDOWN	ESHUTDOWN	10058	Как в BSD
WSAETOOMANYREFS	ETOOMANYREFS	10059	Как в BSD
WSAETIMEDOUT	ETIMEDOUT	10060	Как в BSD
WSAECONNREFUSED	ECONNREFUSED	10061	Как в BSD
WSAELOOP	ELOOP	10062	Как в BSD
WSAENAMETOOLONG	ENAMETOOLONG	10063	Как в BSD
WSAEHOSTDOWN	EHOSTDOWN	10064	Как в BSD
WSAEHOSTUNREACH	EHOSTUNREACH	10065	Как в BSD
WSASYSNOTREADY		10091	Выдается WSAStartup, указывает, что сетевая субсистема использоваться не может.
WSAVERNOTSUPPORTED		10092	Выдается WSAStartup, указывая на то, что WinSock DLL не может поддерживать это приложение.
WSANOTINITIALISED		10093	Выдается любой процедурой кроме WSAStartup, указывая на то, что успешное исполнение WSAStartup не было осуществлено.
WSAEDISCON		10094	Выдается recv, WSARecv, чтобы отметить начало разрыва связи удаленным партнером
WSA_OPERATION_ABORTED		TBD	Совмещенные по времени процедуры прерваны из-за закрытия соединения, или выполнения команды SIO_FLUSH в WSAIoctl
WSAHOST_NOT_FOUND	HOST_NOT_FOUND	11001	Как в BSD
WSATRY_AGAIN	TRY_AGAIN	11002	Как в BSD
WSANO_RECOVERY	NO_RECOVERY	11003	Как в BSD
WSANO_DATA	NO_DATA	11004	Как в BSD

<
Современные версии WinSock обеспечивают протокольно- независимый доступ ко всем ресурсам сети, включая такие стандартные приложения, как DNS, SAP, X.500 и т.д.
Позволяют реализовать несколько сессий ввода/вывода одновременно.
Поддерживают любые стандартные уровни сервиса (QOS - Quality of service). Осуществляют объединение соединителей по группам в соответствии с их параметрами.
Допускается многопротокольная широковещательная или мультикастинг-адресация.
Предусматривается совместное использование соединителей несколькими процессами, условное создание соединителей и объединение их в группы.
Введено понятие WOSA-интерфейса (Windows Open Service Architecture), который обеспечивает связь между прикладной программой и сетевыми процедурами ОС. Этот интерфейс заметно упрощает программирование при работе с пакетами.
Каждая процедура, распознаваемая WOSA, имеет в свою очередь несколько интерфейсов, ориентированных на конкретных сервис-провайдеров. Применение этих средств реализуется через DLL.
WinSock, следуя модели WOSA, обеспечивает прикладной интерфейс для сетевого программирования (API - Application Programming Interface), который организует доступ к транспортным услугам и серверу имен сервис-провайдера (SPI - Service Provider Interfaces). SPI ориентирован на использование в рамках 32-битовой модели Microsoft Windows, включая Windows NT и Windows 95.
Транспортные сервис-провайдеры (например, TCP/IP или IPX/SPX) и именные серверы (DNS) в WinSock представляют собой динамические библиотеки (DLL) с одной точкой входа для процедур инициализации WSPStartup или NSPStartup (обратите внимание на то, что здесь под сервис-провайдером подразумевается система, способная предоставить определенный вид услуг). Все остальные процедуры сервис-провайдера сделаны доступными для WinSock DLL через диспетчерскую таблицу. Динамическая библиотека сервис-провайдера загружаются в память WinSock DLL только по мере необходимости и выгружаются, когда они более не нужны. Динамическая библиотека сервис-провайдера имеет обычно расширение .WSP или .NSP.


Процедуры WinSock SPI имеют префиксы:

WSP	WinSock Service Provider	для транспортных услуг сервис-провайдера;
WPU	WinSock Provider Upcall	для входа в WinSock DLL сервис-провайдера;
WSC	WinSock Configuration	для входа в WinSock DLL инсталляционных приложений;
NSP	Name Space Provider	для работы с сервером имен.

Сервис- провайдеры WinSock при работе со строками используют UNICODE. WinSock DLL выполняют необходимые преобразования при работе с приложениями, использующими ANSI или UNICODE.
Конкретный сервис-провайдер может поддерживать один или более протоколов. Так TCP/IP-провайдер должен как минимум поддерживать TCP- и UDP-протоколы, в то время как IPX/SPX-провайдер - IPX, SPX и SPX II. Каждый поддерживаемый протокол описывается в структуре WSAPROTOCOL_INFO, а набор таких структур представляет собой каталог используемых протоколов (более детальную информацию по данной тематике можно найти по адресу: www.stardust.com/winsock/ws_specs.htm).
Одной из главных задач WinSock DLL является выполнение функции регулировщика информационных потоков между приложениями и сервис-провайдерами. Каждый сервис-провайдер взаимодействует только с WinSock DLL. WinSock DLL заботится об объединении потоков событий от разных сервис-провайдеров и направлении их приложению. Эта библиотека берет на себя функции арбитража и синхронизации. Взаимоотношения между сервис-провайдерами (даже если они поддерживают разные протоколы) улаживаются также WinSock DLL.
Работа WinSock DLL базируется на параметрах соединителей, которые задаются при формировании (socket и WSASocket), именно эта информация определяет, какой из сервис провайдеров будет задействован. Для выбора сервис провайдера используется процедура WSPSocket. В случае процедуры socket, WinSock DLL находит запись в структуре WSAPROTOCOL_INFO, которая соответствует входным параметрам (идентификатор стека протоколов, тип соединителя, протокол).
Сервис-провайдеры используют сетевые протоколы низкого уровня. WinSock DLL осуществляет управление на среднем уровне, обеспечивая связь транспортных протоколов с приложениями.


Транспортный SPI WinSock аналогичен WinSock API с точки зрения базовых процедур с соединителями. Так процедурам connect и WSAConnect ставится в соответствие WSPConnect; accept и WSAAccept - WSPAccept, а socket и WSASocket - WSPSocket.
Так как WinSock DLL не поставляется теперь разработчиками стека протоколов, расширение функциональных возможностей представляет определенную проблему. Для преодоления этих трудностей новейшие версии WinSock используют процедуру WSAIoctl, чтобы помочь сервис-провайдерам на практике реализовать какие-либо функциональные новшества.
Для введения расширенных возможностей приложение должно запросить указатель на точку входа в соответствующую программу. Это делается с помощью процедуры WSAIoctl, используя команду SIO_GET_EXTENSION_FUNCTION_POINTER. При этом входной буфер процедуры WSAIoctl содержит идентификатор запрашиваемой функции, в выходной буфер будет занесен указатель на нужную программу.
Идентификаторы, присвоенные новым функциям, должны быть уникальными глобальными идентификаторами (GUID - Global Unique IDentifiers), которые присваиваются им поставщиками сервис-провайдеров.
Для того чтобы транспортный протокол стал доступен через WinSock, он должен быть правильно инсталлирован и зарегистрирован в WinSock. Когда транспортный сервис-провайдер инсталлирован с помощью программы поставщика, соответствующая информация должна быть введена в конфигурационную базу данных, чтобы дать WinSock DLL необходимые данные для взаимодействия с сервис-провайдером.
В WinSock DLL содержится процедура WSCInstallProvider для инсталляции программ поставщиков и процедура выгрузки этих программ WSCDeinstallProvider.
Структура WSAPROTOCOL_INFO поставляется для каждого протокола и указывает на то, является ли этот протокол базовым, слоевым или стеком. Величина поля ProtocolChain.ChainLen интерпретируется как:

0	протокол слоя
1	базовый протокол (или стек, если стек состоит из одного протокола)
>1	стек протоколов.

Инсталляция стека протоколов возможна лишь после загрузки всех составных частей (слоевых и базовых протоколов).


Структура WSAPROTOCOL_INFO для стека протоколов использует поле ProtocolChain для описания длины стека и идентификации каждой из составных частей. Отдельные протоколы, входящие в стек последовательно перечислены в массиве ProtocolChain.ChainEntries, нулевой элемент списка соответствует первому протоколу слоя.
SDK (System Development Kit) для WinSock включает в себя инструментальную WinSock и отладочную DLL.
При разработке протокольно-независимых приложений для систем клиент-сервер нужно зарегистрировать имя сервера в банке имен, только это может сделать его доступным извне. Программа-клиент может функционировать лишь при условии, если она способна найти необходимую ей процедуру в поле имен и получить доступ к соответствующему транспортному протоколу и адресной информации. Для тех кто работает с протоколами TCP/IP это может в начале вызвать определенные трудности, которые компенсируются возможностями создания программ, пригодных для широкого класса самых разнообразных протоколов (например, Novell). Под работой с полем имен здесь подразумевается возможность установления соответствия между протоколом и адресным атрибутом сетевой услуги, которой присвоено какое-то имя. Примерами таких полей имен могут служить уже используемые системы DNS (Domain Name System), NDS (Netware Directory Services), X.500 и др. Поля имен могут быть динамическими, статическими и постоянными.
Динамические поля имен служат для краткосрочной регистрации сетевой услуги. Часто они базируются на широковещательной системе определения доступности той или иной услуги. Примерами таких систем являются SAP в среде Netware и NBP в среде Appletalk.
Статические поля имен формируются при первоначальном создании сервера имен и в дальнейшем могут изменяться лишь администратором сети. Традиционная система DNS относится именно к этой разновидности. Программа может воспользоваться таким банком имен, но не может произвести туда запись.
Постоянное поле имен сходно с динамическим - запись туда происходит в реальном масштабе времени, но после регистрации имя записывается в постоянную память и остается там до тех пор, пока не придет запрос на ликвидацию этой записи.


Примерами такой системы могут служить X.500 и NDS.
Некоторые поля имен организованы иерархически, X.500 и NDS, например, позволяют неограниченное число уровней вложения. Программные интерфейсы, предназначенные для посылки запросов в именные базы данных, сильно варьируются в зависимости от разновидности используемого поля имен. Сервер имен представляет собой резидентную программу, которая обеспечивает интерфейс между WinSock SPI и некоторой существующей базой данных имен.
Используемые услуги в WinSock группируются в классы услуг и в пределах класса имя услуги должно быть уникально. Примерами классов услуг могут служить FTP и SQL. Каждому классу присваивается имя и идентификатор (ID). Имя класса может не быть уникальным, но идентификатор обязан быть неповторимым. В качестве идентификаторов классов услуг в Winsock используются GUID (Globally Unique Identifiers). Для генерации GUID имеется специальная программа (UUIDGEN.EXE), которой может воспользоваться разработчик новых классов услуг.
DNS в Internet не имеет развитой системы для записи информации о классах услуг. Для TCP/IP-класса услуг GUID присвоен раз и навсегда.
WinSock DLL может маршрутизовать прикладные операции в пространстве имен и переадресовывать их соответствующим серверам имен.
Процедуры установки классов услуг, регистрации и обслуживания запросов осуществляются непосредственно через интерфейс API - SPI. Процедура WSAGetServiceClassNameByServiceClassId не имеет аналога среди операторов SPI, так как эта процедура WinSock DLL осуществляет обращение к NSPGetServiceClassInfo.
Переключение сервера имен из активного состояния в пассивное и обратно осуществляется с помощью процедуры WSCEnableNSProvider. В активном состоянии могут находиться несколько серверов имен одновременно. Инициализация сервис провайдеров выполняется с помощью процедуры WSPStartup (см. аналогично WSAStartup). Каждой процедуре WSPStartup должна соответствовать процедура WSPCleanup.

Процедура WSPSocket имеет параметр flags, который позволяет контролировать атрибуты соединителя.


Флаг WSA_FLAG_OVERLAPPED указывает на то, что данный соединитель будет использоваться в режиме совмещения процессов ввода/вывода.
Существуют атрибуты, ответственные за использование соединителя для работы в многоточечном и/или мультикастинг режимах. Только соединители, созданные для работы в многоточечном режиме, пригодны для запуска многоточечных сессий с помощью WSPJoinLeaf.
Соединитель, созданный для работы в блокирующем режиме, может быть преобразован в неблокирующий с помощью процедур WSPAsyncSelect, WSPEventSelect или WSPIoctl. Перевод соединителя в блокирующий режим производится посредством процедур WSPIoctl, если WSPAsyncSelect неактивен, или WSPEventSelect, если активен.
Процедура WSPCloseSocket ликвидирует дескриптор соединителя и все процессы, использующие этот соединитель, будут прерваны.
Понятие блокировки для среды Windows было фундаментальным. В WinSock 1.1, блокирующие процедуры WinSock были проблемой, так как они парализовали взаимодействие приложения и надстройки Windows, а применение псевдо-блокирующей техники не всегда давало удовлетворительный эффект. В ОС типа Windows 95 или Windows NT блокирующие процедуры уже не могут вызвать каких-либо проблем, более того, они уже представляются привлекательными. Интерфейс WinSock 2 API уже не поддерживает более псевдоблокировку, но для обеспечения совместимости с WinSock 1.1 он эмулирует этот механизм.
В среде Win16, где настоящее блокирование не поддерживается ОС, блокирующие процедуры, которые не могут быть закончены немедленно, обслуживаются с использованием псевдоблокировки. Сервис-провайдер инициализирует процедуру, после чего входит в цикл, внутри которого осуществляет доставку любых сообщений Windows и проверяет завершение процедуры. Если процедура завершилась, или если вызван оператор WSPCancelBlockingCall, происходит выход из цикла, а блокирующая процедура завершается с соответствующим результатом.
Эта схема вполне приемлема для простых приложений. Но она неприемлема для приложений, где должны реализоваться сложные схемы доставки сообщений, например, для модели MDI (Multiple Document Interface).


Для таких приложений псевдоблокировка должна быть реализована в самом приложении. Сервис-провайдер в этом случае должен вызывать именно этот цикл. Для этого он должен получить указатель на него, обратившись к WPUQueryBlockingCallback.
Сервис-провайдер WinSock не может исходить из предположения, что псевдоблокировка, используемая приложением, обеспечит обработку сообщений. Если приложение не приспособлено для решения таких задач, оно откликнется флагом FALSE. Если сервис-провайдер требует обработки сообщений для своих внутренних нужд, он может вызвать процедуру PeekMessage до передачи управления циклу псевдоблокировки в приложении.

Сервис-провайдер WinSock использует псевдоблокировку лишь при выполнении определенных условий:
Программа определена как блокирующая,
Соответствующий соединитель работает в блокирующем режиме,
Запрос не может быть выполнен немедленно.
Если условия не выполнены, уход в цикл псевдоблокировки осуществлен не будет.
Если во время цикла псевдоблокировки получено сообщение Windows, существует опасность того, что будет предпринята попытка вызова еще одной процедуры WinSock. Из-за трудностей управления этим процессом WinSock 1.1 запрещает такие вызовы. Любая попытка осуществить вложенный вызов процедур WinSock вызовет ошибку WSAEINPROGRESS. Для WinSock 1.1 это ограничение справедливо как для блокирующих, так и для неблокирующих процедур. Имеется два исключения из этого правила. Это процедура, которая позволяет приложению проверить, находится ли система в цикле псевдоблокировки (WSAIsBlocking), и процедура ухода из этого цикла (WSPCancelBlockingCall).
WinSock 2 DLL имеет средства для формирования объектов событий, как для приложения, так и для сервис-провайдера, хотя на практике объекты событий создаются в основном приложениями. Для формирования объектов событий в WinSock имеется оператор WPUCreateEvent. Дескриптор объекта события имеет смысл лишь в контексте программы, его сформировавшей. В среде Win32 работа с объектами событий выполняется самой операционной системой.


Объекты событий в WinSock представляют собой простые конструкции, которые могут создаваться и уничтожаться, они могут устанавливаться и сбрасываться. Клиент создает объект события и передает его дескриптор в качестве параметра таким процедурам как WSPSend и WSPEventSelect. Когда оговоренные условия выполнены, сервис-провайдер использует дескриптор для того, чтобы установить объект события с помощью оператора WPUSetEvent. При этом клиент WinSock SPI может находиться в состоянии блокировки-ожидания или в режиме запроса, ожидая, когда объект события будет установлен. Клиент может сбросить объект события в нуль, снова его установить и использовать снова.
Субъект (приложение или сервис-провайдер), создавший объект события, ответственен и за его ликвидацию. Сервис-провайдер может это сделать с помощью WPUCloseEvent.
Одной из главных задач сервис-провайдера является сообщение приложению о том, что произошло соответствующее сетевое событие. Список сетевых событий включает в себя:

FD_CONNECT	Канал до удаленной ЭВМ или для мультикастинг-сессии сформирован
FD_ACCEPT	Удаленная ЭВМ выставила запрос на соединение;
FD_READ	Получены данные и их можно считать;
FD_WRITE	В буферах сервис-провайдера появилось свободное место и можно послать очередную порцию информации;
FD_OOB	Для чтения доступна высокоприоритетная информация;
FD_CLOSE	Удаленная ЭВМ закрывает канал;
FD_QOS	Произошло изменение оговоренного значения QOS (качества услуг);
FD_GROOUP_QOS	Произошло изменение оговоренного значения QOS для данной группы соединителей.

Стандартный BSD-интерфейс соединителей имеет только одно средство получить информацию о сетевых событиях - оператор select. Этот метод не может дать информацию о событиях FD_QOS и FD_GROUP_QOS.
В Windows Sockets 1.1 используется асинхронный механизм получения информации о сетевых событиях. Для регистрации интересующих событий можно использовать процедуру WSPAsyncSelect. Когда нужное сетевое событие произойдет, соответствующему окну будет послано сообщение, заданное клиентом.


Сервис- провайдер использует для тех же целей процедуру WPUPostMessage. В среде Win32 этот метод получения данных о событиях нельзя считать эффективным.

WSPEventSelect ведет себя практически также как WSPAsyncSelect за исключением того, что вместо посылки сообщения Windows при сетевом событии типа FD_XXX, устанавливается соответствующий объект события.
Факт прихода сетевого события FD_XXX сервис-провайдером запоминается. Вызов процедуры WSPEnumNetworkEvents вызывает копирование текущего содержимого памяти сетевых событий в буфер клиента, а основная память событий очищается.
Сервис-провайдеры (ISDN или ATM) могут использовать групповые значения QOS при формировании виртуального канала и повышения эффективности своей работы. Пакеты для соединителей в пределах группы мультиплексируются обычным образом.
Операторы WSPSocket и WSPAccept предназначены для формирования соединителей и подключения новых соединителей, к той или иной группе. Однажды включенный в группу соединитель остается в ней до своего закрытия. Группа прекращает свое существование, лишь когда последний соединитель группы будет закрыт. Идентификатор группы соединителей может быть получен с помощью оператора WSPGetSockOpt с опцией SO_GROUP_ID. Узнать об относительном приоритете соединителя в группе можно, воспользовавшись процедурой WSPGet/SetSockOpt с опцией SO_GROUP_PRIORITY.
Групповое значение QOS можно задать при выполнении WSPConnect, или WSPIoctl с SIO_SET_GROUP_QOS, если специфицированный соединитель является “учредителем” группы. Оператор WSPIoctl с SIO_GET_GROUP_QOS может использоваться для получения группового значения QOS заданного соединителя.
Для провайдеров, поддерживающих группирование соединителей, минимально необходимы следующие функции:
Создание новых групп и присвоение им уникальных идентификаторов.
Возможность включения соединителя в одну из существующих групп.
Учет провайдером значения QOS порождающего соединителя при формировании списка параметров нового соединителя, включаемого в группу.


Существуют группы двух видов. Одни включают в себя соединители, ориентированные на соединение, они могут быть подключены только к определенному адресу ЭВМ, остальные группы относятся к другому виду. Провайдер не может включить в группу соединитель, который не удовлетворяет этому условию. Провайдер не может также выполнить соединение, если адресат не соответствует адресу места назначения группы соединителей. Групповой адрес места назначения определяется, когда выполняется процедура connect для первого из соединителей группы.
Единственный индивидуальный параметр соединителя в группе - его внутренний уровень приоритета. Провайдер должен уметь считывать значение приоритета, но он может полностью игнорировать этот параметр. В настоящее время не существует каких-либо механизмов для сопоставления приоритетов соединителей, принадлежащих к разным группам, или соединителей вне групп. Поддержка провайдеров групп не означает непременную поддержку различного качества услуг (QOS, см. RFC-1363).
Поддержание работы с приоритетами соединителей в пределах группы является рекомендательным требованием. Схема приоритетов WinSock 2 имеет смысл лишь для мультиплексирования данных при соединении точка-точка, например, в случае телефонной связи или любых других вариантах, реализующих коммутацию каналов.
Характер информационного обмена описывается спецификацией потока (flow specs), для каждого соединителя используется две такие спецификации, по одной для каждого из направлений обмена. Запрос на соединение реализуется через процедуры WSPConnect или WSPIoctl с кодом команды SIO_SET_QOS/SIO_SET_GROUP_QOS. Спецификация потока параметрически задает уровень сервиса (QOS) и определяет механизм адаптации приложения к сетевым условиям.
В WinSock 2 спецификация потока содержит следующие характеристики QOS:
Описание источника информационного потока, которое характеризует способ, используемый приложением, для введения потока данных в сеть. Эта спецификация выполняется в терминах модели пакетов символов (token bucket) и включает частоту символов, их размер, частоту пакетов символов и их размер, а также максимальное значение информационного потока.


Задержка (latency) - приемлемые верхние пределы задержки и ее вариации.
Гарантированный уровень обслуживания. Предполагается, что провайдер, который не способен обеспечить требуемый уровень сервиса (QOS), не сможет быть подключен.
Цена (параметр зарезервирован на будущее).
Параметры, специфические для провайдера (спецификация потока может быть расширена, чтобы имелась возможность описать некоторые особенности провайдера).
Для протоколов, ориентированных на соединение более удобно для приложения оговаривать QOS при формировании соединения. Это делается путем запроса WSPConnect, направленного сервис-провайдеру. Если QOS было задано с помощью WSPIoctl, его значение может быть переписано при выполнении процедуры WSPConnect.
Бессвязные соединители могут также использовать WSPConnect с целью установления определенного уровня QOS для канала связи с партнером
После каждой попытки установить связь провайдер производит коррекцию спецификации потока для того, чтобы наилучшим образом отразить реальную ситуацию в сети. Предполагается, что клиенты могут использовать текущую сетевую информацию для того, чтобы оптимально реализовать возможности сети.
Но после того как информация о состоянии сети получена, условия могут измениться, партнеры могут согласовать другой уровень QOS, так что приложение должно быть готово ко всему. Для информирования клиента о возможных изменениях условий в Winsock используется механизм сетевых событий (FD_QOS и FD_GROUP_QOS). Сервис-провайдер должен генерировать события типа FD_QOS/FD_GROUP_QOS, если уровень сервиса изменился значительно. Клиент должен использовать WSPIoctl с кодами команд SIO_GET_QOS и/или SIO_GET_GROUP_QOS, чтобы получить соответствующую спецификацию потока и выяснить, изменился ли уровень сервиса (QOS). Структура QOS должна актуализоваться вне зависимости от типа события FD_QOS/FD_GROUP_QOS. Если новый уровень сервиса неприемлем, клиент может попытаться приспособиться к новым условиям или закрыть соединение. При повторной попытке согласовать уровень QOS успешный выход из процедуры WSPIoctl указывает, что новое значение QOS приемлемо.


Структура QOS в WinSock 2 описана в файле Winsock2.h и представлена ниже.
typedef enum

{

BestEffortService,

ControlledLoadService,

PredictiveService,

GuaranteedService

} GUARANTEE;

typedef struct _flowspec

{

int32	TokenRate;	/* В байтах/сек */
int32	TokenBucketSize;	/* В байтах */
int32	PeakBandwidth;	/* В байтах/сек */
int32	Latency;	/* В микросекундах */
int32	DelayVariation;	/* В микросекундах */

GUARANTEE LevelOfGuarantee;

int32	CostOfCall;	/* Зарезервировано для будущего использования, должно быть = 0 */
int32	NetworkAvailability	/* только для чтения: 1, если есть доступ, 0, если нет */

} FLOWSPEC, FAR * LPFLOWSPEC;

typedef struct _QualityOfService

{

FLOWSPEC	SendingFlowspec;	/* Спецификация потока для данных */
		/* Посылка */
FLOWSPEC	ReceivingFlowspec;	/* Спецификация потока для данных */
		/* Прием */
WSABUF	ProviderSpecific;	/* Дополнительный провайдер */
		/* Специфические параметры */

} QOS, FAR * LPQOS;

Определения:

LevelOfGuarantee	Согласуемый уровень сервиса. Определены четыре уровня: гарантированный, предсказуемый, контролируемая загрузка и лучшее, что возможно. Предсказуемый уровень сервиса может дать наилучший результат при использовании определенного ресурса сети, в то время как гарантированный уровень соответствует необходимому уровню услуг конкретного приложения. Провайдеры могут предоставлять один, оба или ни одного их этих двух видов услуг.
GuaranteedService	Провайдер, поддерживающий гарантированный уровень сервиса, использует алгоритм очередей, в котором поток изолируется от влияния других потоков, и гарантирует, на сколько возможно, пропускную способность. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Если поток находится в пределах допустимого, то гарантируется и задержка отклика. Этот вид сервиса предусмотрен для приложений реального времени.
PredictiveService	Провайдер, поддерживающий предсказуемый уровень сервиса, гарантирует пропускную способность, по крайней мере равную TokenRate, на время соединения. Если отправитель шлет данные с большей скоростью, сеть может задержать или даже ликвидировать “лишнюю” часть потока. Значение задержки не гарантируется. Этот вид сервиса предназначен для приложений, способных адаптироваться к вариациям качества услуг, например, передача видео изображения.
ControlledLoadService	Этот уровень сервиса предполагает, что система сетевых устройств, которыми пользуется приложение, обеспечит условия работы, близкие к тем, которые достижимы при незагруженных каналах, для используемой транспортной среды. Приложения, использующие этот уровень сервиса, могут ожидать что: 1. Большая часть передаваемых пакетов будет успешно доставлена (процент потерь определяется частотой ошибок транспортной среды). 2. Задержка доставки не будет заметно превышать минимальное время распространения сигнала в используемой транспортной среде.
BestEffortService	Провайдеры, поддерживающие уровень сервиса “лучшее что возможно”, рассматривают спецификацию потока, как руководство к действию. И пытаются сделать все возможное, чтобы поддержать запрашиваемый уровень сервиса (без каких-либо твердых гарантий).
TokenRate/TokenBucketSize	Модель “блоков символов” (Token bucket model) используется для задания верхнего предела скорости обмена. Величина value -1 в этом случае означает, что не существует никаких ограничений на скорость обмена. Значение TokenRate (частота символов) выражается в байтах в сек, а TokenBucketSize в байтах. Блок имеет определенный объем (TokenBucketSize), который заполняется с определенной скоростью (TokenRate). Если в блоке достаточно места, приложение может посылать данные, что приводит к уменьшению свободного места. Если же свободного места нет, приложение должно прервать обмен и ждать. Если приложение в течение определенного времени слало данные со скоростью меньше чем TokenRate, оно может затем на некоторое время превысить эту скорость.
PeakBandwidth	Значение этого поля (выражается в байтах в сек) ограничивает максимальную скорость пересылки пакетов приложением. Промежуточные системы могут использовать эту величину для оптимизации использования имеющихся ресурсов.
Latency	Характеризует максимально приемлемую задержку между посылкой бита отправителем и его получением адресатом (в миллисекундах).
DelayVariation	Значение этого поля в миллисекундах характеризует разницу между максимальной и минимальной задержкой доставки пакетов. Этот параметр используется приложением для расчета объема входного буфера.
CostOfCall	Зарезервировано на будущее и должно равняться нулю.
NetworkAvailability	Это поле, доступное провайдерам только в режиме чтения, используется для сообщения приложению о доступности транспортной среды (например, знакомая многим ситуация потери спутника антенной).

<


Приложения, которые не склонны иметь дело с QOS-структурой непосредственно, могут воспользоваться именами известных видов сервиса и получить нужные данные с помощью запроса WSPGetQOSByName.
Прежде чем использовать соединитель, надо связать его с локальным адресом. Это выполняется с помощью процедуры WSPBind, или WSPConnect.
Сервер сначала создает соединитель, связывает его с известным локальным адресом (что позволяет клиенту найти его) и переводит соединитель в режим ожидания посредством WSPListen, готовя его к приему запросов на соединение. Одновременно система подготавливает структуру для формирования очереди запросов. Сервис-провайдер заносит поступающие запросы в очередь, где они ожидают обработки. Запросы могут быть удалены клиентом из очереди по таймауту.
Если использован соединитель блокирующего типа, сервер может немедленно вызвать процедуру WSPAccept, которая вызовет блокировку на время ожидания запроса на соединение. В качестве альтернативы сервер может использовать один из механизмов обработки сетевых событий, описанный ранее. В зависимости от выбранного механизма провайдер или пошлет сообщение Windows или даст знать о приходе запроса на соединение через объект события.
Клиент со своей стороны создаст соответствующий соединитель, запустит процедуру подключения и пошлет запрос WSPConnect, указав известный адрес сервера. Если соединитель является блокирующим, WSPConnect вызовет блокировку до тех пор пока сервер не получит и не обработает запрос на соединение или пока не произойдет таймаут. Клиент должен использовать механизм сетевых событий для отслеживания процесса соединения.
Когда сервер запускает процедуру WSPAccept, сервис-провайдер инициализирует программу проверки условий, поставляемую приложением. В качестве параметров обращения используется информация, полученная вместе с запросом на соединение (берется из очереди запросов). Эта информация включат в себя адрес подключаемой ЭВМ, данные о пользователе и характеристику QOS, если таковая имеется.


На основе полученной информации сервер определяет, принять данный запрос или нет.
Если сервер принял запрос, он должен сформировать новый соединитель с теми же атрибутами что и соединитель ожидавший прихода запроса. Исходный соединитель остается в режиме ожидания последующих запросов.
Для получения локального адреса сопряженными соединителями используется запрос WSPGetSockName. Это особенно полезно, когда послан запрос WSPConnect без предварительного вызова процедуры WSPBind.
Как было сказано ранее, процедура WSPAccept позволяет воспользоваться поставляемой клиентом программой проверки условий, которая осуществляет условную обработку запросов на соединения, ожидающие обслуживания. Принятие решения осуществляется на основе информации, поступающей вместе с запросом (идентификатор источника запроса, QOS и т.д.). Если программа проверки условий возвращает флаг CF_ACCEPT, формируется новый соединитель с теми же свойствами, что и исходный. Если программа проверки вернет флаг CF_REJECT, запрос на соединение будет отвергнут. При возвращении флага CF_DEFER принятие решения откладывается, а запрос на соединение остается в очереди. Клиент должен будет осуществить вызов WSPAccept еще раз.
Некоторые протоколы позволяют переслать информацию в процессе установления связи. Если такая информация получена, она помещается в буфер провайдера, а WinSock SPI получает указатель на этот буфер и длину записи. Если клиент WinSock SPI желает послать некоторую информацию в ответ, он может скопировать ее в буфер, предоставляемый сервис-провайдером.
Разрыв соединения может быть выполнен несколькими способами. Для инициализации прерывания связи можно, например, применить процедуру WSPShutdown (с параметром how равным SD_SEND или SD_BOTH), и WSPSendDisconnect. Процедура WSPCloseSocket может быть применена и для аварийного прерывания соединения.
Сервис провайдер сообщает о разрыве соединения по инициативе удаленного партнера с помощью сетевого события FD_CLOSE. При реализации процедуры разрыва соединения возможен обмен определенной информацией, если это предусмотрено используемым протоколом.


Инициатор разрыва связи может вызвать WSPSendDisconnect, чтобы сообщить, что данных больше посылаться не будет и можно ликвидировать соединение. При этом может быть послана некоторая служебная информация, предусмотренная протоколом обмена. Для чтения этой информации партнер может воспользоваться оператором WSPRecvDisconnect. По завершении этого обмена обе стороны вызывают процедуры WSPCloseSocket.

Следует различать процедуры прерывания (shutdown) связи и ее разрыва (close). Прерывание связи сопряжено с определенным диалогом между партнерами, после чего связь “замораживается”, но дескриптор связи сохраняется. Существует два типа прерывания связи: аварийное (аппаратное) и нормальное. При нормальном прерывании любые данные, которые стояли в очереди, пересылаются до завершения процесса прерывания. При аварийном же прерывании непосланная информация теряется.
В Windows Sockets, как процедура WSPShutdown, так и WSPSendDisconnect могут использоваться для инициализации прерывания связи. В то время как запрос WSPCloseSocket служит для ликвидации дескрипторов соединителей и освобождения связанных с ними ресурсов.
Путем установки определенных значений для опций соединителей SO_LINGER и SO_DONTLINGER можно получит следующие варианты реализации процедуры WSPCloseSocket.
Процедура аварийного прерывания соединения, которая возвращается из WSPCloseSocket немедленно.
Нормальное прерывание соединения (graceful shutdown); задержка исполнения до завершения исполнения процедуры или до истечения заданного времени. Если таймаут наступает до завершения процедуры прерывания соединения, запускается процесс аварийного разрыва соединения.
Нормальное прерывание соединения с немедленным возвратом и завершением процедуры прерывания в фоновом режиме. Этот алгоритм реализуется по умолчанию. Приложение при этом не знает, когда и как завершается процесс прерывания соединения.
Для соединителей, соответствующих протоколам неориентированных на соединение, работа, выполняемая оператором WSPConnect, связана главным образом с установлением адреса места назначения по умолчанию, что позволит в дальнейшем использовать соединитель в операциях обмена, ориентированных на соединение (WSPSend and WSPRecv).


Любые дейтограммы, полученные от отправителя с адресом, отличным от специфицированного, будут проигнорированы.
Место назначения по умолчанию может быть изменено с помощью повторного вызова WSPConnect. Любая дейтограмма из входной очереди будет отброшена, если новый адрес отличается от адреса, заданного в предыдущем WSPConnect.
Если новый адрес равен нулю, соединитель будет отсоединен, так как удаленный адрес не определен, в результате операторы WSPSend и WSPRecv возвратят флаг ошибки WSAENOTCONN, в то же время WSPSendTo и WSPRecvFrom могут использоваться по-прежнему. Существует три базовых способа выполнения операций ввода/вывода:
Блокирующий ввод/вывод,
Неблокирующий ввод/вывод с асинхронными сетевыми событиями,
Совмещенный ввод/вывод.
Первый вариант является режимом по умолчанию, неблокирующий вариант может использоваться на любом соединителе, который поставлен в соответствующий режим. Третья разновидность обмена реализуется только на соединителях, которые при формировании были объявлены совмещенными. Процедуры посылки WSPSend и WSPSendTo и приема WSPRecv и WSPRecvFrom реализуют все три указанных режима обмена. Сервис-провайдеры определяют метод обмена на основе режима работы соединителя, атрибутов и входных параметров.
Простейшим режимом обмена в WinSock 2 является блокирующий ввод/вывод. Этот режим устанавливается по умолчанию. Любая операция ввода/вывода на блокирующем соединителе вернет управление системе только по завершении процедуры. Таким образом, в ходе любой сессии может выполняться только одна операция ввода/вывода. Это простой режим, но отнюдь не самый эффективный.
Если соединитель находится в неблокирующем состоянии, любая операция обмена должна либо завершаться немедленно, либо возвращать флаг ошибки WSAEWOULDBLOCK, указывая, что операция не может быть завершена корректно. Необходим механизм для определения, когда следует попытаться выполнить операцию еще раз. Для решения этой проблемы определен список сетевых событий, наступление которых может контролироваться с помощью процедур WSPSelect, WSPAsyncSelect или WSPEventSelect.


В WinSock 2 впервые разрешено совмещение нескольких процедур ввода/вывода и потребована поддержка этого режима всеми сервис-провайдерами. Этот режим возможен только для соединителей, сформированных с помощью WSPSocket с флагом WSA_FLAG_OVERLAPPED.
Для приема данных клиент может воспользоваться процедурами WSPRecv или WSPRecvFrom, чтобы указать буферы, куда будут записываться данные. Если один или более буферов подготовлены приложением до начала обмена, информация будет заноситься непосредственно в буферы пользователя и многоступенчатое копирование будет исключено. Если буферов заранее приложением не подготовлено, информация заносится сервис-провайдером во внутренний буфер и система ждет запроса, чтобы перенести данные в буфер приложения. Исключением из этого правила является случай, когда приложение использует WSPSetSockOpt для установления нулевого размера входного буфера. В этом варианте данные принимаются лишь при наличии указателей на буфер приложения. При посылке информации клиенты для выдачи указателей на буфер данных используют WSPSend или WSPSendTo.
В совмещенном режиме процедуры посылки и получения данных завершаются немедленно. Полученный по возврату нуль, указывает на то, что процедура завершилась успешно. То есть, сформирован соответствующий объект события или программа завершения установлена в очередь с помощью WPUQueueApc. Возврат флага SOCKET_ERROR, сопряженного с кодом ошибки WSA_IO_PENDING, указывает, что совмещенная операция успешно начата и будет позднее сообщено, когда выходной буфер будет свободен или входной буфер будет заполнен. Любые другие коды ошибок говорят о сбое.
Совмещаться могут как операции ввода, так и вывода. Следует иметь в виду, что если было послано несколько блоков данных друг за другом, сообщения о завершении операций по их пересылке могут прийти в другом порядке. Тоже может произойти и при приеме данных.
Сервис-провайдеры имеют два способа сообщать о завершении совмещенных по времени операций: установка объекта события, заданного программой-клиентом, или запуск заданной клиентом программы завершения.


В обоих случаях каждой из совмещенных операций ставится в соответствие структура WSAOVERLAPPED. Память для размещения этой структуры выделяется клиентом и используется им для указания того, какой из объектов следует установить при завершении процесса обмена. Структура WSAOVERLAPPED может использоваться сервис-провайдером для хранения дескриптора соответствующей совмещенной процедуры. Для извлечения нужной информации из указанной структуры можно воспользоваться оператором WSPGetOverlappedResult.
Если параметр lpCompletionRoutine совмещенной операции не равен нулю, то сервис-провайдер может вызвать программу завершения, специфицированную клиентом. WinSock DLL предлагает асинхронную процедуру вызова (APC) программ завершения обмена.
Для реализации той или иной функции в рамках сессии сервис-провайдер вызывает сначала процедуру WPUQueueApc. Сервис-провайдер должен позаботиться о том, чтобы процесс, соответствующий выбранному контексту, был активным до вызова функции WPUQueueApc.

WPUQueueApc берет в качестве входных параметров указатель на структуру WSATHREADID, указатель на процедуру APC и 32-разрядный контекстный код. Сервис-провайдеры всегда получают указатель на соответствующую структуру WSATHREADID через параметр lpThreadId. Провайдер должен запомнить структуру WSATHREADID и выдать указатель на ее копию в качестве параметра оператора WPUQueueApc.
Так как механизм APC работает только с одним 32-разрядным контекстным кодом, процедура APC не может быть сама программой завершения, заданной клиентом. Сервис-провайдер должен выдать указатель на свою собственную процедуру APC, которая, используя контекстный код, обеспечивает доступ к необходимой информации для совмещенной операции обмена и вызывает заданную клиентом программу завершения.
Сервис-провайдер должен позволить клиентам WinSock 2 вызов процедур чтения или записи во время выполнения процедуры завершения обмена и гарантировать, что для данного соединителя не будет допущено вложение операций завершения.
Структура WSAOVERLAPPED создает коммуникационную среду между запуском совмещенной операции обмена и последующим ее завершением.


Структура WSAOVERLAPPED совместима со структурой OVERLAPPED для Win32:
typedef struct _WSAOVERLAPPED {

DWORD	Internal;	// Зарезервировано
DWORD	InternalHigh;	// Зарезервировано
DWORD	Offset;	// Зарезервировано
DWORD	OffsetHigh;	// Зарезервировано
WSAEVENT	hEvent;

} WSAOVERLAPPED, LPWSAOVERLAPPED;

Internal и InternalHigh	Резервное поле, которое используется объектом, вовлеченным в совмещенные операции ввода/вывода. Для IFS-провайдеров это поле используется базовой операционной системой (IFS - Installable File System - инсталлируемая файловая система).
Offset и OffsetHigh	Поле зарезервировано для сервис-провайдеров.
hEvent	Если совмещенные операции ввода/вывода запущены в отсутствии программ завершения (lpCompletionRoutine равно NULL), тогда это поле должно содержать дескриптор (указатель) объекта WSAEVENT. В противном случае (lpCompletionRoutine не равно NULL) клиент может использовать это поле как сочтет нужным.

Приоритетные данные могут доставляться пользователю независимо от обычной информации. Для коммуникационных протоколов, где предусмотрена пометка данных как срочные (например, TCP, позволяющий доставку срочной информации в общем потоке данных) система извлекает приоритетную информацию из общего потока и запоминает отдельно.
Пользователь может определить, имеется ли приоритетная непрочитанная информация, используя процедуру WSPIoctl(SIOCATMARK). Для протоколов, где положение приоритетной информации в общем потоке имеет смысл, сервис-провайдер обеспечивает указатели, определяющие это положение. Для таких протоколов допускается обработка приоритетных данных в общем информационном потоке. Это достигается путем установки опции соединителя SO_OOBINLINE (OOB - Out-Of-Band). Для других протоколов, где блоки приоритетных данных независимы от общего информационного потока, попытка установить опцию SO_OOBINLINE вызовет ошибку. Приложение может использовать команду SIOCATMARK WSPIoctl для определения наличия непрочитанных блоков приоритетной информации.


При запрещении SO_OOBINLINE (disabled - значение по умолчанию):
Сервис-провайдер WinSock сообщает клиенту о FD_OOB событиях, если клиент зарегистрирован для этого с помощью процедуры WSPAsyncSelect, точно таким же образом FD_READ используется для сообщения о присутствии обычных данных. Таким образом, FD_OOB посылается, когда поступает приоритетная информация, а также когда данные прочитаны с использованием флага MSG_OOB, в условиях присутствия приоритетных данных, подлежащих чтению. Сообщение FD_READ для приоритетных данных не посылается.
Сервис-провайдер WinSock возвращает соответствующий набор exceptfds при выполнении процедуры WSPSelect, если приоритетные данные присутствуют в очереди соединителя.
Клиент может вызвать WSPRecv с MSG_OOB для чтения блока приоритетных данных.
Клиент может вызвать процедуру WSPRecv без MSG_OOB для чтения потока обычной информации. Блок приоритетных данных не может появиться в потоке обычных данных. Если приоритетные данные остаются после запроса WSPRecv, сервис-провайдер дает сообщение клиенту с помощью флага FD_OOB или через exceptfds при использовании запроса B>WSPSelect.
Для протоколов, где приоритетные данные находятся в потоке обычных данных, одного запроса WSPRecv недостаточно. Один вызов WSPRecv вернет обычные данные до маркера, и потребуется второй запрос WSPRecv для чтения данных после маркера.
При разрешении SO_OOBINLINE (enabled):
Сообщение FD_OOB не посылается для приоритетных данных, а процедуры WSPSelect и WSPAsyncSelect рассматривают эти данные как обычные, о типе информации можно судить по readfds соединителя или по сообщению FD_READ, соответственно.
Клиент не может осуществлять вызов WSPRecv с флагом MSG_OOB для чтения блока приоритетных данных - в противном случае будет получен код ошибки WSAEINVAL.
Клиент может вызвать WSPRecv без флага MSG_OOB. Любая приоритетная информация будет доставлена в потоке обычных данных. Приоритетные данные не будут никогда перемешаны с обычными данными, необходимо три запроса чтения для получения приоритетной информации.


Первый запрос возвращает обычные данные, предшествующие приоритетным, второй - возвращает приоритетные данные, третий возвращает нормальные данные, следующие за приоритетными.
Программа WSPAsyncSelect прекрасно приспособлена для выявления приоритетных данных, когда SO_OOBINLINE находится в состоянии выключено.
Использование соединителя несколькими процессами одновременно организовано следующим образом. Базовый процесс для получения специальной структуры WSAPROTOCOL_INFO вызывает WSPDuplicateSocket. Эта процедура для передачи структуры другому процессу использует межпроцессный механизм коммуникаций (IPC). Последний процесс использует структуру WSAPROTOCOL_INFO при обращении к WSPSocket. Дескриптор соединителя, полученный в результате этой операции, будет дополнительным дескриптором исходного соединителя, который с этого момента может использоваться двумя процессами.
Такой механизм разработан для того, чтобы удовлетворить как требованиям однопроцессной версии Windows 3.1, так и многопроцессным вариантам Windows 95 и NT. Следует иметь в виду, что совместное использование соединителей несколькими процессами возможно и без использования WSPDuplicateSocket, так как дескриптор соединителя доступен для всех процессов.
Когда формируется дескриптор нового соединителя IFS-провайдер должен вызвать WPUModifyIFSHandle, а не-IFS-провайдер должен вызвать WPUCreateSocketHandle (IFS - Installable File System).
Так как реально дублируются дескрипторы, а не сами соединители, все параметры соединения оказываются абсолютно идентичными.
Контроль состояния используемых совместно соединителей осуществляется посредством WSPAsyncSelect и WSPEventSelect. Вызов одного из указанных запросов с одним из дескрипторов соединителя в качестве параметра, аннулирует любую предшествующую регистрацию событий для указанного соединителя, вне зависимости от того, какой из дескрипторов использован для новой регистрации. Таким образом, нельзя для процесса A иметь FD_READ-события, а для процесса B получать FD_WRITE-события.


Процесс может вызвать WSPCloseSocket для дублирующего соединителя и старый дескриптор будет ликвидирован, в то время как сам соединитель, ему соответствующий, останется открытым вплоть до выполнения процедуры WSPCloseSocket.
Два или более дескрипторов могут соответствовать одному и тому же соединителю и использоваться независимо для операций ввода/вывода. Однако, интерфейс WinSock не осуществляет какого-либо контроля за доступом, задача координации совместного использования соединителя является объектом ответственности самих процессов.
Для простоты в дальнейшем термин “многоточечный” будет означать широковещательный или мультикастинг.
В настоящее время многоточечные приложения (напр., IP-мультикастинг, ST-II, T.120, ATM UNI, и т.д.) значительно различаются по способу подключения узла к многоточечной сессии. Для декларации различных многоточечных атрибутов протокола в WinSock 2 используется структура WSAPROTOCOL_INFO. Просматривая эти атрибуты, программист может узнать, какие соглашения должны быть реализованы.
В плоскости управления существует два типа различных сессий: rooted и non-rooted (корневые и некорневые). В случае корневого управления существует участник, называемый c_root, который отличается от всех остальных членов многоточечной сессии, которые называются c_leaf (периферийные члены группы). Участник сессии c_root должен оставаться в списке участников на протяжении всей многоточечной сессии, так как без его участия сессия будет прервана. c_root обычно инициирует многоточечную сессию путем установления связей с участниками типа c_leaf. c_root может вводить членов в группу, но c_leaf может подключиться к c_root позднее.
Для некорневой плоскости управления, все участники многоточечной сессии являются периферийными узлами и не существует какого-то выделенного узла. Каждый c_leaf должен подключиться к многоточечной сессии, которая либо существует всегда (как в случае IP-мультикастинг адреса), или создана за счет какого-то внешнего механизма. При другом подходе c_root по-прежнему существует, но принадлежит сети в целом (не является одним из участников сессии).


Так как корневой узел существует, некорневая управляющая плоскость может рассматриваться как неявно корневая. Примерами такого рода неявно корневых схем являются система IP-мультикастинга многоточечные блоки управления (Multipoint Control Unit - MCU) в H.320-видеоконференциях и т.д.
В плоскости данных существует два стиля передачи информации: rooted и non-rooted (корневой и некорневой). В корневой плоскости данных существует выделенный участник, называемый d_root. Обмен данными происходит исключительно между d_root и остальными участниками многоточечной сессии, которые называются d_leaf. Трафик может быть однонаправленным или двунаправленным. Данные, посланные d_root, будут доставлены всем d_leaf, в то время как данные, отправленные d_leafs попадут только в d_root. В случае корневой плоскости данных не существует потока данных между периферийными узлами группы (d_leaf).
В некорневой плоскости данных, все участники эквивалентны и любая информация, посланная участником, будет доставлена всем членам группы (сессии). Аналогично каждый узел d_leaf может получать данные ото всех остальных узлов группы, а также от любых узлов, не участвующих в данной сессии.
В структуре WSAPROTOCOL_INFO имеется три поля атрибутов для выделения различных схем, используемых в плоскостях управления и данных:
XP1_SUPPORT_MULTIPOINT = 1 указывает на то, что этот протокол поддерживает многоточечные коммуникации, а последующие два поля имеют смысл.
XP1_MULTIPOINT_CONTROL_PLANE определяет, является ли плоскость управления корневой ( = 1) или не корневой ( = 0).
XP1_MULTIPOINT_DATA_PLANE указывает, является ли плоскость данных корневой ( = 1) или некорневой ( = 0).
В определенные моменты соединители, включенные в многоточечную сессию, могут по своему поведению отличаться от соединителей типа точка-точка. Так соединитель вида d_leaf в корневой плоскости данных может только посылать информацию участнику d_root. Это вызывает необходимость для клиента быть способным заявить об этом на стадии формирования соединителя.


Делается это с помощью четырех многоточечных атрибутных флагов, которым присваивается определенное значение через параметр dwFlags в WSPSocket:
SA_FLAG_MULTIPOINT_C_ROOT служит для создания соединителя, работающего как c_root. Это разрешено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости управления.
WSA_FLAG_MULTIPOINT_C_LEAF предназначен для генерации соединителя, работающего как c_leaf. Это возможно, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.
WSA_FLAG_MULTIPOINT_D_ROOT предполагает формирование соединителя, работающего как d_root. Это позволено, если в WSAPROTOCOL_INFO указано, что имеет место контекст корневой плоскости данных.
WSA_FLAG_MULTIPOINT_D_LEAF служит для создания соединителя, работающего как d_leaf. Это допускается, если XP1_SUPPORT_MULTIPOINT присутствует в соответствующей записи WSAPROTOCOL_INFO.
Когда создается многоточечный соединитель, один из двух флагов плоскости управления и один из двух флагов плоскости данных должны быть заданы в параметре dwFlags WSPSocket. Таким образом, при создании многоточечного соединителя могут быть реализованы четыре возможности: c_root/d_root, c_root/d_leaf, c_leaf/d_root, или c_leaf /d_leaf.
Когда d_leaf-соединители используются в некорневой плоскости данных, обычно желательно управлять системой так, чтобы отправляемый трафик попадал назад в тот же соединитель. Команда SIO_MULTIPOINT_LOOP для WSPIoctl используется для разрешения или запрещения зацикливания многоточечного трафика.
При использовании мультикастинга обычно необходимо специфицировать способ реализации сессии. Среди параметров сессии важную роль играет число вовлеченных сетевых сегментов. Для регулирования этого числа используется команда SIO_MULTICAST_SCOPE WSPIoctl. Нулевое значение числа сетевых сегментов означает, что мультикастинг пакеты не покинут пределы ЭВМ и могут попадать только во внутренние соединители. Значение единица (число по умолчанию) указывает, что мультикастинг-пакеты не могут выйти за пределы маршрутизатора локальной сети.


Большие величины позволят распространение сообщений, проходящих соответствующее число маршрутизаторов. Этот код идентичен параметру времени жизни (TTL) в IP-мультикастинге.
Многоточечный соединитель часто характеризуется его ролью в плоскости данных и управления. Следует иметь в виду, что один и тот же соединитель может иметь совершенно разную роль в разных плоскостях.
В схемах для корневой плоскости периферийные узлы добавляются в многоточечную группу одним из двух способов. В первом методе, корень использует WSPJoinLeaf для инициализации соединения с периферийным узлом и приглашает его быть участником сессии. Со стороны периферийного узла приложение должно создать c_leaf-соединитель и использовать WSPListen для установки его в режим ожидания (listen). Периферийный узел получит сообщение FD_ACCEPT, которое означает приглашение присоединиться к многоточечной сессии, и может объявить о своем желании подключиться путем вызова WSPAccept. Корневое приложения получит сообщение FD_CONNECT, когда операция подключения к группе завершена.
Во втором методе роли меняются. Корневой клиент создает соединитель c_root и переходит в режим ожидания (listen). Периферийный узел, желающий присоединиться к сессии, создает соединитель c_leaf и запускает WSPJoinLeaf, чтобы инициализировать соединение и доступ. Корневой клиент получает FD_ACCEPT, когда приходит запрос доступа, и принимает периферийный узел в группу посредством запроса WSPAccept. Периферийный узел получает FD_CONNECT, когда он принят в группу. Для случая IP-мультикастинга это эквивалентно опции соединителя IP_ADD_MEMBERSHIP. Читателей, знакомых с использованием несвязного UDP-протокола в IP-мультикастинге, может смутить семантика, ориентированная на соединение, присутствующая здесь. В частности указание на то, что используется запрос WSPJoinLeaf для соединителя UDP и ожидание сообщения FD_CONNECT могут вызвать недоразумение. Существуют уже, однако, прецеденты использования такой семантики для протоколов, не ориентированных на соединение.


Разрешено и иногда полезно, например, использовать процедуру WSPConnect для UDP-соединителей. Общим результатом применения семантики, ориентированной на соединение для несвязных соединителей, является ограничение на то, как эти соединители могут использоваться. UDP-соединитель, используемый в WSPJoinLeaf, будет иметь определенные ограничения, а ожидание сообщения FD_CONNECT (которое в этом случае указывает на посылку соответствующего IGMP-сообщения) является одним из таких ограничений. Существует три случая, когда клиент может использовать WSPJoinLeaf:
При работе в качестве многоточечного сервера (root), приглашая новый периферийный узел принять участие в сессии.
При работе в качестве периферийного узла, выполняя запрос подключения к корневой многоточечной сессии.
При работе в качестве периферийного узла, запрашивая подключение к некорневой многоточечной сессии (например, IP-мультикастинг).
Как было упомянуто ранее, WSPJoinLeaf используется для присоединения периферийного узла к многоточечной сессии. WSPJoinLeaf имеет те же параметры и семантику, что и WSPConnect за исключением того, что он возвращает дескриптор соединителя (как и WSPAccept), и имеет дополнительный параметр dwFlags. Параметр dwFlags показывает, будет ли соединитель работать только в режиме чтения, только в режиме записи или в обоих режимах. Только многоточечный соединитель может использоваться в качестве входного параметра s этой процедуры. Если многоточечный соединитель находится в неблокирующем состоянии, полученный дескриптор соединителя нельзя будет использовать до тех пор, пока не будет получено FD_CONNECT. Корневое приложение в многоточечной сессии может вызвать WSPJoinLeaf один или более раз для того, чтобы добавить новые узлы к текущей многоточечной сессии.
Параметры дескриптора соединителя, присланного WSPJoinLeaf, варьируются в зависимости от того, является ли дескриптор c_root или c_leaf. Для c_root соединителя, параметр name означает имя определенного периферийного узла, который должен быть добавлен, а возвращенный дескриптор соединителя является c_leaf и соответствует вновь добавленному периферийному узлу.


Некоторые многоточечные приложения могут позволять этому соединителю “постороннее” общение с корневым сервером.
При вызове WSPJoinLeaf для соединителя c_leaf, параметр name содержит адрес корневого приложения (для схемы корневого управления) или существующей многоточечной сессии (некорневая схема управления), и возвращенный дескриптор соединителя является тождественным по отношению ко входному дескриптору соединителя. В корневой схеме управления, корневой клиент должен поставить свой c_root соединитель в режим ожидания с помощью WSPListen. При запросе периферийного узла о присоединении к группе присылается стандартное сообщение FD_ACCEPT. Корневой клиент использует для подключения нового периферийного узла обычную процедуру WSPAccept. Запрос WSPAccept присылает дескриптор соединителя c_leaf, точно также как и WSPJoinLeaf.
Многоточечный корневой клиент является ответственным за прерывание сессии. Такое приложение может использовать WSPShutdown или WSPClosesocket для соединителя c_root, чтобы прислать всем членам группы соединителей c_leaf сообщение FD_CLOSE.
Рассмотрим семантическое отличие многоточечных и обычных соединителей. В плоскости управления имеется существенное семантическое отличие между соединителями c_root и обычными соединителями точка-точка:
Cоединитель c_root может использоваться в процедуре WSPJoinLeaf для подключения новых периферийных узлов;
Постановка соединителя c_root socket в режим ожидания (путем вызова WSPListen) не препятствует тому, чтобы соединитель c_root использовался оператором WSPJoinLeaf для добавления в список участников нового периферийного узла или для посылки или получения информации;
Закрытие соединителя c_root вызовет отправку всем сопряженным соединителям c_leaf сообщения FD_CLOSE.
Не существует какого-либо семантического различия между соединителем c_leaf и традиционным соединителем в плоскости управления, за исключением того, что соединитель c_leaf может использоваться процедурой WSPJoinLeaf, а использование соединителя c_leaf в WSPListen указывает на то, что должны восприниматься только запросы многоточечного соединения.


В плоскости данных семантическое отличие между соединителями d_root и традиционными соединителями заключается в следующем:
Данные, посланные на соединитель d_root, будут доставлены всем членам группы узлов, участвующих в многоточечном обмене;
Данные, полученные соединителем d_root, могут поступить от любого участника многоточечного обмена.
Соединитель d_leaf в корневой плоскости данных не имеет каких-либо семантических отличий от традиционных соединителей, однако, в некорневой плоскости данных информация, посланная на соединитель d_leaf, поступит ко всем периферийным узлам группы. Данные могут передаваться любым участником многоточечной сессии. Информация о том, находится ли соединитель d_leaf в корневой или некорневой плоскости данных, хранится в структуре соединителя WSAPROTOCOL_INFO.
Сводные данные по опциям Winsock 2 вместе с их значениями по умолчанию приведены в таблице 7.11 (см. также описания WSPGetSockOpt и WSPSetSockOpt). Сервис-провайдеры Windows должны распознавать все эти опции.

Номера и назначения используемых портов

Таблица 4.4.13.2. Номера и назначения используемых портов

Назначение	Порт	Пояснение
SNMP	161/TCP	Simple Network Management Protocol
SNMP	162/TCP	Trap
SMUX	199/TCP	SNMP Unix Multiplexer
SMUX	199/UDP	SNMP Unix Multiplexer
synoptics-relay	391/TCP	SynOptics SNMP Relay Port
synoptics-relay	391/UDP	SynOptics SNMP Relay Port
agentx	705/TCP	AgentX
snmp-tcp-port	1993/TCP	cisco SNMP TCP port
snmp-tcp-port	1993/UDP	cisco SNMP TCP port

Нотация протокола SET

Таблица 4.6.2.2. Нотация протокола SET

Понятие	Нотация	Описание
Группа (tuple)	{A,B,C}	Группа из нуля или более информационных элементов. Представляет документы или сообщения, обозначается идентификаторами, содержащими алфавитно-цифровые символы
Компонент	T={A,B,C}	Группе может быть присвоено имя. В этом случае T.A, T.B и T.C обозначают компоненты Т.
Упорядоченное объединение	A|B|C	Служит для обозначения упорядоченного объединения элементов A,B и C
Опционное значение	[A]	Значение A является опционным	Допускается любое вложение этих скобок
Выбор	<A,B,C>	Обозначает, что должно присутствовать одно из значений A,B или C
Опционный выбор	[<A,B,C>]	То же, что и предыдущее, но сам выбор опционен
Кратное использование	{A+}	Группа содержит один или более элементов A
	{A*}	Группа содержит нуль или более элементов A
	{[A]+}	Означает, что группа содержит: один или более элементов A в упорядоченном массиве, где каждое вхождение A является опционным (этот элемент может отсутствовать)
Исключающее ИЛИ	A	Обозначает операцию исключающее ИЛИ

Обязательные расширения сертификата ЕЕ

Таблица 4.6.2.34. Обязательные расширения сертификата ЕЕ.

	Сертификат владельца карты	Сертификат продавца		Сертификат расчетного центра
Расширение Х.509	Подпись	Подпись	Шифрова-ние ключа	Подпись	Шифрова-ние ключа
AuthorityKeyIdentifier	Х	Х	Х	Х	Х
KeyUsage	Х	Х	Х	Х	Х
PrivateKeyUsagePeriod	Х	Х		Х
CertificatePolicies	Х	Х	Х	Х	Х
SubjectAltName	O	O	O	O	O
BasicConstraints	Х	Х	Х	Х	Х
IssuerAltName	O	O	O	O	O
Частное расширение
HashedRootKey
CertificateType	Х	Х	Х	Х	Х
MerchantData		Х	Х
CardCertRequired					Х
Tunneling					Х
SETExtensions					Х

Х – обязательный

O - опционный

Обязательные расширения сертификатов СА

Таблица 4.6.2.35. Обязательные расширения сертификатов СА

	СА				Корневой центр сертификации
Расширение Х.509	Цифровая подпись	Подпись серти-фиката	Шифрова-ние ключа	Подпись CRL	Подпись сертификата & CRL
AuthorityKeyIdentifier	Х	Х	Х	Х	Х
KeyUsage	Х	Х	Х	Х	Х
PrivateKeyUsagePeriod	Х	Х		Х
CertificatePolicies	Х	Х	Х	Х	Х
SubjectAltName	O	O	O	O	O
BasicConstraints	Х	Х	Х	Х	Х
IssuerAltName	O	O	O	O	O
Частное расширение
HashedRootKey					Х
CertificateType	Х	Х	Х	Х	Х
MerchantData
CardCertRequired
Tunneling			Х
SETExtensions

Каждый центр сертификации (за исключением MCA и CCA) поддерживает CRL и производит их рассылку. BCI (BrandCRLIdentifier), определенный SET, содержит список всех CRL в пределах данной платежной системы (Brand). Как только СА выпустит новый список CRL, соответствующий BCI актуализируется. Получение конечным пользователем BCI гарантирует, что устаревшие или скомпрометированные сертификаты не будут использованы. В CRL записываются серийные номера устаревших сертификатов. СА идентифицируется в CRL по своему уникальному имени, CRL подписывается рассылающим СА. Длина списка CRL со временем растет. Каждый СА CRL содержит в себе следующую информацию:

Номер CRL. Номера монотонно возрастают.

Список серийных номеров устаревших сертификатов.

Даты, когда конкретные сертификаты были признаны устаревшими.

Даты, когда был сформирован CRL и когда завершается срок его действия (замещается новым CRL).

Уникальное имя СА, который поддерживает данный CRL.

Эмитент и серийный номер сертификата СА, который используется для подписи данного CRL.

В таблице 4.6.2.36 определен формат полей CRL и ограничения для их значений (X.509).

Обработка оттисков получателем

Таблица 4.6.2.8. Обработка оттисков получателем

Шаг	Действие
1	Инициализировать буфер для запоминания оттисков
2	Для каждого из них: Для сертификата, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить соответствует ли оттиск (хэш) сертификата одному из полученных в сообщении-запросе. Если соответствие найдено, сертификат в кэше удаленной системы существует и его не нужно включать в отклик. Если соответствия нет или список пуст, то включить сертификат в сообщение отклик. Для CRL, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствие имеется, то CRL в кэше удаленной системы существует и его не следует помещать в отклик. Если соответствия нет или список пуст, то данное CRL включается в отклик. Для BCI, который имеет отношение к обрабатываемому сообщению-отклику и ко всей цепочке сертификатов, проверить, соответствует ли CRL-оттиск (хэш) одному из оттисков, полученных в сообщении-запросе. Если соответствия нет или список пуст, то данное CRL включается в отклик.
3	Присылается результат работы шага 2 со списком сертификатов, CRL и BCI, которые следует послать в отклике.

Простая инкапсуляция с оператором подписи Enc(s,r,t) представляет данные, которые были сначала подписаны, а затем зашифрованы. Этот случай соответствует варианту PKCS#7 SignedData, инкапсулированных в EnvelopedData. Процедура выполняется следующим образом.

Шаг	Действие
1	Используя оператор подписи и секретный ключ объекта s, подписать содержимое группы t
2	Добавить результат шага 1 в группу t
3	Используя оператор асимметричного шифрования и общедоступный ключ получателя r, зашифровать результат шага 2
4	Послать результат работы шага 3

Другие варианты инкапсуляции осуществляются сходным образом.

Асимметричный оператор шифрования E(r,t) соответствует EnvelopedData PKCS#7 для группы t, зашифрованной для объекта r. Этот оператор включает в себя быстрое симметричное шифрование основного объема данных, а также асимметричное шифрование секретного ключа предшествующего шифрования с привлечением общедоступного ключа получателя. Протоколом шифрования по умолчанию для SET является DES, а для асимметричного шифрования – RSA. Последовательность операций при асимметричном шифровании представлена в таблице 4.6.2.9.

Опции соединителей

Таблица 7.8. Опции соединителей

Опция	Тип	Назначение	Значение по умолчанию
SO_GROUP_ID	GROUP	Идентификатор группы, к которой принадлежит соединитель.	NULL
SO_GROUP_PRIORITY	int	Относительный приоритет соединителей, принадлежащих к группе.	0
SO_MAX_MSG_SIZE	int	Максимальный размер сообщения для соединителей, ориентированных на сообщения. Не имеет смысла для соединителей типа stream.	Зависит от реализации
SO_PROTOCOL_INFO	struct WSAPROTOCOL_INFO	Описание протокольной информации.	Зависит от протокола
PVD_CONFIG	char FAR *	Информационная структура, содержащая данные о сервис провайдере.	Зависит от реализации

Сводная таблица кодов операций для процедуры ioctl приведена ниже (таблица 7.9). Оператор WSAIoctl поддерживает также все операции, специфицированные для процедуры iocltsocket.

Опции соединителей для оператора setsockopt

Таблица 7.2. Опции соединителей для оператора setsockopt.

Опция	Тип	Назначение
SO_BROADCAST	булев	Позволяет передачу широковещательных сообщений
SO_DEBUG	булев	Осуществляет запись отладочных данных.
SO_DONTLINGER	булев	Разрешает закрытие без ожидания при наличии не отосланной информации. Эта опция эквивалентна SO_LINGER с l_onoff=0.
SO_DONTROUTE	булев	Запрет маршрутизации - отправка непосредственно интерфейсу.
SO_KEEPALIVE	булев	Посылка сообщения keepalive (“еще жив”)
SO_LINGER	структура	Задержка закрытия в случае наличия не отосланной информации.
SO_OOBINLINE	булев	Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных
SO_RCVBUF	целый	Определяет размер входного буфера
SO_REUSEADDR	булев	Позволяет соединителю использовать адрес, который уже задействован
SO_SNDBUF	целый	Определяет размер выходного буфера
TCP_NODELAY	булев	Запрещает использование алгоритма Нагля (TCP).

Программа getsockopt(s, int level, int optname, char far*optval, int FAR* optlen) позволяет получить значение опции для любого типа соединителей. Значения параметров обращения аналогичны setsockopt. Ниже представлена таблица (7.3) поддерживаемых опций.

В среде Windows существуют аналоги (асинхронные) многих из приведенных выше операторов. Имена этих операторов имеют префикс WSA (Windows Socket Asynchronous). Асинхронными они названы по той причине, что их выполнение сопряжено с определенным диалогом и ни начало, ни завершение не ограничено какими-либо временными рамками. Список таких операторов представлен в таблицах 7.4 и 7.5 (версия windows socket 2.2).

Таблица 7.3. Опции соединителей для оператора getsockopt

Опция	Тип	Назначение
SO_ACCEPTCONN	булев	Соединитель в режиме listen
SO_BROADCAST	булев	Разрешена передача широковещательных сообщений
SO_DEBUG	булев	Отладочный режим разрешен
SO_DONTLINGER	булев	Если равен TRUE, SO_LINGER-опция запрещена
SO_DONTROUTE	булев	Запрет маршрутизации.
SO_ERROR	целое	Выдает статус ошибок
SO_KEEPALIVE	булев	Сообщение keepalive (“еще жив”) послано
SO_LINGER	структура	Возвращает текущие значения опции SO_LINGER
SO_OOBINLINE	булев	Принимает информацию, приходящуюю по независимым каналам, в общем потоке данных
SO_RCVBUF	целый	Сообщает размер входного буфера
SO_REUSEADDR	булев	Соединителю разрешено использовать адрес, который уже задействован
SO_SNDBUF	целый	Сообщает размер выходного буфера
SO_TYPE	целый	Тип соединителя (например, SOCK_STREAM)
TCP_NODELAY	булев	Использование алгоритма Нагля запрещено (tcp).

Опции Winsock

Таблица 7.11. Опции Winsock 2.

Опция	Тип	Назначение	Значение по умолчанию
SO_ACCEPTCONN	BOOL	Соединитель в режиме WSPListen.	FALSE, если WSPListen не была выполнена
SO_BROADCAST	BOOL	Соединитель сконфигурирован для передачи широковещательных сообщений.	FALSE
SO_DEBUG	BOOL	Разрешен отладочный режим.	FALSE
SO_DONTLINGER	BOOL	Если истинно, опция SO_LINGER запрещена.	TRUE
SO_DONTROUTE	BOOL	Маршрутизация запрещена.	FALSE
SO_ERROR	int	Возвращает статус ошибки и осуществляет сброс.	0
SO_GROUP_ID	GROUP	Идентификатор группы, к которой принадлежит соединитель.	NULL
SO_GROUP_ PRIORITY	int	Относительный приоритет для соединителей членов группы.	0
SO_KEEPALIVE	BOOL	Послано сообщение “еще жив”.	FALSE
SO_LINGER	struct linger	Возвращается текущее значение опции LINGER.	l_onoff = 0
SO_MAX_MSG_SIZE	int	Максимальный размер сообщения для соединителей, ориентированных на обмен сообщениями. Не имеет смысла для соединителей, ориентированных на потоки данных.	Зависит от реализации
SO_OOBINLINE	BOOL	Приоритетная информация получена в потоке обычных данных.	FALSE
SO_PROTOCOL_INFO	struct WSAPROTOCOL_INFO	Описание протокола для заданного соединителя.	Зависит от протокола
SO_RCVBUF	int	Размер буфера для приема.	Зависит от реализации
SO_REUSEADDR	BOOL	Адрес, к которому подключен соединитель, может быть использован другими.	FALSE
SO_SNDBUF	int	Размер буфера для отправки	Зависит от реализации
SO_TYPE	int	Тип соединителя (т.е. SOCK_STREAM).	Как было при создании socket
PVD_CONFIG	char FAR *	Структурный объект, содержащий информацию о конфигурации сервис-провайдера.	Зависит от реализации
TCP_NODELAY	BOOL	Запрещает алгоритм Нагля.	Зависит от реализации

В таблице 7.12 приведен список ioctl-кодов команд для соединителей.

Операции клиента и значения полей заголовка

Таблица 4.4.16.6. Операции клиента и значения полей заголовка

Имя поля	Уникаст/Эникаст		Мультикаст
	Запрос	Отклик
LI	0	0-2	0-2
VN (номер версии)	1-4	копируется из запроса	1-4
Режим	3	4	5
Слой	0	1-14	1-14
Запрос	0	Игнорируется	Игнорируется
Точность	0	Игнорируется	Игнорируется
Root Delay	0	Игнорируется	Игнорируется
Root Dispersion	0	Игнорируется	Игнорируется
Reference Identifier	0	Игнорируется	Игнорируется
Reference Timestamp	0	Игнорируется	Игнорируется
Originate Timestamp	0	(смотри текст)	Игнорируется
Receive Timestamp	0	(смотри текст)	Игнорируется
Transmit Timestamp	(смотри текст)	не равно нулю	не равно нулю
Аутентификатор	опционно	опционно	опционно

6. Операции сервера SNTP

Сервер SNTP может работать в уникастном, эникастном или мультикастном режимах, а также реализовать любую из комбинаций этих режимов. В уникаст и эникаст режимах сервер получает запросы (режим 3), модифицирует определенные поля в заголовке NTP, и посылает отклик (режим 4), возможно используя тот же буфер сообщения, что и в случае запроса. В режиме эникаст сервер прослушивает определенный широковещательный или групповой мультикаст-адрес, определяемый IANA, но использует свой собственный уникастный адрес в поле адреса отправителя отклика. За исключением выбора адреса в отклике работа сервера в эникаст и уникаст режима идентична. Мультикастные сообщения обычно посылаются с интервалом от 64 до 1024 сек, в зависимости от стабильности часов клиента и требуемой точности.

В эникаст и уникаст режимах поля VN и регистрация (Poll) запроса копируются без изменений в отклик. Если поле режим запроса содержит код 3 (клиент), оно делается в отклике равным 4 (сервер); в противном случае в это поле записывается 2 (симметричный пассивный), для того чтобы обеспечить соответствие со спецификацией NTP. Это позволяет клиентам, сконфигурированным для симметричного активного режима (режим 1) успешно работать, даже если конфигурация не является оптимальной.
В мультикастном режиме в поле VN заносится код 4, в поле режим код 5 (широковещательный) и в поле регистрация целая часть значение логарифма по основанию 2 от длительности периода посылки запросов.
Заметим, что крайне желательно чтобы серверы, поддерживающие мультикастинг, поддерживали и уникастный режим. Это необходимо для измерения RTT клиент/сервер, прежде чем осуществлять регулярный обмен в мультикастном режиме.
В уникастном и эникастном режимах сервер может реагировать, а может и игнорировать запросы, если не синхронизован надлежащим образом с помощью радио-часов. Но предпочтительным поведением является присылка отклика в любом случае, так как позволяет убедиться в достижимости сервера. В мультикастном режиме сервер посылает широковещательные сообщения, только если он синхронизован.
Остальные поля заголовка NTP заполняются следующим образом. Если сервер синхронизован и функционирует правильно, в поле LI заносится 0, а в поле слой – 1 (первичный сервер). Если это не так, в поле слой записывается 0, а в поле LI - 3. В поле точность заносится код, характеризующий точность локальных часов. Для всех практических случаев этот код вычисляется, как отрицательное число бит справа от запятой в формате временной метки NTP. Поля Root Delay и Root Dispersion для первичного сервера делаются равными 0. Поле Root Dispersion опционно может быть сделано равным значению, соответствующему максимальной ожидаемой ошибке радио-часов. В поле Reference Identifier заносится идентификатор первичного эталона времени, как это указано в таблице 4.4.16.4.
Поля временных меток заполняются следующим образом. Если сервер не синхронизован или только что включился, все временные метки устанавливаются равными нулю. Если сервер синхронизован, в поле Reference Timestamp записывается время последней коррекции по радио-часам или модему. В уникастном и эникастном режимах в поля Receive Timestamp и Transmit Timestamp заносится время дня, когда было послано сообщение, а в поле Originate Timestamp записывается неизмененная копия поля Transmit Timestamp из запроса.В мультикастном режиме в поля Originate Timestamp и Receive Timestamp заносится 0, а в Transmit Timestamp время дня, когда послано сообщение. В таблице 4.4.16.7 представлены все перечисленные операции.

Операторы, используемые протоколом SET

Таблица 4.6.2.3. Операторы, используемые протоколом SET

Нотация	Оператор		Описание
H(t)	хэш		160-битовый хэш группы t
HMAC(t,k)	Ключевой хэш-механизм		160-битовый ключевой хэш группы t, использующий ключ k и алгоритм HMAC-SHA-1 HMAC(t,k) = H(k A opad) | H((k A ipad)|t)), где ipad - байт 0х36, повторенный 64 раза; opad – байт 0х5С, повторенный 64 раза; а A - знак операции исключающее ИЛИ.
L(t1,t2)	Связь		Ссылка, указатель или связь t2 с t1; эквивалентно группе {t1, H(t2)}
Нотация операторов цифровой подписи
S(s,t)	Подписанное сообщение		Подпись объекта s для группы t, включая открытый текст t. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1. Соответствует SignedData PKCS #7.
Нотация операторов двойной цифровой подписи
SO(s,t)	Только подпись		Подпись объекта s для группы t, не включая открытый текст t. SO соответствует внешней подписи PKCS #7. Алгоритмом цифровой подписи для SET является RSA с дайджестом SHA-1.
Нотация операторов шифрования
E(r,t)	Асимметричное шифрование (цифровой конверт)		Сначала шифруется t с новым симметричным ключом k, затем ключ вкладывается в цифровой конверт PKCS #7 для объекта r. Производится шифрование OAEP(k) с использованием общедоступного ключа объекта r, взятого из сертификата группы r. Для симметричного шифрования в SET по умолчанию используется алгоритм DES. Соответствует EnvelopedData.
EH(r,t)	Шифрование целостности		Процедура подобна E за исключением того, что цифровой конверт PKCS#7 содержит OAEP({k,H(t)}) для гарантии целостности, когда подпись не доступна. Программа вычисляет повторно хэш t и проверяет соответствие H(t) в цифровой конверте.
EX(r,t,p)	Дополнительное шифрование		Процедура подобна E за исключением того, что t и p являются частями составного сообщения. t – группа, которая должна быть соединена с p и подвергнута обычному симметричному шифрованию, а p – параметр или часть, которая должна быть подвергнута дополнительной обработке. t связано с p. OAEP({k,p}) вкладывается в цифровой конверт PKCS#7 для объекта r.
EXH(r,t,p)	Дополнительное шифрование с обеспечением целостности		Процедура подобна EX за исключением того, что это делается с OAEP({k,H(t), p}) в цифровом конверте PKCS#7 и с требованием проверки H(t), как и в случае EH
EK(k,t)	Симметричное шифрование посредством ключа k		Симметричное шифрование группы t с помощью секретного ключа k. Соответствует формату EncryptedData
Нотация операторов инкапсуляции
Enc(s,r,t)		Простая инкапсуляция с подписью		Подписанное и затем зашифрованное сообщение. Соответствует SignedData в EnvelopedData
EncK(k,s,t)		Простая инкапсуляция с подписью и предоставленным ключом		Подписанное сообщение, зашифрованное с помощью секретного ключа. Соответствует EncryptedData.
EncX(s,r,t,p)		Дополнительная инкапсуляция с подписью		Составное сообщение, первая часть которого зашифрована симметричным алгоритмом. Вторая часть сообщения преобразуется с привлечением алгоритма OAEP
EncB(s,r,t,b)		Простая инкапсуляция с подписью с загрузкой		Подписанное зашифрованное сообщение с загрузкой (baggage)
EncBX(s,r,t,p,b)		Дополнительная инкапсуляция с подписью и загрузкой		Подписанное, Е-шифрованное составное сообщение с загрузкой

<
В протоколе SET часто используются так называемые двойные подписи. Для того чтобы понять их назначение, рассмотрим следующий пример. Пусть Боб хочет послать Алисе предложение купить некоторый товар и авторизационные параметры своего счета в банке, чтобы она могла выполнить оплату товара в случае, если предложение ее устроило. Предположим также, что Боб не хочет, чтобы банк узнал условия предложения, а Алиса получила данные о его счете в банке. Кроме того, Боб хочет, чтобы денежный перевод производился лишь в случае принятия его предложения Алисой. Для решения такой задачи сообщения Алисе и распоряжение банку подвергаются процедуре двойной подписи.
Для реализации двойной подписи формируются дайджесты обоих сообщений, после чего они объединяются. Вычисляется дайджест сообщения-результата, после чего этот дайджест шифруется секретным ключом отправителя (Боба). Подписант должен добавить дайджест другого сообщения, для того чтобы получатель мог проверить корректность двойной подписи. Получатель любого из указанных выше сообщений может проверить их аутентичность, путем вычисления дайджеста самого сообщения с последующим добавлением к нему дайджеста другого сообщения (присланного отправителем) и вычислением дайджеста результата. Если вычисленный таким образом дайджест совпадет с дешифрованной двойной подписью, получатель может быть уверен в аутентичности сообщения. При этом ни одна из сторон не может оспаривать корректность действий другой стороны (будет оплачено именно то предложение, которое было послано клиенту).
Если Алиса принимает предложение Боба, она может послать сообщение в банк, указав свое согласие на оплату предложения Боба и включив в это сообщение дайджест предложения, вычисляет дайджест всего такого сообщения. Можно было бы включить само предложение, но, во-первых, в этом случае было бы раскрыто его содержимое, а во-вторых, предложение обычно во много раз больше по объему, чем дайджест. Получатель проверяет соответствие этого дайджеста дешифрованной двойной подписи, что позволяет ему судить об аутентичности сообщения.


Банк в этом случае может быть уверен, что согласие получено именно на это, а не на какое-то другое сообщение. В то же время банк не получает доступа к тексту предложения.
В протоколе SET двойные подписи используются для установления связи между сообщением-заказом, посланным продавцу, и платежными инструкциями, содержащими информацию о счетах клиента, посланными получателю платежа (обычно это банк продавца).
Важным принципом при анализе работы программ SET является идемпотентность – реакция алгоритма на повторное выполнение одних и тех же сообщений. Обычно SET используется поверх протоколов HTTP или SMTP, которые, в свою очередь, работают на основе транспортного протокола TCP. Протокол TCP сам по себе гарантирует доставку сообщения. Но в SET из-за высокой степени финансовой ответственности вводится дополнительный контроль доставки уже на прикладном уровне. Любой механизм гарантированной доставки предполагает повторную посылку сообщения при отсутствии отклика от получателя. Следует иметь в виду, что практически невозможно разделить потерю сообщения и отклика на это сообщение. Именно по этой причине программа получателя должна быть готова к обработке повторных сообщений, так как задержка при транспортировке в Интернет может спровоцировать повторную посылку запроса. Повторные запросы должны иметь тождественные идентификаторы (XID и PRPID). Повторная посылка запросов и их обработка не должны влиять на конечный результат. Но не все виды запросов требуют такой обработки. Информационные запросы в отличие от запросов-заказов не нуждаются в запоминании продавцом (для выяснения того, являются ли они повторными). На такие запросы посылаются отклики каждый раз в соответствии со статусом системы. То есть на один и тот же запрос в разное время может быть получен разный отклик. Если приложение SET детектирует атаку типа “шторма запросов”, оно может не реагировать на эти запросы.

XID является статистически уникальным идентификатором платежной транзакции и позволяет идентифицировать все относящиеся к ней сообщения.


Его длина составляет 20 байт.

BrandID представляет собой поле, используемое протокольными сообщениями управления платежом и сертификации. Оно содержит имя платежной системы (Brand) и опционное название продукта в рамках данной платежной системы. Запись имеет формат brand:product.
Безопасность системы SET зависит от подлинности сертификатов, используемых системой. Система производит иерархическую верификацию всех сертификатов. Цепочка сертификатов завершается корневым сертификатом (Root CA), общим для всей системы. Общедоступный ключ Root CA (корневого сертификационного центра; X.509v3) распространяется в виде сертификата программным обеспечением SET. Для верификации цепи сертификатов необходимо иметь общедоступный корневой ключ.

Cert-PE представляет собой сертификат, сформированный узлом сертификации платежного центра (PCA) и связывает расчетный центр с общедоступным ключом шифрования, присылаемым в сообщении запроса сертификата CertReq.
Отправитель гарантирует корректность формата сообщения, который должен соответствовать типу сообщения. Если какая-то часть сообщения подписана отправителем, сообщение должно содержать сертификаты CRL и BrandCRLIdentifiers.
Для обеспечения совместимости и дальнейшего расширения возможностей протокола используются стандарты PKCS и Cryptographic Message Syntax (стандарт на криптографический синтаксис сообщений), которые определяют и механизмы криптографического вложения. Форматы PKCS используются для вложения данных в сообщения SET. Данный протокол использует следующие методы инкапсуляции PKCS #7.
SignedData для вложения подписанной информации
EnvelopedData для инкапсуляции зашифрованных данных
EncryptedData для инкапсуляции зашифрованных данных c использованием симметричного алгоритма
DigestedData для инкапсуляции хэшированных или связанных данных
Тип SignedData из PKCS #7 проиллюстрирован на Рисунок 4.6.2.5, где отображен процесс цифровой подписи. В пределах SignedData может присутствовать несколько полей Signerinfo, но подписывать SignedData может не более двух субъектов.

Описание алгоритма OAEP

Таблица 4.6.2.15. Описание алгоритма OAEP

Шаг	Действие
1	Подготовить дополнительные данные, как это описано в формате сообщения
2	Если используется оператор шифрования EH или EXH, вычислить хэш SHA-1 для данных подлежащих DES-шифрованию
3	Сформировать новый случайный ключ для DES-шифрования регулярной части данных
4	Объединить DES-ключ, хэш SHA-1 данных (HD) перед DES-шифрованием (если оно применяется) и любые дополнительные данные, чтобы сформировать действительный блок данных ADB (Actual Data Block).
5	Взять байт, содержащий код 0х03 (тип блока – BT), семь байтов нулей (байты верификации – V) и байт блока содержимого (BC) и положить в ADB, тем самым формируя блок данных (DB). DB= BT|BC|V|ADB
6	Сгенерировать случайную 16-битовую строку E-Salt и вычислить H1(E-Salt). H1 выдает лидирующие байты хэша SHA-1
7	Вычислить А=DB A H1(E-Salt)
8	Осуществить присвоение B= E-Salt A H2(A). Сформировать PDB, объединив А и В. Н2 предоставляет завершающие байты хэша SHA-1
9	Присвоить I случайное значение, не равное 0х00 или 0х80
10	Зашифровать полученный блок R с помощью RSA

Алгоритм работа OAEP показан на рисунке 4.6.2.9.

В DB присутствуют только информационные элементы типа атомик (в нотации ASN.1). Каждый элемент DB кодируется согласно требованиям DER, но без тэгов и октетов длины. При преобразовании из DER-формата в DB к концу блока данных могут добавляться нули (0х00). При обратном преобразовании такие заполнители удаляются.

Основные операторы winsock

Таблица 7.4. Основные операторы winsock

Имя оператора	Назначение
WSAAsyncGetHostByAddr	Аналог оператора gethostbyaddr
WSAAsyncGetHostByAddr	Аналог оператора gethostbyaddr
WSAAsyncGetHostByName	Аналог оператора gethostbyname
WSAAsyncGetProtoByName	Аналог оператора getprotobyname
WSAAsyncGetProtoByNumber	Аналог оператора getprotobynumber
WSAAsyncGetServByName	Аналог оператора getservbyname
WSAAsyncGetServByPort	Аналог оператора getservbyport
WSAAsyncSelect	Функциональный аналог оператора select
WSACancelAsyncRequest	Прерывает выполнение операторов типа WSAAsyncget*by*
WSACancelBlockingCall	Прерывает выполнение блокирующего оператора приложения (API)
WSACleanup	Сообщает Windows sockets о завершении работы программы с DLL
WSAGetLastError	Выдает сообщение о последней ошибке
WSAIsBlocking	Определяет, является ли Winsock DLL блокирующей
WSASetBlockingHook	Устанавливает перехват блокирующего вызова
WSASet LastError	Фиксирует тип ошибки для последующего вызова WSALastError
WSAStartup	Инициализирует следующий уровень Winsock
WSAUNhookBlockingHook	Восстанавливает прежнюю блокировку.

Из этого списка можно выделить две программы WSAStartup и WSACleanup, первая вызывается в начале любой процедуры, вторая - ее завершает. wsastartup может вызываться за время сессии несколько раз, она позволяет указать версию winsock или получить информацию об ее конкретной реализации. При вызове WSAStartup осуществляется диалог с динамической библиотекой WINSOCK.DLL и настройка параметров системы. При аварийном завершении программы нужно корректно окончить работу с WINSOCK.DLL. Следует при этом помнить, что WSACleanup воздействует на все потоки завершаемого процесса (например, в случае Windows 95 или NS). Определенные проблемы может вызвать перенос программ из Unix в Windows, так как там вместо read и write используются операторы recv и send, вместо ioctl - ioctlsocket, а вместо close - closesocket. Некоторые операторы вообще непереносимы: readv, writv, recvmsg и sendmsg и части программы, где они содержатся, необходимо переписать. При обнаружении ошибки Unix присваивает переменной errno соответствующее значение. В winsock для этой цели используется символьная константа SOCKET_ERROR (равная -1), а для уточнения типа ошибки следует вызвать WSAGetLastError. В системах Windows 95 или NT этот оператор обращается к программе Win32 GetLastError, которая возвращает значение ошибки для сессии, вызвавшей эту ошибку.

Отправление сообщения

Таблица 4.6.2.4. Отправление сообщения

Шаг	Действие
1	Генерация сообщения SET
2	Вложение кода текущей версии в MessageWrapper (цифровой конверт, сейчас 1 или 0)
3	Вложить код даты, включая время.
4	Заполнить MessageID из полей TransID в Message. Если MessageID в Message отсутствует, поле опускается.
5	Вводится RRPID. Если это запрос, генерируется RRPID и запоминается для последующего сравнения с соответствующим кодом отклика. Если посылается отклик, то RRPID копируется из запроса.
6	Вводится SWIdent. Это строка, которая идентифицирует разработчика и версию программного продукта
7	Вкладывается Message
8	Производится DER-кодирование вложенного сообщения
9	Сообщение передается на транспортный уровень

Процедура обработки входящего сообщения рассмотрена в таблице 4.6.2.5.

Перечень служебных операторов для работы с соединителями (Беркли)

Таблица 7.1. Перечень служебных операторов для работы с соединителями (Беркли)

Имя команды	Назначение
getdomainname	Возвращает имя домена
gethostbyname	Возвращает IP-адрес для заданного сетевого имени.
gethostname	Возвращает имя ЭВМ (обычно имя ее домена).
gethostadr	Возвращает IP-адрес ЭВМ.
getnetaddr	Возвращает адрес сети.
getnetname	Возвращает имя сети.
getpeername	Возвращает имя партнера, подключенного к соединителю.
getportbyname	Возвращает имя и код протокола для указанного имени (например, ICMP, UDP или TCP)
getportbynumber	Возвращает имя протокола для указанного его кода
getservbyname	Извлекает из базы данных название протокола и номер порта для указанного имени сетевой услуги
getservbyport	Возвращает имя сетевой услуги для заданного номера порта
getsockname	Возвращает местный адрес соединителя.
getsockopt	Запрашивает информацию о соединителе.
htonl	Преобразует порядок байтов 32-разрядного кода из машинного в сетевой.
htons	Преобразует порядок байтов 16-разрядного кода из машинного в сетевой.
inet_addr	Преобразует символьную строку IP-адреса из десятично-точечного формата в 32-разрядный код с сетевым порядком байтов.
inet_ntoa	Преобразует IP-адрес в десятично-точечный формат.
ioctlsocket	Управляет параметрами соединителя, связанными с обработкой операций ввода/вывода.
ntohl	Преобразует порядок байтов 32-разрядного кода из сетевого в машинный.
ntohs	Преобразует порядок байтов 16-разрядных кодов из сетевого в машинный.
ethostname	Устанавливает имя ЭВМ.
setsockopt	Устанавливает опции соединителя.
shutdown	Закрывает один из концов дуплексного канала для местной ЭВМ.
socketpair	Генерирует пару соединителей.

Большинство перечисленных команд имеют развитую систему диагностики, кроме того, во многих реализациях Unix имеется много других полезных команд, описание которых вы можете найти в инструкциях по использованию системы Unix. Рассмотрим некоторые из них.

Программа ioctlsocket(s, long cmd, u_long FAR*argp) служит для получения параметров соединителя (выполнение не зависит от типа протокола и коммуникационной субсистемы).
Аргумент cmd представляет собой код команды, которая будет выполнена для соединителя s, argp - указатель на параметр команды. Возможно применение команд: FIONBIO - разрешает/запрещает режим блокировки соединителя s (команда WSAAsyncSelect ставит соединитель в режим запрета блокировок автоматически). FIONREAD - определяет объем данных, которые могут быть автоматически считаны через соединитель s. SIOCATMARK - задает режим чтения приоритетной информации (для соединителей типа SOCK_STREAM.
Программа setsockopt(s, int level, int optname, const char far*optval, int optlen) устанавливает текущие значения опций для соединителя s. Аргумент level описывает уровень, на котором определена данная опция (например, SOL_SOCKET или IPPROTO_TCP). optname - имя опции, значение которой устанавливается, optval - указатель на буфер, где лежит значение опции, optlen - размер этого буфера. Для опции SO_LINGER - это размер структуры, для остальных - длина целого. При корректном исполнении setsockopt возвращает нуль, в противном случае SOCKET_ERROR. Программа setsockopt поддерживает следующие опции (BSD поддерживает и некоторые другие опции; колонка тип соответствует значению optval, таблица 7.2):

Уникальный порядковый номер, приписываемый СА,

Таблица 4.6.2.32. Поля формата сертификата Х.509

Имя	Ограничения на формат и значения	Описание
Version (Версия)	Целое	Указывает на версию сертификата
SerialNumber	Целое	Уникальный порядковый номер, приписываемый СА, сформировавшим сертификат
Signature.AlgorithmIdentifier	OID и тип	Определяет алгоритм, используемый для генерации подписи сертификата
Issuer (эмитент)	Имя	Содержит уникальное имя (Distinguished Name) CA, выдавшего сертификат
Validity.notBefore	Время UTC	Специфицирует время, когда сертификат становится активным
Validity.notAfter	Время UTC	Специфицирует время, когда сертификат перестает действовать. Если это относится к сертификату владельца карты, то его время действия не может быть дольше пригодности карты.
Subject	Имя	Содержит уникальное имя объекта владельца ключа
SubjectPublicKeyInfo.algorithm. AlgorithmIdentifier	OID и тип	Специфицирует алгоритм, который может использоваться с этим ключом.
SubjectPublicKeyInfo. subjectPublicKey	Строка битов	Содержит общедоступный ключ, представленный в запросе сертификата
IssuerUniqueID		В SET не используется
SubjectUniqueID		В SET не используется
Extensions.extnId	Формат OID	Содержит расширение OID, как это определено Х.509 или SET
Extensions.critical	Булево: 0=ложно 1=истинно	Каждое описание расширения определяет то, какое значение должно принимать это поле
Extensions.extnValue		Информация расширения

Для определения позиций необходимы следующие идентификаторы объектов OID (указаны в скобках) в сертификатах SET:

countryName [2 5 4 6]

organizationName [2 5 4 10]

organizationUnitName [2 5 4 11]

commonName [2 5 4 3]

Ниже представлены формальные определения атрибутов (at), которые заключают в себе уникальные имена (Subject Distinguished Name) для каждого объекта SET, указанного в расширении типа сертификата (CertificateType).



OID имен (ASN.1)

id-at-countryNameOBJECT IDENTIFIER ::= { id-at 6 }

id-at-organizationNameOBJECT IDENTIFIER ::= { id-at 10 }



id-at-organizationalUnitNameOBJECT IDENTIFIER ::= { id-at 11 }

id-at- commonNameOBJECT IDENTIFIER ::= { id-at 3 }

Владелец карты

countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>

organizationName=<BrandID> (идентификатор платежной системы)

organizationalUnitName=<Название финансового учреждения, выпустившее карту>

organizationalUnitName=<Опционно - название карты>

commonName=<Уникальный идентификатор владельца карты>

Если в перечне появляется два атрибута organizationalUnitName, первый из них представляет название финансового учреждения, выпустившее карту.

Продавец

countryName=< Страна, где размещается банк продавца – Acquirer>

organizationName=<BrandID>

organizationalUnitName=<Название банка продавца>

commonName=<Имя продавца, как написано в заявлении владельца карты>

Расчетный центр

countryName=<Страна, где размещается банк продавца – Acquirer>

organizationName=<BrandID>

organizationalUnitName=<Название банка продавца>

commonName=<Уникальный идентификатор расчетного центра>

Центр сертификации владельца карты

countryName=<Страна, где размещается финансовое учреждение, выпустившее карту>

organizationName=<BrandID>

organizationalUnitName=<Описательное имя>

commonName=<Опционный уникальный идентификатор>

Центр сертификации продавца

countryName=<Страна, где размещается банк продавца – Acquirer >

organizationName=<BrandID>

organizationalUnitName=<Описательное имя>

commonName=<Опционный уникальный идентификатор>

Центр сертификации расчетного центра

countryName=<Страна, где размещается банк продавца – Acquirer >

organizationName=<BrandID>

organizationalUnitName=<Описательное имя>

commonName=<Опционный уникальный идентификатор>

Геополитический центр сертификации

countryName=<Страна геополитической организации>

organizationName=<BrandID>

organizationalUnitName=<Описательное имя>



commonName=<Опционный уникальный идентификатор>

Центр сертификации платежной системы (Brand)

countryName=<Страна, где размещен центр сертификации платежной системы>

organizationName=<BrandID>

organizationalUnitName=<Описательное имя>

commonName=<Опционный уникальный идентификатор>

Корневой центр сертификации

countryName=<Страна, где размещен корневой центр сертификации – СА>

organizationName=<Корневой центр SET>

commonName=<Опционный – уникальный ID>

Поля имен в имени субъекта сертификата определены в таблице ниже:

Country	2 символа кода страны (ISO 3166)
BrandID	<Brand Name>:<Product>, где название продукта является опционным.
Brand Name	Платежная система карты, которая определяется разработчиками платежной системы.
Product Type	Опционное поле, которое определяет тип продукта в рамках заданной платежной системы.
Описательное имя	Это описательное имя объекта, ответственного за выпуск сертификата в рамках данного СА. Например: Название финансовой организации Название организации, выполняющей функцию СА Название платежной системы Имя объекта, ответственного за одобрение сертификатов
Официальное название карты	Это опционное поле содержит официальное название карты. Примерами могут служить, например: Frequent Flayer Program, Affinity Program и т.д.
Название финансовой организации	Имя финансовой организации, выпускающей расчетные карты
Уникальный идентификатор владельца карты	Уникальным идентификатором владельца карты в сертификате владельца является хэшированный номер его счета.
Уникальный идентификатор расчетного центра	Поле содержит BIN, за которым следует серийные номера банка продавца или расчетной системы. Поле форматировано как <BIN:SerialNumber>. Серийный номер позволяет однозначно идентифицировать каждый расчетный центр, ассоциированный с одним и тем же банком продавца (Acquirer). В пределах расчетной системы (Brand) может быть несколько сертификатов для одного BIN.

<


Уникальный ID владельца карты в сертификате представляет собой хэшированный номер его счета. PAN маскируется с использованием общего секретного ключа (PANSecret), который состоит из комбинации CardSecret владельца карты и Nonce-CCA сертификационного центра. Вычисление хэша производится с привлечением алгоритма HMAC-SHA1 (RFC-2105). Функция HMAC-SHA1 определяется в терминах ключа K и текста, который кэшируется следующим образом:
Hash(KA
opad|hash((KAipad)|text)),
где A
- оператор исключающее ИЛИ, а оператор | - обозначает объединение кодов. K, text, ipad и opad определяются в SET следующим образом:

K	Равно PANSecret и представляет собой 20-байтовую строку, полученную в результате операции исключающее ИЛИ, выполненной над DER-кодированными значениями CardSecret и Nonce-CCA.
Text	Представляет собой DER-кодированную копию исходного текста, содержащего PAN и CardExpiry. Text ::= SEQUENCE { pan PAN cardExpiry CardExpiry } PAN ::= NumberString (SIZE(1..19)) CardExpiry ::= NumericString (SIZE(6)) --YYYMM Время истечения действия карты
ipad	64 байта, содержащих код 0x36
opad	64 байта, содержащих код 0x5C

K дополняется нулями до 64 байт.
Результат вычисления HMAC кодируется в представлении base64, после чего производится в поле сертификата commonName.

Поля MessageWrapper

Таблица 4.6.2.1. Поля MessageWrapper

Название поля	Описание
Message-Wrapper	{MessageHeader, Message, [MWExtension]}}
MessageHeader	{Version, Revision, Date, [MessageID], [RRPID], SWIdent}
Version	Версия SET-сообщения
Revision	Подтип SET-сообщения
Date	Дата генерации сообщения
MessageID	{[LID-C], [LID-M], [XID]}
RRPID	Идентификатор, позволяющий объединять в пары запросы и отклики
SWIdent	Идентификация программы (поставщик и версия), инициировавшей запрос. Эта информация представляется строкой символов
Message	< PInitReq, PInitRes, PReq, PRes, InqReq, InqRes, AuthReq, AuthRes, AuthRevReq, AuthRevRes, CapReq, CapRes, CapRevReq, CapRevRes, CredReq, CredRes, CredRevReq, CredRevRes, PCertReq, PCertRes, BatchAdminReq, BatchAdminRes, CardCInitReq, CardCInitRes, Me-AqCInitReq, Me-AqCInitRes, RegFormReq, RegFormRes, CertReq, CertRes, CertInqReq, CertInqRes, Error>
LID-C	Локальный идентификатор, генерируемый системой владельца карты или для его системы
LID-M	Локальный идентификатор, генерируемый системой продавца или для его системы
XID	Глобальный идентификатор, генерируемый продавцом (или владельцем карты, если нет PInitRes)
MWExtension	Расширение сообщения SET. Расширение используется, когда информация в расширении является общей, описывающей сообщения SET, или когда содержимое сообщения зашифровано, а расширение содержит нефинансовую информацию, не требующую конфиденциальности.

Обработка сообщения начинается с MessageWrapper. Каждое сообщение должно иметь незашифрованный конверт MessageWrapper, который декодируется перед началом обработки самого сообщения. Поля TransID и RRPID используются для ранней диагностики дублированных сообщений.

При декодировании MessageWrapper компонента Message не может обрабатываться, но его тип можно определить по полю тип (DER) сообщения. По завершении декодирования MessageWrapper производится дешифрование и верификация подписи Message. После этого проводится декодирование Message. Обработка этого компонента зависит от его типа.

При описании протокола используется нотация представленная в таблице 4.6.2.2.

Посылка оттиска

Таблица 4.6.2.7. Посылка оттиска

Шаг	Действие
1	Инициализировать буфер для запоминания оттисков
2	Добавить оттиск (хэш): Для каждого сертификата, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому сертификату. Для каждого CRL, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому CRL. Для каждого BCI, который имеется в кэше отправителя и имеет отношение к обрабатываемому сообщению-отклику и для всей цепочки сертификатов добавляется оттиск (хэш), соответствующий этому BCI.
3	Присылается результат работы шага 2.

Получатель проверяет то, что отправитель владеет всеми сертификатами, CRL и BCI, необходимыми для завершения обработки сообщения. Получатель может проигнорировать оттиски и послать эту информацию запросившему. Обработка оттисков получателем представлена в таблице 4.6.23.8.

Прием и обработка входного сообщения

Таблица 4.6.2.5. Прием и обработка входного сообщения

Шаг	Действие
1	Извлекается цифровой конверт сообщения
2	Проверяется формат и содержимое полей цифрового конверта сообщения: версия, субверсия, дата/время, тип сообщения. Если обнаружена ошибка, возвращается отклик Error с ErrorCode.
3	Используя RRPID, производится сравнение и актуализация контрольного журнала на предмет выявления повторных сообщений
4	Произвести DER-декодирование сообщения
5	Если сообщение содержит SignedData, произвести следующее: Актуализовать системный кэш с учетом полученных CRL. Для каждого полученного сертификата, произвести верификацию цепочки сертификатов Проверить подпись сообщения
6	Если сообщение содержит инкапсулированные данные, выполняется извлечение вложенных данных согласно типу вложенного содержимого, включая шаг 5, если вложенные данные содержат SignedData
7	Извлечь идентификаторы BrandCRLIdentifier, включенные в сообщение и актуализовать системный кэш, проверить, что все CRL, идентифицированные BCI, находятся в системном кэше. В противном случае обработка сообщения прерывается.
8	Обработать сообщение
9	Актуализовать системный журнал с учетом состояния транзакции

Верификация цепочки сертификатов требует, чтобы последовательно проверялся каждый сертификат, и контролировалось его соответствие выпустившему его центру. Например, держатель карты должен проверить сертификаты продавца, центра сертификации продавца, центра сертификации платежной системы (Brand CA), и корневого центра Root CA. Процесс верификации включает в себя следующие компоненты:

Контроль сертификатов X.509

Контроль сертификатов SET

Обработку CRL (Certificate Revocation List)

Обработку BrandCRLIdentifier (BCI)

На практике предполагается, что процесс верификации будет остановлен на уровне, который был успешно пройден ранее. Все приложения SET помимо самих сертификатов контролируют их дату пригодности. Процедура верификации представлена в таблице 4.6.2.6.

Процедура асимметричного шифрования

Таблица 4.6.2.9. Процедура асимметричного шифрования

Шаг	Действие
1	Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2	Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3	Сформировать новый ключ DES
4	Зашифровать результат работы шага 2, используя ключ DES из шага 3. Используется режим DES-CBC.
5	Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма и добавить эту информацию к результату шага 4.
6	Инициализировать буфер цифрового конверта, в зависимости от получателя (128 байт)
7	Инициализировать буфер дополнительного шифрования OAEP с использование ключа из шага 3.
8	Применить OAEP для буфера цифрового конверта
9	Зашифровать результат шага 8, используя асимметричный общедоступный ключ объекта r
10	Инициализировать информационный буфер получателя посредством идентификатора алгоритма RSA и добавить туда результат работы шага 9
11	Инициализировать буфер EnvelopedData PKCS#7 и положить туда результат шага 10 и 5
12	Прислать результат шага 11

Оператор шифрования с гарантией целостности EH(r,t) подобен Е за исключением того, что цифровой конверт PKCS#7 включает в себя хэш группы t. Он предполагает быстрое симметричное шифрование открытого текста сообщения и последующее шифрование секретного ключа с использование общедоступного ключа получателя. Процедура такого шифрования представлена в таблице 4.6.2.10.

Процедура формирования цифровой подписи

Таблица 4.6.2.12. Процедура формирования цифровой подписи

Шаг	Действие
1	Инициализировать тип SignedData, введя код версии, идентификатор алгоритма и тип содержимого, подлежащего подписанию
2	Преобразовать информацию, подлежащую подписанию в формат DER
3	Использовать результат шага 2 для инициализации компонента content из ContentInfo.
4	Инициализировать тип SignerInfo, введя код версии, идентификаторы алгоритмов вычисления и шифрования дайджеста
5	Вычислить дайджест сообщения, используя SHA-1 для результата шага 3
6	Инициализировать структуру authenticatedAttributes и занести в структуру атрибуты contentType и messageDigest. Установить компоненты type атрибутов равными идентификаторам этих атрибутов
7	Инициализировать компонент values первого атрибута типа кодом содержимого, подлежащего подписанию, а второго атрибута – значением дайджеста, вычисленного на этапе 5
8	Закодировать аутентифицированные атрибуты и зашифровать результат, используя секретный ключ отправителя. Поместить результат в SignedData
9	Выбрать соответствующие сертификаты Х.509 и CRL, необходимые для верификации подписи, и включить их в SignedData
10	Если тип сообщения требует двух подписей, повторить шаги с 4 по 9

Оператор ключевого хэширования HMAC(t,k) соответствует 160-битовому хэшу HMAC-SHA-1 для группы t при использовании секретного ключа k. Эта функция нужна для сокрытия номера счета в сертификате владельца карты. Секретный ключ известен только владельцу карты и эмитенту. Процедура ключевого хэширования представлена в таблице 4.6.2.13.

Процедура ключевого хэширования

Таблица 4.6.2.13. Процедура ключевого хэширования

Шаг	Действие
1	Установить ipad соответствующим буферу, который содержит 64 байта с кодами 0х36
2	Установить opad равным буферу, содержащему 64 байта с кодами 0х5С
3	Добавить нули в конец k, чтобы размер строки стал равным 64 байтам. Например, если длина k равна 20 байт, то следует добавить 44 нуля.
4	Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и ipad
5	Добавить данные группы t в 64-байтовый буфер, сформированный на этапе 4
6	Вычислить хэш SHA-1 для результата шага 5 с привлечением Hash-оператора
7	Осуществить операцию побитового исключающего ИЛИ для результата шага 3 и opad
8	Добавить результат SHA-1 шага 6 к 64-байтовому буферу, заполненному в результате шага 7
9	Вычислить хэш SHA-1 для результата шага 8 с привлечением Hash-оператора
10	Прислать результат работы шага 9

Оператор хэширования H(t) соответствует 160-битовому хэшу SHA-1 для группы t. Этот оператор соответствует параметризованному типу ASN.1 H{}. Он используется только в обработке OAEP.

Оператор DigestedData DD(T) соответствует 160-битовому хэшу SHA-1 группы, вложенной в последовательность PKCS DigestedData. Протокол SET использует параметризованный тип DD{} (detached digests). Каждый тип содержимого типа дайджест в SET имеет имя, уникальный идентификатор объекта. Компонент contentType из ContentInfo делается равным значению этого идентификатора.

Компонент digest из DigestedData является результатом вычисления дайджеста сообщения. Он содержит дайджест сообщения типа SET, идентифицируемый компонентом contentType из contentInfo. Дайджест вычисляется с помощью алгоритма из перечня DigestAlgorithm. Вычисление производится для полного DER-представления, включая тэг, длину в октетах и типа ASN.1. Компонент digestAlgorithm из DigestedData устанавливается равным одному из значений кодов алгоритма. Код digestAlgorithm используется получателем для проверки дайджеста сообщения. Верификация осуществляется путем независимого вычисления дайджеста сообщения и сравнения его значения с компонентом digest из DigestedData. Последовательность действий показана в таблице 4.6.2.14.

Процедура симметричного шифрования

Таблица 4.6.2.11. Процедура симметричного шифрования

Шаг	Действие
1	Инициализировать и загрузить информационные поля, зависимые от типа сообщения
2	Преобразовать информационные поля, подлежащие шифрованию, в формат DER
3	Зашифровать результат работы шага 2, используя ключ k. Применяется алгоритм DES или CDMF в зависимости от того, какой из этих алгоритмов поддерживается получателем сообщения. Для DES используется режим DES-CBC.
4	Инициализировать буфер зашифрованных данных с помощью кода типа данных, идентификатора алгоритма (DES или CDMF) и добавить к этой информации результат шага 3.
5	Прислать результат шага 4

Оператор цифровой подписи S(s,t) соответствует PKCS#7 SignedData для группы t, подписанной объектом s. Для SET алгоритмом подписи по умолчанию является RSA с хэшем SHA-1. Обычно для SET подпись делается до шифрования.

Операция цифровой подписи для SignedData всегда производится над данными, представленными в формате DER (ASN.1). Операции подпись SignedData никогда не производятся для произвольных строк октетов (например, для ASCII-строк). По этой причине тип содержимого data не используется никогда. PKCS#7 требует включения в подписываемый текст двух аутентифицированных атрибутов. Такими атрибутами являются contentType и messageDigest, оба они включаются в содержимое, которое подписывается в рамках SET. SignedData имеет формат DER, и содержат октеты тэга и длины атрибутов. Исходные данные для расчета дайджеста сообщения берутся из компонента content последовательности ContentInfo. ContentInfo связывает идентификатор компонента contentType с типом компонента >content. В SET каждый тип содержимого однозначно именуется объектным идентификатором. Так как это значение не защищено от атак подмены, он также включается в authenticateAttributes. Атрибут contentType специфицирует идентификатор объекта, который соответствует значению компонента contentType последовательности ContentInfo. Атрибут messageDigest содержит значение хэшированного компонента content ContentInfo.

Определение последовательности SignerInfos в PKCS#7 допускает любое число подписантов (по одному SignerInfo на каждого). SET PKCS#7 SignedData требует наличия одного подписанта для всех сообщений кроме CertReq и CertInqReq, которые требуют две подписи, когда используются для обновления сертификата. Таким образом, требования SET несколько мягче, чем PKCS#7.

В компоненте SignerInfo из SignerInfos как authenticateAttributes, так и unauthenticateAttributes компоненты специфицируются опционно. В SET компонент unauthenticateAttributes

последовательности SignerInfo всегда отсутствует и никогда не появляется при кодировании SignedData. Компонент же authenticateAttributes всегда присутствует и включается в процесс вычисления дайджеста. Процедура цифровой подписи представлена в таблице 4.6.2.12.

Процедура вычисления дайджеста сообщения

Таблица 4.6.2.14. Процедура вычисления дайджеста сообщения.

Шаг	Действие
1	Установить B равным адресу группы t, для которой вычисляется дайджест
2	Установить L равным длине группы t
3	Инициализировать 160-битный буфер для хранения хэша SHA-1
4	Вычислить хэш SHA-1 для буфера, используя B и L
5	Положить результат шага 4 в поле digest DigestedData
6	Положить идентификатор хэш-алгоритма SHA-1 в digestAlgorithm
7	Установить значение версии равным нулю

Оператор связи L(t1,t2) соответствует последовательности t1 и DigestedData. Компонент связи DigestedData содержит дайджест сообщения для группы t2 и может быть представлен посредством DD(t2). Оператор связи не является симметричным и не может связать t2 с t1.

Целью OAEP является обеспечение гарантии того, что отдельные фрагменты сообщения не будут извлечены из блока PKCS#7. Существуют криптографические методы, которые позволяют определить одни биты сообщения легче, чем другие. OAEP случайным образом перераспределяет биты блока PKCS#7 так, что все биты становятся с этой точки зрения эквивалентными.

Примитивы шифрования E, EH, EX и EXH объединяют RSA-шифрование и алгоритм OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). SET использует OAEP для получения дополнительной защиты информации о счете клиента (владельца карты, продавца или получателя) с помощью цифрового конверта. Реализация алгоритма OAEP продемонстрирована в таблице 4.6.2.15.

Шаблон регистрационной формы MCA и PCA

Таблица 4.6.2.25. Шаблон регистрационной формы MCA и PCA

Me-AqCInitRes	S(CA, Me-AqCInitResTBS)
Me-AqCInitResTBS	{RRPID, LID-EE, Chall-EE, [LID-CA], Chall-CA, RequestType, RegFormOrReferral, [AcctDataField], [Thumbs]}
RRPID	ID пары запрос/отклик
LID-EE	Копируется из Me-AqCInitReq
Chall-EE	Копируется из Me-AqCInitReq
LID-CA	Локальный ID; генерируется СА системой или для нее
Chall-CA	СА обращение по поводу пригодности сертификата запрашивающей стороны
RequestType	Смотри табл. 4.6.2.24
RegFormOrReferral	Смотри табл. 4.6.2.21
AcctDataField	RegField; дополнительное поле регистрационной формы, которое следует отобразить, для того чтобы получить значение AcctData в CertReq
CAEThumb	Оттиск сертификата ключевого обмена СА, который должен использоваться для шифрования CertReq
BrandCRLIdentifier	Смотри раздел описания BrandCRLIdentifier ниже.
Thumbs	Копируется из Me-AqCInitReq

Приложение SET (продавца или расчетного центра) обрабатывает Me-AqCInitRes

следующим образом:

Шаг	Действие
1	Получить Me-AqCInitRes из входного сообщения.
2	Верифицировать подпись. Если она некорректна, послать сообщение об ошибке с ErrorCode равным signatureFailure.
3	Из Me-AqCInitResTBS извлекаются и запоминаются RRPID, LID-EE, Chall-EE, CAEThumb, BrandCRLIdentifier, оттиски и TequestType
4	Проверяется, что RRPID совпадает со значением, извлеченным из цифрового конверта сообщения и кодом, посланным в Me-AqCInitReq. Если равенства нет, посылается сообщение об ошибке с ErrorCode равным unknownRRPID.
5	Проверяется, что полученный Chall-EE соответствует посланному в Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным challengeMisMatch.
6	Проверяется, что полученный список оттисков соответствует посланному в сообщении Me-AqCInitReq. Если соответствие отсутствует, посылается сообщение об ошибке с ErrorCode равным thumbsMisMatch.
7	Если в Me-AqCInitResTBS включено поле RegFormData то: Запомнить LID-CA и Chall-CA Отобразить текст общих требований и ввод пользователя, прежде чем приложение SET сформирует CertReq Отобразить видимые поля регистрационной формы и приглашение пользователю для заполнения этих полей Если Me-AqCInitResTBS содержит URL, отобразить логотипы расчетной системы и/или карты Если присутствует поле AcctDataField, отобразить имя и описание, а также приглашение пользователю для заполнения этого поля Заполнить невидимые поля регистрационной формы. Если приложение не может заполнить поле, оно будет оставлено пустым, остальные поля будут заполнены обычным порядком и пересланы в CertReq.
8	После того как продавец или расчетный центр заполнили регистрационную форму и ввели AcctData, (если это требуется) генерируется CertReq.
9	Если в Me-AqCInitResTBS включено поле ReferrelData, то: Отображается причина Если включено поле ReferralLoc, отображается URL или электронный адрес из ReferralLoc CertReq не генерируется. Протокол продолжит работу с посылки Me-AqCInitReq

<
Владелец карты, системный администратор продавца или расчетного центра вводит информацию, необходимую для RegForm, а приложение SET (EE) посылает сообщение CertReq центру СА. После успешной верификации CertReq формируются сертификаты, которые посылаются ЕЕ в сообщениях CertRes. Если в регистрационной форме обнаружены ошибки, СА оповещает об этом в CertRes. Приложение SET может повторно представить исправленную регистрационную форму в новом CertReq.
Владелец карты вводит ее номер, дату пригодности и другие данные, запрошенные ССА в регистрационной форме.
Системный администратор продавца вводит аутентификационные данные расчетного центра и другую информацию, запрошенную МСА в регистрационной форме.
Системный администратор расчетного центра вводит аутентификационные данные продавца (если таковые имеются) и другую информацию, запрошенную РСА в регистрационной форме.
Запрос сертификата (CertReq) содержит в себе:
Новые общедоступные ключи.
Обновляемые сертификаты (если таковые есть).
Заполненную регистрационную форму.
Информацию об аккоунте ЕЕ
Секретные ключи, которые должен использовать СА для шифрования отклика CertRes,
Другие контрольные коды
Поле данных сообщения и опционно хэш аккоунт-данных ЕЕ подписываются секретным ключом, соответствующим сертификату подписи, подлежащему обновлению (если таковой имеется) и новым секретным ключом. Симметричный ключ, используемый для этого шифрования, берется из OAEP (Bellare-Rogaway Optimal Asymmetric Encryption Padding). Все перечисленные данные шифруются с использованием общедоступного ключа.
Если СА обнаружит ошибку в представленной регистрационной форме, информация о ней будет передана в сообщении CertRes и будет послан новый запрос CertReq.
ЕЕ-приложение генерирует CertReq следующим образом. Это делается с использованием EncX или Enc техники в зависимости от присутствия AcctInfo. Если ЕЕ является владельцем карты, AcctInfo всегда содержит аутентификационные данные, которые могут быть, а могут и не быть затребованы СА.


Me- AqCInitRes указывает, нужно ли AcctInfo в AcctInfoField. EncX используется лишь при наличии AcctInfo.
Если ЕЕ является владельцем карты, продавцом или расчетным центром и намерен послать AcctInfo, то CertReq формируется с привлечением методики EncX следующим образом.

Шаг	Действие
1	Если RequestType соответствует новому сертификату подписи или его обновлению, формируется пара ключей (общедоступный/секретный), необходимых для подписи сертификата
2	Если запрашивающим субъектом не является владелец карты и, если RequestType соответствует новому сертификату шифрования, формируется пара ключей (общедоступный/секретный), необходимых для сертификата шифрования.
3	Если ЕЕ является владельцем карты, генерируется 160-битовый случайный код – CardSecret.
4	Генерируется 160-битовый случайный код – EXNonce
5	Формируется CertReqTBS: Генерируется RRPID Если ЕЕ получил RegFormRes или Me-AqCInitRes, копируется RequestType из этого сообщения, в противном случае вводится требуемый RequestType. Заполняется поле RequestData Копируется LID-EE (если присутствует) и Chall-CA из предыдущего сообщения. Если его нет, генерируется новый. Генерируется новый Chall-EE3 Копируется LID-CA, (если присутствует) и Chall-CA из предыдущего сообщения. Если ЕЕ является продавец карты или расчетный центр, то: заполняется поле IDData и, если в Me-AqCInitRes включено поле AcctDataField, записывается AccData, введенная ЕЕ Если ЕЕ является продавец, занести PAN, CardExpiry и CardSecret. Сформировать EXNonce Скопировать RegForm ID, который был послан в RegFormRes или Me-AqCInitRes Если RegFieldSeq присутствовал в Me-AqCInitRes или RegFormRes, включить новую или исправленную форму.
6	Если приложение владельца карты выберет алгоритм шифрования CertRes, производится заполнение ID алгоритма и ключа в CaBackKeyData. Если общего алгоритма не найдено, процесс прерывается, о чем уведомляется пользователь. Заносится вновь сформированный общедоступный ключ, PublicKeyS и/или PublicKeyE, предназначенный для сертификации СА. Если ЕЕ является продавец или расчетный центр, а тип запроса соответствует обновлению сертификата шифрования, заполняется EEThumb с оттиском сертификата, подлежащего обновлению. Если тип запроса соответствует обновлению сертификата подписи, оттиск сертификата подписи не требуется, так как CertReq подписан им. Опционно включается список, который содержит оттиски для каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентно размещенных в кэше.
7	Данные, подлежащие дополнительному шифрованию, имеют следующий формат. Если ЕЕ является продавец карты, заполняется PAN, CardExpiry, CardSecretCardNonce и EXNonce в PANData0. Если ЕЕ является продавец или расчетный центр, опционно заполняется AccTData и EXNonce.
8	Данные укладываются в конверт с использованием техники EncX: Включить: Обработка а. В качестве подписанных данных CertReqTBS То, как данные подписываются зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса относится к новому сертификату подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуcя в PublicKeyS. Если тип запроса относится к обновлению сертификата подписи, подписать данные, используя секретный ключ, соответствующий общедоступному ключу, содержащемуся в PublicKeyS и, используя секретный ключ, соответствующий обновляемому сертификату. Если тип запроса относится к сертификату шифрования, подписать данные, используя секретный ключ, соответствующий существующему сертификату подписи. Если данные подписаны секретным ключом, который не соответствует сертификату, установить SignerInfo.SerialNumber равным нулю, а SignerInfo.IssuerName=”Null-DN”, т.е. RDNSequence равна кодированному NULL. Тип содержимого SignedData устанавливается равным id-set-content-CertReqTBS. b. Результат шага 6 в качестве данных, подлежащих дополнительному шифрованию Провести дополнительное шифрование, используя СА-сертификат, указанный CAEThumb в CardCInitRes или RegFormRes, если один из них был включен, или Me-AqCInitRes c. CertReqTBEX в качестве данных, подлежащих шифрованию Зашифровать CertReqTBEX и установить тип содержимого EnvelopedData равным id-set-content-CertReqTBEX
9	Сформировать цифровой конверт и послать сообщение CertReq центру СА

<


Если приложением ЕЕ является продавец или расчетный цент, который не имеет данных AcctData (в AcctInfo), чтобы их послать, тогда генерируется CertReq с привлечением техники Enc:

Шаг	Действие
1	Если RequestType соответствует обновлению сертификата подписи, формируется пара ключей (секретный/общедоступный) для сертификата подписи
2	Если RequestType соответствует новому или обновляемому сертификату шифрования, формируется пара ключей (секретный/общедоступный) для сертификата шифрования
3	Сгенерируется 160-битное случайное число - EXNonce
4	Данные CertReqData формируются следующим образом: Генерируется RRPID Если продавец или расчетный центр получают Me-AqCInitRes, RequestType копируется из этого сообщения, в противном случае это поле заполняется обычным путем. Заполняется поле ReqestDate Копируется LID-EE из предыдущего сообщения. Если такового нет, генерируется новое. Генерируется новое Chall-EE3 Копируется LID-CA (если имеется) и Chall-CA из предыдущего сообщения, если таковое имеется. Заполнить поле IDData Занести RegFormID, полученный из Me-AqCInitRes Занести новую или скорректированную форму RegForm Занести вновь сформированные общедоступные ключи, PublicKeyS и/или PublicKeyE, предназначенные для сертификации СА. Если RequestType соответствует обновлению сертификата шифрования, заполняется EEThumb оттиском сертификата, подлежащего обновлению. Опционно включается список, который содержит оттиски каждого CRL, сертификата SET, BrandCRLIdentifier и корневого сертификата, резидентные в кэше владельца карты.
5	Поместить данные в цифровой конверт, используя инкапсуляцию Enc: Включить: Обработка CertReqData в качестве информации, подлежащей подписыванию. То, как подписываются данные, зависит от RequestType. Имеется как минимум одна и допускаются две подписи, т.е. SignerInfo для CertReq. Если тип запроса соответствует новому сертификату подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS. Если тип запроса соответствует обновлению сертификата подписи, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который содержится в PublicKeyS, а затем посредством секретного ключа, соответствующего обновляемому сертификату. Если тип запроса соответствует сертификату шифрования, данные подписываются с применением секретного ключа, составляющего пару с общедоступным ключом, который соответствует существующему сертификату подписи. Если данные подписаны ключом, который еще не соответствует сертификату, следует установить Signer.Info.SerialNumber равным “Null-DN”. Тип содержимого SignedData делается равным id-set-content-CertReqData. Производится DER-кодирование полученной информации SignedData с целью получения CertReqTBE. Ключ DES в качестве данных, подлежащих дополнительному шифрованию Для Enc-обработки единственной информацией, которая должна быть зашифрована, является симметричный ключ, используемый для шифрования “обычных данных”. Шифруется ключ с применением сертификата, указанного посредством CAEThumb в Mt-AqCInitRes. CertReqTBE в качестве обычных данных, подлежащих шифрованию Шифруется CertReqTBE и устанавливается ContentType равным id-set-Content-CertReqTBE.
6	Подготовить цифровой конверт и послать CertReq центру СА

Формат сообщения CertReq, генерируемого EE (End Entity) представлен ниже в таблице 4.6.2.26:

Скорости передачи данных по цифровым каналам

Таблица 2.4.1 Скорости передачи данных по цифровым каналам

Линия	Быстродействие Мбит/с	Число аудио каналов
DS-0	0,064	1
T-1	1,544	24
T-1C	3,152	48
T-2	6,312	96
T-3	44,736	672

Скорости передачи данных по оптическим каналам

Таблица 2.4.2. Скорости передачи данных по оптическим каналам

Линия OC-x	Быстродействие Мбит/с	Число аудио каналов	STM-x
1	51,84	672	-
3	155,52	2016	1
9	466,56	6048	3
12	622.08	8064	4
24	1244,16	16128	8
48	2488,32	32256	16
96	4976,64	64512	32
192	9953,28	129024	64

Еще одним методом, нацеленным на повышение эффективности преобразования входного аналогового сигнала в код, является дельта-модуляция.

Сравнение европейской и американской иерархии каналов

Таблица 4.3.6.1. Сравнение европейской и американской иерархии каналов

Уровень иерархии	Скорости передачи для иерархий
	Американская 1544 Кбит/c	Европейская 2048 Кбит/c	Японская 1544 Кбит/c
0	64 (DS0)	64	64
1	1544 (DS1)	2048 (Е1)	1544 (DS1)
2	6312 (DS2)	8448 (Е2)	6312 (DS2)
3	44736 (DS3)	34368 (Е3)	32064 (DSJ3)
4	274176 (Не входит в рекомендации МСЭ-Т)	139264 (Е4)	97728 (DSJ4)

Но добавление выравнивающих бит в PDH делает затруднительным идентификацию и вывод потоков 64 Кбит/с или 2 Мбит/с, замешанных в потоке 140 Мбит/с, без полного демультиплексирования и удаления выравнивающих бит. Если для цифровой телефонии PDH достаточно эффективна, то для передачи данных она оказалась недостаточно гибкой. Именно это обстоятельство определило преимущество систем SONET/SDH. Эти виды иерархических систем позволяют оперировать потоками без необходимости сборки/разборки. Структура кадров позволяет выполнять не только маршрутизацию, но и осуществлять управление сетями любой топологии. Здесь использован чисто синхронный принцип передачи и побайтовое, а не побитовое чередование при мультиплексировании. Первичной скоростью SONET выбрана 50688 Мбит/с (ОС1). Число уровней иерархии значительно расширено (до 48). Кратность уровней иерархии равна номеру уровня.

CCITT выработал следующие рекомендации на эту тему: G.707, G.708 и G.709. CCITT разработал рекомендации для высокоскоростных каналов H:

H0		384 Кбит/с=4*64 Кбит/с. 3*h0=1,544 Мбит/с
H1	H11	1536 Кбит/с
	H12	1920 Кбит/с
h4		~135 Мбит/с
H21		~34 Мбит/с
H22		~55 Мбит/с.

На нижних уровнях SDH и SONET в некоторых деталях различаются. Внедрение стандарта SONET ликвидировало многие недостатки каналов T-1 (ограничения на размер максимальной полезной нагрузки, простота стыковки скоростных каналов связи). SONET хорошо согласуется с ATM и FDDI, что создает фундаментальный базис для широкополосных сетей ISDN (B-ISDN). Следует учитывать, что SONET сохраняет совместимость с уже существующими каналами, убирая лишь некоторые присущие им недостатки.
Одним из базовых каналов сегодня является T-1 (1544 Кбит/с для США). Он содержит в себе 24 субканалов DS-0 (digital signal at zero level, 64 Кбит/с, США). Мультиплексирование 24 каналов DS-0 по времени формирует канал DS-1 (24 канала*64 Кбит/с)+8 Кбит/с=1544 Кбит/с, последнее слагаемое связано с заголовками информационных блоков). Этой величине соответствует в Европе 2048 Кбит/с (канал E-1 = 30*ds0). Два канала T-1 образуют канал T-1c, четыре канала T-1 формируют канал T-2, а семь T-2 (28 T-1) образуют T-3. Для оптических систем связи в качестве базового принят канал OC-1, равный по пропускной способности T-3. А кадр STS-1 выбран в качестве основного в системе SONET. Кадр STS-1 имеет 9 строк и 90 столбцов (810 байт). Кадры передаются с частотой 8 кГц, что дает для канала STS-1 51840 Кбит/с = 8000Гц*810байт*8бит. Эта цифра характеризует физическую скорость обмена, включающую в себя передачу служебной информации (заголовков), эффективная информационная пропускная способность равна 50112 Кбит/с. Быстродействие каналов более высокого уровня SONET получается умножением пропускной способности STS-1 (51,84 Мбит/с) на целое число. Так пропускная способность OC-3 будет равна 155,52 Мбит/с, а OC-24 - 1244,16 Мбит/с и т.д. Целью создателей SONET было прямая стыковка оптических каналов различных сервис-провайдеров (вспомним, что непосредственное соединение каналов T-1 и E-1 не возможно). SDH допускает сцепление нескольких контейнеров (в том числе и разных размеров), если в один контейнер данные не помещаются. Допускается объединение нескольких контейнеров равного размера в один большой. Хотя относительный размер заголовка виртуального контейнера невелик (~3,33%), его объем достаточен для передачи достаточно больших объемов служебной информации (до 5,184 Мбит/c).
В SONET предусмотрено четыре варианта соединений: точка-точка, линейная цепочка (add-drop), простое кольцо и сцепленное кольцо (interlocking ring). Линейные варианты используются для ответвлений от основного кольца сети.


Наиболее распространенная топология - самовосстанавливающееся кольцо (см. также FDDI). Такое кольцо состоит из ряда узлов, которые связаны между собой двухсторонними линиями связи, образующими кольцо и обеспечивающими передачу сообщений по и против часовой стрелки. Способность сетей SONET к самовосстановлению определяется не только топологией, но и средствами управления и контроля состояния. При повреждении трафик перенаправляется в обход, локально это приводит к возрастанию информационного потока, по этой причине для самовосстановления сеть должна иметь резерв пропускной способности (как минимум двойной). Но, проектируя сеть, нужно избегать схем, при которых основной и резервный маршрут проходят через одну и ту же точку, так как они могут быть, если не повезет, повреждены одновременно. Резервные пути могут использоваться для низкоприоритетных обменов, которые могут быть заблокированы при самовосстановлении.
Сети SONET (и SDH) имеют 4 архитектурных уровня:
Фотонный (photonic) - нижний уровень иерархии. Этот уровень определяет стандарты на форму и преобразование оптических сигналов, на электронно-оптические связи.
Секционный (section) - предназначен для управление передачей STS-кадров (sonet) между терминалами и повторителями. В его функции входит контроль ошибок.
Линейный (line) - служит для синхронизации и мультиплексирования, осуществляет связь между отдельными узлами сети и терминальным оборудованием, например линейными мультиплексорами, выполняет некоторые функции управления сетью.
Маршрутный (path) - описывает реальные сетевые услуги (T-1 или T-3), предоставляемые пользователю на участке от одного терминального оборудования до другого.
Существующие PDH-сети мультиплексируют каналы, используя каскадную схему, показанную на Рисунок 4.3.6.1.

Статусные коды для запросов сертификата

Таблица 4.6.2.30. Статусные коды для запросов сертификата

Код	Значение	Источник
requestComplete	Запрос сертификата одобрен	CA
invalidLanguage	В запросе указан неверный язык	CA
invalidBIN	Запрос сертификата отклонен из-за некорректного BIN	Эмитент или получатель
sigValidationFail	Запрос сертификата отклонен по причине некорректной подписи	CA
decryptionError	Запрос сертификата отклонен из-за ошибки дешифрования	CA
requestInProgress	Запрос сертификата обрабатывается	СА, эмитент или получатель
rejectedByIssuer	Запрос сертификата отклонен эмитентом карты	Эмитент
requestPended	Запрос сертификата ждет обработки	СА, эмитент или получатель
rejectedByAquirer	Запрос сертификата отклонен банком продавца (получателем)	Получатель
regFormAnswerMalformed	Запрос сертификата отклонен из-за неверной позиции в регистрационной форме.	CA
rejectedByCA	Запрос сертификата отклонен центром сертификации	CA
unableToEncryptCertRes	Центр сертификации не получил ключа и по этой причине не может зашифровать отклик для владельца карты	CA

Конечный пользователь ЕЕ проверяет новый сертификат следующим образом:

Шаг	Действие
1	Выделить CertRes из входного сообщения. Если CertRes содержит подписанные данные, дешифровать их и проверить подпись CertRes (см. описание методики EncK). Процедура осуществляется для полученных сертификатов CRL и BrandCRLIdentifier.
2	Проверить, что полученные оттиски соответствуют посланным в сообщении CardCInitReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch.
3	Проверить, что LID-EE и Chall-EE соответствуют значениям, посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным challengeMismatch.
4	Если CertStatusCode указывает “Certificate request complete” (с запросом сертификата все в порядке), то: Извлекаются новые сертификаты из сертификатной секции SignedData и проверяются подписи. Проверяется, что полученные CertThumbs соответствуют посланным в CertReq. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным thumbsMismatch. В случае владельца карты извлекается CaMsg, отображается логотип и CardholderMsg из CaMsg и запоминается CardCurrency. Проверяется, что общедоступные ключи в сертификате соответствуют секретным ключам. Если проверка не прошла, возвращается сообщение Error с ErrorCode равным invalidCertificate. В случае владельца карты выполняются следующие дополнительные действия: Для того чтобы получить PANSecret, вычисляется (Nonce-CCAA CardSecret) Вычисляется уникальный идентификатор владельца карты, HMAC-SHA-1{{PAN, cardExpiry}, PANSecret}, т.е. Salted Hash, и проводится верификация того, что полученный результат соответствует значению сертификата.
5	Если CertStatusCode равен “MalFormed Registration Form Items”, это означает, что некоторые позиции регистрационной формы заполнены неверно. Для каждой ошибочной позиции приложение ЕЕ занесет в CertRes номер этой позиции и соответствующее сообщение об ошибке. ЕЕ разрешается повторить ввод для полей с ошибкой и повторно послать CertReq с новым запросом сертификата.
6	Если CertStatusCode установлен равным requestinProgress или requestPended, сертификат может быть доставлен позднее с помощью процедуры CertInqReq
7	Если CertStatusCode указывает какой-либо иной статус, отображается EEMessage.

Структура AcqCardMsg

Таблица 4.6.2.43. Структура AcqCardMsg

AcqCardMsg	EncK(AcqBackKeyData, P, AcqCardCodeMsg) AcqBackKeyData предоставляется владельцем карты в PI. Зашифрованное сообщение адресуется владельцу карты.
AcqBackKeyData	Копируется из PIHead.AcqBackKeyData (см. табл. 4.6.2.40)
AcqCardCodeMsg	{AcqCardCode, AcqCardMsgData}
AcqCardCode	Числовой код
AcqCardMsgData	{[AcqCardText], [AcqCardURL], [AcqCardPhone]}
AcqCardText	Текстовое сообщение, отображаемое владельцу карты
AcqCardURL	URL HTML-сообщения, отображаемого владельцу карты
AcqCardPhone	Телефонный номер, предоставляемый владельцу карты

Для AcqCardCode определены следующие значения:

messageOfDay	Банк продавца хочет, чтобы это сообщение было передано всем
accountInfo	Информация о счете должна быть передана назад пользователю
сallCustomerService	Предлагает приложению отобразить сообщение, рекомендующее пользователю обратиться в службу обслуживания клиентов

CapToken предоставляет данные, необходимые расчетному центру для платежной транзакции на фазе авторизации. Структура данных CapToken представлена в таблице 4.6.2.44.

Структура AuthReq

Таблица 4.6.2.64. Структура AuthReq

AuthReq	EncB(M, P, AuthReqData, PI)
AuthReqData	{AuthReqItem, [Mthumbs], CaptureNow, [SaleDetail]}
PI	См. табл. 4.6.2.39.
AuthReqItem	{AuthTags, [CheckDigests], AuthReqPayload}
MThumbs	Оттиски сертификатов, CRL и BrandCRLIdentifiers, хранимые в данный момент в кэше продавца.
CaptureNow	Булева переменная, указывающая, что резервирование должно проводиться, если проведена авторизация.
SaleDetail	См. табл. 4.6.2.47
AuthTags	{AuthRRTags, TransIDs, [AuthRetNum]}
CheckDigests	{HOIData, HOD2} используется расчетным центром для аутентификации PI. Опускается, если PI = AuthToken
AuthReqPayload	См. табл. 4.6.2.65
AuthRRTags	RRTags Необходим RRPID, так как для одного PReq может потребоваться более одного цикла авторизации.
TransIDs	Копируется из соответствующего поля OIData (см. табл. 4.6.2.59)
AuthRetNum	Идентификация запроса авторизации, используемого в пределах финансовой сети.
HOIData	DD(OIData) (См. табл. 4.6.2.59) Независимый хэш, вычисляемый продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.
HOD2	DD(HODInput) (См. табл. 4.6.2.59) Вычисляется независимо продавцом. Расчетный центр сравнивает это значение с копией, сформированной владельцем карты в PI.

Структура данных AuthReqPayload представлена в таблице 4.6.2.65.

Структура AuthReqPayload

Таблица 4.6.2.65. Структура AuthReqPayload

AuthReqPayload	{SubsequentAuthInd, AuthReqAmt, [AVSData], [SpecialProcessing], [CardSuspect], RequestCardTypeInd, [InstallRecurData], [MarketSpecAuthData], MerchData, [ARqExtensions]}
SubsequentAuthInd	Булева переменная, указывающая на запросы со стороны продавца дополнительной авторизации из-за раздельной поставки
AuthReqAmt	Может отличаться от PurchAmt; политика банка продавца может наложить ограничение на допустимое отличие
AVSData	{[StreetAddress], Location} Адрес счета владельца карты: содержимое получается от владельца карты посредством механизмов, выходящих за пределы SET.
SpecialProcessing	Числовое поле, указывающее тип запрошенной обработки
CardSuspect	Числовое поле, указывающее, что продавец подозревает владельца карты, и на причину подозрения
RequestCardTypeInd	Указывает, что тип карты должен быть прислан в поле CardType отклика. Если информация недоступна, присылается значение unavailable(0).
InstallRecurData	См. табл. 4.6.2.41.
MarketSpecAuthData	< MarketAutoAuth, MarketHotelAuth, MarketTransportAuth > Специфические авторизационные данные рынка
MerchData	{[MerchCatCode], [MerchGroup]}
ARqExtensions	Данные в расширении авторизационного запроса должны иметь финансовый характер и относиться к процессу авторизации (или последующей оплаты заказа) расчетного центра, финансовой сети или эмитента карты.
StreetAddress	Адрес улицы владельца карты
MarketAutoAuth	{Duration}
MarketHotelAuth	{Duration, [Prestige]}
MarketTransportAuth	{} В настоящее время нет авторизационных данных для этого сегмента рынка
MerchCatCode	4-байтовый код (определен в ANSI X9.10), описывающий тип бизнеса, продукта или услуги продавца.
MerchGroup	Числовой код, идентифицирующий общую категорию продавца
Duration	Ожидаемая длительность транзакции (в днях). Эта информация помогает понять, какое время пройдет со времени авторизации до оплаты заказа (capture).
Prestige	Числовой тип приоритета, определяется платежной системы карты.

<
Схема обработки запроса AuthReq платежным центром представлена в таблице ниже.

Шаг	Действие
1	Извлечь запрос из транспортного сообщения
2	Дешифровать PI
3	Сравнить TransIDs из AuthTags и PIHead или AuthToken: Проверить что коды XID идентичны Проверить что коды LID-C идентичны Если LID-M присутствуют в AuthTags и PIHead, сравнить их значения Если хотя бы одна из проверок не прошла, сообщение отбрасывается и возвращается AuthCode = piAuthMismatch
4	Если PI является AuthToken: Обработать AuthToken В противном случае, если PI подписаны: Проверить, что платежная система в подписи владельца карты согласуется с платежной системой сертификата шифрования расчетного центра. Если согласия нет, то авторизация отвергается путем отправки AuthCode = CardMerchBrandMismatch. Проверить PANData Запомнить данные из PANData В противном случае, если PI не подписаны: Проверить, что расчетный центр не требует подписи (путем проверки сертификата платежного центра). Если подпись требуется, отвергнуть авторизацию, послав AuthCode = signatureRequired Верифицировать хэш в EXH Запомнить данные из PANToken
5	Проверить состояние авторизации PI. Если PI была обработана и не отвергнута или отозвана, отвергнуть авторизацию, послав AuthCode = piPreviouslyUsed
6	Обработать PIHead: Проверить, что PiHeadMerchantID соответствует содержимому поля merID в расширении merchantData сертификата подписи, используемом при верификации подписи продавца для сообщения AuthReq. Если соответствия нет, авторизация отвергается и посылается отклик с AuthCode = piAuthMismatch. Это предотвращает атаки подстановки, когда PI разных продавцов меняются местами. Передать TransStain эмитенту через финансовую сеть для верификации или запоминания с последующей верификацией. Проверить хэши OIData, полученные от владельца карты и продавца. Если они не совпадают, прислать AuthCode = piAuthMismatch. Проверить, что HOD от HIHead соответствует HOD2 от AuthReqPayload, при несовпадении прислать сообщение Error c ErrorCode = HODMismatch Обработать PIExtensions. Если обнаружены неподдерживаемые расширения, сообщение отвергается путем посылки сообщения Error c кодом unrecognizedExtension Запомнить данные от PIHead
7	Если в AuthReq имеется InstallRecurData, проверить, что InstallRecurData в AuthReqPayload и в PIHead совпадают. Если это не так, отклонить авторизацию с AuthCode = InstallRecurMismatch.
8	Запомнить AcqBackInfo в безопасной локальной памяти, если таковая имеется.
9	Если captureNow=TRUE и платежная система не поддерживает этот режим, послать AuthCode = captureNotSupported
10	Выполнить авторизацию через финансовую сеть платежной карты
11	Если captureNow=TRUE, выполнить платеж через существующую финансовую сеть платежной карты
12	Продолжить формирование сообщения AuthRes

<


Отклик AuthRes генерируется после завершения авторизации через финансовую сеть платежной карты. AuthCode и AuthAmt извлекаются из данных, полученных через финансовую сеть платежной карты. Формирование отклика AuthRes производится по схеме, изложенной в нижеприведенной таблице.

Шаг	Действие
1	Получить необходимые данные от авторизационного процесса
2	Заполнить поле AuthTags из AuthReq. Если это необходимо, занести в поле AuthRetNum, значение, полученное из авторизационного процесса.
3	Заполнить текущее значение BrandCRLIdentifier, хранимое расчетным центром, если для текущего BrandCRLIdentifier не получен оттиск или он устарел.
4	Если Mthumbs из AuthReq указывает, что продавцу нужен новый Cert-PE шифрования информации для расчетного центра: Вставить Cert-PE в цифровой конверт PKCS#4 Вставить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
5	Заполнить поле PaySysID в TransIDs, если они получены из авторизационного процесса
6	Заполнить поле PANToken, если это необходимо для сертификата продавца,
7	Заполнить AuthResBaggage (опционно): Опционно заполнить CapToken Опционно заполнить AcqCardMsg, если соответствующие правила платежной системы требуют посылки запроса и получения ключа от владельца карты. Занести в AuthToken значения, полученные в InstallRecurData продавца, если осуществлена дополнительная авторизация (в предыдущем AuthReq SubsequentAuthInd=TRUE). Если ни одна из этих величин не присутствует, AuthResBaggage характеризуется пустой последовательностью.
8	Опционно заполнить BatchStatus, как этого требует политика платежной системы карты.
9	Если PANToken имеется, реализовать EncBX-инкапсуляцию
10	Вставить сообщение в цифровой конверт и отправить владельцу карты

Расчетный центр формирует AuthResPayload следующим образом.

Шаг	Действие
1	Сгенерировать CapResPayload
	Заполнить AuthCode и AuthAmt c привлечением результатов авторизационного процесса Если авторизация отвергнута, вернуть AuthAmt, специфицированный в предыдущем AuthReq. Если флаг CaptureNow был указан в AuthReq, но не был реализован, вернуть в случае успешной авторизации AuthCode = captureNotSupported
3	Заполнить поле CurrConv в соответствии с запрошенным владельцем карты типом валюты и с учетом текущего курса, если специфицирована валюта, отличная от используемой владельцем карты.
4	Заполнить ResponseData: Заполнить поле AuthValCodes следующим образом: записать ApprovalCode, RespReason, AuthCharInd, ValidationCode и LogRefID, если получены из авторизационного процесса. Если RequestCardTypeInd в AuthReq был установлен равным TRUE, занести в поле CardType значение, полученное из авторизационного процесса. Занести в AuthCharInd значение, присланное авторизационным процессом

Структура полей AuthRes представлена в таблице 4.6.2.66.

Структура AuthResPayload

Таблица 4.6.2.67. Структура AuthResPayload

AuthResPayload	{AuthHeader, [CapResPayload], [ARsExtensions]}
AuthHeader	{AuthAmt, AuthCode, ResponseData, [BatchStatus], [CurrConv]}
CapResPayload	Присылается, если CaptureNow имеет значение TRUE в AuthReq. См. табл. 4.6.2.71.
ARsExtensions	Данные в расширении к авторизационному отклику должны быть финансовыми и существенными для обработки авторизационного отклика.
AuthAmt	Копируется из AuthReqPayload.AuthReqAmt
AuthCode	Числовой код, индицирующий результат процесса авторизации
ResponseData	{[AuthValCodes], [RespReason], [CardType], [AVSResult], [LogRefID]}
BatchStatus	См. табл. 4.6.2.53.
CurrConv	{CurrConvRate, CardCurr}
AuthValCodes	{[ApprovalCode], [AuthCharInd], [ValidationCode], [MarketSpecDataID]}
RespReason	Числовой код, который указывает на объект сервиса авторизации и причину отказа (если таковая имеется)
CardType	Числовой код, который указывает на тип карты, использованной для транзакции.
AVSResult	Числовой код отклика адресной верификационной службы
LogRefID	Алфавитно-цифровые данные, ассоциируемые с авторизационной транзакцией (используется для распознавания при отзыве предшествующего запроса)
CurrConvRate	Курс обмена валюты. Значение, на которое нужно умножить AuthReqAmt, чтобы получить сумму в валюте владельца карты.
AuthReqAmt	Код валюты владельца карты в стандарте ISO 4217
ApprovalCode	Код одобрения, присваиваемый транзакции эмитентом
AuthCharInd	Числовое значение, которое указывает условия, при которых выполнена авторизация.
ValidationCode	4-байтовый алфавитно-цифровой код, вычисленный, чтобы гарантировать, что необходимые поля авторизационных сообщений присутствуют в соответствующих клиринговых сообщениях.
MarketSpecDataID	Числовой код, который указывает тип данных, специфических для рынка, представляемых при авторизации (как это определено финансовой сетью)

Список возможных значений кода AuthCode приведен ниже

approved	Запрос авторизации удовлетворен
unspecifiedFailure	Запрос авторизации не может быть обработан по причине, которая отсутствует в приведенном здесь списке.
declined	Запрос авторизации отклонен
noReply	Эмитент не откликнулся на запрос авторизации. Это значение часто указывает на временное отсутствие доступа к системе обработки данных эмитента.
callIssuer	Эмитент запрашивает телефонный вызов от продавца
amountError	Такое число транзакций не может быть обработано системой (банком продавца, финансовой сетью, эмитентом и т.д.)
expiredCard	Срок действия карты истек
invalidTransaction	Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как тип транзакции является недопустимым.
systemError	Запрос не может быть обработан последующей системой (банком продавца, финансовой сетью, эмитентом и т.д.), так как запрос содержит в себе некорректные данные.
piPreviouslyUsed	Платежная инструкция (PI) в запросе авторизации использовалась для первичной авторизации (отклик, сформированный расчетным центром).
recurringTooSoon	Минимальное время между авторизациями для рекуррентной транзакции еще не истекло (отклик, сформированный расчетным центром).
recurringExpired	Дата истечения действия для рекуррентной транзакции наступила (отклик, сформированный расчетным центром)
piAuthMismatch	Дата в PI от владельца карты не согласуется с данными в OD от продавца.
installRecurMismatch	InstallRecurData в PI от владельца карты не согласуется с InstallRecurData в OD от продавца.
captureNotSupported	Расчетный центр не поддерживает платеж (capture).
signatureRequired	Опция неподписанной PI не поддерживается расчетным центром для данной платежной системы.
cardMerchBrandMismatch	Платежная система в сертификате подписи владельца карты не согласуется с платежной системой сертификата шифрования расчетного центра.

<
Обработка продавцом отклика AuthRes производится следующим образом.

Шаг	Действие
1	Получить отклик из входного сообщения
2	Извлечь запись транзакции и сравнить с AuthTags: Проверить, что XID соответствует транзакции. Если соответствия нет, сообщение отвергается с Error = unknownXID Проверить, что LID-M и, если имеется в записи транзакции, LID-C согласуются с содержимым записи транзакции. Если соответствия нет, сообщение отвергается, а в журнал операций расчетного центра записывается Error = unknownLID.
3	Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
4	Обработать AuthResPayload
5	Проверить, что GKThumb соответствует существующему сертификату шифрования расчетного центра, если GKThumb имеется. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата
6	Если BatchStatus присутствует, обработать и запомнить данные.
7	Обработать AuthResBaggage: Запомнить CapToken, если это поле присутствует Если имеется AcqCardMsg, запомнить его для отправки владельцу карты Запомнить AuthToken, если имеется, для последующей авторизации. Если в AuthReq SubsequentAuthInd = TRUE, будет возвращено AuthToken
8	Если присутствует PANToken, записать его в безопасную локальную память
9	Продолжить обработку оплаты заказа и/или отклика на покупку, в зависимости от результатов авторизации и временных рамок продавца для возвращения отклика на покупку.

Алгоритм обработки AuthResPayload представлен ниже.

Шаг	Действие
1	Обработать ARsExtensions, если они имеются. Если неподдерживаемое расширение помечено как критическое, расчетный центр производит запись в журнал Error = unrecognizedExtension, а сообщение игнорируется.
2	Обрабатать CapResPayload: Обработать CRsPayExtensions. Если имеется нераспознанное расширение, помеченное как критическое, отвергнуть AuthRes, а расчетный центр делает запись в журнал Error = unrecognizedExtension Обработать CapCode с целью определения результата Обработать SaleDetail в соответствии с политикой платежной системы карты Для успешной оплаты заказа, записать CapCode и CapAmt. Если делался запрос оплаты (capture), будет возвращен CapResPayload
3	Если имеется CurrConv, запомнить его для переадресации владельцу карты
4	Обработать AuthCode, AuthAmt и ResponseData: Для определения результата обрабатывается AuthCode. Запомнить AuthCode и AuthAmt для получения успешного результата. Запомнить ValidationCode для успешного исхода, если это поле имеется. Запомнить AuthValCode, если имеется. Запомнить AVSResult, если имеется. Запомнить LogRefID, если имеется.

<


Когда эмитент обрабатывает авторизационный запрос, возможно получение трех результатов: одобрение, отклонение, условное отклонение. Последний вариант называется referral (откладывание) и индицируется значением callissuer(4) в AuthCode. При получении отклика referral продавец может обратиться в свой банк по телефону (вне пределов протокола SET). После идентификации транзакции банк свяжет продавца с эмитентом. В результате этого телефонного вызова эмитент может преобразовать авторизацию в одобрение путем посылки продавцу кода ApprovalCode.
Программное обеспечение продавца позволяет оператору сервера продавца вводить код одобрения. Последующая обработка транзакции будет производиться так, как если бы кодом отклика был approved(0).
При этом код отклика не переписывается.
Программа расчетного центра обрабатывает отложенные авторизации как одобрение за исключением случаев, когда AuthCode = callIssuer и когда оплата (capture) не осуществляется, до тех пор пока продавец не получит от эмитента кода ApprovalCode.
Программа расчетного центра обрабатывает все последующие сообщения для транзакций, как если бы транзакция была одобрена, при условии посылки продавцом корректного кода ApprovalCode.
Запрос авторизации несет в себе необходимую информацию от продавца к расчетному центру для формирования сообщения-запроса авторизации, которое может быть обработано банком продавца. Отклик на запрос авторизации несет в себе информацию от расчетного центра, относящуюся к обработке запроса авторизации.
Пары сообщений AuthRevReq/AuthRevRes (Autorization Reversal Request/Response) используются только для сокращения или аннулирования полученной ранее авторизации. Эта пара опционных сообщений не может применяться для ликвидации разделения авторизации, выполненной ранее. Необходимость разделения авторизации возникает тогда, когда поставка в рамках сделки должна быть выполнена поэтапно. Данные сообщения могут посылаться когда угодно после авторизации и до осуществления платежа (capture).Для реализации разделения или ликвидации авторизации продавец посылает запрос AuthRevReq, который уменьшает значение AuthAmt и устанавливает переменную SubsequentAuthInd = TRUE. Расчетный центр возвращает AuthToken в отклике AuthRevRes. Маркер AuthToken будет использоваться для авторизации покупок при последующих частичных поставках.

Структура AuthToken

Таблица 4.6.2.42. Структура AuthToken

AuthTokenData	{TransIDs, PurchAmt, MerchantID, [AcqBackKeyData], [InstallRecurData], [RecurringCount], PrevAuthDataTime, TotalAuthAmount, AuthTokenOpaque}
PANToken	Поля копируются из поля PI-Head, сформированного владельцем карты (см. табл. 4.6.2.40)
TransIDs
PurchAmt
MerchantID
AcqBackKeyData
InstallRecurData
RecurringCount	Число реализованных рекуррентных авторизаций
PrevAuthDateTime	Дата и время последней авторизации продавца в последовательности рекуррентных авторизаций
TotalAuthAmount	Полное число авторизованных в результате всех авторизаций для данного XID
AuthTokenOpaque	Невидимые данные, генерируемые расчетным центром

AuthToken формируется следующим образом:

Шаг	Действие
1	Генерируется AuthTokenTBE как: Если это первая авторизация (выполнена согласно PI) а. Заполняется из PI поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется в PI, AcqBackInfo и InstallRecurData б. RecurringCount делается равным 1 в. В PrevAuthDateTime записывается текущая дата г. В TotalAuthAmount заносится AuthAmt из авторизационного отклика, который содержит данный AuthToken Если это очередная аутентификация (сгенерирована из предыдущего AuthToken) а. Заполняется из предыдущего AuthToken поля PANToken, TransIDs, PurchAmt, MerchantID и, если имеется, AcqBackInfo и InstallRecurData б. Инкрементируется на 1 RecurringCount в. В PrevAuthDateTime записывается текущая дата г. TotalAuthAmount увеличивается на AuthAmt, взятое из авторизационного отклика, который содержит данный AuthToken Если это полная (reversal) аутентификация (сгенерирована из предыдущего AuthToken) а. Из предыдущего AuthToken заполняются поля PANToken, TransIDs, PurchAmt, MerchantID, PrevAuthDateTime и, если имеется, AcqBackInfo и InstallRecurData б. Если это повторное выполнение всех авторизаций (т.е. AuthNewAmt в AuthRevReq равно нулю), уменьшить RecurringCount на 1 в. Уменьшить TotalAuthAmount на AuthNewAmt из авторизацилнного отклика, который будет содержать маркер AuthToken.
2	Сформировать PANToken (см. табл. 4.6.2.46)
3	С привлечением инкапсуляции EncX уложить данные в цифровой конверт, используя P1=P2=Cert-PE в качестве s и r параметров, AuthTokenTBE (из шага 1) - в качестве параметра t и PANToken - в качестве параметра p.

<
Обработка AuthToken выполняется в следующем порядке:

Шаг	Действие
1	Извлечь AuthToken из EncX-конверта, используя секретный ключ расчетного центра.
2	Если это автризационный запрос и AuthToken уже использовался при авторизации, установить AuthCode равным piPreviouslyUsed
3	Если это запрос повторной авторизации (reversal request) и AuthToken не использовался при авторизации, установить AuthCode=piAuthMismatch.
4	Если это авторизационный запрос и InstallRecurData специфицирована рекурентной информацией: Проверить, что текущая дата относится ко времени раньше даты RecurringExpiry. Если проверка не прошла, установить AuthCode равным recurringExpired. Проверить, что текущая дата позднее, чем PrevAuthDate плюс число дней, специфицированное в RecurringFrequency. Если проверка не прошла, установить AuthCode равным recurringTooSoon.
5	Если это автризационный запрос и InstallRecurData специфицирована информацией Installment, реализовать специфические требования платежной системы карты.
6	Если на предыдущих шагах AuthCode не был установлен, переадресовать данные от AuthToken авторизационному процессу.

AcqCardMsg является полем, которое предоставляет механизм для посылки банком продавца сообщения владельцу карты, не информируя об этом продавца (туннелирование). Это поле может быть использовано после того, как расчетный центр получит сообщение AuthReq от продавца. Структура данных AcqCardMsg представлена в таблице 4.6.2.43.

Структура BatchAdminReq

Таблица 4.6.2.81. Структура BatchAdminReq

BatchAdminReq	Enc(M, P, BatchAdminReqData)
BatchAdminReqData	{BatchAdminRRTags, [BatchID], [BrandAndBINSeq], [BatchOperation], ReturnBatchSummaryInd, [ReturnTransactionDetail], [BatchStatus], [TransDetails], [BARqExtensions]}
BatchAdminRRTags	RRTags. Новый идентификатор RRPID и Date (дата)
BatchID	Идентификатор платежной линии для счета банка продавца
BrandAndBINSeq	{BrandAndBIN +}
BatchOperation	Числовая величина, указывающая на операцию, которая должна быть выполнена в рамках платежной линии
ReturnBatchSummaryInd	Обозначает, что в BatchAdminRes должны быть возвращены итоговые данные.
ReturnTransactionDetail	{StartingPoint, MaximumItems, ErrorsOnlyInd, [BrandID]} Если специфицирован BrandID, присылаются данные только для позиций, определяемых платежной системой карты.
BatchStatus	См. табл. 4.6.2.53.
TransDetails	{NextStartingPoint, TransactionDetailSeq}
BARqExtensions	Данные в расширении административного сообщения платежной линии должны иметь финансовый характер и быть важными для обработки административных запросов.
BrandAndBIN	{BrandID, [BIN]}
StartingPoint	Нуль указывает на то, что следует прислать данные для первой группы позиций, в противном случае NextStartingPoint предшествующего BatchAdminRes
MaximumItems	Максимальное число позиций, которые следует прислать в этой группе.
ErrorsOnlyInd	Булево число, индицирующее, следует ли присылать только позиции с состоянием ошибки.
BrandID	Тип платежной системы (без указания типа продукта).
NextStartingPoint	Нуль индицирует, что это последняя группа позиций, в противном случае, используется значение, идентифицирующее начальную точку следующей группы позиций.
TransactionDetailSeq	{TransactionDetail +}
BIN	Идентификационный номер банка для обработки транзакций продавца.
TransactionDetail	См. табл. 4.6.2.54

Расчетный центр обрабатывает запрос BatchAdminReq следующим образом.

Шаг	Действие
1	Выделить запрос из входного сообщения
2	Проверить подпись. Если проверка не прошла, присылается отклик Error c ErrorCode = signatureFailure.
3	Проверить, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте сообщения. Если проверка не прошла, присылается отклик Error c ErrorCode = unknownRRPID.
4	Если BatchOperation = open: Проверить, что BatchID еще не открыт. Если это не так, установить BAStatus = batchAlreadyOpen. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется BrandIDSeq: Проверить, что каждый BrandID поддерживается. Если это не так, установить BAStatus = brandNOTSupported. Проверить, что каждый BIN поддерживается. Если это не так, установить BAStatus = unknownBIN. Запомнить платежные системы и BIN, которые можно использовать для данной платежной линии. Открыть платежную линию для использования продавцом и установить BAStatus = success. Продолжить процесс посылкой BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = open.
5	Если BatchOperation = purge: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Если BrandIDSeq присутствует: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Удалить все транзакции платежной линии, ассоциированные со специфицированной платежной системой и BIN. В противном случае, удалить все транзакции из группы платежей Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq, будут игнорироваться, когда BatchOperation = purge.
6	Если BatchOperation = close: Проверить, что BatchID уже открыт. Если это не так, установить BAStatus = unknownbatchID. Установить BAStatus = success Продолжить работу посылкой сообщения BatchAdminRes Любые другие поля, присутствующие в сообщении BatchAdminReq будут игнорироваться, когда BatchOperation = close.
7	Если BatchOperation опущено, а возвращенное значение ReturnBatchSummaryInd = TRUE: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если BrandAndBIN включен: Проверить, что каждый BatchID относится к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN относится к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить структуры данных BrandBatchDetails для каждого специфицированного значения BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN, или для всех транзакций, если BrandAndBIN отсутствует. Заполнить BatchTotals в структурах данных BatchStatus вычисленными значениями. Если TransmissionStatus и SettlementInfo доступны в клиринговой системе, используемой расчетным центром, занести эту информацию в BatchAdminRes. Если StartingPoint опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes, в противном случае перейти к следующему шагу. NextStartingPoint и TransactionDetailSeq игнорируются, если ReturnBatchSummaryInd = TRUE.
8	Если включено поле StartingPoint: Если MaximumItem установлен равным 0, аннулировать любую предшествующую информацию для данной платежной линии и установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если StartingPoint не равен нулю, проверить, что StartingPoint равен NextStartingPoint, присланном в предыдущем отклике BatchAdminRes. Если StartingPoint равен нулю, установить указатель на начало списка платежей, в противном случае установить указатель согласно содержимому StartingPoint. Если имеется BrandAndBIN: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Если специфицировано поле MaximumItems, заполнить TransactionDetail вплоть до MaximumItems из текущей позиции и установить NextStartingPoint в позицию, из которой можно получить данные для последующих транзакций. Если система достигла конца списка платежей, установить NextStartingPoint = 0. Выбор позиции ограничивается BrandandBIN и ErrorOnlyInd. f) Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
9	Если код BatchOperation опущен, а BatchStatus имеется: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если имеется поле BrandBatchDetails: Проверить, что каждый BatchID имеет отношение к данной платежной линии. Если это не так, установить BAStatus = brandBatchMismatch. Проверить, что каждый BIN имеет отношение к данной платежной линии. Если это не так, установить BAStatus = unknownBIN. Вычислить BatchTotals и заполнить информационные структуры BrandBatchDetails для каждого специфицированного BrandAndBIN. Вычислить BatchTotals для платежных систем, включенных в BrandAndBIN или для всех транзакций, если BrandAndBIN отсутствует. Для любого значения BatchTotals, которое не согласуется с приведенным в сообщении BatchAdminReq, занести вычисленные значения в BatchTotals информационной структуры BatchStatus. Если какое-либо итоговое значение не согласовано, установить BAStatus = totalsOutOfBalance и перейти к следующему пункту. Если поле TransactionDetails опущено, установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes
10	Если код BatchOperation опущен и включено поле TransactionDetails: Проверить, что BatchID доступен. Если это не так, установить BAStatus = batchIDUnavailable. Если указатель StartingPoint не равен нулю и не согласуется с NextStartingPoint из предыдущего BatchAdminReq, установить BAStatus = unknownStartingPoint. Если NextStartingPoint не равен нулю, запомнить TransactionDetails, скопировать NextStartingPoint в сообщение BatchAdminRes и установить BAStatus = success. Продолжить работу посылкой отклика BatchAdminRes. Проверяется соответствие полученных транзакций с теми, что хранятся в расчетном центре. Если отличие обнаружено, установить BAStatus = totalsOutOfBalance. Продолжить работу посылкой отклика BatchAdminRes. Опционно установить BAStatus = stopItemDetail, чтобы проинформировать продавца о том, что расчетный центр не желает обрабатывать позиции в данной последовательности платежей (batch). Продолжить работу посылкой отклика BatchAdminRes. Установить BAStatus = success и продолжить работу посылкой отклика BatchAdminRes. Последовательность BrandAndBIN игнорируется.

<
Формирование отклика BatchAdminRes осуществляется согласно следующему алгоритму.

Шаг	Действие
1	Если BAStatus не установлен равным success (успех) или MaximumItems в BatchAdminReq установлен равным 0, аннулировать любую информацию в рамках платежной линии для заданной последовательности запросов BatchAdmin, посланных ранее продавцом.
2	Используя сертификат расчетного центра, запустить операцию подписи для BatchAdminResData.
3	Зашифровать BatchAdminResTBE, используя сертификат шифрования, поставляемый продавцом, и установить код типа содержимого равным id-set-content-BatchAdminResTBE.
4	Вложить сообщение в цифровой конверт и послать владельцу карты.

Структура отклика BatchAdminRes представлена в таблице 4.6.2.82.

Структура BatchAdminRes

Таблица 4.6.2.82. Структура BatchAdminRes

BatchAdminRes	Enc(P, M, BatchAdminResData)
BatchAdminResData	{BatchAdminTags, BatchID, [BAStatus], [BatchStatus], [TransmissionStatus], [SettlementInfo], [TransDetails], [BARsExtensions]}
BatchAdminTags	RRTags; копируется из предшествующего BatchAdminReq
BatchID	Идентификатор платежной линии между продавцом и его банком.
BAStatus	Числовой код, указывающий на состояние открытой платежной линии.
BatchStatus	См. табл. 4.6.2.53.
TransmissionStatus	Числовое значение, индицирующее состояние передачи данных из расчетного центра системе вышестоящего уровня
SettlementInfo	{SettlementAmount, SettlementType, SettlementAccount, SettlementDepositDate}
TransDetails	{NextStartingPoint, TransactionDetailSeq}
BARsExtensions	Данные расширения административного отклика должны носить финансовый характер и иметь значение для обработки административного запроса по поводу платежной линии. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData; информация, относящаяся к состоянию платежной линии, должна содержаться в расширении BatchStatus; информация, относящаяся к информационным деталям позиции в пределах платежной линии должна содержаться в расширении TransactionDetail.
SettlementAmount	Занесенная через сеть на счет продавца сумма
SettlementType	Числовой код, указывающий тип суммы
SettlementAccount	Счет продавца
SettlementDepositDate	Дата, когда сумма SettlementAmount будет занесена или снята со счета продавца
NextStartingPoint	Нуль индицирует, что это последняя группа позиций, в противном случае, для идентификации начальной точки следующей группы позиций используется скрытое значение
TransactionDetailSeq	{TransactionDetail +}
TransactionDetail	См. табл. 4.6.2.54..

В ниже приведенной таблице представлены стандартизованные значения поля ReimbursementID

unspecified	Неизвестное значение
standard	Стандартная скорость обмена
keyEntered	Скорость обмена для транзакций key-entered (ввод с клавиатуры)
electronic	Скорость обмена для электронных транзакций
additionalData	Скорость обмена для транзакций, которые включают в себя дополнительные клиринговые данные
enhancedData	Скорость обмена для транзакций, которые включают в себя усовершенствования (такие как данные дополнительной авторизации).
marketSpecific	Скорость обмена для транзакций в пределах специфического сегмента рынка (такого как пассажирский транспорт).

<
Продавец получает и обрабатывает BatchAdminRes следующим образом.

Шаг	Действие
1	Извлекается отклик BatchAdminRes из входного сообщения.
2	Верифицируется подпись. Если проверка не прошла, присылается сообщение Error с ErrorCode = signatureFailed.
3	Проверяется, что RRPID в BatchAdminReq соответствует RRPID в цифровом конверте. Если проверка не прошла, присылается сообщение Error с ErrorCode = unknownRRPID.
4	Если BAStatus не равен success, а продавец передает или запрашивает подробности о платежной линии, аннулировать любую информацию, запомненную для данной платежной линии и перезапустить процесс, если детальные данные о платежах по-прежнему нужны.
5	Если продавец получает детальные данные о платежной линии, запомнить NextStartingPoint для использования в последующих откликах BatchAdminRes. Значение нуль указывает, что все подробности о платежной линии переданы.
6	Если продавец передает детальные данные о платежной линии, проверить, что NextStartingPoint согласуется со значением, посланным в BatchAdminReq. Если согласия нет, послать BatchAdminReq с MaximumItems = 0, чтобы расчетный центр аннулировал детали платежной линии, посланные ранее, после чего повторить посылку этих деталей расчетному центру в последующей серии запросов BatchAdmin.
7	Запомнить детали из запроса BatchAdmin и передать их расчетным процедурам продавца.

Для реализации протокола SET в конкретных приложениях можно использовать утилиту Wallet (http://www.microsoft.com/commerce/wallet/) фирмы Microsoft (Microsoft Commerce Server). Следует учитывать, что, так как система SET является достаточно сложной и дорогостоящей, а продавец должен платить за каждую операцию с кредитной карточкой, то через систему SET проходят платежи, превышающие 10$.
Для осуществления более мелких платежей используются другие схемы (например, First Virtual, CyberCoin, DigiCash (http://www.digicash.nl) или Millicent -
http://www.millicent.digital.com/). Схема First Virtual (http://www.fv.com) предназначена для продажи дешевых программных продуктов или услуг. Она предполагает регистрацию клиента, при которой он сообщает номер своей кредитной карточки и получает регистрационный номер (PIN). При покупке клиент вводит свой индивидуальный номер и, если он верен, немедленно получает доступ к нужному ему продукту. Позднее First Virtual связывается с клиентом по электронной почте, уведомляет о цене покупки, предоставляя ему одобрить или нет снятие соответствующей суммы с его кредитной карточки. Эта система зиждется на полном доверии и честности обеих сторон.
Система CyberCash (http://www.cybercash.com) базируется на схеме, сходной с SET. Здесь также используется специальное программное обеспечение со стороны клиента и продавца. Клиент при регистрации получает бесплатно программу CyberCash Wallet и заполняет идентификационную и платежную информацию. Данная информация в зашифрованном виде будет храниться на ЭВМ клиента. Эти данные посылаются при нажатии клиентом клавиши “оплатить”. Система предоставляет клиенту ряд дополнительных услуг, например просмотр баланса последних операций.

Структура BatchStatus

Таблица 4.6.2.53. Структура BatchStatus

BatchStatus	{OpenDateTime, [ClosedWhen], BatchDetails, [BatchExtensions]}
OpenDateTime	Дата и время открытия платежной линии
ClosedWhen	{CloseStatus, CloseDateTime}
BatchDetails	{CloseDateTime, [BrandBatchDetailsSeq]}
BatchExtensions	Данные в расширении для сообщения управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса
CloseStatus	Цифровой код, указывающий статус закрытия платежной линии
CloseDateTime	Дата и время закрытия платежной линии
BatchTotals	{TransactionCountCredit, TransactionTotalAmtCredit, TransactionCountDebit, TransactionTotalAmtDebit, [BatchTotalExtensions]}
BrandBatchDetailsSeq	{BrandBatchDetails +}
TransactionCountCredit	Число транзакций, которые внесли вклад в кредит продавца.
TransactionTotalAmtCredit	Полная сумма, внесенная на счет продавца
TransactionCountDebit	Число транзакций, которые внесли вклад в дебет продавца
TransactionTotalAmtDebit	Полная сумма, снятая со счета продавца
BatchTotalExtensions	Данные расширения отклика управления платежами должны носить финансовый характер и быть существенными для обработки административного запроса. Информация, относящаяся к обработке запроса, должна появляться в расширении BatchAdminResData. Информация, имеющая отношение к состоянию платежной линии, должна лежать в расширении BatchStatus. Информация, относящаяся к деталям по конкретной позиции заказа, присутствует в расширении TransactionDetail.
BrandBatchDetails	{BrandID, BatchTotals}
BrandID	Тип платежной системы карты без типа продукта

Структура TransactionDetail служит для предоставления детальной информации о платежной линии между расчетным центром и продавцом. Формат этой структуры описан в таблице 4.6.2.54.

Структура CapPayload

Таблица 4.6.2.69. Структура CapPayload

CapPayload	{CapDate, CapReqAmt, [AuthReqItem], [AuthResPayload], [SaleDetail], [CPayExtensions]}
CapDate	Дата платежа - это дата транзакции, которая появится в уведомлении владельца карты.
CapReqAmt	Сумма платежа, затребованная продавцом, может отличаться от AuthAmt. Это сумма транзакции (до конвертации валюты), которая появится в уведомлении владельца карты.
AuthReqItem	См. табл. 4.6.2.64. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного запроса.
AuthResPayload	См. табл. 4.6.2.67. Поле необходимо, если соответствующий маркер CapToken отсутствует или система расчетного центра/банка продавца не содержит подходящих данных для авторизационного отклика.
SaleDetail	См. табл. 4.6.2.47.
CPayExtensions	Данные в расширении запроса платежа (capture) должны иметь финансовый характер и быть существенными для сообщения capture, посланного расчетному центру, финансовой сети или эмитенту. Данные этого расширения приложимы к индивидуальным позициям платежного запроса. Данные, относящиеся ко всему запросу, помещаются в расширение CapReqData.

Расчетный центр, получив запрос CapReq, обрабатывает его следующим образом.

Шаг	Действие
1	Извлечь запрос из входного сообщения
2	Обработать CRqExtensions. Если какое-либо неподдерживаемое расширение имеет критический флаг, отбросить сообщение, послав сообщение Error = unrecognizedExtension
3	Для каждого CapItem обработать платеж и сформировать CapResItem с суммой из обрабатываемого платежа и кодом CapCode, соответствующим успеху или неудаче: Обработать CapPayload Если CapToken присутствует: Проверить CapToken. Если CapToken некорректен, отклонить платеж, возвратив для данной позиции CapCode = invalidCapToken Проверить, что CapToken не был еще обработан. Если проверка не прошла, отклонить платеж, прислав CapCode = invalidCapToken Обработать TokenOpaque В противном случае, если допустимы платежи без CapToken: Если AuthReqItem и AuthResPayload отсутствуют, отклонить платеж, послав CapCode = authDataMissing Сверить AuthReqItem и AuthResPayload с записями транзакции. Если соответствия нет, платеж отвергается путем посылки CapCode = invalidAuthData. В противном случае, если платежи без CapToken не поддерживаются, платеж отклоняется посылкой CapCode = missingCapToken Проверить TransIDs Извлечь запись транзакции Проверить, что XID согласуется с записью транзакции. Если согласия нет, то платеж отклоняется посылкой CapCode = unknownXID Сверить LID-C и, если имеется, LID-M со значениями из записи транзакции. Если совпадения нет, то транзакция терпит неудачу, посылается CapCode = unknownLID f) Обработать платеж для заданной позиции через существующую финансовую сеть карты и записать результат.

<
Расчетный центр обрабатывает CapPayLoad следующим образом.

Шаг	Действие
1	Обработать CPayExtensions. Если неизвестное расширение помечено как критическое, сообщение отвергается и возвращается сообщение Error unrecognizedExtension
2	Запомнить SaleDetail
3	Проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия неизвестна, отклонить платеж с посылкой CapCode = batchUnknown. Если линия не открыта, отклонить платеж с CapCode = batchClosed
4	Проверить, что идентификатор BatchSequenceNum является уникальным в рамках платежной линии. Если идентификатор не уникален, отклонить платеж путем возвращения CapCode = batchUnknown.

Расчетный центр формирует отклик CapRes согласно следующему алгоритму.

Шаг	Действие
1	Получить данные о платеже от платежного процесса
2	Скопировать CapRRTags из CapReq
3	Заполнить текущее значение BrandCRLIdentifier, имеющееся в расчетном центре, если оттиск для текущего BrandCRLIdentifier не получен или устарел.
4	Если MThumbs указывают, что продавцу для шифрования информации нужен новый Cert-PE: Вложить Cert-PE в цифровой конверт PKCS#7 Вложить GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
5	Опционно занести в поле BatchSequenceNum состояние текущих платежных линий
6	Скопировать BatchID и BatchSequenceNum из SaleDetail в CapResPayload
7	Заполнить CapResSeq. Для каждого CapItem в соответствующем CapReq заполнить CapResItem следующим образом: Скопировать TransIDs из соответствующего CapReqItem Скопировать AuthRRPID из соответствующего CapReqItem, если он имеется Заполнить CapResPayload
8	Опционно заполнить CRsExtensions
9	Вставить сообщение в цифровой конверт и послать продавцу

Генерация CapResPayload осуществляется следующим образом.

Шаг	Действие
1	Заполнить CapCode и CapAmt результатами обработки соответствующего CapReqItem
2	Скопировать BatchID и BatchSequenceNum из соответствующего CapReqItem
3	Опционно заполнить CRsPayExtensions

Структура сообщения-отклика CapRes показана в таблице 4.6.2.70.

Структура CapRes

Таблица 4.6.2.70. Структура CapRes

CapRes	Enc(P, M, CapResData)
CapResData	{CapRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapResItemSeq, [CRsExtensions]}
CapRRTags	RRTag>s; копируется из CapReq
BrandCRLIdentifier	Список текущих CRL для всех СА в области ответственности платежной системы СА.
PEThumb	Оттиск сертификата расчетного центра, предоставляемый, если CapReqData.Mthumbs указывает на то, что продавец в нем нуждается.
BatchStatusSeq	{BatchStatus +}
CapResItemSeq	{CapResItem +} Заказ соответствует CapReq
CRsExtensions	Данные в расширении платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа или последующего возврата денег.
BatchStatus	См. табл. 4.6.2.53.
CapResItem	{TransIDs, AuthRRPID, CapResPayload}
TransIDs	Копируется из соответствующего CapReq
AuthRRPID	RRPID, который появился в соответствующем AuthReq или AuthRevReq, копируется из соответствующего CapReq
CapResPayload	См. табл. 4.6.2.71.

Структура данных CapResPayload представлена в таблице 4.6.2.71.

Структура CapResPayload

Таблица 4.6.2.71. Структура CapResPayload

CapResPayload	{CapCode, CapAmt, [BatchID], [BatchSequenceNum], [CRsPayExtensions]}
CapCode	Цифровой код, указывающий на состояние платежа
CapAmt	Копируется из соответствующего CapReq
BatchID	Идентификатор для установления платежной линии между продавцом и его банком. Копируется из соответствующего CapReq
BatchSequenceNum	Порядковый номер позиции в текущей последовательности платежей; копируется из соответствующего CapReq
CRsPayExtensions	Данные в расширении поля данных платежного отклика должны иметь финансовый характер и быть важными для осуществления платежа ли последующего возврата денег.

Продавец обрабатывает отклик CapRes следующим образом.

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Обрабатывается CRsExtensions, если таковые имеются. Если не узнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается
3	Извлекается запись транзакции и производится сравнение CapRRTags: Проверяется, что XID соответствует транзакции. Если это не так, сообщение отвергается и посылается отклик Error = unknownXID Проверяется, что LID-M и, если присутствует в записи транзакции, LID-C согласуются с записью транзакции. Если согласия нет, сообщение отвергается и посылается отклик Error = unknownLID
4	Если в сообщение включен BrandCRLIdentifier, запомнить все CRL.
5	Проверить, что GKThumb согласуется с сертификатом шифрования платежного центра (если GKThumb имеется). Если это не так, актуализовать кэш сертификата с использованием текущего сертификата.
6	Для каждого CapResItem в CapResSeq: Обрабатывается CRsPayExtensions. Если неузнанное расширение помечено как критическое, в рабочий журнал заносится запись Error = unrecognizedExtension, а сообщение CapRes отбрасывается. Обработать CapCode для получения результата операции Для успешного платежа запомнить CapCode и CapAmt, ассоциированные с AuthRRPID.
7	Если BatchStatusSeq присутствует, обработать и запомнить каждое значение BatchStatus

<
В таблице ниже представлены допустимые значения CapCode.

success	Платежная позиция обработана расчетным центром успешно
unspecifiedFailure	Причина неудачи неизвестна
duplicateRequest	Платежный запрос для данной транзакции уже был обработан (для XID и AuthRRPID)
authExpired	Авторизационный запрос был обработан слишком давно в прошлом. Это время определяется политикой платежной системы карты.
authDataMissing	В платежном запросе отсутствует авторизационная информация
invalidAuthData	Авторизационная информация для данной транзакции некорректна
capTokenMissing	Для обработки данной позиции необходимо поле CapToken, а его нет
invalidCapToken	Поле CapToken некорректно для данной транзакции
batchUnknown	Расчетный центр не знает о существовании платежной линии для данной позиции
batchClosed	Платежная линия для данной позиции закрыта
unknownXID	Не распознан идентификатор XID
unknownLID	Не распознан идентификатор LID

Сообщения отзыва платежа и кредита синтактически идентичны и выполняют сходную функцию. Алгоритм формирования информационной структуры CapRevOrCredReqData продавцом представлен ниже.

Шаг	Действие
1	Сформировать CapRevOrCredRRTags с новым RRPID и текущей датой.
2	Рекомендуется заполнить MThumbs путем вычисления оттисков сертификатов и CRL, имеющихся у продавца. Продавец должен заполнить оттиски в сообщении, которые могут быть затем нужны для верификации подписей и сертификатов, присылаемых расчетным центром.
3	Заполнить одну или более позиций в CredRevOrCredReqItems: Скопировать TransIDs из соответствующего CapRes. Скопировать AuthRRPID из самого последнего запроса (settlement), если имеется. Скопировать CapPayload из самого последнего запроса (settlement), (т.е. CapReq, CapRevReq, CredReq или CredRevReq). Заполнить NewBatchID, если кредитная линия транзакции закрыта. Заполнить CapRevOrCredReqData с текущей датой и временем Опционно заполнить CapRevOrReqAmt с новой суммой, которая может отличаться от значений, содержащихся в AuthAmt из CapToken и CapReqAmt из CapPayload. Опционно установить новое значение NewAccountInd, если сделка состоится для нового счета владельца карты, как это специфицировано в PANToken. Опционно заполнить CRvRqItemExtensions
4	Опционно заполнить CRvRqExtensions

Структура данных CapRevOrCredReqData описана в таблице 4.6.2.72.

Структура CapRevOrCredReqData

Таблица 4.6.2.72. Структура CapRevOrCredReqData

CapRevOrCredReqData	{CapRevOrCredRRTags, [MThumbs], CapRevOrCredReqItemSeq, [CRvRqExtensions]}
CapRevOrCredRRTags	RRTags. Новый идентификатор RRPID и Date для данной пары.
MThumbs	Оттиски сертификатов, CRL и BrandCRLIdentifier, хранящиеся в кэше продавца
CapRevOrCredReqItemSeq	{CapRevOrCredReqItem +} Один или более CapRevOrCredReqItem в виде упорядоченного массива
CRvRqExtensions	Данные расширения отзыва платежа или запроса кредита должны иметь финансовый характер и играть важную роль для обработки этих сообщений расчетным центром или эмитентом.
CapRevOrCredReqItem	{TransIDs, AuthRRPID, CapPayload, [NewBatchID], CapRevOrCredReqDate, [CapRevOrCredReqAmt], NewAccountInd, [CRvRqItemExtensions]}
TransIDs	Копируется из соответствующего CapRes. Поле необходимо, если соответствующий маркер CapToken отсутствует или не содержит подходящих данных авторизационного запроса
CapPayload	См. табл. 4.6.2.69
NewBatchID	Это поле специфицирует новый идентификатор платежной линии; оно используется для запросов отзыва платежа для позиций, реализованных в рамках платежной линии, которая была закрыта. BatchID >в CapPayload идентифицирует исходную платежную линию.
CapRevOrCredReqDate	Дата подачи запроса
CapRevOrCredReqAmt	В кредитных запросах сумма запрашиваемого кредита, которая может отличаться от AuthAmt в CapToken и CapReqAmt в CapPayload
NewAccountInd	Указывает, что новый номер счета специфицирован в PANToken; когда это поле установлено, новый номер счета будет записан поверх информации о старом номере счета в CaptureToken или авторизационных данных, хранимых банком продавца. Использование этого поля является предметом политики платежной системы карты или банка продавца.
CRvRqItemExtensions	Данные в расширении поля данных отзыва платежа или запроса кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром

Расчетный центр обрабатывает CapRevOrCredReqData следующим образом.

Шаг	Действие
1	Обрабатываются CRvRqxtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions, а обрабатываемое сообщение отбрасывается.
2	Обрабатывается каждое CapRevOrCredItem: Обрабатываются CRvRqItemExtensions. Если неподдерживаемое расширение помечено как критическое, возвращается отклик Error = unrecognizedExtensions Извлекается запись транзакции и производятся сравнения с TransIDs в CapRevOrCredItem Проверяется, что XID соответствует предшествующей транзакции. Если это не так, сообщение отбрасывается и посылается сообщение Error = unknownXID. Проверяется соответствие LID-C с записью транзакции. Если соответствия нет, сообщение отбрасывается и посылается отклик Error = unknownLID Проверяется CapPayload на соответствие записи транзакции. Если равенства нет, позиция отбрасывается и возвращается CapRevOrCredCode = capDataMismatch. Если установлен идентификатор NewBatchID, проверить, что BatchID является открытой платежной линией для BrandAndBIN. Если платежная линия закрыта, возвращается код CapRevOrCredCode = batchClosed. Если платежная линия неизвестна, возвращается код CapRevOrCredCode = batchUnknown. Запоминается CapRevOrCredAmt Если установлен NewAccountInd, использовать номер счета в PANToken для работы с расчетной картой в финансовой сети.
3	На основе TransIDs в AuthRevTags извлекается запись транзакции.

Расчетный центр формирует CapRevOrCredResData с помощью следующей последовательности операций.

Шаг	Действие
1	Заполнить поле CapRevOrCredTags
2	Заполнить текущий BrandCRLIdentifier, хранимый расчетным центром, если оттиск BrandCRLIdentifier не получен или устарел.
3	Если Mthumb указывает, что продавец нуждается в новом Cert-PE при шифровании информации для расчетного центра, то: Ввести Cert-PE в цифровой конверт PKCS#7 Ввести GKThumb в AuthResData, так как сам Cert-PE не защищен подписью
4	Опционно ввести BatchStatus в поле BatchStatusSeq для каждой платежной линии, чье состояние запрошено.
5	Для каждой позиции в соответствующем CapRevOrCredItems заполнить поле CapRevOrCredResItem следующим образом: Скопировать TransIDs из соответствующего CapRevOrCredReqItem Если доступно, скопировать RRPID из соответствующего CapRevOrCredItem Заполнить CapRevOrCredResPayload следующим образом: Занести в CapRevOrCredCode результат кредита или отзыва платежа Занести в CapRevOrCredActualAmt действительную сумму кредита или отзыва Если имеется, скопировать BatchID и BatchSequanceNum из соответствующего CapRevOrCredReqItem Опционно заполнить CRvRsPayExtensions
6	Опционно заполнить CRvRsExtensions

Структура данных CapRevOrCredResData имеет формат, описанный в таблице 4.6.2.73.

Структура CapRevOrCredResData

Таблица 4.6.2.73. Структура CapRevOrCredResData

CapRevOrCredResData	{CapRevOrCredRRTags, [BrandCRLIdentifier], [PEThumb], [BatchStatusSeq], CapRevOrCredResItemSeq, [CRvRsExtensions]
CapRevOrCredRRTags	RRTags; копируется CapRevOrCredRRTags из соответствующего поля CapRevOrCredReqData
BrandCRLIdentifier	Список текущих CRL для всех СА в зоне ответственности СА платежной системы.
PEThumb	Оттиск сертификата расчетного центра, поставляемого, если CapRevOrCredReq.MThumbs указывает, что продавец в нем нуждается
BatchStatusSeq	{BatchStatus +}
CapRevOrCredResItemSeq	{CapRevOrCredResItem +} Один или более CapRevOrCredResItem в упорядоченном массиве
CRvRsExtensions	Данные в расширении поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для осуществления отзыва платежа или кредита расчетным центром
BatchStatus	См. табл. 4.6.2.53.
CapRevOrCredResItem	{TransIDs, AuthRRPID, CapRevOrCredResPayload}
TransIDs	Копируется из соответствующего CapRevOrCredReqData.AuthReqData.AuthTags
AuthRRPID	RRPID, который появляется в соответствующем AuthReq или >AuthRevReq
CapRevOrCredResPayload	См. табл. 4.6.2.74

Структура данных CapRevOrCredResPayload представлена в таблице 4.6.2.74.

Структура CapRevOrCredResPayload

Таблица 4.6.2.74. Структура CapRevOrCredResPayload

CapRevOrCredResPayload	{CapRevOrCredCode, CapRevOrCredActualAmt, [BatchID], [BatchSequenceNum], [CRvRsPayExtensions]}
CapRevOrCredCode	Числовой код, характеризующий состояние отзыва платежа или кредита.
CapRevOrCredActualAmt	Копируется из соответствующего CapRevOrCredReqItem.
BatchID	Идентификатор платежной линии сделки для банка продавца
BatchSequenceNum	Порядковый номер позиции в последовательности платежей
CRvRsPayExtensions	Расширение поля данных отклика на запрос отзыва платежа или кредита должны иметь финансовый характер и быть важными для обработки отклика на отзыв платежа или кредит.

Допустимые значения кода CapRevOrCredCode представлены ниже

success	Позиция была успешно обработана расчетным центром
unspecifiedFailure	Причина неудачи не специфицирована
duplicateRequest	Запрос отзыва платежа или кредита для данной транзакции был уже обработан (XID и AuthRRPID)
originalProcessed	Запрос платежа для данной позиции был уже обработан
originalNotFound	Специфицированная позиция расчетным центром не обнаружена
capPurged	Информация о платеже была удалена из памяти транзакций расчетного центра
missingCapData	Информация о платеже отсутствует в запросе отзыва платежа или кредита
missingCapToken	Необходимый для обработки данной позиции маркер CapToken отсутствует в запросе отзыва платежа или кредита
invalidCapToken	Маркер CapToken некорректен
batchUnknown	Платежная линия для данной позиции расчетному центру неизвестна
batchClosed	Платежная линия для данной позиции уже закрыта

Обработка продавцом CapRevOrCredResData осуществляется следующим образом.

Шаг	Действие
1	Обработать CRvRsExtensions. Если какое-то нераспознанное расширение помечено как критическое, сообщение отбрасывается и посылается отклик Error = unrecognizedExtension.
2	Обработать CapRevOrCredTags
3	Извлечь запомненную запись транзакции и обработать TransIDs следующим образом: Проверить, что XID согласуется с данными из записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownXID Проверить, что LID-C и LID-M согласуются с данными записи транзакции. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID.
4	Если в сообщение включен BrandCRLIdentifier, запомнить CRL.
5	Проверить, что GKThumb согласуется с существующим сертификатом шифрования расчетного центра, если GKThumb присутствует. Если соответствия нет, актуализовать кэш сертификата с использованием текущего сертификата.
6	Для каждого BatchStatus в batchStatusSeq обработать BatchStatus и запомнить результат
7	Обработать каждый CapRevOrCredResItem в CapRevOrCredResItems следующим образом Обработать CRvRsPayExtensions. Если какое-либо не узнанное расширение помечено как критическое, сообщение отвергается и посылается отклик Error = unrecognizedExtension Извлечь записи транзакции, используя TransIDs. Если не удается найти транзакцию с подходящим TransIDs, отвергнуть сообщение и записать в журнал операций Error = unknownXID Сравнить LID-C и LID-M с данными в сообщении. Если согласия нет, сообщение отбрасывается, а в журнал операций записывается Error = unknownLID. Обработать CapRevOrCredPayload следующим образом: Обработать CapRevOrCredCode для получения результата Если предоставление кредита или отзыв платежа прошел успешно, записать CapCode и CapAmt Обработать BatchID и BatchSequenceNum, если таковые имеются

Пара сообщений CapRevReq/CapRevRes служит для сокращения или аннулирования суммы предшествующего платежа. Они используются после осуществления оплаты и до того, как записи платежа продавца и его банка устареют. Обмен такими сообщениями носит опционный характер. Сообщение CapRevReq может быть послано когда угодно после запроса платежа, направленного расчетному центру. Структура данных в запросе CapRevReq представлена в таблице 4.6.2.75.

Структура CapRevReq

Таблица 4.6.2.75. Структура CapRevReq

CapRevReq	<EncB(M, P, CapRevData, CapTokenSeq), EncBX(M, P, CapRevData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken содержится в сообщении, поле должно соответствовать одной записи в CapRevData.CapRevOrCredReqItemSeq и одному маркеру CapToken в CapTokenSeq
CapRevData	CapRevOrCredReqData
CapTokenSeq	{[CapToken] +} Один или более CapTokens, при полном соответствии последовательности CapRevOrCredReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что только маркер CapToken может быть опущен; т.е., может быть нулем (NULL)
PANToken	См. табл. 4.6.2.46
CapToken	Копируется из соответствующего AuthRes или AuthRevRes

Структура отклика показана ниже CapRevRes.

CapRevRes	Enc(P,M, CapRevResData)
CapRevResData	CapRevOrCredResData

Пары сообщений CredReq/CredRes используются для возвращения кредита по оплаченным ранее транзакциям. Они могут применяться вместо CapRevReq/Res, когда записи о конкретной транзакции у продавца и в расчетном центре оказались удаленными или устаревшими. Такая последовательность сообщений используется продавцом, который может послать запрос CredReq в любое время после согласования номера счета с банком продавца. Формирование запроса CredReq осуществляется в следующей последовательности.

Шаг	Действие
1	Генерируется информация CredReqData
2	Для каждой позиции CapRevOrCred в CapRevOrCredItems заполнить позицию в CapTokSeq следующим образом: Если доступно, записать CapToken для соответствующей транзакции. В противном случае (если недоступно), записать NULL. Результатом этого шага будет CapTokSeq с соответствием один-к-одному между позициями в CredReqData и CapTokSeq
3	Если доступно или необходим новый PAN, заполнить PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken имеется, только одна позиция может присутствовать как в CredReqData, так и CapTokSeq
4	Если PANToken имеется, использовать EncBX-инкапсуляцию, в противном случае EncB-инкапсуляцию.
5	Вставить сообщение в цифровой конверт и послать владельцу карты

Структура запроса CredReq показана в таблице 4.6.2.76.

Структура CapToken

Таблица 4.6.2.44. Структура CapToken

CapToken	<Enc(P1, P2, CapTokenData), EncX(P1, P2, CapTokenData, PANToken), {}> P1 и P2 обозначают платежные центры: P1 – отправителя P2 - получателя В данной версии SET P1 и P2 означают один и тот же расчетный центр (т.е. P1=P2)
CapTokenData	{AuthRRPID, AuthAmt, TokenOpaque}
PANToken	Смотри табл. 4.6.2.46
AuthRRPID	RRPID, который появляется в соответствующем AuthReq или AuthRevReq
AuthAmt	Действительное число авторизованных, которое может отличаться от PurchAmt владельца карты
TokenOpaque	Невидимые данные, определенные расчетным центром

Алгоритм формирования CapToken показан ниже:

Шаг	Действие
1	Если формируется в ходе авторизации, установить AuthAmt в CapTokenData равным AuthAmt в AuthRes. В противном случае, если генерируется во время повторного авторизационного процесса, занести AuthAmt в CapTokenData равным AuthNewAmt для последующей посылки в AuthRevRes
2	Занести в TokenOpaque из CapTokenData частные данные, необходимые для расчетов
3	Если продавец получает PANToken из своего банка, тогда: Занести PANToken из PI Использовать EncX инкапсуляцию с CapTokenData в нормально зашифрованной части и PANToken в дополнительно зашифрованной секции В противном случае: Использовать Enc инкапсуляцию с CapTokenData

Обработка CapToken производится следующим образом:

Шаг	Действие
1	Используя секретный ключ расчетного центра, извлечь CapTokenData из упаковки ЕncX или Enc.
2	Если это платежный запрос (capture request) и CapToken уже использовался в таком запросе, установить CapCode в CapResPayload равным dublicateRequest.
3	Если это аннулирование (reversal) платежного запроса, запрос кредита или отзыв кредита и CapToken ранее не использовался в платежных запросах, установить CapRevOrCredCode в поле CapRevOrCredResPayload равным originalNotFound
4	Если это аннулирование платежного запроса, а CapToken уже использовался в подобном запросе, установить CapRevOrCredCode в CapRevOrCredResPayload равным dublicateRequest.
5	Если CapCode или CapRevOrCredCode не были установлены при выполнении предыдущих шагов, переадресовать данные из CapToken процессу платежного запроса.

PANData содержит информацию, идентифицирующую определенный счет платежной карты. Структура данных PANData представлена в таблице 4.6.2.45.

Структура CredReq

Таблица 4.6.2.76. Структура CredReq

CredReq	<EncB(M, P, CredReqData, CapTokenSeq), EncBX(M, P, CredReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredReqData.CapRevOrCredReqItemSeq и одной CapToken в CapTokenS
CredReqData	CapRevOrCredReqData ; см. табл. 4.6.2.72.
CapTokenSeq	{[CapToken] +} Один или более CapTokens в соответствии один-к-одному с CapRevOrCredReqItem последовательностью в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой маркер CapToken может быть опущен, т.е., может быть NULL
PANToken	См. табл. 4.6.2.46
CapToken	Копируется из соответствующего AuthResили AuthRevRes

Расчетный центр обрабатывает полученный CredReq следующим образом.

Шаг	Действие
1	Извлекается запрос из входного сообщения
2	Для каждой позиции, для которой продавец получил маркер CapToken: Проверяется присутствие CapToken. Если CapToken отсутствует, позиция отвергается и присылается CapRevOrReqCode = capTokenMissing Проверяется CapToken
3	Для каждой транзакции в сообщении реализовать кредитную операцию, используя существующую финансовую сеть платежной карты, как это специфицировано в содержимом CapRevOrCredItem.

Формирование CredRes осуществляется в следующей последовательности.

Шаг	Действие
1	Получить отклик из финансовой сети платежной карты
2	Сгенерировать CredResData, как это описано в CapRevOrCredResData, используя результаты из финансовой сети платежной карты. Заполнить RRTags, полученные в запросе
3	Включить Enc-инкапсуляцию для полученных результатов
4	Поместить сообщение в цифровой конверт и отправить владельцу карты

Формат отклика CredRes представлен ниже.

CredRes	Enc(P, M, CredResData)
CredResData	CapRevOrCredResData; см. табл. 4.6.2.74.

Продавец обрабатывает CredRes за два шага:

Получается отклик CredRes из входного сообщения

Обрабатывается CredResData, как это описано в CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать успешно проплаченную сумму.

Сообщения CredRevReq/ CredRevRes обеспечивают для продавца механизм отзыва предоставленного ранее кредита. Формирование запроса CredRevReq осуществляется следующим образом.

Шаг	Действие
1	Сформировать CredRevReqData, как это описано в разделе CapRevOrCredReq
2	Для каждой позиции CapRevOrCred в CapRevOrCredItem заполнить позицию в CapTokSeq следующим образом: Если доступен, занести CapToken для соответствующей транзакции В противном случае, если маркер не доступен, записать NULL
3	Если доступен или необходим новый PAN, занести PANToken в дополнительную нишу EncBX-инкапсуляции. Если PANToken в наличии, только одна позиция может присутствовать как в CredRevReqData, так и в CapTokSeq.
4	Если PANToken присутствует, включить EncBX-инкапсуляцию. В противном случае - EncB-инкапсуляцию.
5	Вставить сообщение в цифровой конверт и направить владельцу карты

Структура запроса CredRevReq показана в таблице 4.6.2.77.

Структура CredRevReq

Таблица 4.6.2.77. Структура CredRevReq

CredRevReq	<EncB(M, P, CredRevReqData, CapTokenSeq), EncBX(M, P, CredRevReqData, CapTokenSeq, PANToken)> CapTokenSeq является внешним “багажом”. Если PANToken имеется, он должен соответствовать одной записи в CredRevReqData.CredRevReqSeq и однму маркеру CapToken в CapTokenSeq.
CredRevReqData	CapRevOrCredReqData; см. табл. 4.6.2.72
CapTokenSeq	{[CapToken] +} Один или более CapTokens, в соответствии один-к-одному с CredRevReqItem в CapRevOrCredReqData.CapRevOrCredReqItemSeq. Заметим, что любой CapToken может быть опущен, т.е. может быть NULL
PANToken	См. табл. 4.6.2.46
CapToken	Копируется из соответствующего AuthRes или AuthRevRes

Расчетный центр обрабатывает запрос CredRevReq следующим образом.

Шаг	Действие
1	Выделить запрос из входного сообщения
2	Для каждой позиции, для которой продавец получил CapToken: Проверить присутствие CapToken. Если CapToken отсутствует, отвергнуть позицию, послав CapRevOrReqCode = capTokenMissing Проверить CapToken
3	Для каждой транзакции в сообщении выполнить отзыв кредита, используя существующую финансовую сеть расчетной карты, как это специфицировано содержимым CapRevOrCredItem

Формирование отклика CredRevRes осуществляется в следующей последовательности.

Шаг	Действие
1	Получить отклик из финансовой сети платежной карты
2	Сформировать CredRevResData, как это описано в разделе CredRevOrCredResData, используя результаты из финансовой сети карты. Заполнить RRTags, полученные в запросе.
3	Включить для полученного результата Enc-инкапсуляцию
4	Вложить отклик в цифровой конверт и отправить владельцу карты

Отклик CredRevRes имеет достаточно простой формат:

CredRevRes	Enc(P, M, CredRevResData)
CredRevResData	CredRevOrCredResData; См. табл. 4.6.2.74.

Продавец обрабатывает полученный отклик следующим образом

Шаг	Действие
1	Извлекается отклик из входного сообщения
2	Обрабатывается CredRevResData, как это описано в разделе о CapRevOrCredResData. Для каждого CapRevOrCredResItem проверяется CapRevOrCredCode, чтобы определить результат и записать сумму успешного платежа.

<
Обработка запроса сертификата расчетного центра включает в себя два сообщения, запрос от продавца к расчетному центру и отклик последнего, направляемый продавцу. В запросе продавец просит расчетный центр прислать ему сертификат, который необходим для последующего шифрования сообщений от продавца к расчетному центру. Сертификат присылается в сообщении-отклике. Генерация запроса PCertReq выполняется в следующей последовательности.

Шаг	Действие
1	Заполнить PCertTags, как это описано в разделе о RRTags табл. 4.6.2.52.
2	Рекомендуется заполнить отклики Mthumbs путем вычисления оттисков сертификатов и CRL, хранящихся у продавца. Продавец должен занести оттиски в сообщение, которое может потребоваться позднее для верификации подписей и сертификатов, предоставленных расчетным центром. Включение этого поля служит оптимизации с целью уменьшения передач сертификатов и CRL в последующих сообщениях из расчетного центра.
3	Заполнить BrandIDSeq одним или более BrandIDandBIN, для которого необходимы сертификаты: Заполнить поле BrandID Опционно заполнить поле BIN
4	Опционно заполнить поле PCRqExtensions
5	Ввести S (см. описание оператора подпись выше)
6	Вложить сообщение в цифровой конверт и отправить владельцу карты

Формат сообщения-запроса PCertReq представлен в таблице 4.6.2.78.

PCertReq	S(M, PCertReqData)
PCertReqData	{PCertTags, [MThumbs], BrandAndBINSeq, [PCRqExtensions]}
PCertTags	RRTags. Новый RRPID для этого PCertReq, MerTermIDs, поставляемый продавцом, и текущая дата
MThumbs	Оттиски сертификатов расчетного центра, хранящиеся в кэше продавца.
BrandAndBINSeq	{BrandAndBIN +} Продавец запрашивает сертификаты расчетного центра для платежных систем карты, если оттиск текущего сертификата отсутствует в MThumbs
PCRqExtensions	Запрос сертификата расчетного центра не шифруется, поэтому это расширение не должно содержать конфиденциальной информации
BrandAndBIN	{BrandID, [BIN]}
BrandID	Платежная система карты (без указания типа).
BIN	Идентификационный номер банка для обработки транзакции продавца в расчетном центре.

Структура InqReq

Таблица 4.6.2.63. Структура InqReq

InqReq	<InqReqSigned, InqReqData>
InqReqSigned	S(C, InqReqData)
InqReqData	{TransIDs, RRPID, Chall-C2, [InqRqExtensions]}
TransIDs	Копируется из самого последнего: PReq, PRes, InqReq
RRPID	Идентификатор пары запрос/отклик
Chall-C2	Новый вызов владельца карты по поводу подписи продавца.
InqRqExtensions	Информационный запрос не шифруется, по этой причине расширения не должны содержать конфиденциальной информации.

Когда продавец получает InqReq, он обрабатывает это сообщение следующим образом:

Шаг	Действие
1	Извлекается запрос из входного сообщения
2	Если получены данные InqReqData (в противоположность InqReqSigned), проверить, позволяет ли сертификат расчетного центра неподписанные транзакции. Если он этого не допускает, тогда: Прислать сообщение InqRes c CompletionCode = signatureRequired. Прервать обработку InqReq В противном случае перейти к пункту 4.
3	Если получен InqReqSigned, проверить подпись. Если проверка подписи не прошла: Прислать сообщение Error с ErrorCode = signatureFailure Прервать обработку InqReq
4	Сравнить TransIDs со значениями из цифрового конверта сообщения. Если равенства нет: Прислать сообщение Error c ErrorCode = wrapperMsgMismatch Прервать обработку InqReq
5	Искать транзакцию в базе данных, основанную на TransIDs.XID. Если поиск неудачен: Прислать InqRes c CompletionCode = orderNotReceived. Прервать обработку InqReq
6	Если PReq был подписан, проверить, что PReq и InqReq подписаны одним и тем же владельцем карты. Если соответствия нет, то: Прислать сообщение Error c ErrorCode = unknownXID. Прервать обработку InqReq
7	Сформировать PResPayloadSeq

Авторизация платежей продавца осуществляется согласно схеме, показанной на Рисунок 4.6.2.17.

Структура InstallRecurData

Таблица 4.6.2.41. Структура InstallRecurData

InstallRecurData	{InstallRecurDInd, [IRExtensions]}
InstallRecurDInd	< InstallTotalTrans, Recurring >
IRExtensions	Данные в расширении или рекурсивные данные. Они должны носить финансовый характер и должны иметь отношение к последующим процедурам авторизации продавца и расчетного центра
InstallTotalTrans	Владелец карты специфицирует максимально допустимое число авторизаций для последовательных платежей
Recurring	{RecurringFrequency, RecurringExpiry}
RecurringFrequency	Минимальное число дней между авторизациями (ежемесячная авторизация обозначается 28 днями)
RecurringExpiry	Окончательная дата, после которой никакие авторизации не разрешены

Рекуррентные данные являются компонентом платежной инструкции, которая копируется в авторизационный маркер (token). Эта информация не пересылается эмитенту.

AuthToken представляет данные, необходимые расчетному центру для авторизации последующих транзакций. Расчетный центр, если необходимо, актуализует AuthToken. Данные, содержащиеся там должны быть доступны только расчетному центру. Структура данных AuthToken представлена в таблице 4.6.2.42.

---

---