Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 13
Я прошу прощения, это случайно не алгоритм Беллмана-Форда? И на его основе построенный дистанционно-векторный протокол RIP 1969 года, где "волновой поиск в сторону УП" реализован методом разделения горизонта. Или его развитие - проприетарный EIGRP, где в метрику входят (или могут входить): полоса пропускания, задержка, надежность, загруженность и даже MTU. Непонятно почему протоколы состояния канала (link-state), к которым относятся OSPF, ISIS назвали "методом рельефа", которые действительно знают всю топологию для выполнения алгоритма Дейкстры локально на каждой ноде, но им не нужен центральный "сетевой администратор", они слушают LSA. У каждого типа протоколов маршрутизации есть свои плюсы и минусы. Дистанционно-векторные протоколы имеют крупные изъяны - они слишком медленно сходятся на больших топологиях и слишком многословны в обмене между нодами просто по своему дизайну. При флапах каналов, что происходит сплошь и рядом, волна просто не успевает сходиться и получаются петли маршрутизации со всеми вытекающими, потому от них отказались уже очень давно.
Нет, тут алгоритм обхода в ширину. Его еще как раз называют волновым алгоритмом иногда.
Здравствуйте! Спасибо, что обратили внимание на мою статью. Дело в том, что в прошлом до 1995г.я был одним из ведущих инженеров-конструкторов большой специальной информационной системы СССР и до сих пор живу её проблемами. Одна из этих проблем состояла в том, что меня попросили дать ответ на вопрос: а что будет, если узел А не будет иметь служебной информации о состоянии связи с узлом Б, но узлу А для принятия решений обязательно нужно знать есть-ли какая-то связь с Б. Я долго думал и предложил решение, которое оформил в виде заявки на «способ выбора оптимального пути в сети коммутации сообщений».
1970 год. Холодная война в разгаре, «железный занавес». У них там появляются понятия сеть передачи данных, маршрутизация, пакеты, коммутация пакетов, модель ВОС, сетевой уровень и т.п. ,и т.д. А у нас известны понятия коммутация каналов и коммутация сообщений, и аналог маршрута-путь. У них, как сейчас стало известно, создаётся ARPANET, а у нас функционирует (я-живой свидетель) и модернизируется нечто такое же. Нам неизвестно, что у них- им, надеюсь ,неизвесно, что у нас ( я не имею ввиду 90-е). Выдано в закрытом доступе авторское св-во с условным названием «способ автоматической коммутации сообщений», Это я думал, что попутно я впервые изобрёл, как это сейчас названо в википедии , волновой метод маршрутизации. Как мне намекают это далеко как не так ( ну и что? ).Похоже, что в Комитете по изобретениям что-то знали , «что там у них», и дали правильную юридическую интерпретацию моей заявке.
Как к.т.н. по специальности 20.00.12 , как отнюдь не специалист по сетевым технологиям на так называемом сетевом уровне, имею возможно существенные отличия моих понятий от тех понятий, с которыми оперируете Вы. Это:
1. То, что изобретено мною следует называть поисковый метод, ибо его основа это запрос в сеть для поиска оптимального пути, который можно осуществлять и последовательным перебором (при известной топологии) возможных путей, но за длительное время, я же предложил делать это принципиально децентрализованно передачей известной к тому времени волны. Волна здесь всего лишь один из инструментов реализации поиска. Запрос - это всеми обожаемый пакет или в моём понимании относительно короткое сообщение.
2. Поисковый ( он же и волновой (см. ссылку в википедии )) метод для меня тоже всего лишь инструмент для решения задачи распределения информации (см.ссылку в тексте) на так называемом прикладном уровне.
3. В изобретении 73730 метод предложен в одноадресной интерпретации. В тексте статьи предложено создавать в узлах на так называемом прикладном уровне динамически обновляемые списки (синоним таблицы) кратчайших маршрутов, т.е. фактически в сети передачи данных создать сети кратчайших маршрутов с определёнными требованиями от Заказчика информационной сети и потом их использовать для решения задач оптимизации, через инструмент под названием многоадресный запрос.
4.Отвечу на возможный вопрос почему я выбрал хаб сетевые технологии. Во-первых, ответ в п.п.2, почему бы и нет, просто других ,как я называю «кибернетических», в перечне не нашёл. Во-вторых, хочу посмотреть не появятся-ли сторонники моего подхода. В-третьих, считаю, что за этим будущее и его нужно бесплатно передать молодым, может кому-то пригодится.
5.И простите немного по поводу конкретных вопросов. Не согласен, что метод изложен не чётко. В статье в задаче №1 приведён один из возможных ,как говорится «навскидку», вариантов
Здравствуйте! Спасибо, что обратили внимание на мою статью. Дело в том, что в прошлом до 1995г.я был одним из ведущих инженеров-конструкторов большой специальной информационной системы СССР и до сих пор живу её проблемами. Одна из этих проблем состояла в том, что меня попросили дать ответ на вопрос: а что будет, если узел А не будет иметь служебной информации о состоянии связи с узлом Б, но узлу А для принятия решений обязательно нужно знать есть-ли какая-то связь с Б. Я долго думал и предложил решение, которое оформил в виде заявки на «способ выбора оптимального пути в сети коммутации сообщений».
1970 год. Холодная война в разгаре, «железный занавес». У них там появляются понятия сеть передачи данных, маршрутизация, пакеты, коммутация пакетов, модель ВОС, сетевой уровень и т.п. ,и т.д. А у нас известны понятия коммутация каналов и коммутация сообщений, и аналог маршрута-путь. У них, как сейчас стало известно, создаётся ARPANET, а у нас функционирует (я-живой свидетель) и модернизируется нечто такое же. Нам неизвестно, что у них- им, надеюсь ,неизвесно, что у нас ( я не имею ввиду 90-е). Выдано в закрытом доступе авторское св-во с условным названием «способ автоматической коммутации сообщений», Это я думал, что попутно я впервые изобрёл, как это сейчас названо в википедии , волновой метод маршрутизации. Как мне намекают это далеко как не так ( ну и что? ).Похоже, что в Комитете по изобретениям что-то знали , «что там у них», и дали правильную юридическую интерпретацию моей заявке.
Как к.т.н. по специальности 20.00.12 , как отнюдь не специалист по сетевым технологиям на так называемом сетевом уровне, имею возможно существенные отличия моих понятий от тех понятий, с которыми оперируете Вы. Это:
1. То, что изобретено мною следует называть поисковый метод, ибо его основа это запрос в сеть для поиска оптимального пути, который можно осуществлять и последовательным перебором (при известной топологии) возможных путей, но за длительное время, я же предложил делать это принципиально децентрализованно передачей известной к тому времени волны. Волна здесь всего лишь один из инструментов реализации поиска. Запрос - это всеми обожаемый пакет или в моём понимании относительно короткое сообщение.
2. Поисковый ( он же и волновой (см. ссылку в википедии )) метод для меня тоже всего лишь инструмент для решения задачи распределения информации (см.ссылку в тексте) на так называемом прикладном уровне.
3. В изобретении 73730 метод предложен в одноадресной интерпретации. В тексте статьи предложено создавать в узлах на так называемом прикладном уровне динамически обновляемые списки (синоним таблицы) кратчайших маршрутов, т.е. фактически в сети передачи данных создать сети кратчайших маршрутов с определёнными требованиями от Заказчика информационной сети и потом их использовать для решения задач оптимизации, через инструмент под названием многоадресный запрос.
4.Отвечу на возможный вопрос почему я выбрал хаб сетевые технологии. Во-первых, ответ в п.п.2, почему бы и нет, просто других ,как я называю «кибернетических», в перечне не нашёл. Во-вторых, хочу посмотреть не появятся-ли сторонники моего подхода. В-третьих, считаю, что за этим будущее и его нужно бесплатно передать молодым, может кому-то пригодится.
5.И простите немного по поводу конкретных вопросов. Не согласен, что метод изложен не чётко. В статье в задаче №1 приведён один из возможных ,как говорится «навскидку», вариантов алгоритма обработки многоадресного запроса. Комментаторы сознательно или бессознательно ставят знак равенства между понятиями метод и алгоритм. Алгоритм –это одна из возможных реализаций метода, а реализация алгоритма, написанная на понятном компьютере языке-это программа. Я не напрасно начинаю статью с терминологии, а то можно говорить одно и то же, но не понимать друг друга. В частности непонятно замечание, что в статье нет упоминания о таблицах маршрутизации. Есть, но это названо списком. Или возьмём этот товарный знак Интернета-коммутация пакетов. Не умеете надёжно передавать всю книгу? Рвёте на страницы? Разумно. Но причём здесь коммутация. Есть всего два вида коммутации: коммутация через физический контакт и коммутация через переприём в накопителях. И подгоняют под это всякую аргументацию.
Алгоритм изложен фрагментарно, многое оставлено за бортом, так как мне это показалось несущественным и вообще подлежащим разработке при взятии метода на вооружение. Если кому-то что-то неясно и возникают вопросы, то может лучше научиться самим отвечать на них (что я с удовлетворением и заметил), чтобы за деревьями увидеть лес. В целом у меня нет сомнений в реальности алгоритма. Могу сказать, что запрос в сети существует до тех пор, пока в сети есть хотя бы одна его копия хотя бы с одним «необслуженным» ( см.текст ) адресом. Особый случай, когда копия ходит в сети и не находит адресат потому, что к нему нет пути. Тогда в системе для прерывания процесса должен использоваться фактор времени, например, заданием времени поиска самого длительного (например, в СДВ диапазоне ) пути.
Получилась опять чуть-ли не статья, хватит здоровья придётся ещё написать.
Ещё раз спасибо за комментарии, за повышение моего уровня знаний. И прошу, как говорят классики, »понять и простить». В оценках можно не стесняться. Хабр для меня не площадка для карьеры, а площадка для пропаганды. Еретик? На дыбу, в костёр? Ату его!
Здравствуйте, есть несколько вопросов, метод в статье изложен не достаточно четко и формально.
Если все узлы посылают поисковую посылку по всем портам, то как предотвращается бесконечные хождения по циклу? Каждый узел должен помнить из какого начала посылки он уже получал, чтобы не ретранслировать их второй раз? Но как тогда можно будет найти два маршрута из узла 8 в узел 7, ведь все маршруты пройдут через узел 5? Значит, логика еще сложнее: надо помнить сколько посылок было получено и пропускать ровно столько первых, сколько маршрутов нужно?
Или у посылки есть счетчик переходов, чтобы ограничить максимальное количество прыжков фиксированным числом?
Из вашего текста похоже, что все узлы дописывают свой идентификатор в поисковую посылку, чтобы искомый узел смог понять кратчайшие маршруты. Хорошо. Но никого упоминания таблицы маршрутизации нет. Значит ли, что для маршрутизации данных весь путь должен записываться в пакете?
Здравствуйте! Спасибо, что обратили внимание на мою статью. Дело в том, что в прошлом до 1995г.я был одним из ведущих инженеров-конструкторов большой специальной информационной системы СССР и до сих пор живу её проблемами. Одна из этих проблем состояла в том, что меня попросили дать ответ на вопрос: а что будет, если узел А не будет иметь служебной информации о состоянии связи с узлом Б, но узлу А для принятия решений обязательно нужно знать есть-ли какая-то связь с Б. Я долго думал и предложил решение, которое оформил в виде заявки на «способ выбора оптимального пути в сети коммутации сообщений».
1970 год. Холодная война в разгаре, «железный занавес». У них там появляются понятия сеть передачи данных, маршрутизация, пакеты, коммутация пакетов, модель ВОС, сетевой уровень и т.п. ,и т.д. А у нас известны понятия коммутация каналов и коммутация сообщений, и аналог маршрута-путь. У них, как сейчас стало известно, создаётся ARPANET, а у нас функционирует (я-живой свидетель) и модернизируется нечто такое же. Нам неизвестно, что у них- им, надеюсь ,неизвесно, что у нас ( я не имею ввиду 90-е). Выдано в закрытом доступе авторское св-во с условным названием «способ автоматической коммутации сообщений», Это я думал, что попутно я впервые изобрёл, как это сейчас названо в википедии , волновой метод маршрутизации. Как мне намекают это далеко как не так ( ну и что? ).Похоже, что в Комитете по изобретениям что-то знали , «что там у них», и дали правильную юридическую интерпретацию моей заявке.
Как к.т.н. по специальности 20.00.12 , как отнюдь не специалист по сетевым технологиям на так называемом сетевом уровне, имею возможно существенные отличия моих понятий от тех понятий, с которыми оперируете Вы. Это:
1. То, что изобретено мною следует называть поисковый метод, ибо его основа это запрос в сеть для поиска оптимального пути, который можно осуществлять и последовательным перебором (при известной топологии) возможных путей, но за длительное время, я же предложил делать это принципиально децентрализованно передачей известной к тому времени волны. Волна здесь всего лишь один из инструментов реализации поиска. Запрос - это всеми обожаемый пакет или в моём понимании относительно короткое сообщение.
2. Поисковый ( он же и волновой (см. ссылку в википедии )) метод для меня тоже всего лишь инструмент для решения задачи распределения информации (см.ссылку в тексте) на так называемом прикладном уровне.
3. В изобретении 73730 метод предложен в одноадресной интерпретации. В тексте статьи предложено создавать в узлах на так называемом прикладном уровне динамически обновляемые списки (синоним таблицы) кратчайших маршрутов, т.е. фактически в сети передачи данных создать сети кратчайших маршрутов с определёнными требованиями от Заказчика информационной сети и потом их использовать для решения задач оптимизации, через инструмент под названием многоадресный запрос.
4.Отвечу на возможный вопрос почему я выбрал хаб сетевые технологии. Во-первых, ответ в п.п.2, почему бы и нет, просто других ,как я называю «кибернетических», в перечне не нашёл. Во-вторых, хочу посмотреть не появятся-ли сторонники моего подхода. В-третьих, считаю, что за этим будущее и его нужно бесплатно передать молодым, может кому-то пригодится.
5.И простите немного по поводу конкретных вопросов. Не согласен, что метод изложен не чётко. В статье в задаче №1 приведён один из возможных ,как говорится «навскидку», вариантов
Описываемый метод имеет принцип маршрутизации от источника (source routing): "я вам даю путь прохождения пакета, а вы - кто там по цепочке - выполняйте". На заре сетей маршрутизация от источника ещё хоть где-то применялась, например, UUCP, но этот метод регрессирует с ростом количества узлов, повышения динамичности (появлений/исчезновений) связей и хостов, прохождения маршрута через множество доменов администрирования. Да и что такое: хостовая маршрутизация в массовых сетях? Поэтому сейчас имеем везде сетевую, а не хостовую, маршрутизацию с принципом "от целевого назначение" (destination routing) - это всем известный IP.
Вообще, подход может иметь нишевое применение, скажем, в пределах домена, где админ желает иметь под жёстким контролем host-to-host передачу данных. Но сколько найдётся тех условий и сколько тех админов.
А автору в любом случае уважение за стремление к новым решениям.
Здравствуйте! Спасибо, что обратили внимание на мою статью. Дело в том, что в прошлом до 1995г.я был одним из ведущих инженеров-конструкторов большой специальной информационной системы СССР и до сих пор живу её проблемами. Одна из этих проблем состояла в том, что меня попросили дать ответ на вопрос: а что будет, если узел А не будет иметь служебной информации о состоянии связи с узлом Б, но узлу А для принятия решений обязательно нужно знать есть-ли какая-то связь с Б. Я долго думал и предложил решение, которое оформил в виде заявки на «способ выбора оптимального пути в сети коммутации сообщений».
1970 год. Холодная война в разгаре, «железный занавес». У них там появляются понятия сеть передачи данных, маршрутизация, пакеты, коммутация пакетов, модель ВОС, сетевой уровень и т.п. ,и т.д. А у нас известны понятия коммутация каналов и коммутация сообщений, и аналог маршрута-путь. У них, как сейчас стало известно, создаётся ARPANET, а у нас функционирует (я-живой свидетель) и модернизируется нечто такое же. Нам неизвестно, что у них- им, надеюсь ,неизвесно, что у нас ( я не имею ввиду 90-е). Выдано в закрытом доступе авторское св-во с условным названием «способ автоматической коммутации сообщений», Это я думал, что попутно я впервые изобрёл, как это сейчас названо в википедии , волновой метод маршрутизации. Как мне намекают это далеко как не так ( ну и что? ).Похоже, что в Комитете по изобретениям что-то знали , «что там у них», и дали правильную юридическую интерпретацию моей заявке.
Как к.т.н. по специальности 20.00.12 , как отнюдь не специалист по сетевым технологиям на так называемом сетевом уровне, имею возможно существенные отличия моих понятий от тех понятий, с которыми оперируете Вы. Это:
1. То, что изобретено мною следует называть поисковый метод, ибо его основа это запрос в сеть для поиска оптимального пути, который можно осуществлять и последовательным перебором (при известной топологии) возможных путей, но за длительное время, я же предложил делать это принципиально децентрализованно передачей известной к тому времени волны. Волна здесь всего лишь один из инструментов реализации поиска. Запрос - это всеми обожаемый пакет или в моём понимании относительно короткое сообщение.
2. Поисковый ( он же и волновой (см. ссылку в википедии )) метод для меня тоже всего лишь инструмент для решения задачи распределения информации (см.ссылку в тексте) на так называемом прикладном уровне.
3. В изобретении 73730 метод предложен в одноадресной интерпретации. В тексте статьи предложено создавать в узлах на так называемом прикладном уровне динамически обновляемые списки (синоним таблицы) кратчайших маршрутов, т.е. фактически в сети передачи данных создать сети кратчайших маршрутов с определёнными требованиями от Заказчика информационной сети и потом их использовать для решения задач оптимизации, через инструмент под названием многоадресный запрос.
4.Отвечу на возможный вопрос почему я выбрал хаб сетевые технологии. Во-первых, ответ в п.п.2, почему бы и нет, просто других ,как я называю «кибернетических», в перечне не нашёл. Во-вторых, хочу посмотреть не появятся-ли сторонники моего подхода. В-третьих, считаю, что за этим будущее и его нужно бесплатно передать молодым, может кому-то пригодится.
5.И простите немного по поводу конкретных вопросов. Не согласен, что метод изложен не чётко. В статье в задаче №1 приведён один из возможных ,как говорится «навскидку», вариантов
алгоритма обработки многоадресного запроса. Комментаторы сознательно или бессознательно ставят знак равенства между понятиями метод и алгоритм. Алгоритм –это одна из возможных реализаций метода, а реализация алгоритма, написанная на понятном компьютере языке-это программа. Я не напрасно начинаю статью с терминологии, а то можно говорить одно и то же, но не понимать друг друга. В частности непонятно замечание, что в статье нет упоминания о таблицах маршрутизации. Есть, но это названо списком. Или возьмём этот товарный знак Интернета-коммутация пакетов. Не умеете надёжно передавать всю книгу? Рвёте на страницы? Разумно. Но причём здесь коммутация. Есть всего два вида коммутации: коммутация через физический контакт и коммутация через переприём в накопителях. И подгоняют под это всякую аргументацию.
Алгоритм изложен фрагментарно, многое оставлено за бортом, так как мне это показалось несущественным и вообще подлежащим разработке при взятии метода на вооружение. Если кому-то что-то неясно и возникают вопросы, то может лучше научиться самим отвечать на них (что я с удовлетворением и заметил), чтобы за деревьями увидеть лес. В целом у меня нет сомнений в реальности алгоритма. Могу сказать, что запрос в сети существует до тех пор, пока в сети есть хотя бы одна его копия хотя бы с одним «необслуженным» ( см.текст ) адресом. Особый случай, когда копия ходит в сети и не находит адресат потому, что к нему нет пути. Тогда в системе для прерывания процесса должен использоваться фактор времени, например, заданием времени поиска самого длительного (например, в СДВ диапазоне ) пути.
Получилась опять чуть-ли не статья, хватит здоровья придётся ещё написать.
Ещё раз спасибо за комментарии, за повышение моего уровня знаний. И прошу, как говорят классики, »понять и простить». В оценках можно не стесняться. Хабр для меня не площадка для карьеры, а площадка для пропаганды. Еретик? На дыбу, в костёр? Ату его!
Плохая нейросеть, на все комментарии один и тот же ответ копипастит.
И опять же здравствуйте!
Что это «это»? Если это алгоритм из задачи № 1, то это похоже на моё изобретение № 73730, а моё изобретение похоже на моё изобретение.
Перехожу к Вашим понятиям.
У Вас есть понятие - сервер маршрутов? Что он делает?
Делаю выписку из Вашей многоязычной (глобалистской) интернет энциклопедии: "собирает и анализирует информацию о топологии ( я предпочитаю слово связность) сети, а затем по запросам передает ее маршрутизаторам, которые освобождены от функций создания ПРИ."
Где он находится, в каждом узле сети или в неких центрах, или в одном центре?
Скорей всего в центрах, которые раздают указания как себя вести.
А кто или что формирует эту топологию сети?
Либо естественный интеллект (человек), либо автомат. Откуда они черпают сведения? Из докладов под названием «служебная информация». Попробуйте сами оценить её объёмы и требования к её обработке. Да ещё пишут при описании функций маршрутизатора о
неких «различных сетевых топологиях».
Теперь о том, что написано в статье между строк:
Нет того, что «собирает и анализирует информацию о топологии сети». А где же оно? Да оно в сети, децентрализовано, распределено по узлам сети. Узел источник информации
получает результат работы этого децентрализованного автомата в виде списков кратчайших путей, которые учитывают не только связность, но ещё и временные характеристики.
На что это похоже? На слона в посудной лавке. А Вы мне сказки про нейросеть и искуственный интеллект.
Спасибо за публикацию. В начале 80-х у нас была базовая кафедра в вашем НИИ. В частности, Кулешов А.П. вел у нас семинары. Было очень интересно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Волновой метод маршрутизации, технические предложения по использованию