Здравствуйте, McQwerty, Вы писали:

MQ>Зачем на принимающей стороне знать какими частями передающая сторона посылала данные? Этак и ответы на вопросы типа "не могу принять пакет по TCP" перестанут взывать гневные отповеди "пакетов нет!". Или я неправильно понял термин?

Потому что часто прикладному протоколу нужна передача сообщений, а не потока байтов. Если использовать TCP, то приходится самому мучаться с передачей границ сообщений. А SCTP берет эту заботу на себя.

MQ>И до кучи: а зачем может понадобиться "Unordered delivery", которая тоже "Yes".

На случай, если принимать данные в порядке поступления важнее, чем ждать, пока они все придут в правильном порядке.

Здравствуйте, Sinclair, Вы писали:

S>Ну то есть за два года, прошедших с этого спора, ты так ничему и не научился. Похвально.

Не сдержался. Просто пример с туннелированием — самый удивительный в этом топике, в том плане, что этот костыль в IP, нагляднее всего демонстрирующий недостатки системы адресации, снова и снова настойчиво предъявляют как аргумент в пользу того же IP, не понимая, видимо, принципов организации виртуальных сетей как таковых.

Здравствуйте, netch80, Вы писали:


N>Расскажите, как именно "банально" с точки зрения OSI мне связать (пусть, предположим, везде OSI протоколы) две сети на разных континентах в один broadcast segment, как будто между ними стоит просто свич. Прошу сразу детали реализации, а не общие слова.

Это все делается "родным" способом для OSI, т.к. существует отдельное понятие логической сети/подсети. Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

Так же напомню, что адреса в пакетах могут быть произвольной длины, адреса сетей/подсетей используются отдельно от адресов хостов, соотвественно, существуют посылки уровня сети/подсети, твой broadcast. Прикол в том, что сетевой уровень понятия не имеет, broadcast сообщение или нет, он просто доставит пакет в сеть/подсеть, а интерпретацией содержимого займется уже транспортный уровень, на котором и станет понятно, что данный пакет — broadcast.

В принципе, вот здесь

Автор: vdimas
Дата: 01.11.06

я обобщил все свои отдельные высказывания (где-то с середины поста).

Здравствуйте, vdimas, Вы писали:

Я повторю вслед за netch'ем: чушь и воронятина.


V>Здравствуйте, netch80, Вы писали:

N>>Расскажите, как именно "банально" с точки зрения OSI мне связать (пусть, предположим, везде OSI протоколы) две сети на разных континентах в один broadcast segment, как будто между ними стоит просто свич. Прошу сразу детали реализации, а не общие слова.

V>Это все делается "родным" способом для OSI, т.к. существует отдельное понятие логической сети/подсети.

Понятие существует, да. Которое описывает определенные функции. Так вот, должно быть нечто, что выполнит эти функции через "OSI-интернет" для двух сетей на разных континентах. Поэтому надо либо сделать либо реальный subnetwork, либо виртуальный, что и означает туннелирование в конечном итоге.

V> Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

Что это каша? IDRP выполяет функции распространения маршрутной информации между маршрутизационными доменами. Т.е. речь об общей subnetwork, расположенной в двух доменах тут речи не идет.

Кстати, домашнее задание для OSI/ISO-фанатов: выяснить как инкапсулируются BISPDU и с помощью сложных теологических рассуждений доказать, что IDRP не нарушает священную модель OSI, в то время как BGP — это вероотступничество.

Здравствуйте, Изя Рнет, Вы писали:


ИР>Понятие существует, да. Которое описывает определенные функции. Так вот, должно быть нечто, что выполнит эти функции через "OSI-интернет" для двух сетей на разных континентах. Поэтому надо либо сделать либо реальный subnetwork, либо виртуальный, что и означает туннелирование в конечном итоге.

Этим "нечто" является ПО по организации логических подсетей. Логическая подсеть и так всегда виртуальна (совпадение с физической подсеткой может быть случайным ), почему я и говорю, что аналог туннелирования заложен в OSI-модель изначально.


V>> Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

ИР>Что это каша? IDRP выполяет функции распространения маршрутной информации между маршрутизационными доменами.

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

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Изя Рнет, Вы писали:


ИР>>Понятие существует, да. Которое описывает определенные функции. Так вот, должно быть нечто, что выполнит эти функции через "OSI-интернет" для двух сетей на разных континентах. Поэтому надо либо сделать либо реальный subnetwork, либо виртуальный, что и означает туннелирование в конечном итоге.

V>Этим "нечто" является ПО по организации логических подсетей. Логическая подсеть и так всегда виртуальна (совпадение с физической подсеткой может быть случайным ), почему я и говорю, что аналог туннелирования заложен в OSI-модель изначально.

Туннелирование "заложено" во все что угодно. Ничто, подчеркиваю, ничто, не мешает трактовать payload любого протокола, как PDU любого другого протокола. Ничто, кроме глупой схоластики про Священные Уровни.

На самом деле, конечно, это все растет от некоторого непонимания, что OSIRM — она про функции и интерфейсы между ними, а не про пакетную инкапсуляцию, а инкапсуляция, совпадающая с уровнями OSI — это иногда так, а иногда не так. Есть это понимать, то все противоречия снимаются, но заодно и исчезает всякая польза от самой модели.

V>>> Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

ИР>>Что это каша? IDRP выполяет функции распространения маршрутной информации между маршрутизационными доменами.

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

Ну да.

И чего? Где итог? Где неоспоримое доказательство преимуществ OSI-стека над IP-стеком в деле организации VPN?

Здравствуйте, Изя Рнет, Вы писали:


ИР>И чего? Где итог? Где неоспоримое доказательство преимуществ OSI-стека над IP-стеком в деле организации VPN?

IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
— фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата
— ограниченная система адресации.
— мало того, что ограниченная, так еще и избыточная, в том смысле, что на сетевом уровне требуется только номер сети.
— приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.
— в итоге невозможно развивать сам протокол и систему адресации, не рискуя сделать неработоспособными ВСЕ приложения, использующие IP, т.е. вариант "просто пропатчить OS до новой версии протокола" не прокатит. В ближайшие 5-10 лет будет очччень болезненный переход на IPv6.

Если читать топик с начала, то основная критика была именно из-за сильной связанности как самого семейства протоколов, так и зависимости приложений от этого протокола. Собственно, разработчики модели OSI утверждают, что модель разрабатывалась именно с целью ослабления связей м/у уровнями. Такое положение вещей позволяет в модели OSI прозрачно вкладывать транспортные и сетевые протоколы друг в друга (да хоть стократное туннелирование). Для сравнения, IP VPN живёт только в IP-сетях, ибо полностью ограничивается спецификой IP-протокола, начиная от формата пакета и далее по списку, что было уже перечисленно.

Здравствуйте, vdimas, Вы писали:

V> Для сравнения, IP VPN живёт только в IP-сетях, ибо полностью ограничивается спецификой IP-протокола, начиная от формата пакета и далее по списку, что было уже перечисленно.

Ай, ай. L2TP, PPPoE, наверно, мне и миллионам использующих их пользователей приснились, потому что "IP VPN живёт только в IP-сетях".

V>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

А что, любая должна использовать все?
Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

V>- ограниченная система адресации.
V>- мало того, что ограниченная, так еще и избыточная, в том смысле, что на сетевом уровне требуется только номер сети.

Когда IPv4 вводился, 32 бита было типичным машинным словом реального компьютера (не мини/микро), и эта избыточность уже никого не волновала. Сейчас шинные передачи по 64-128 байт — норма процессоростроения, 16 байт адреса IPv6 по сравнению с этим — меньше чиха. Ну не мелочится никто за такими крохами.

V>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.

Приложения уже давно отвязаны, кто хотел. API независимое от размера адреса и прочих деталей уже 10 лет как стабилизировалось.

V>- в итоге невозможно развивать сам протокол и систему адресации, не рискуя сделать неработоспособными ВСЕ приложения, использующие IP, т.е. вариант "просто пропатчить OS до новой версии протокола" не прокатит. В ближайшие 5-10 лет будет очччень болезненный переход на IPv6.

Это вина не авторов протоколов, а тех, кто живёт в 80-х годах и не хочет писать по-новому. Я не верю в приложение, которое само работает с сетью и за 10 лет не развивалось ни разу.

V>Если читать топик с начала, то основная критика была именно из-за сильной связанности как самого семейства протоколов, так и зависимости приложений от этого протокола. Собственно, разработчики модели OSI утверждают, что модель разрабатывалась именно с целью ослабления связей м/у уровнями. Такое положение вещей позволяет в модели OSI прозрачно вкладывать транспортные и сетевые протоколы друг в друга (да хоть стократное туннелирование).

90% приложений хотят чтобы отрабатывался URL и был потоковый сокет. Всё остальное — проблемы ОС.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Изя Рнет, Вы писали:

ИР>>И чего? Где итог? Где неоспоримое доказательство преимуществ OSI-стека над IP-стеком в деле организации VPN?

V>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

В этом есть маленький плюс: можно полагаться, что IS-IS и ES-IS пакеты (NLPID 0x83, 0x82) не придут к нам из-за роутера — от этого произрастает некоторая [довольно сомнительная] секурность. И большие минусы: из-за отдельного формата заголовка возникает совершенно глупая пляска с IIH трех (!) типов в IS-IS, и невозможно сложные и ненадежные процедуры area partition repair в том же IS-IS — нет ни одной реализации, которая поддерживала бы partition repair. И это очень обидно, поскольку IS-IS — единственная грамотно спроектированная часть OSI-стека (поэтому и дожившая до наших дней).

V>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.

Это вопрос к API, а не к протоколу.

V>- в итоге невозможно развивать сам протокол и систему адресации, не рискуя сделать неработоспособными ВСЕ приложения, использующие IP, т.е. вариант "просто пропатчить OS до новой версии протокола" не прокатит. В ближайшие 5-10 лет будет очччень болезненный переход на IPv6.

Будет. Болезненный. Не в последнюю очередь из-за приложений, к которым IPv4 прибит гвоздями. Но и не в первую.

V>Если читать топик с начала, то основная критика была именно из-за сильной связанности как самого семейства протоколов, так и зависимости приложений от этого протокола. Собственно, разработчики модели OSI утверждают, что модель разрабатывалась именно с целью ослабления связей м/у уровнями.

Доослаблялись. OSI-модель и OSI-стек, как воплощение этой модели — яркий пример оверинжиниринга кроме маленького куска всего стека, где ISO-шная амбивалентность пришлась ко двору.

V>Такое положение вещей позволяет в модели OSI прозрачно вкладывать транспортные и сетевые протоколы друг в друга (да хоть стократное туннелирование).

Это везде так.

V>Для сравнения, IP VPN живёт только в IP-сетях

Ась?

А, ну да, конечно. Поскольку не-IP сетей в жизни [почти] не осталось, то IP VPN живет только в IP-сетях. В этом смысле да, правда. А вообще ахинея.

Здравствуйте, netch80, Вы писали:


V>>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

N>А что, любая должна использовать все?
N>Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

Антинаучная ерунда. Есть такие вещи — конечные цифровые автоматы. Простые цифровые автоматы (а требуются очень простые для парсинга PDU большинства современных протоколов, особенно семейства IP) способны работать на тактовых частотах до нескольких гигагерц (до десяти и выше), и еще учтём, что автомат оперирует как минимум байтами, а не битами. Ну и самое главное — конечному автомату глубоко плевать на схожесть различных PDU, просто чем разнообразнее PDU, тем больше "несклеиваемых" конечных состояний автомата. В общем, экономию на лишней десятке состояний трудно считать за аргумент.


N>90% приложений хотят чтобы отрабатывался URL и был потоковый сокет. Всё остальное — проблемы ОС.

Именно, об этом говорил неоднократно в этом топике.

Здравствуйте, Изя Рнет, Вы писали:

ИР>Доослаблялись. OSI-модель и OSI-стек, как воплощение этой модели — яркий пример оверинжиниринга кроме маленького куска всего стека, где ISO-шная амбивалентность пришлась ко двору.

Какого именно куска? Например, физический и канальный, разбиение канального уровня на два слоя с разными ролями, их связь и типичные сценарии взаимодействия — это классика, которой отвечают практически все современные канальные протоколы (Ethernet, Token Ring, FDDI, LLC, X.25, ISDN).

Сетевой уровень самый сложный, абстрактный и т.д. Но это, ИМХО, от того, что IP стал популярнее, и другие альтернативы лишились как внимания, так и банального бабла. Напомню, что первые RFC относительно семейства IP были тоже не ахти (мягко сказано).

Тем не менее, в стек от OSI медленно, но верно вкладывают бабло:

Этот стек протоколов поддерживает правительство США в своей программе GOSIP. Все компьютерные сети, устанавливаемые в правительственных учреждениях после 1990 года, должны либо непосредственно поддерживать стек OSI, либо обеспечивать средства для перехода на этот стек в будущем. Тем не менее, стек OSI более популярен в Европе, а не в США, так как в Европе меньше установлено старых сетей, использующих свои собственные протоколы.

Здравствуйте, vdimas, Вы писали:

N>>А что, любая должна использовать все?
N>>Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

V>Антинаучная ерунда. Есть такие вещи — конечные цифровые автоматы. Простые цифровые автоматы (а требуются очень простые для парсинга PDU большинства современных протоколов, особенно семейства IP) способны работать на тактовых частотах до нескольких гигагерц (до десяти и выше), и еще учтём, что автомат оперирует как минимум байтами, а не битами. Ну и самое главное — конечному автомату глубоко плевать на схожесть различных PDU, просто чем разнообразнее PDU, тем больше "несклеиваемых" конечных состояний автомата. В общем, экономию на лишней десятке состояний трудно считать за аргумент.

Вы это циске расскажите. Которая рассказывает на своей практике то же, что я — что любые подобные автоматы недопустимо усложняют построение маршрутизаторов.

Или покажите от другого производителя маршрутизатор той же производительностью и ценою хотя бы в две цискиных.

N>>90% приложений хотят чтобы отрабатывался URL и был потоковый сокет. Всё остальное — проблемы ОС.
V>Именно, об этом говорил неоднократно в этом топике.

Вот только не надо изображать это так, будто я подтверждаю Вашу точку зрения.:)

Интересно то, что прямо на поставленный вопрос никто отвечать не возжелал, а только развели базар на тему "кому это нужно, что тебе не нравится?" вместо того, чтобы помочь...

По причине бесперспективности . Даже если сделать, никто кроме энтузиастов пользоваться не будет. Я тут недавно с сетевыми протоколами плотно работал, похожая задача стояла. Альтернатив TCP — сотни. И заточенные под десятигигабитки, и под минимальное время отклика, и под... много вообщем. Мало кто ими пользуется.

Покопался в реализации TCP во FreeBSD. Почитал мануали. Разобрал несколько open-source протоколов. Сделал несколько своих моделей. Там, вообщем, не все так просто . Много математики, нюансов работы уже существующих сетей которые надо учитывать, нюансы взаимодействия с ethernet под операционной системой...

Над этим институты годами бьются, и успехов пока не ахти. Смысл 'по фану' этим заниматься?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Изя Рнет, Вы писали:

ИР>>Доослаблялись. OSI-модель и OSI-стек, как воплощение этой модели — яркий пример оверинжиниринга кроме маленького куска всего стека, где ISO-шная амбивалентность пришлась ко двору.

V>Какого именно куска?

Протокола IS-IS. Который до сегодняшнего дня жив, здоров и широко используется для маршрутизации IP.

V>Сетевой уровень самый сложный, абстрактный и т.д. Но это, ИМХО, от того, что IP стал популярнее, и другие альтернативы лишились как внимания, так и банального бабла. Напомню, что первые RFC относительно семейства IP были тоже не ахти (мягко сказано).

IP стал популярней потому что решал конкретные проблемы, а не реализовывал абстракции, придуманные full time заседателями комитетов по стандартизации.

V>Тем не менее, в стек от OSI медленно, но верно вкладывают бабло:
V>

V>Этот стек протоколов поддерживает правительство США в своей программе GOSIP. Все компьютерные сети, устанавливаемые в правительственных учреждениях после 1990 года, должны либо непосредственно поддерживать стек OSI, либо обеспечивать средства для перехода на этот стек в будущем. Тем не менее, стек OSI более популярен в Европе, а не в США, так как в Европе меньше установлено старых сетей, использующих свои собственные протоколы.

Хи-хи-хи. Вы б еще выкопали нормативный документ 19-го века о дизайне котлов паровозов.

Действительно GOSIP был, формально не отменен, но на него все забили болт и то же самое правительство США замечательно покупает и использует оборудование, которое кроме IP ничего другого не умеет.

Единственное место, где в реальной жизни можно встретить OSI-стек в полном его воплощении (с CLNP, TP*, CMIP и прочими радостями жизни) — это внутренний OAM SDH-сетей некоторых производителей. Да и то, это все переходит на IP, а где еще нет, там просто туннелируется через IP-сети.

Всё. OSI-стек RIP. И к жизни никогда не возвратится. Реализаций, которые могли бы его роутить хоть на каких-нибудь приемлимых на сегодня скоростях не существует. И уже не появится.

А сама модель так и останется моделью сферического коня в вакууме.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, netch80, Вы писали:


V>>>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>>>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

N>>А что, любая должна использовать все?
N>>Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

V>Антинаучная ерунда. Есть такие вещи — конечные цифровые автоматы. Простые цифровые автоматы (а требуются очень простые для парсинга PDU большинства современных протоколов, особенно семейства IP) способны работать на тактовых частотах до нескольких гигагерц (до десяти и выше), и еще учтём, что автомат оперирует как минимум байтами, а не битами. Ну и самое главное — конечному автомату глубоко плевать на схожесть различных PDU, просто чем разнообразнее PDU, тем больше "несклеиваемых" конечных состояний автомата. В общем, экономию на лишней десятке состояний трудно считать за аргумент.

Поскольку речь шла именно о форматах ISO-стека, то в данном конкретном случае я соглашусь. Там всего три типа пакета:
ES-IS, IS-IS и CLNP, которые различаются по первому байту. ES-IS и IS-IS — контрольные и поэтому однозначно отправляются заинтересованному процессу. В форвардинговый путь идет только CLNP, а у него адрес начинается с фиксированного смещения. Поэтому в данном случае много типов пакетов и, соответственно, заголовков — само по себе не проблема.

Проблема в самом NSAP адресе. В лучших традициях design by committee он очень гибкий, переменной длины, все его части переменной длины. Без знания (и реализации в роутере!) конкретных правил назначения адресов во всех частях адресного пространства иерархический роутинг просто невозможен. Поэтому все конкретные реализации наложили определенные ограничения на формат адреса и его составных частей.

Здравствуйте, Изя Рнет, Вы писали:

V>>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.
ИР>Это вопрос к API, а не к протоколу.

То есть, на самом деле c IP-протоколами всё в порядке, а всё дело испортили подлые разработчики клиентских API?

Здравствуйте, eugals, Вы писали:

E>Здравствуйте, Изя Рнет, Вы писали:

V>>>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.
ИР>>Это вопрос к API, а не к протоколу.

E>То есть, на самом деле c IP-протоколами всё в порядке, а всё дело испортили подлые разработчики клиентских API?

С IP в порядке не все. Но данная проблема — это проблема API, а не протокольного стека.

Здравствуйте, <Аноним>, Вы писали:

E>>То есть, на самом деле c IP-протоколами всё в порядке, а всё дело испортили подлые разработчики клиентских API?

А>С IP в порядке не все. Но данная проблема — это проблема API, а не протокольного стека.
А нельзя ли было её решить уже при проектировании стека протоколов, чтобы у API-писателей просто не было ни одного шанса создать проблемы будущему развитию этих протоколов?