Разработка протокола - Protocol engineering

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

История

Когда первые экспериментальные и коммерческие компьютерная сеть были разработаны в 1970-х годах, концепция протоколов еще не была развита. Это были первые распределенные системы. В контексте недавно принятой многоуровневой архитектуры протокола (см. Модель OSI ), определение протокола конкретного уровня должно быть таким, чтобы любой объект, реализующий эту спецификацию на одном компьютере, был совместим с любым другим компьютером, содержащим объект, реализующий ту же спецификацию, и их взаимодействие должно быть таким, чтобы желаемая служба связи быть полученным. С другой стороны, спецификация протокола должна быть достаточно абстрактной, чтобы допускать различные варианты реализации на разных компьютерах.

Было признано, что точное определение ожидаемой услуги, предоставляемой данным уровнем, имеет важное значение. [1]. Это важно для проверки протокола, которая должна продемонстрировать, что услуга связи предоставляется, если оба объекта протокола правильно реализуют спецификацию протокола. Позже этому принципу следовали при стандартизации Стек протоколов OSI, в частности для транспортный уровень.

Также было признано, что некоторая формализованная спецификация протокола будет полезна для проверки протокола и для разработки реализаций, а также тестовых примеров для проверки соответствия реализации спецификации. [2]. Первоначально в качестве (упрощенных) моделей протокольного объекта использовались в основном конечные автоматы. [3], в 1980-х годах были стандартизированы три официальных языка спецификаций, два - ISO [4] и один МСЭ [5]. Последний, названный SDL, позже использовался в промышленности и был объединен с Конечные автоматы UML.

Принципы

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

Ниже приведены наиболее важные принципы разработки протоколов:[1]

  • Многоуровневая архитектура: уровень протокола на уровне n состоит из двух (или более) объектов, которые имеют интерфейс службы, через который служба уровня предоставляется пользователям протокола, и который использует службу, предоставляемую локальным объектом уровень (n-1).
  • Спецификация службы уровня описывает в абстрактном и глобальном виде поведение уровня, видимое на интерфейсах служб уровня.
  • Спецификация протокола определяет требования, которым должна удовлетворять реализация каждого объекта.
  • Проверка протокола состоит в демонстрации того, что два (или более) объекта, удовлетворяющих спецификации протокола, будут предоставлять на своих служебных интерфейсах указанную услугу этого уровня.
  • (Проверенная) спецификация протокола используется в основном для следующих двух действий:
  1. Разработка сущности реализации. Обратите внимание, что абстрактные свойства интерфейса службы определяются спецификацией службы (а также используются в спецификации протокола), но подробный характер интерфейса может быть выбран в процессе реализации отдельно для каждого объекта.
  2. Разработка набора тестов для проверка на соответствие. Тестирование на соответствие протокола проверяет, соответствует ли реализация данного объекта спецификации протокола. Сценарии проверки соответствия разрабатываются на основе спецификации протокола и применимы ко всем реализациям объекта. Поэтому стандартные наборы тестов на соответствие были разработаны для определенных стандартов протоколов.[3]

Методы и инструменты

Инструменты для действий по верификации протокола, реализации сущностей и разработке набора тестов могут быть разработаны, когда спецификация протокола написана на формализованном языке, понятном для этого инструмента. Как уже упоминалось, формальная спецификация были предложены языки для спецификации протоколов, а первые методы и инструменты были основаны на моделях конечных автоматов. Анализ доступности было предложено понять все возможные варианты поведения распределенной системы, которые необходимы для проверки протокола. Позже это было дополнено проверка модели. Однако описания с конечным числом состояний недостаточно эффективны для описания ограничений между параметрами сообщения и локальными переменными в объектах. Такие ограничения могут быть описаны с помощью упомянутых выше стандартизованных формальных языков спецификации, для которых были разработаны мощные инструменты.

Именно в области разработки протоколов модельно-ориентированная разработка использовался очень рано. Эти методы и инструменты позже использовались для программная инженерия а также дизайн оборудования, особенно для распределенных систем и систем реального времени. С другой стороны, многие методы и инструменты, разработанные в более общем контексте программной инженерии, также могут быть использованы для разработки протоколов, например проверка модели для проверки протокола, и гибкие методы для реализации сущностей.

Конструктивные методы проектирования протокола

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

  • Полуавтоматический синтез протокола[6]: Пользователь определяет все действия сущностей по отправке сообщений, а инструмент выводит все необходимые действия приема (даже если несколько сообщений находятся в пути).
  • Протокол синхронизации[7]: Переходы состояний одного объекта протокола задаются пользователем, и метод определяет поведение другого объекта таким образом, чтобы он оставался в состояниях, соответствующих предыдущему объекту.
  • Протокол, полученный из спецификации услуги[8]: Спецификация сервиса предоставляется пользователем, и метод выводит подходящий протокол для всех объектов.
  • Протокол для управляющих приложений[9]: Дается спецификация одного объекта (называемого объектом, который должен контролироваться), и метод выводит спецификацию другого объекта, так что определенные состояния отказа объекта никогда не достигаются, и определенные заданные свойства взаимодействия служб объекта довольный. Это случай диспетчерский контроль.

Книги

  • Минг Т. Лю, Протоколная инженерия, достижения в области компьютеров, Том 29, 1989 г., страницы 79-195.
  • G.J. Хольцманн, Разработка и проверка компьютерных протоколов, Прентис-Холл, 1991.
  • Х. Кёниг, Протокол инженерии, Springer, 2012.
  • М. Попович, Разработка протоколов связи, CRC Press, 2-е изд. 2018.
  • П. Венкатарам, С.С. Манви, Б.С. Бабу, Разработка протоколов связи, 2014.

использованная литература

  1. ^ а б Г. В. Бохманн и К. А. Саншайн, Формальные методы в разработке протоколов связи, IEEE Tr. COM-28, № 4 (апрель 1980 г.), стр. 624-631.
  2. ^ Смотрите серию конференций на Тестирование и проверка спецификации протокола (PSTV) с 1981 года.
  3. ^ а б Г. фон Бохманн, Д. Райнер и К. Х. Уэст, Некоторые заметки по истории разработки протоколов, журнал Computer Networks, 54 (2010), стр 3197–3209.
  4. ^ К. А. Виссерс, Г. В. Бохманн и Р. Л. Тенни, Методы формального описания, Труды IEEE, т. 71, 12, стр. 1356-1364, декабрь 1983 г.
  5. ^ G.J. Диксон; P.E. де Шазаль, Статус методов описания CCITT и их применения к спецификации протокола, Proceedings of the IEEE, vol. 71, 12, стр. 1346-1355 (1983).
  6. ^ П. Зафиропуло, К. Уэст, Х. Рудин, Д. Коуэн, Д. Бранд: На пути к анализу и синтезу протоколов, IEEE Transactions on Communications (том: 28, выпуск: 4, апрель 1980 г.)
  7. ^ М.Г. Гауда и Ю. Ю., Синтез сообщающихся конечных автоматов с гарантированным прогрессом, IEEE Trans. по сообщению, т. Com-32, № 7, июль 1984 г., стр. 779-788.
  8. ^ М.Ф. Аль-Хаммури и Г.В. Бохманн, Возможность реализации спецификаций услуг, Proc. Конференция по системному анализу и моделированию (SAM) 2018, Копенгаген, LNCS, Springer.
  9. ^ Г. В. Бохманн, Использование логики для решения проблемы построения подмодулей, Журнал по динамическим системам с дискретными событиями, Vol. 23 (1), Springer, март 2013 г., стр. 27-59.