Как стать автором
Обновить

Комментарии 21

Для идеального цифрового коня в вакууме идея синхронного интернета отличная. Но для неидеального реального интернета, с его задержками и авариями на разных узлах сети, это не будет работать. Особенно при его последующем развитии для дальней связи (Луна, Марс).
Из Ваших 3-х пунктов выкинут очень важный момент, на котором держится интернет — любые два пользователя должны иметь возможность соединиться при неработоспособности промежуточных узлов.

Возможно при изобретении квантовых систем связи с их «пугающим дальнодействием» и моментальной связью на любом расстоянии (hello StarTrack) Ваши идей найдут свое применение.
Из Ваших 3-х пунктов выкинут очень важный момент, на котором держится интернет — любые два пользователя должны иметь возможность соединиться при неработоспособности промежуточных узлов.

Я написал просто:
Возможность в любой момент мгновенно установить соединение любого абонента с любым абонентом.

Заметьте, что маршрутов может быть очень много и при отсутствии ответа в расчетный момент времени можно попытаться установить связь с использованием альтернативного маршрута.
Поздравляю!!!
Вы первый человек задавший вопрос по существу задачи.
Я помню тут на сайте была статья про зарождение интернета. И там в самом начале проектировали как блочную передачу так и каналы. В дальнейшем каналы подохли не выдержав конкуренцию с блочной передачей.
В этом и вся проблема, вовремя не нашли оптимального решения и все.
А сейчас любое упоминание про синхронность наталкивается на подобный аргумент.
Я разговаривал с достаточно крупным производителем сетевых устройств в Новосибирске. Ответ такой все синхронное давно проиграло и ничего нового сделать нельзя, потому даже читать не будем. В остальных компаниях, если нас заинтересует ваша работа вам ответят (секретари так отвечают).
Основная причина в дороговизне такого типа оборудования на тот момент (его использовали телефонные компании и им на цену было плевать).
НЛО прилетело и опубликовало эту надпись здесь
Потери могут быть двух типов:
— ошибка передачи символа (при обнаружении будет заменен на специальный символ «ошибка», восстановление происходит протоколом более высокого уровня или логикой взаимодействующих клиентов).
— отключение коммутаторов (если промежуточный буфер не пополняется больше чем три периода передачи (время передачи 3х символов в виртуальном канале), то канал закрывается, приемник и передатчик уведомляются о разрыве спец символом «закрыть канал» повторное создание канала на усмотрение взаимодействующих сторон). Главное что о потери связи приемник и передатчик узнают даже быстрее чем требуется времени для передачи в одну сторону.

В современных системах связи типичное значение постоянной загрузки канала не более 40%, после этого значения будут проблемы с доставкой (даже специальный алгоритм придумали для постепенной загрузки канала). Предлагаемый алгоритм должен хорошо работать до 99% загрузки (без потери данных).
В пакетной сети примерно 20% и более потока представляют собой служебные данные. В Предлагаемом алгоритме служебные данные (примерно как в заголовке IP пакета) только в момент установления соединения, потом 2% от физического потока (в современном оборудовании примерно столько и расходуется на физическом уровне). Получается что производительность увеличится на эти 20% плюс 60% не загруженной сейчас полосы.
Распределение ширины канала в современной IP связи реализуется протоколом высокого уровня и нет гарантии справедливого распределения. В моем алгоритме если канал создан, то он имеет абсолютную гарантию на строго определенную полосу пропускания (понятно, что предоставление полосы нужно будет периодически подтверждать).
НЛО прилетело и опубликовало эту надпись здесь
Как детектируется — в символе не все комбинации бит разрешены, один из видов ошибки прием комбинации не принадлежащей ни одному легитимному символу. Если используются корректирующие биты встроенные передаваемый символ, то вероятность детектирования ошибки возрастает (за счет не скорректированных ошибок).

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

100 м бит канал — проблема возникает когда на этом канале весит «весь подъезд», тоже достаточно большая проблема и все с ней смирились — даже такое позорище как пропадание связи при общении с корреспондентом на телевидении уже считается само собой разумеющимся. Про заикание в скайпах и тд я уже не говорю — все смирились.

например торрент — будет иметь гарантированную нижнюю скорость и если никто не занял канал будет занимать весь канал (все 100 м бит) и мгновенно освободит сколько нужно пропускной способности если нужно поговорить или открыть сайт.
Виртуальные каналы могут быть односторонними, перестраиваемыми по скорости (в сторону уменьшения производительности гарантированно и мгновенно), асиметричными. можно даже перестраивать сетку скоростей доступа в зависимости от текущего состояния ПО.
НЛО прилетело и опубликовало эту надпись здесь
А где собственно проблема?
— Если не ошибаюсь информация о разрыве соединения будет получена через 30 секунд (поправьте если не так). Для многих приложений это неприемлемые величины и в промышленных сетях делают дублирование физического соединения(натурально отправляют пакеты по двум маршрутам). Так что проблема существует.
Менять не будут это точно, но постепенно заменять начиная мест где это выгодно — вполне могут — пакетная сеть это частный и очень ограниченный случай моего варианта сети (клиент не сможет распознать что пользуется не пакетной сетью). Те прозрачно передавать пакеты через сеть с синхронной символьной коммутацией можно, а вот наоборот нельзя. К стати SDH тоже частный случай и тоже прозрачно замещается.
Вопросы:
1. Я собирался опубликовать серию статей про устройство вычислительной системы пятого поколения (как я это вижу), но как то печально все выходит (смотрим на распределение голосов).
2. Я правильно понимаю, что ХАБР не место для таких публикаций?
3. Я правильно понимаю, что основу аудитории ХАБР составляют люди с «филологическим» образованием и вникать в технические тексты они не могут по определению?

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

Еще хочется добавить, думаю с кармой сложилась странная ситуация.
Посмотрите кто то поставил минус на каждый мой комментарий, а может существует система выдавливания независимых авторов из информационного пространства?
Предлагаю лишить анонимности голосующих в плюс или в минус и возможно при голосовании забирать часть кармы у голосующего?
Добавить обязательное объяснение о принятом решение (можно только для минуса — автор должен понимать что не нравится читателям), иначе авторское сообщество скатится до публикации технических комиксов.
Опубликуйте White Paper на английском языке и не парьтесь на научно-популярных новостных сайтах и в социальных сетях с их лайкорейтингами.
После публикации всех базовых принципов, наверное так и поступлю.
Я питаю надежду, пусть и очень небольшую, что «родным» языком для следующей вычислительной парадигмы будет именно русский язык.
Но жизнь идет к тому, что надписи на «терминаторе» будут выполнены иероглифическим письмом.

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

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

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

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

Прочитаю и постараюсь понять все что вы порекомендовали.
Быстрый ответ не обещаю, отвечу в личку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории