Jump to content
Калькуляторы

Надеюсь что разработал идеальную сеть (с учетом физических ограничений)

 Ребята, ну сегодня же всего понедельник. А так - вполне псевдонаучно, с введением новых терминов. Ну пусть будет, отчего бы и нет ? С икапсуляцией и виртуализацией глядишь и до mnp5 модемной докатятся, затем алгоритмы лепельзива докопаются.... И про системы РВ почитают воспоминания. И про королёвские ракеты.... В общем - как у Лема, выкопалистика. Но это радует, может быть новые мозги вспомнят учебники по tcp/ip. Хотя они их и не читали никогда, и что под реакторами белоярки стояли см18хх с осрв(rtos)  не знают....

Share this post


Link to post
Share on other sites
38 минут назад, YuryD сказал:

 Ребята, ну сегодня же всего понедельник. А так - вполне псевдонаучно, с введением новых терминов. Ну пусть будет, отчего бы и нет ? С икапсуляцией и виртуализацией глядишь и до mnp5 модемной докатятся, затем алгоритмы лепельзива докопаются.... И про системы РВ почитают воспоминания. И про королёвские ракеты.... В общем - как у Лема, выкопалистика. Но это радует, может быть новые мозги вспомнят учебники по tcp/ip. Хотя они их и не читали никогда, и что под реакторами белоярки стояли см18хх с осрв(rtos)  не знают....

Цитата

А так - вполне псевдонаучно, с введением новых терминов.

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

Желательно с аргументированными доказательствами.

 

По поводу сжатия  : этого делать нельзя по многим причинам.

 

По поводу учебников :

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

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

 

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

Думаю одним высказываний и было : Учи мат. часть. ))))

Edited by Rutel

Share this post


Link to post
Share on other sites
17 минут назад, Rutel сказал:

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

Желательно с аргументированными доказательствами.

 

 

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

Share this post


Link to post
Share on other sites
6 минут назад, YuryD сказал:

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

С цифровой точки зрения : Символ не делимая сущность, переносящая некоторый объем информации.

 

Если возможно, не нужно формальных претензий.

 

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

Я изобрел третью : Синхронное символьное мультиплексирование. 

Ближайший аналог из аналоговых систем: Частотное мультиплексирование.

Edited by Rutel

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Существенное увеличение производительности сети передачи данных и снижение сложности построения аппаратной составляющей сети. 

 

Полная децентрализация.

 

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

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

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

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

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

 

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

На максимуме развития, хочу получить вот такую технологию : https://habr.com/ru/post/489068/

 

 

Edited by Rutel

Share this post


Link to post
Share on other sites
43 минуты назад, Rutel сказал:

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

 

— Не беспокойтесь, — сказал Остап, — мой проект гарантирует вашему городу неслыханный расцвет производительных сил. Подумайте, что будет, когда турнир окончится и когда уедут все гости. Жители Москвы, стесненные жилищным кризисом, бросятся в ваш великолепный город. Столица автоматически переходит в Васюки. Сюда переезжает правительство. Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира.

 

— Всего мира! ! ! — застонали оглушенные васюкинцы.

Share this post


Link to post
Share on other sites
28 минут назад, sdy_moscow сказал:

 

— Не беспокойтесь, — сказал Остап, — мой проект гарантирует вашему городу неслыханный расцвет производительных сил. Подумайте, что будет, когда турнир окончится и когда уедут все гости. Жители Москвы, стесненные жилищным кризисом, бросятся в ваш великолепный город. Столица автоматически переходит в Васюки. Сюда переезжает правительство. Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира.

 

— Всего мира! ! ! — застонали оглушенные васюкинцы.

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

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

 

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

В данном случае достаточно прочитать текст из прищепки и осмыслить его.

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

 

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

В реальности фиг вам. Человек обладает врожденным свойством сопротивляться переменам до последнего. Такого попаданца просто загнобят (для примера читаем :https://takiedela.ru/2020/03/ignac-zemmelveys/)

 

Вот я и предлагаю технологию кандидата, оцените на предмет применимости.

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

Упустите время и потом будете жалеть, родилась в мое время вот эта технология, был рядом , но что называется "мимо рта пронес".

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

Да и вообще 99 процентов начинаний не имеют практического применения, затеваются для души.

Edited by Rutel

Share this post


Link to post
Share on other sites

@Rutel  Простите, сейас будет "легкая грубость".

 

Ваш текст в прищепке - это "влажные фантазии".

 

Когда Вы отпишите ВСЕ алгоритмы, уточните ВАШУ терминологию, засунете всё это хотя-бы в какие-то уровни модели OSI. Вот тогда и поговорим о содержании.

 

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

 

С тем же успехом можно описать построение машины времени работающей через гравитационные линзы.

 

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

 

Как писал другой известный автор:

 

– Вы стоите на самой низшей ступени развития, – перекричал Филипп Филиппович, – вы ещё только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие‑то советы космического масштаба и космической же глупости....

Share this post


Link to post
Share on other sites
46 минут назад, sdy_moscow сказал:

@Rutel  Простите, сейас будет "легкая грубость".

 

Ваш текст в прищепке - это "влажные фантазии".

 

Когда Вы отпишите ВСЕ алгоритмы, уточните ВАШУ терминологию, засунете всё это хотя-бы в какие-то уровни модели OSI. Вот тогда и поговорим о содержании.

 

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

 

С тем же успехом можно описать построение машины времени работающей через гравитационные линзы.

 

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

 

Как писал другой известный автор:

 

– Вы стоите на самой низшей ступени развития, – перекричал Филипп Филиппович, – вы ещё только формирующееся, слабое в умственном отношении существо, все ваши поступки чисто звериные, и вы в присутствии двух людей с университетским образованием позволяете себе с развязностью совершенно невыносимой подавать какие‑то советы космического масштаба и космической же глупости....

Если я правильно понимаю, вы специалист в области коммуникационных систем.

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

Если вы не можете этого сделать, то наверное Ваших знаний недостаточно.

 

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

Поэтому приходится рисовать " технические комиксы" с ограничением в 10 страниц, а в результате получается анекдот : Расскажи "Войну и мир" в двух словах - Война и Мир.

Кстати попробуйте несведущему человеку описать устройство современной сети с коммутацией пакетов и всеми 700 протоколами в 10 страницах и убедить, что это будет работать.

Все что вы сделаете опишите концепцию пакета и его коммутацию, примерно это я и сделал.

 

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

 

 Сейчас я пытаюсь решить две задачи ;

- получить оценку сторонних (рецензию) специалистов.

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

Мне еще нужно еще несколько сущностей описать и каждая практически на порядок сложнее. Если для алгоритма, который можно объяснить практически на пальцах такие проблемы, то 

мне остатка жизни гарантированно не хватит.

 

Edited by Rutel

Share this post


Link to post
Share on other sites
19 минут назад, Rutel сказал:

Прошу Вас, как специалиста в своей области,

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

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

указать в каком месте новая сеть может стать "влажными фантазиями" при соприкосновении с реальной нагрузкой.

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

 

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

 

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

 

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

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

Не было тут никакого динамического регулирования. Наоборот, все описано так, что скорость является строго постоянной. А если не хватает скорости в уже установленных каналах - то просто 'нет обслуживания', без малейших попыток объяснить, как именно возможный маршрут ищется.

Share this post


Link to post
Share on other sites

Ну вот в пример. В приатаченном документе:

Цитата

Поток R в 1/3, поток G в ¼ и поток B в 1/5, от пропускной способности исходного физического канала. Оставшуюся пропускную способность можно использовать для других нужд.

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

Share this post


Link to post
Share on other sites
3 минуты назад, Sergey Gilfanov сказал:

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

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

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

 

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

 

Не было тут никакого динамического регулирования. Наоборот, все описано так, что скорость является строго постоянной. А если не хватает скорости в уже установленных каналах - то просто 'нет обслуживания', без малейших попыток объяснить, как именно возможный маршрут ищется.

Цитата

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

Да мне уже говорили (профессор из СибГУТИ), что в нашей стране нет теоретиков от связи. Я склонен верить, пока ни одного не нашел.

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

Поскольку я очень скромный, то буду считать, что я и есть единственный "теоретик".

И как теоретику мне не пристало непосредственно заниматься практической реализацией. 

 

Шучу я так )))

Цитата

После того, как все эти виртуальные каналы (в глобальном масштабе!) как-то построены.

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

Цитата

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

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

 

Цитата

Интересно, как оно переживает глобально меняющуюся глобальную сеть с кучей операторов.

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

Цитата

Не было тут никакого динамического регулирования.

Я описываю один самый простой вариант обслуживания, если "мыслью по древу" закончится не читаемым монстром.

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

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

Цитата

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

 

2 это максимально возможная скорость потока (определяется физически каналом)

Если затребованная скорость больше 1 то это уже вопрос к коммутатору (обратное мультиплексирование)

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

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

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

 

 

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

Здесь можно реализовать много механизмов, самый простой :

- отправили запрос и не получили входящего обратного канала

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

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

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

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
22 минуты назад, Sergey Gilfanov сказал:

Ну вот в пример. В приатаченном документе:

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

Цитата

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

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

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

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

Не гарантированность пропускной способности это одна из главных проблем в IP сети. Целые научные работы пишут про оптимальную сортировку пакетов и тд. 

 

Мультиплексирование гарантирует минимальный и конечный по объему и быстродействию буфер коммутатора. Размер буфера определяется отношением физической скорости канала к минимальной скорости виртуального канала умноженному на размер заголовка (все в информационной емкости символов). Для физического канала 400G и минимального виртуального канала 100 кбит в секунду - максимум потребуется буфер 150 МБайт. Далеко не запредельное значение и реализуемое в пределах одного кристалла.

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

Edited by Rutel

Share this post


Link to post
Share on other sites
1 минуту назад, Rutel сказал:

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

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

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

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

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

Share this post


Link to post
Share on other sites
21 минуту назад, Sergey Gilfanov сказал:

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

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

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

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

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

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

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

 

Похожие мысли (если все рассчитать) присутствуют и в программно определяемых сетях (мое мнение: у данной технологии нет перспектив)

 

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

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

 

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

Цитата

Как все коммутаторы по пути виртуального канала определяют, что вот этот прилетевший на входной интерфейс символ - это вот этот виртуальный канал?

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

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

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

Edited by Rutel

Share this post


Link to post
Share on other sites
12 минут назад, Rutel сказал:

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

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

 

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

 

Теперь в предложении:

Цитата

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

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

Т.е. канал убивается, все что в него передано и не принято мной уходит в потери.

Нужно создать новый (я же продолжаю видео смотреть).... и на какую скорость нужно договариваться - оно же неизвестно, сколько именно мой текущий WiFi пролезет?

Share this post


Link to post
Share on other sites
1 минуту назад, Sergey Gilfanov сказал:

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

 

Теперь в предложении:

Т.е. канал убивается, все что в него передано и не принято мной уходит в потери.

Нужно создать новый (я же продолжаю видео смотреть).... и на какую скорость нужно договариваться - оно же неизвестно, сколько именно мой текущий WiFi пролезет?

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

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

Для реального канала с помехами, тут есть два варианта 

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

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

 

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

Share this post


Link to post
Share on other sites
13 минут назад, Rutel сказал:

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

Это не раз говорилось и совершенно непонятно. Почему он быстрый-то? Если у меня (или у моего оператора) два физических канала. Смотрю я ютуб через один из них. Вирутальный канал через него упал. И почему будет быстро его (и сотни тысяч других, от других абонентов и проложений) пересоздать? Придется же, как минимум, найти другой маршрут(ы) через другого оператора/канал. А нахождение маршрутов - процесс ну вот ни разу не быстрый.

 

И на вопрос не было ответа - ну пересоздаем, но на какую скорость -то? Чтобы на ближайшие 10 минут (пока микроволновка работает) у меня квадратики пропали за счет уменьшения разрешения.

Share this post


Link to post
Share on other sites
27 минут назад, Sergey Gilfanov сказал:

Это не раз говорилось и совершенно непонятно. Почему он быстрый-то? Если у меня (или у моего оператора) два физических канала. Смотрю я ютуб через один из них. Вирутальный канал через него упал. И почему будет быстро его пересоздать? Придется же, как минимум, найти другой маршрут через другого оператора. А нахождение маршрутов - процесс ну вот ни разу не быстрый.

 

И на вопрос не было ответа - ну пересоздаем, но на какую скорость -то? Чтобы на ближайшие 10 минут (пока микроволновка работает) у меня квадратики пропали за счет уменьшения разрешения.

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

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

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

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

 

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

 

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

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

 

В современных IP сетях понятие скорости размыто, это по существу неизмеримый мгновенно параметр и носит случайный, статистический характер.

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

 

 

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

 

Edited by Rutel

Share this post


Link to post
Share on other sites
29 минут назад, Rutel сказал:

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

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

image.thumb.png.b3b9fd4a8bdea8277457298d46ab72d2.png

Первый (оптимальный), маршрут - красный.

Какой маршрут будет вторым и как это определяется? 

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

Share this post


Link to post
Share on other sites
2 минуты назад, Sergey Gilfanov сказал:

image.thumb.png.b3b9fd4a8bdea8277457298d46ab72d2.png

Первый (оптимальный), маршрут - красный.

Какой маршрут будет вторым и как это определяется? 

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

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

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

 

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

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

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

 

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

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

Приходится использовать различные решения для различных частей сети передачи данных.

Share this post


Link to post
Share on other sites
12 часов назад, Rutel сказал:

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

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

Share this post


Link to post
Share on other sites
4 минуты назад, edo сказал:

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

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

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

Тайм слоты наверное неправильно наименование - скорее часть пропускной способности.

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

Edited by Rutel

Share this post


Link to post
Share on other sites
32 минуты назад, Rutel сказал:

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now