Intel Pentium processor - технический обзор
Технический обзор
Главная -
Общие способы взаимодействия
Общие способы взаимодействия
Ниже приводятся некоторые общие способы взаимодействия между
объектами.
ВЗАИМОДЕЙСТВИЕ ЗАПРОС/ОТВЕТ
Большинство типов взаимодействия составляет взаимодействие
между запросом, движущемся в одном направлении, и последующим отве-
том, движущимся в другом направлении.
В тех ситуациях, когда взаимодействие происходит в ненадежном
транспорте (т.е. UDP - Протокол пользовательских дейтаграмм), или
когда запрос является широковещательным, жесткой взаимосвязи или
отношения один к одному между запросом и ответом может и не быть.
В любом случае, это более, чем один ответ, вырабатываемый на
полученный запрос. В то время, когда ответ ожидает, отвечающий об-
ъект может посылать одно или более подтверждение приема с ожиданием.
ПОВТОРНАЯ ПЕРЕДАЧА ЗАПРОСОВ
Протокол пользовательских дейтаграмм (UDP) является ненадежным
механизмом отправки сообщений, где пакеты могут быть утеряны, полу-
чены не в последовательности их передачи, дублированы, кроме того,
отправка может происходить со значительной задержкой. Вследствие
того, что протоколы NETBIOS интенсивно используют UDP, они компен-
сируют недостаток надежности UDP дополнительными механизмами.
Каждый пакет NETBIOS содержит всю необходимую информацию для
его обраотки. Ни один из протоколов не использует несколько паке-
тов UDP для передачи одиночного запроса или ответа. Если требуется
больше исформации, чем может поместиться в один пакет UDP, напри-
мер, когда узел типа "Р" хочет получить от спецпроцессора NETBIOS
всех владельцев группового имени, используется связь TCP (Протокол
управления транспортом). Следовательно, в протоколах не произойдет
сбой из-за нарушения последовательности отправки пакетов UDP.
Для того, чтобы исключить потерю пакета ответа или пакета зап-
роса, каждая операция запроса повторно передаст запрос, если ответ
не будет получен в течение определенного промежутка времени.
Операции с протоколами, чуствительные к успешной передаче па-
кетов ответов, например, операции обнаружения конфликтов с именами,
защищены от дублирования пакетов вследствие того, что они игнори-
руют последовательные пакеты с одной и той же информацией NETBIOS.
Так как никакое состояние в отвечающем узле не ассоциируется с зап-
росом, ответчик просто посылает подходящий ответ, когда бы не при-
был пакет с запросом. Следовательно, дублирующиеся или задержанные
пакеты запросов игнорируются.
Для всех запросов, если пакет ответа задерживается слишком
долго, то посылается другой пакет запроса. Второй пакет ответа,
посылаемый "в ответ" на второй пакет запроса, эквивалентен дублиру-
ющемуся пакету. Следовательно, протоколы проигнорируют второй полу-
ченный пакет. Если отправка ответа задерживается до завершения опе-
рации запроса (успешной или нет), пакет ответа будет проигнорирован.
ЗАПРОСЫ БЕЗ ОТВЕТОВ
Некоторые типы запросов не имеют соответствующих ответов. Эти
запросы называются "требованиями". В целом, требование представляет
собой запрос-приказание (императивный запрос), которому получающий
узел должен подчиниться. Однако, вследствие того, что требования
не подтверждаются, они применяются только в тех ситуациях, когда
при утере пакета требования произошло бы ограниченное повреждение.
Пакеты требований не передаются повторно.
ТРАНЗАКЦИИ
Взаимодействия между парой объектов группируются в "транзак-
ции". Эти транзакции объединяют одну или более пару типа "зап-
рос/ответ".
Идентификатор транзакции
Вследствие того, что между парой объектов может происходить
несколько одновременных транзакций, используется "идентификатор
транзакции".
Инициатор транзакции выбирает идентификатор, уникальный для
данного инициатора. Идентификатор транзакции перемещается вперед и
назад при каждом взаимодействии внутри данной транзакции. Партнеры
по транзакции должны устанавливать соответствие ответов и запросов,
сравнивая идентификатор транзакции и адрес IP (IP - Межсетевой про-
токол) партнера по транзакции. Если соответствующий запрос не нахо-
дится, ответ должен быть сброшен.
Для каждой транзакции используется новый идентификатор. Гене-
ратором идентификатора транзакции должен быть простой 16-битовый
счетчик транзакций. Необходимости искать и отфильтровывать
дублирующийся идентификатор транзакции нет: вероятность сущест-
вования такой транзакции, чей "срок жизни" превышал бы небольшую
долю обычного циклического периода счетчика, чрезвычайна мала. При-
менение адресов IP вместе с идентификатором транзакции значитель-
но сокращает вероятность сбоев, в том случае, если идентификатор
транзакции был бы использован повторно.
20.05.2012