Протокольная инженерия

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

История

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

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

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

Принципы

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

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

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

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

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

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

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

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

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

Книги

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

Ссылки

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

[Boch1980-1] Jump up to: ^а ^б Г. против Бохманна и К. А. Саншайн, Формальные методы разработки протоколов связи, IEEE Tr. COM-28, № 4 (апрель 1980 г.), стр. 624–631.

[2] См. серию конференций по тестированию и проверке спецификаций протоколов (PSTV) с 1981 года.

[Boch2010-3] Jump up to: ^а ^б Г. против Бохманна, Д. Рейнер и Ч. Уэст, Некоторые заметки по истории разработки протоколов, журнал Computer Networks, 54 (2010), стр. 3197–3209.

[4] К. А. Виссерс, Г. против Бохманна и Р. Л. Тенни, Методы формального описания, Proceedings of IEEE, vol. 71, 12, стр. 1356–1364, декабрь 1983 г.

[5] Дж. Дж. Диксон; П.Е. де Шазал, Статус методов описания CCITT и их применение к спецификации протоколов, Proceedings of IEEE, vol. 71, 12, стр. 1346-1355 (1983).

[6] П. Зафиропуло, К. Уэст, Х. Рудин, Д. Коуэн, Д. Брэнд: На пути к анализу и синтезу протоколов, Транзакции IEEE в коммуникациях (Том: 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.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]