[Rutel]

Рад приветствовать сообщество специалистов в области цифровой передачи данных.

Для моего хобби проекта понадобилась система передачи данных с идеальными характеристиками 

(по хотелкам совпадает с описанием идеальной мультисервисной сети):

 

- стабильная скорость (заранее заданная)

- стабильная задержка доставки (можно даже сказать постоянная), время доставки в основном лимитируется только физической скоростью и временем распространения сигнала в среде передачи.

- быстрое время установления соединения.

- большое КПД (больше 90%) использования пропускной способности канала связи 

- отсутствие потерь данных (отброшенных данных - для уже существующих каналов)

- отсутствие влияния перегрузки канала (требуется передать больше чем физическая скорость канала) на уже передаваемые данные (нельзя только создать новое соединение)

- простота реализации различных сервисных функций (объединение, разделение физических каналов), построение альтернативных маршрутов и тд (думаю можно перечислять все хотелки не противоречащие физике и здравому смыслу)

 

Из ограничений (главные):

- нельзя получить время доставки меньше времени распространения сигнала в среде передачи.

- нельзя передать данных больше чем позволяет спецификация канала связи (предварительное сжатие функция более высокого уровня)

 

 

Результатом размышлений явилась технология (алгоритм мультиплексирования) с рабочим названием Синхронное Символьное Мультиплексирование.

Кратное описание можно прочитать в файле (в прищепке).

 

Интернет на похожие мысли не отзывается (кроме моей статьи на хабре). 

Есть описание системы в данном направлении FlexE от Хуавей FlexE ( https://e.huawei.com/en/material/networking/ne-router/34e5c5bd90ad4a588bee2d4d1310abde ), но там все примитивно и скорее это TDM/

 

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

Все компании не отвечают на письма отправляемые на их ПЯ, телефонный звонок выводит на секретаря со стандартной фразой : Пишите на ПЯ, если заинтересует, то Вам ответят.

Сходил в гости (наверное все компании в Новосибирске), удалось поговорить только с одним достаточно крупным производителем.

Если кратно : Мы не занимаемся новыми разработками и изготавливаем только то, что массово покупают.

Ответ из СибГУТИ : 

Могу уверенно ответить, что в открытом доступе о научных школах указанного направления информации нет. Можно попробовать обратиться в компанию Т8, где работают известные специалисты по современным телекоммуникациям из МГУ, МГТУ им. Баумана, ФизТеха. Они ближе всего к разработкам такого типа и их практическому внедрению. Работу по этой тематике рекомендую продолжить. При наличии патентов и публикаций в научных изданиях из списка ВАК и Scopus может потянуть на учёную степень.
 

Ответа из МГУ пока нет.

 

Прошу ответить на следующие вопросы :

- была ли изобретена похожая технология построения сети ранее.

- есть ли логические ошибки в самой основе (в кодировании и локальных алгоритмах еще есть что оптимизировать).

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

 

Прошу специалистов в коммуникационных системах написать свое мнение и отправить письмом (Rutel@Mail.ru).

Каждое письмо (написанное человеком) будет прочитано и будет дан ответ.

PS Я считаю, что отсутствие ответа (пусть даже и созданного автоматически) является неуважением к написавшему и показывает отношение адресата к своим клиентам (это про различные компании).

Синхронный интернет.pdf

Изменено 30 сентября, 2020 пользователем Rutel
ошибка в ссылке

[Ivan_83]

13 часов назад, Rutel сказал:

- нельзя получить время доставки меньше времени распространения сигнала в среде передачи.

В теории можно сократить время до половины, если излучать посредине линии запутанные кванты и на концах используя запутанность передавать чтото.

 

13 часов назад, Rutel сказал:

- стабильная скорость (заранее заданная)

- стабильная задержка доставки (можно даже сказать постоянная), время доставки в основном лимитируется только физической скоростью и временем распространения сигнала в среде передачи.

- быстрое время установления соединения.

- большое КПД (больше 90%) использования пропускной способности канала связи 

- отсутствие потерь данных (отброшенных данных - для уже существующих каналов)

- отсутствие влияния перегрузки канала (требуется передать больше чем физическая скорость канала) на уже передаваемые данные (нельзя только создать новое соединение)

- простота реализации различных сервисных функций (объединение, разделение физических каналов), построение альтернативных маршрутов и тд (думаю можно перечислять все хотелки не противоречащие физике и здравому смыслу)

И что?

Кетайский коммутатор на 100 мегабит всем пунктам удовлетворяет, кроме быстрого установления соединения, но и то только потому, что это время зависит от многих факторов за его пределами.

Если нет прототипа - говорить не о чем.

 

PS: а вы случаем новые цвета или новые звуки не открыли?)

 

[sdy_moscow]

1 час назад, Ivan_83 сказал:

если излучать посредине линии запутанные кванты и на концах используя запутанность передавать чтото

Заблуждаетесь. Передать ничего не получится. На эту тему есть несколько статей. Почитайте.

[sdy_moscow]

1 час назад, Ivan_83 сказал:

а вы случаем новые цвета или новые звуки не открыли?)

Скорее что-то вроде хPON с велосипедом.

 

ТС видимо плохо понимает характер данных передаваемых по современным сетям и неравномерность их передачи. А вопросы гарантированной передачи трафика с равномерными скоростями решали лет 50 назад, сейчас это не очень актуально - пусть смотрит решения по телефонии.

З.Ы.

Я не знаю что там за хобби-проект, но возможно человеку просто не хватило денег на гигабитный коммутатор  б/у и пару патчкордов.

[Rutel]

6 часов назад, Ivan_83 сказал:

В теории можно сократить время до половины, если излучать посредине линии запутанные кванты и на концах используя запутанность передавать чтото.

 

И что?

Кетайский коммутатор на 100 мегабит всем пунктам удовлетворяет, кроме быстрого установления соединения, но и то только потому, что это время зависит от многих факторов за его пределами.

Если нет прототипа - говорить не о чем.

 

PS: а вы случаем новые цвета или новые звуки не открыли?)

 

Пакетная коммутация хорошо (относительно) работает до момента пока загрузка канала не превысит 20% от максимальной.

Потом начинаются потери.

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

С помощью обычного коммутатора Вы сможете организовать распределенную виртуальную память без потери производительности (цикл чтения и записи не более 200 нс) - для высокопроизводительных вычислительных систем ?

И это не считая потребности в экспоненциальном числе нитей вычислительного процесса.

Сеть постепенно становится сложной, уходят те времена когда когда она использовалась для файлового доступа к одному серверу или просмотра картинок на нем.

 

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

 

5 часов назад, sdy_moscow сказал:

Скорее что-то вроде хPON с велосипедом.

 

ТС видимо плохо понимает характер данных передаваемых по современным сетям и неравномерность их передачи. А вопросы гарантированной передачи трафика с равномерными скоростями решали лет 50 назад, сейчас это не очень актуально - пусть смотрит решения по телефонии.

З.Ы.

Я не знаю что там за хобби-проект, но возможно человеку просто не хватило денег на гигабитный коммутатор  б/у и пару патчкордов.

А вы прочитали и смогли понять (простое описание в прищепке) , то что я изобрел ?

[Rutel]

19 минут назад, Rutel сказал:

Пакетная коммутация хорошо (относительно) работает до момента пока загрузка канала не превысит 20% от максимальной.

Потом начинаются потери.

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

С помощью обычного коммутатора Вы сможете организовать распределенную виртуальную память без потери производительности (цикл чтения и записи не более 200 нс) - для высокопроизводительных вычислительных систем ?

И это не считая потребности в экспоненциальном числе нитей вычислительного процесса.

Сеть постепенно становится сложной, уходят те времена когда когда она использовалась для файлового доступа к одному серверу или просмотра картинок на нем.

 

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

 

А вы прочитали и смогли понять (простое описание в прищепке) , то что я изобрел ?

Когда связисты смотрят новости им должно быть стыдно - если даже заседания правительства идут с "фризами" - это так что бы Вы не думали что уже всего достигли и дальше только эксплуатировать.

 

Хобби проект называется - процессор основанный на принципах dataflow. 

Для такого процессора пакетная сеть это натуральный тормоз.

Современная вычислительная техника это просто калькулятор, пусть весь из себя запутанный, но калькулятор.

Цитата

Я не знаю что там за хобби-проект, но возможно человеку просто не хватило денег на гигабитный коммутатор  б/у и пару патчкордов.

Если умножить  этот гигабит еще в миллиард раз то как раз и получится минимальная требуемая производительность коммутатора.

Да еще и при условии, что основные задержки передачи (90% и более), это задержка в кабеле.

Простой коммутатор работать не будет - представьте коммутатор с числом соединений до 1000 с пропускной способностью каждого канала до 1Тбит и заполнением каждого до 90% - Теперь подумайте что будет с обычным пакетным коммутатором.

Таких стоек далеко не одна.

 

Еще раз прошу - сначала прочитайте текст, гордыня это смертный грех ))))

 

7 часов назад, Ivan_83 сказал:

В теории можно сократить время до половины, если излучать посредине линии запутанные кванты и на концах используя запутанность передавать чтото.

 

И что?

Кетайский коммутатор на 100 мегабит всем пунктам удовлетворяет, кроме быстрого установления соединения, но и то только потому, что это время зависит от многих факторов за его пределами.

Если нет прототипа - говорить не о чем.

 

PS: а вы случаем новые цвета или новые звуки не открыли?)

 

Цитата

PS: а вы случаем новые цвета или новые звуки не открыли?)

Прочитайте текст из прищепке и сможете сформулировать свое обоснованное мнение.

Изменено 27 сентября, 2020 пользователем Rutel

[Rutel]

5 часов назад, sdy_moscow сказал:

Скорее что-то вроде хPON с велосипедом.

 

ТС видимо плохо понимает характер данных передаваемых по современным сетям и неравномерность их передачи. А вопросы гарантированной передачи трафика с равномерными скоростями решали лет 50 назад, сейчас это не очень актуально - пусть смотрит решения по телефонии.

З.Ы.

Я не знаю что там за хобби-проект, но возможно человеку просто не хватило денег на гигабитный коммутатор  б/у и пару патчкордов.

Прочитайте текст из прищепки - там всего 10 страниц. Сложность текста минимальная.

 

7 часов назад, Ivan_83 сказал:

В теории можно сократить время до половины, если излучать посредине линии запутанные кванты и на концах используя запутанность передавать чтото.

 

И что?

Кетайский коммутатор на 100 мегабит всем пунктам удовлетворяет, кроме быстрого установления соединения, но и то только потому, что это время зависит от многих факторов за его пределами.

Если нет прототипа - говорить не о чем.

 

PS: а вы случаем новые цвета или новые звуки не открыли?)

 

Стабильная скорость в пакетной коммутации недостижима - пакетная коммутация является принципиально асинхронной.

Потери данных, тоже определяются принципом работы сети.

[Andrei]

1 час назад, Rutel сказал:

Пакетная коммутация хорошо (относительно) работает до момента пока загрузка канала не превысит 20% от максимальной.

Потом начинаются потери.

 

54 минуты назад, Rutel сказал:

основные задержки передачи (90% и более), это задержка в кабеле.

Мне одному показалось, что какие-то странные воззрения на нынешние сети связи?

[jffulcrum]

 

 

Цитата

Общий принцип разделения достаточно прозрачен: 1. Сортируем создаваемые каналы по убыванию скорости передачи.

Откуда вы знаете скорость в начале, из астрала? В начале нет никакой скорости, более того, её вообще нет как таковой, есть статистика пост-фактум.

[nemo_lynx]

Я работаю инженером-разработчиком аппаратно-программных платформ в некотором научном учреждении.

Прочитал работу автора топика. Что могу сказать хорошего:

1. Автор желает создать что-то новое, чего до сих пор не существует. Это похвально!

2. Всё, хорошее закончилось.

Теперь о нехорошем:

1. Концепция "идеального" не может основываться на синхронности. Почему? Во-первых, синхронность - это квантование во времени. Любое квантование - это заранее жёстко заданные и в дальнейшем неустранимые временные интервалы. Как мы можем после этого говорить о минимизации задержек? Во-вторых, вокруг нас есть великолепный пример того, как строятся идеалы - вселенная, природа, макромир, микромир. Что в природе, во вселенной, в макромире или микромире реализовано как синхронное взаимодействие процессов? НИ-ЧЕ-ГО! Все процессы взаимодействуют асинхронно. Ибо это максимально эффективно. В организме автора топика, например, хоть что-нибудь функционирует строго по временным квантам? Только не надо путать циклические процессы с синхронными - это немного о разном :) .

2. Кто сказал, что идеальный способ передачи информации - это последовательный поток данных? Разве у вас одно ухо и один глаз? Уши ловят в один момент времени звук только от одного источника? Тоже самое с глазами - они сканируют/фиксируют последовательно (пусть даже и очень быстро) или воспринимают всю картину сразу целиком? Последовательный поток - это не эффективно. Даже в одном и том же оптоволокне сегодня ПАРАЛЛЕЛЬНО ведут передачу в несколько потоков на разных длинах волн - вот это эффективно! Ибо это гораздо ближе к тому, как реализовано в природе/макромире/микромире.

3. Носителем информации данных автор делает сигнал. Но сигнал - то всегда поток каких-то более элементарных частиц. Сегодня передовая наука ведёт разработки по использованию самих элементарных частиц в качестве носителей информации, а вовсе не сигналов. То есть, автор не удосужился изучить существующие передовые идеи и разрабатываемые технологии. Слышали что-то о квантовой связи? О фотонной технологии в оптике? Об идеях использовать даже нейтрино в качестве носителей битов? Что уже говорить о том, что электрический ток в проводах - это поток протонов/электронов. А единственный электрон - это уже достаточно для обозначения одного бита. И прошу заметить - поток элементарных частиц в природе всегда АСИНХРОННЫЙ.

4. Есть ещё ряд более мелких несуразностей у автора. Не буду расписывать придирки к ним. На фоне перечисленного выше это уже не важно.

Автор, пожелаю Вам не сдаваться. Прорывы всегда делают пионеры, бунтари, безумцы и просто неравнодушные люди. А у нас, как пел Владимир Семёнович: "Настоящих буйных мало, вот и нету вожаков". Но, научную работу ведут немного не так, как Вы. Попробуйте обратиться за консультацией к любому работнику ВУЗа или НИИ, имеющему любую научную степень. Вам подскажут основные НЕОБХОДИМЫЕ этапы работы.

[Rutel]

2 часа назад, jffulcrum сказал:

 

 

Откуда вы знаете скорость в начале, из астрала? В начале нет никакой скорости, более того, её вообще нет как таковой, есть статистика пост-фактум.

Цитата

Откуда вы знаете скорость в начале, из астрала?

В момент когда создается виртуальный канал (программой, телефоном, видеокамерой и тд), приложение знает требуемую скорость.

 

Если данная технология применяется как промежуточный коммутатор для пакетной сети (в синхронных сетях скорости тоже известны) происходит периодическое "редактирование" скорости и соответственно перестроение  очереди.

 

Если есть большое число локальных сетей объединяемых посредством синхронного Символьного мультиплексирования, то будет происходить постоянное редактирование скорости канала между группами локальных сетей в зависимости 

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

 

Кстати сортировать можно по приоритету (выше приоритет выше скорость).

 

Аппаратно данная сеть достаточно проста, только смысла делать образец нет.

Сделаю я его, что это покажет - покажет, что работает, это и так можно понять.

Идея организации сети очень простая, вероятность логических ошибок минимальна.

 

Кстати заметьте - получилась комбинированная сеть : передаем много или долго через виртуальный канал, мало  передаем через свободную часть пропускной способности короткими пакетами (типа АТМ).

Если если создан виртуальный канал то имеем гарантированные параметры канала (скорость ,время доставки, строгая последовательность передачи и отсутствие потерь при коммутации). По факту получили 

что то типа SDH 

Если передаем мало и редко - получается обычная пакетная сеть, со всеми ее проблемами. Но только для асинхронной (случайной) части трафика.

 

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

Есть ограничение - зарезервировать можно не больше чем есть физически (есть вероятность что весь резерв потребуется в один момент - такой ситуации боятся все финансовые организации)

Понимание что канал создан будет получено за удвоенное и точно известное время доставки до адресата (должен быть построен обратный канал и в нем будет информация по результату).

Просто идеал а не сеть.

 

 

 

Ответы для  nemo_lynx

 

Цитата

 Концепция "идеального" не может основываться на синхронности. 

Приведите пример канала, который не сможет быть создан с использованием канала с постоянной скоростью, временем доставки путем добавления дополнительных ограничений (по существу посредством не использования части исходной пропускной способности). Вообще идеал нужно рассматривать не как некую сказку с бесконечностями, а как предсказуемость свойств.

Цитата

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

Не путайте сладкое с тяжелым. Во как пример, а давайте вы будете слушать звуки в случайном порядке (задержка будет изменяться от времени да еще и местами части фразы менять)

Ближайший аналог - Вы пробовали слушать переговоры железнодорожников (на путях у них есть локальная связь через громкоговоритель)

Цитата

Носителем информации данных автор делает сигнал.

Вы ошиблись - носитель информации символ, неразрывная сущность могущая переносить больше одного бита информации.

Цитата

Есть ещё ряд более мелких несуразностей у автора. 

Перечислите пожалуйста - мне очень важно знать, что я еще пропустил.

 

 

 

Про идеал не может быть основан на квантовании - наш мир основан на квантовых эффектах.

То что наш мир не идеал, здесь я не берусь судить (другого мира не видел и из него никто не приходил).

Изменено 27 сентября, 2020 пользователем Rutel

[Sergey Gilfanov]

(прочитав сообщения) Я правильно понял, что автор утверждает, что он научился в реальном времени на сети из миллионов-миллиардов узлов решать Maximum flow problem (это про достижение максимальной пропускной способности без задержек)?

Ну так с этим алгоритмом надо не к связистом бежать, а к транспортникам-логистам. С руками оторвут и гору денег дадут, если работает.

(пошел читать файл в аттаче)

[Sergey Gilfanov]

(заметки по ходу чтения)

Мультиплексирование (разделение) канала связи....

не понял, что должно происходить, когда суммарная скорость желаемых потоков (со входных портов) больше суммарной пропускной способности канала связи на выходном порте.

 

Алгоритм разделения (мультиплексирования) физического канала канала на отдельные виртуальные каналы ... Используемые символы разделены на четыре группы: данные пользователя, управляющие символы
пользователя, служебные данные и служебные управляющие символы....Размер символа (битовая информационная емкость) не фиксирована и потенциально может быть любой. Конкретный размер символа
выбирается для каждого соединения индивидуально.

Выглядит что используемые автором "символы" более-менее соответствуют по смыслу "пакетам данных" в обычной терминологии.

 

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

Ну очень похоже на многоуровневый Token bucket алгоритм для пакетов.

 

Алгоритм создания виртуального канала. В начальный момент времени между передатчиком и приемником существует только служебный поток (ранее созданные виртуальные каналы не считаем).

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

 

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

В IPv6, в общем - это и пытаются делать. IPv6 адрес существенно "географический" в смысле топологии сети. До сих пор взлететь не может.

 

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

Который, видимо, должен знать всю топологию мирового интернета, чтобы рассчитать оптимальный маршрут. Смотри упомянутую выше flow problem. 

 

Для построения цепочек физических каналов можно использовать аналог обычных поисковых систем или DNS из современных сетей, задаем параметры пункта назначения (любой набор параметров: IP адрес тоже обычный параметр) и получаем результатом набор цепочек с альтернативными маршрутами. 

Ну или поставить какие-то специальные сервера, которые все это знают и снабжают всех желающих нужными маршрутами.

 

Для построения цепочек физических каналов можно использовать аналог обычных поисковых систем или DNS из современных сетей, задаем параметры пункта назначения (любой набор параметров: IP адрес тоже обычный параметр) и получаем результатом набор цепочек с альтернативными маршрутами.

опять, смотри выше про flow problem

 

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

Не, ну правда что ли? По обоим пунктам. Очень-очень сомнительно как про короткие сообщения так и про быструю процедуру создания виртуального канала.

 

 

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

 

 

 

 

1 час назад, Rutel сказал:

Аппаратно данная сеть достаточно проста, только смысла делать образец нет. Сделаю я его, что это покажет - покажет, что работает, это и так можно понять. Идея организации сети очень простая, вероятность логических ошибок минимальна.

Предлагаю сделать модельку, работающую не на символах, а на обычных нормальных пакетах. Собственно, не получиться ли то же самое, что SCTP пытается сделать?

 

 

 

Вообще, понятно, почему "Попытки связаться с производителями и разработчиками оборудования не увенчались успехом." Чтобы увенчались - нужна статья с горой математики, в которой доказывается, строго, что рассказываемые алгоритмы действительно делают то что делают.

[Rutel]

54 минуты назад, Sergey Gilfanov сказал:

(заметки по ходу чтения)

Мультиплексирование (разделение) канала связи....

не понял, что должно происходить, когда суммарная скорость желаемых потоков (со входных портов) больше суммарной пропускной способности канала связи на выходном порте.

 

Алгоритм разделения (мультиплексирования) физического канала канала на отдельные виртуальные каналы ... Используемые символы разделены на четыре группы: данные пользователя, управляющие символы
пользователя, служебные данные и служебные управляющие символы....Размер символа (битовая информационная емкость) не фиксирована и потенциально может быть любой. Конкретный размер символа
выбирается для каждого соединения индивидуально.

Цитата

Выглядит что используемые автором "символы" более-менее соответствуют по смыслу "пакетам данных" в обычной терминологии.

 

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

Цитата

Ну очень похоже на многоуровневый Token bucket алгоритм для пакетов.

 

Алгоритм создания виртуального канала. В начальный момент времени между передатчиком и приемником существует только служебный поток (ранее созданные виртуальные каналы не считаем).

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

 

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

В IPv6, в общем - это и пытаются делать. IPv6 адрес существенно "географический" в смысле топологии сети. До сих пор взлететь не может.

 

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

Который, видимо, должен знать всю топологию мирового интернета, чтобы рассчитать оптимальный маршрут. Смотри упомянутую выше flow problem. 

 

Для построения цепочек физических каналов можно использовать аналог обычных поисковых систем или DNS из современных сетей, задаем параметры пункта назначения (любой набор параметров: IP адрес тоже обычный параметр) и получаем результатом набор цепочек с альтернативными маршрутами. 

Ну или поставить какие-то специальные сервера, которые все это знают и снабжают всех желающих нужными маршрутами.

 

Для построения цепочек физических каналов можно использовать аналог обычных поисковых систем или DNS из современных сетей, задаем параметры пункта назначения (любой набор параметров: IP адрес тоже обычный параметр) и получаем результатом набор цепочек с альтернативными маршрутами.

опять, смотри выше про flow problem

 

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

Не, ну правда что ли? По обоим пунктам. Очень-очень сомнительно как про короткие сообщения так и про быструю процедуру создания виртуального канала.

 

 

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

 

 

 

 

Предлагаю сделать модельку, работающую не на символах, а на обычных нормальных пакетах. Собственно, не получиться ли то же самое, что SCTP пытается сделать?

Цитата

не понял, что должно происходить, когда суммарная скорость желаемых потоков (со входных портов) больше суммарной пропускной способности канала связи на выходном порте.

В сам простом случае прекращение создания виртуального канала. Отказ происходит только на этапе создания, если канал уже создан, то никакого влияния уже нет.

Модно прописать более сложное поведение. Пример :

- Все каналы требующие точно известной скорости без изменений.

- Обычные каналы понижаются в скорости пропорционально приоритету

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

Такой подход достаточно оптимален для систем массового обслуживания с большим временем передачи данных (большие расстояния) .

Для локальной системы выгоднее просто прекратить создание канала (повторный запрос на создание канала с другим маршрутом будет инициирован меньше чем через микросекундц)

 

Конкретные алгоритмы могут быть любыми и различными в различных частях сети

Цитата

Выглядит что используемые автором "символы" более-менее соответствуют по смыслу "пакетам данных" в обычной терминологии.

Основное отличие пакета от символа (или последовательности данных) не в размерах, в отсутствии адресной информации в любом ее виде. Сам по себе символ несет только информацию, но никак не идентифицирует ни источник не приемник.

Цитата

Ну очень похоже на многоуровневый Token bucket алгоритм для пакетов.

Думаю аналогия не очень правильная. Мне больше нравится сравнивать данный алгоритм с частотным мультиплексированием в аналоговой электроники.

Скорость это частота несущей. Номер строки в таблице это фаза несущей. Информационное наполнение символа - амплитуда.

Цитата

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

В IPv6, в общем - это и пытаются делать. IPv6 адрес существенно "географический" в смысле топологии сети. До сих пор взлететь не может.

Если этого не делать, то есть вероятность, что коммутатор не успеет вычислить в какой выходной поток поместить новый канал.

Для высоких скоростей канала на это будет отводиться единицы наносекунд иначе переполнение буферов, а они маленькие опять же из-за высоких скоростей

(на кристалле много не сделаешь, а за пределами не разместишь - не хватит скорости самой быстрой памяти - речь идет о десятках террабит)

Цитата

Ну или поставить какие-то специальные сервера, которые все это знают и снабжают всех желающих нужными маршрутами.

Примерно так, да еще и в пирамидальной структуре (как DNS) локальный сервер рулит своей сеткой, а если нужно наружу отправить, то запрашивает у вышестоящего.

Еще можно добавить (даже нужно) сервис редактирования уже выданных маршрутов для балансировки сети почти в реальном масштабе времени (тоже с использованием пирамиды серверов)

 

Цитата

Не, ну правда что ли? По обоим пунктам. Очень-очень сомнительно как про короткие сообщения так и про быструю процедуру создания виртуального канала.

В момент когда запрос ушел в локальное соединение (сетевой кабель), канал уже существует (можно начинать отправлять данные).

Время отправки запроса запроса  равно свободная пропускная способность деленное на размер данного запроса и размер всех ранее отправленных запросов.

Если загрузка канала не велика, то это практически мгновенно.

Весь вопрос только в том, что может случиться отказ в предоставлении канала (нет свободной пропускной способности) и узнать это возможно только через расчетное 

время. В этот момент времени должен построится обратный канал и по нему вернется отправленный запрос.

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

Для каналов с малой физической длиной кабеля и большой пропускной способностью это время будет в районе первых сотен наносекунд.

Для каналов с требованием гарантированного доступа  - лучше заранее создавать каналы и не удалять их после передачи информации (у связистов есть термин "выделенка"),

а еще лучше создавать несколько резервных каналов с не пересекающимся маршрутом (тракториста или экскаваторщика никто не отменял).

Не используемая, но зарезервированная  часть пропускной способности будет использована для передачи коротких сообщений (жалко только, что повторно зарезервировать нельзя)

Цитата

Вывод по прочтению - для соединения точка-точка (там где каналы по времени мультиплицируются) явно изобретено уже что-то существующее.

Пока не нашел - что то похожее есть у Хуавея FlexE - ссылка в самом начале.

Цитата

Про глобальную сеть - автор, по сути, предлагает коммутаторы-маршрутизаторы сделать еще более тупыми, но поставить n-ное количество серверов вычисления маршрута, которые будут по запросу оконечных устройств им эти маршруты говорить. Которые маршруты уже и будут использоваться при отправке пакетов с данными.

Да и именно так. Быстрые никогда умными не бывают - скорость это рефрекс.

Вот я и предлагаю разделить "интеллект" и "скорость".

 

Цитата

(прочитав сообщения) Я правильно понял, что автор утверждает, что он научился в реальном времени на сети из миллионов-миллиардов узлов решать Maximum flow problem (это про достижение максимальной пропускной способности без задержек)?

Ну так с этим алгоритмом надо не к связистом бежать, а к транспортникам-логистам. С руками оторвут и гору денег дадут, если работает.

(пошел читать файл в аттаче)

Думаю не так радикально.

Правильнее сказать - разделить задачу поиска маршрута на большое число отдельных задач (локальных серверов для построения маршрута)

И на высоко параллельную задачу передачи данных между миллиардами абонентов одновременно (непосредственно коммутаторы).

Цитата

Предлагаю сделать модельку, работающую не на символах, а на обычных нормальных пакетах. Собственно, не получиться ли то же самое, что SCTP пытается сделать?

Может быть и сделаю - пока времени нет.

Мне необходимо создать описание dataflow процессора, а там и размер текста (число идей) на порядок больше, да еще и обрадовать программистов тем что большинство их знаний устарело.

Думаю что это пережить будет трудно, сейчас на костре конечно не жгут, но в луддитах недостатка нет.

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

Изменено 27 сентября, 2020 пользователем Rutel

[Sergey Gilfanov]

12 минут назад, Rutel сказал:

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

Для каналов с малой физической длиной кабеля и большой пропускной способностью это время будет в районе первых сотен наносекунд.

Мы все-таки про сеть с обозримой структурой или про глобальный интернет?

Если второе - ни разу не верю. Расчет оптимального маршрута на такой огромной сети - просто офигенно сложная в смысле вычислений задача.

И вот это:

12 минут назад, Rutel сказал:

Примерно так, да еще и в пирамидальной структуре (как DNS) локальный сервер рулит своей сеткой, а если нужно наружу отправить, то запрашивает у вышестоящего.

Перестает работать, как только мы поднимается до уровня связности, грубо говоря, оператора. Когда у нас не один вышестоящий сосед, а несколько соседей. Для определения маршрута придется знать глобальную топологию. Собственно, как я понимаю, коммутация пакетов потому и выиграла, что на глобальном уровне создание каналов не очень получилось (ATM, если я правильно помню, как раз этим пыталось заниматься и успешно сдохло - смотрим на Virtual path identifier/ Virtual channel identifier )

[Rutel]

36 минут назад, Sergey Gilfanov сказал:

Мы все-таки про сеть с обозримой структурой или про глобальный интернет?

Если второе - ни разу не верю. Расчет оптимального маршрута на такой огромной сети - просто офигенно сложная в смысле вычислений задача.

И вот это:

Перестает работать, как только мы поднимается до уровня связности, грубо говоря, оператора. Когда у нас не один вышестоящий сосед, а несколько соседей. Для определения маршрута придется знать глобальную топологию. Собственно, как я понимаю, коммутация пакетов потому и выиграла, что на глобальном уровне создание каналов не очень получилось (ATM, если я правильно помню, как раз этим пыталось заниматься и успешно сдохло - смотрим на Virtual path identifier/ Virtual channel identifier )

Цитата

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

Для каналов с малой физической длиной кабеля и большой пропускной способностью это время будет в районе первых сотен наносекунд.

Думаю скоро  особой разницы локальная или глобальная  сеть особой разницы не будет.

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

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

Теоретически их не должно быть, в реальности при росте структуры будут выползать проблемы - на сегодня все что не упирается в физику почистил (даже особых ограничений на точность синхронизации нет)

Цитата

Перестает работать, как только мы поднимается до уровня связности, грубо говоря, оператора. 

эффективность работы алгоритма построения маршрута может упасть. Ну и произвол появиться - аварийные завершения каналов (своим понадобилось)

 

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

По поводу адресов (маршрутов) - найдете технологию за 1 нс вычислять маршрут (для очень большого их числа) можно будет поговорить.

А пока реальность такая (для высоких скоростей) - пока вычисляется маршрут - пакет давно уже принят и возможно переполнил буфер.

Хотя здесь я возможно сгущаю краски - для 1Тбит именно так и будет, вот куда деть сотни потоков со скоростью 1ТБит (даже один поток больше чем производительность большинства интерфейсов памяти)

Получается 1 нс - принято до двух маленьких (56 байт) IP пакетов.

Минимальный разбаланс в скоростях приема и передачи и приплыли.

 

[Sergey Gilfanov]

25 минут назад, Rutel сказал:

Думаю скоро  особой разницы локальная или глобальная  сеть особой разницы не будет.

Будет, еще какая. Достаточно посмотреть на скорости алгоритмов по той ссылке про maximum flow prolem. Они очень быстро станут просто практически невычислимыми.

А если учитывается только локальная топология - то и обычная пакетная маршрутизация неплохо работает.

 

Ну и собственно - если между приемником и получателем имеется два одинаковых непересекающихся свободных маршрута, (грубо говоря, двумя шнурками два коммутатора соединили) - то "идеальная сеть" должна использовать оба - чтобы максимальной пропускной способности добиться. Из всего что в документе описано, совершенно  неясно, как именно это получаться будет.

[Sergey Gilfanov]

Пример картинки:

Как виртуальный канал выглядеть где будет?

[Rutel]

2 минуты назад, Sergey Gilfanov сказал:

Будет, еще какая. Достаточно посмотреть на скорости алгоритмов по той ссылке про maximum flow prolem. Они очень быстро станут просто практически невычислимыми.

А если учитывается только локальная топология - то и обычная пакетная маршрутизация неплохо работает.

 

В пакетной коммутации основная проблема это ее асинхронность (пакетная коммутация принципиально асинхронный алгоритм).

Вычисление маршрутов не является проблемой способной затормозить систему связи :

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

- не оптимальная (для данного момента) конфигурация не приведет к коллапсу системы передачи данных просто немного притормозит ее и все.

 

Если посмотреть на алгоритм пакетной коммутации с точки зрения перегрузки, что происходит : объем трафика увеличивается (необходимо повторно передать все что потерялось), а потери растут геометрически при приближении к 100% загрузки.

Резко перестроить маршрут (за время сопоставимое времени передачи) при локальной перегрузке коммутатора нельзя, соответственно перегрузка сама не "рассосется"

Получается система с положительной обратной связью (чем больше потери, тем больше необходимо передать). Я пока не рассматриваю различные протокольные бантики, которые привязали что бы сгладить проблему.

За эти бантики пришлось заплатить скоростью.

 

Предлагаемый алгоритм : Отказ от создания канала приведет к необходимости повторно передать запрос и начало данных (это если мы не ожидаем окончание построения канала), а это первые десятки байт.

Если бы такой механизм был бы в пакетной коммутации, то передача пакет выглядела так:

- передали заголовок пакета 

- если сеть подтвердила обслуживание, то передали данные

- если сеть отказала в обслуживании, то вновь передали заголовок но уже другим маршрутом 

Чувствуете разницу в нагрузке на сеть ?

 

Клиент не осуществляет передачу данных (не создает виртуальный канал) при перегрузке.

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

Еще интересный момент - перегрузился какой то конкретный линк - через него медленно или вообще не будут транслировать запросы дальше в сеть и не вызовут перегрузку в следующих узлах.

В результате получается система с быстрым переключением на резервные каналы и отрицательной обратной связью по перегрузке (перегрузка вызывает уменьшение трафика).

 

4 минуты назад, Sergey Gilfanov сказал:

Пример картинки:

Как виртуальный канал выглядеть где будет?

В данном случае будет два варианта построения виртуального канала.

Как конкретно решит сервер генерирующий конкретные пути, только он сможет вычислить где эффективней прокладывать виртуальный канал.

Скорее всего будет предоставлен сортированный список, первый элемент списка наиболее оптимальный и далее по снижению эффективности (практически без ограничение на число вариантов маршрута).

При отказе сети по первому маршруты берем следующий и так по кругу (таймаут можно приделать, а можно и связаться с аварийным каналом связи - основной сервер не отвечает переходим на резервный ).

Или вообще на аварийный режим работы (проектировщики систем с жестким реальным временем и гарантированной надежностью еще те затейники).

[Sergey Gilfanov]

10 минут назад, Rutel сказал:

В данном случае будет два варианта построения виртуального канала.

Обещалось "- большое КПД (больше 90%) использования пропускной способности канала связи"

В данном случае должен быть один виртуальный канал между Src и Dst пропускной способности 2 - на картинке имелось в виду одно соединение. Как он будет выглядеть на низком уровне?

[Rutel]

3 минуты назад, Sergey Gilfanov сказал:

Обещалось "- большое КПД (больше 90%) использования пропускной способности канала связи"

В данном случае должен быть один виртуальный канал между Src и Dst пропускной способности 2 - на картинке имелось в виду одно соединение. Как он будет выглядеть на низком уровне?

Все зависит от заданных условий (свойств создаваемого канала)

Самый простой вариант (канал создается и удаляется каждый сеанс связи) :

- Делается запрос к серверу маршрутов (если от предыдущего сеанса не осталось маршрутной информации) - по существу это есть регистрация в сети.

- выбираем первый маршрут и генерируем запрос к сети на построение канала с нужной скоростью (скорость для компьютера с Фон Неймановской парадигмой понятие относительное ну пока будем снисходительны).

- Пакет уходит в сеть (используя служебную часть канала)

- Последовательно проходя коммутаторы (устройство присоединяемые к концам физического кабеля) в каждом из них резервируется минимальный буфер (3 символа минимум - определяется частью заголовка который позволит определить скорость и физический номер номер интерфейса куда необходимо направить создаваемый виртуальный канал). Ну или размером пакета для передачи коротких сообщений.

- как только пакет с запросом ушел в конкретный физический интерфейс, поток в нем перестраивается и уже содержит выделенный виртуальный канал с нужной скоростью, в который отправляются данные из буфера принадлежащего  данному каналу(при приеме также)

- как только пакет с запросом добирается к адресату, то прикрепляет его в своему входному и выходному  буферу и отправляет запрос назад в сеть (аналогичным образом строится обратный канал - кстати не обязательно тем же путем.)

 

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

В данном сценарии задействовано минимум ресурсов системы.

 

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

Канал не удаляется, если нет передачи данных. В него отправляются символы отсутствия данных, которые могу быть заменены промежуточными коммутаторами на необходимые для него данные  (служебные данные, короткие сообщения и тд), таким образом зарезервированный канал (канал создан а передачи нет) не вызывает снижение КПД (используется для передачи асинхронных данных). Единственный минус это расход ресурса буферов в промежуточных коммутаторах и резерва физического канала передачи данных. 

Предельный КПД для символа размером 100 бит - 98% (линейное символьное кодирование не учитывается)

 

[Sergey Gilfanov]

1 минуту назад, Rutel сказал:

Все зависит от заданных условий (свойств создаваемого канала)

Не, как оно будет выглядеть уже после построения всех маршрутов. Видно же, что в данном случае для получения пропускной способности 2 нужно использовать и верхний и нижний путь одновременно. Как это обеспечивается?

 

4 минуты назад, Rutel сказал:

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

А так же как обрабатывается отказ уже после построения каналов? Где и кто определяет, какой кусок уже переданных данных нужно заново послать, а какой уже у получателя есть?

[Ivan_83]

15 часов назад, sdy_moscow сказал:

Заблуждаетесь. Передать ничего не получится. На эту тему есть несколько статей. Почитайте.

Мне казалось я тоже что то читал про это.

Впрочем, я не "частотный трейдер" и мне как то похер :)

 

15 часов назад, sdy_moscow сказал:

Скорее что-то вроде хPON с велосипедом.

Про новые цвета - это был намёк на проблемы в области психиатрии.

Судя по гиперактивности это оно и есть :)

[Ivan_83]

10 часов назад, Rutel сказал:

Пакетная коммутация хорошо (относительно) работает до момента пока загрузка канала не превысит 20% от максимальной.

Странно, не замечал такого в реальном мире.

 

10 часов назад, Rutel сказал:

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

Вероятно вам кажется, то что я смотрю редко притормаживает/заикается.

 

10 часов назад, Rutel сказал:

С помощью обычного коммутатора Вы сможете организовать распределенную виртуальную память без потери производительности (цикл чтения и записи не более 200 нс) - для высокопроизводительных вычислительных систем ?

Не моя область.

 

10 часов назад, Rutel сказал:

И это не считая потребности в экспоненциальном числе нитей вычислительного процесса.

Не ваша область.

 

10 часов назад, Rutel сказал:

Сеть постепенно становится сложной, уходят те времена когда когда она использовалась для файлового доступа к одному серверу или просмотра картинок на нем.

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

 

10 часов назад, Rutel сказал:

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

Именно поэтому если вы хотите чтобы ваша поделка дошла до конечных потребителей вам нужно будет сжечь как минимум пару ярдов зелени - задонатить их производителям, чтобы они это бесплатно встроили. Во всех остальных случаях это не интересно.

 

И я согласен с немо, что синхронность = говно. Она проканывает в точка-точка на коротких расстояниях, во всех остальных применениях она сосёт.

[Rutel]

20 часов назад, Sergey Gilfanov сказал:

Не, как оно будет выглядеть уже после построения всех маршрутов. Видно же, что в данном случае для получения пропускной способности 2 нужно использовать и верхний и нижний путь одновременно. Как это обеспечивается?

 

А так же как обрабатывается отказ уже после построения каналов? Где и кто определяет, какой кусок уже переданных данных нужно заново послать, а какой уже у получателя есть?

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

Можно инкапсулировать много независимых пакетных сетей, по существу технология виртуализации сетевой инфраструктуры с полной защитой информации.

Или объединять разнородные сети (телефония, IP, различные технологические интерфейсы и тд), с гибким управлением.

В качестве начального применения, можно использовать как внутренний интерфейс распределенного коммутатора (внутри символьное мультиплексирование, снаружи уже существующие сети)

или для построения например единой сети самолета, там требуются сеть с гарантированным доступом. 

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