ar-net.ru 24.2 "Простое управление доставкой"
Значение "простое управление доставкой" предоставляет пользователю ВТ, обновляющему ОО, дополнительную услугу VT-DELIVER, которая выполняет следующие действия:
a) происходит доставка сохраняемой последовательности элементов обновления (таким образом доступно дополнительное средство запроса, имеющее отношение к случаю "нет управления доставкой");
b) явная индикация конца доставляемой последовательности элементов обновления передается принимающему пользователю ВТ;
c) эта индикация может в необязательном средстве пользователя ВТ, инициирующего доставку, также потребовать подтверждение доставки принимающим пользователем ВТ.
За исключением вышесказанного, операция поставщика услуг со значением "простое управление доставкой" такая же, как и в случае значения "нет управления доставкой".
24.3 "Карантинное управление доставкой"
Значение "карантинное управление доставкой" предоставляет пользователю ВТ, обновляющему ОО, возможности значения "простое управление доставкой" со следующими ограничениями:
a) поставщику услуг не разрешается явная или неявная доставка элементов обновлений до инициирования функции "доставка";
b) поставщику услуг разрешается выполнять сцепление или сегментацию элементов обновлений;
с) поставщик услуг может осуществлять функцию "конечный эффект" элементов обновлений, накопленных между двумя доставками (см. В. 15). Функция "конечный эффект" может объединить обновления из двух или более примитивов запроса VT-DATA при условии, что параметр "эхоконтроль" не установлен или установлен только в последнем элементе.
24.4 Неявная доставка
Некоторые подтверждаемые услуги, как побочный эффект, выполняют неявную доставку любых хранимых элементов доставки. Этими услугами являются VT-RELEASE, VT-SWITCH-PROFILE и VT-START-NEG. Эта неявная доставка выполняется следующим образом:
a) примитив запроса выполнит доставку равноправному пользователю ВТ любых обновлений, введенных инициирующим пользователем ВТ, до соответствующего примитива индикации;
b) примитив ответа, указывающий, что услуга выполнилась успешно, вызовет доставку равноправному пользователю ВТ любых обновлений, введенных принимающим пользователем ВТ, до соответствующего примитива подтверждения;
с) примитив ответа, указывающий, что услуга отвергнута, не вызовет доставку каких-либо обновлений, но такая доставка может произойти на усмотрение поставщика услуг, если не используется "карантинное управление доставкой", при которой доставка выполняться не будет.
Примечание - Эти услуги описаны как условно упорядоченные, поскольку ответ/подтверждение могут дополнять уже введенную информацию обновления, если услуга отвергнута.
Неявная доставка всех обновлений вызывается также передачей полномочия доступа ПДЗ из-за инициирования услуги VT-GIVE-TOKENS или в результате действия "триггер" (см. 24.1 а).
В таблице 15 отражены действия поставщика услуг, относящиеся к доставке обновления для А-режима и С-режима.
24.5 Очереди обновления и обработка приоритета
Определены три приоритета обновления: "нормальный", "высокий" и "срочный". Приоритет обновления является характеристикой объекта в ФСВТ. ОО имеют неявно "нормальный" приоритет. Параметром ФСВТ "ОУ-приоритет" ОУ назначается один из трех приоритетов (см. 20.1).
Таблица 15 - Перечень действий поставщика услуг по отношению к управлению доставкой и передаче полномочия доступа
С-режим | А-режим | ||
| Явная доставка | ВыдачаVT-DATA.индикация иVT-DATA.индикация | ВыдачаУТ-ВАТА.индикация и VT-DELIVER.индикация | |
| Неявное управление доставкой | Передача полномочия доступа | ВыдачаVT-DATA.индикация иVT-GIVE-TOKENS.индикация | |
| Обновление ОУ с характеристикой "триггер" | ВыдачаVТ-DATA, индикация иVT-GIVE-TOKENS.индикация | ВыдачаVT-DATA.индикация | |
| Из-за других услуг ВТ | ВыдачаVT-DATA. индикация с индикацией для запрошенной услуги | ВыдачаVT-DATA.индикация с индикацией для запрошенной услуги | |
| 1. VT-RELEASE. запрос2. VT-START-NEG. запрос3. VT-SWITCH-PROFILE.запрос | |||
| 4. VT-RELEASE. ответ (получатель)5. VT-START-NEG. ответ (получатель)6. VT-SWITCH-PROFILE.ответ (получатель) | Выдача подтверждения для запрошенной услуги (VT-DATA.индикация не выдается) | ВыдачаVT-DATA.индикация с подтверждением для запрошенной услуги | |
| 7. VT-RELEASE. ответ (отказ)8. VT-START-NEG. ответ (отказ)9. VT-SWITCH-PROFILE.ответ (отказ) | Выдача подтверждения для запрошенной услуги (VT-DATA.индикация не выдается) | Выдача подтверждения для запрошенной услуги VT-DATA.индикация не выдается) | |
| Примечание - VT-DATA.индикация выдается, только если имеются один или более элементов обновления. | |||
Приоритет обновления связан со срочностью, с которой поставщик услуг будет пытаться уведомить равноправного пользователя ВТ об обновлении, запрошенным одним пользователем ВТ. Обновления с приоритетом "высокий" могут быть доставлены, когда обновления с приоритетом "нормальный" задерживаются управлением доставкой, но могут быть задержаны равноправным пользователем ВТ или "обратным давлением" поставщика услуг. Обновления с приоритетом "срочный" могут обходить некоторые такие блокировки и будут доставляться наиболее быстро, если выбран функциональный блок "срочные данные" (см. раздел 10).
Действие поставщика услуг по выполнению обновлений объекта (инициированное примитивом VT-DATA, см. 31.1) моделируется с использованием нескольких очередей, как показано на рисунке 8. Между двумя пользователями ВТ предполагается наличие двух дополнительных экземпляров механизма, каждый из которых имеет дело с запросами VT-DATA от одного пользователя ВТ и выдачей индикаций VT-DATA равноправному пользователю ВТ.
Примечание - Два экземпляра, используемые в А-режиме и С-режиме, внутренне независимы один от другого. Объект с правилом доступа "ПДЗ" в любой конкретный момент времени может быть обновлен только одним пользователем ВТ, поскольку в любое время не более чем один пользователь ВТ владеет полномочием доступа ПДЗ.
Ниже содержится расширенное описание рисунка 8. Оно применимо независимо к каждому направлению потока обновлений.
24.5.1 Выдача пользователем ВТ запроса на обновление подчиняется только правилу доступа для этого объекта.
24.5.2 Правильный запрос на обновление помещается в "хвост" очередей запросов на обновление Q1, Q2 или Q3 согласно приоритету обновления объектов.
24.5.3 Три очереди запросов на обновление обслуживаются в порядке "срочный", "высокий" и "нормальный", каждая очередь должна стать полностью пустой перед тем, как будет обслуживаться следующая очередь, т.е. после того, как обновление взято из начала очереди, снова проверяются очереди с более высоким приоритетом.
Примечание - Поставщик услуг будет всегда обеспечивать обход механизма приоритета, представленный очередями Q1 и Q4, но может ограничить количество элементов в любой из этих очередей до одного или некоторого малого количества, приостанавливая сервисный интерфейс или маршрут передачи, когда достигнуто это количество. Применение очередей Q2, Q3, Q5 или Q6 не должно препятствовать использованию механизма обхода.
 | |
| 1306 × 1650 пикс. Открыть в новом окне | |
24.5.4 Между двумя пользователями ВТ всегда существует "нормальный маршрут передачи", и он используется для упорядоченной (в порядке поступления) передачи запросов на обновление из очередей "нормального" или "высокого" приоритета.
24.5.5 Если был выбран функциональный блок "срочные данные", то существует "специальный маршрут передачи", и он всегда будет использован для упорядоченной в порядке поступления передачи запросов обновления из очереди с приоритетом "срочный"; если он не существует, для таких обновлений будет использован нормальный маршрут.
24.5.6 Если существует "специальный маршрут передачи", то гарантируется, что обновления, которые передаются по этому маршруту, всегда будут доставлены раньше, чем последующие "нормальные" обновления. Они могут "догнать" ранее посланные "нормальные" обновления, если они задерживаются по какой-либо причине.
24.5.7 Действие стимула для выполнения "доставки" (см. 24.2-24.4) приводит к размещению метки доставки в Q3 и к исчерпыванию очередей запросов на обновление по маршруту передачи, как в 24.5.3-24.5.5, пока метка "доставки" присвоена нормальному маршруту.
Примечание - Явный стимул для доставки при помощи VTDELIVER. запрос должен различаться в механизме передачи так, чтобы VTDELIVER.индикация могла быть порождена при корректных обстоятельствах.
24.5.8 Как только обновления приняты от маршрута (маршрутов) передачи, они помещаются в очередь индикаций обновлений Q4, Q5 или Q6 согласно приоритетом обновлений.
24.5.9 Три очереди индикаций обновлений обслуживаются способом, описанным в 24.5.3, но если выполняется "карантинное управление доставкой", никакие обновления не могут быть взяты из очереди Q6 до тех пор, пока не будет получена метка "доставки" от маршрута передачи (см. 24.5.7 и 24.5.10). Если выбрано "нет управления доставкой" (см. 24.1), то каждое обновление выдается принимающему пользователю ВТ как индикация VT-DATA.
См. примечание в 24.5.3.
24.5.10 Метка "доставка" приводит к исчерпыванию трех очередей индикаций обновления в порядке Q4 - Q6, т.е. освобождению любых "карантинных" и соответствующих индикаций VT-DATA, которые должны быть выданы, с разрешенным "конечным эффектом", только если выполняется "карантинное управление доставкой".
25 Модель взаимодействия
В остальных разделах настоящего стандарта определяются средства взаимодействия службы ВТ.
В настоящем стандарте использована абстрактная модель взаимодействия между пользователями ВТ и поставщиком услуг ВТ. Эти взаимодействия имеют форму услуг, которые передают информацию между пользователем ВТ и поставщиком услуг ВТ в параметрах услуги ВТ.
Примечания
1 Модель взаимодействия эквивалентна модели, описанной в ИСО/ТО 8509 за исключением того, что здесь не определены граница уровня или пункты доступа к услугам.
2 Модель взаимодействия идентична модели, изображенной на рисунке 2 и описанной в разделе 12.
3 Услуги ВТ концептуальны и необязательно должны быть прямо связаны с элементами протокола или иметь вид макровызовов метода доступа к услуге.
4 Существуют другие эквивалентные наборы услуг ВТ, которые могут обеспечить те же сервисные средства.
5 Определены только те услуги, которые имеет отношение к взаимодействию между двумя пользователями ВТ. Услуги, связанные с локальными соглашениями между пользователем ВТ и поставщиком услуг, находятся вне сферы действия настоящего стандарта.