Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

История [ править ]

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

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

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

Принципы [ править ]

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

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

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

Методы и инструменты [ править ]

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

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

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

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

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

Книги [ править ]

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

Ссылки [ править ]

  1. ^ a b Г. В. Бохманн, К. А. Саншайн, Формальные методы в разработке протоколов связи, IEEE Tr. COM-28, № 4 (апрель 1980 г.), стр. 624-631.
  2. ^ См. Серию конференций по тестированию и проверке спецификаций протоколов (PSTV) с 1981 года.
  3. ^ a b G. v. Bochmann, D. Rayner и CH West, Некоторые заметки по истории разработки протоколов, Computer Networks journal, 54 (2010), pp 3197–3209.
  4. ^ CA Vissers, G. v. Bochmann и RL Tenney, Формальные методы описания, Proceedings of the IEEE, vol. 71, 12, стр. 1356-1364, декабрь 1983 г.
  5. ^ Дж. Дж. Диксон; PE de Chazal, Статус методов описания CCITT и их применение к спецификации протокола, Proceedings of the IEEE, vol. 71, 12, стр. 1346-1355 (1983).
  6. ^ П. Зафиропуло, К. Вест, Х. Рудин, Д. Коуэн, Д. Бранд: К анализу и синтезу протоколов, IEEE Transactions on Communications (том: 28, выпуск: 4, апрель 1980 г.)
  7. ^ MG Gouda и YT Yu, Синтез взаимодействующих конечных автоматов с гарантированным прогрессом, IEEE Trans. по сообщению, т. Com-32, № 7, июль 1984 г., стр. 779-788.
  8. ^ MF Al-hammouri и Gv Bochmann, Реализуемость сервисных спецификаций, Proc. Конференция по системному анализу и моделированию (SAM) 2018, Копенгаген, LNCS, Springer.
  9. ^ Г. В. Бохманн, Использование логики для решения проблемы построения подмодуля, Журнал по динамическим системам с дискретными событиями, Vol. 23 (1), Springer, март 2013 г., стр. 27-59.