Синхронная Символьная Иерархия
Символьное представление данных
Требования к кодированию передаваемых данных и их реализацию:
-
Данные цифровые : Используется цифровой канал передачи данных.
-
Данные могут быть синхронными и асинхронными: К каждой единице данных добавляем идентификатор (0 — асинхронные, 1-синхронные). В современной вычислительной технике такого понятия нет.
-
Данные представляются значением или типом: добавляем идентификатор (0 значение, 1- тип данных). В современной вычислительной технике все данные являются просто числами и интерпретируются только обрабатывающей их программной, что приводит к множеству ошибок.
-
Для экономии «транзисторов», считаем что данные всегда передаются младшим битом вперед. Последовательность данных от первого до последнего, по порядку.
-
Логические данные необходимо «разложить» по «физическим» символам, которые могут быть разными для разных типов аппаратных систем.
-
Локальные данные могут иметь битовую емкость больше «физического» символа, занимать больше одного «физического» символа. Добавляем идентификатор указывающий на завершение текущего символа (0 — будет продолжение в следующем «физическом» символе, 1 — завершение текущего символа символа).
-
Битовая емкость логического символа может быть как меньше «физического» символа, так и не кратными размеру «физического» символа. Добавляем идентификатор указывающий что данные являются значащими (0 - данные пропускаются, 1 - данные используются в обработке). Если есть хоть один ноль в четвертом бите атрибутов, то передаваемые данные целиком поместились в «физический» символ. Если нулей нет, то данные будут продолжены в следующем символе (даже если там будет ноль передаваемых битов).
Получаем, что каждому биту передаваемых данных нужно добавить четыре бита атрибутов, что приведет к крайне не эффективному расходованию пропускной способности канала передачи данных. К счастью атрибуты будут очень часто повторяться, битовый размер данных в большинстве случаев существенно больше одного.
Предварительно получается что можно добавлять биты атрибутов только в момент их изменения, но и тут есть проблема: Символ который определяется как последовательность бит атрибутов плюс битовое значения данных постоянно будет разного размера и нужно как то определять где начинается новый символ.
С другой стороны аппаратура передачи данных, микросхемы памяти и прочее работают с постоянным, пусть и не всегда одинаковым размером символа.
Наиболее оптимальным решением будет каждый «аппаратный символ» символ начинать с битов атрибута, такая аппаратная привязка местоположения атрибутов будет максимально эффективной. Для выравнивания битового размера символа использовать размножение последнего атрибута, помечая лишние биты как не используемые и сразу за единичным битом до конца «физического» символа будут размещены действительные данные. Если символ перемещается через границу между аппаратурой с различным размером «физического» символа, то необходимо производить преобразование размера символа на лету. Разницу в битовом размере, а значит и накладные размеры, необходимо учитывать при вычислении скорости передачи.
Есть два условия, которые лимитируют размер символа снизу и сверху. Слишком маленькие символы будут иметь большой процент битов атрибутов в своем составе (предел 1 значащий бит на 4 бита атрибутов). Слишком большие символы будут иметь много битов пропуска данных, не используемых для кодирования значений данных.
Итог: Размер символа, соответственно битовый размер данных, может быть любым (оптимальным для конкретной выполняемой задачи). Да есть некоторые потери, не используемые биты, но они контролируемы через изменение размера аппаратных символов.
Следует пояснить понятие «тип данных»
С другой стороны можно считать, что список типов данных является своеобразным API распределенной вычислительной системы. Функции API подразумевают передачу параметров, их можно передавать как отдельными символами данных (следуют за символами типа данных), так и в виде «интегрированных» в тело символа самого типа данных (размер символа не ограничен и данные добавляются со стороны младшего значащего бита). В таком случае тип данных может быть различного размера (передается младшими битами вперед). Интерпретация начинается в момент окончания приема именно логического символа, в таком случае все необходимые данные уже находятся в буфере приемника. Необходимость размешать данные такого составного типа в буфере приемника ограничивают длину такого символа.
Изначально никаких требований к «стандартизации» списка такого API нет. Считаем, что требования к функциональной полноте и возможности обратного преобразования объектов позволит выполнить автоматическое преобразование из одного локального API в другое.
Комментарии
Какая-то путаница.
Сначала нечёткое обозначение терминов "синхронные", "значение" - что это?
Разграничив данные, они теперь независимые, или должны взаимодействовать. Как?
Далее - что-то очень похожее на принцип питоновской интерпретации запихнуть в логику асамблера -- заранее провально.
Наконец неверное определение защит и "контрольных сумм" - это не для определения ошибок распознавания данных, а для элементарных сбоев "потеря силнала". Чем больше количество передоваемых сигналов(0-1), тем больше вероятность технической ошибки.(потеря даже одной цифры, искажает весь пакет данных)
Классические 7 уровней протоколов нам всем в помощь.
А зачем они нужны ?
В моем понимании они появились из-за неприспособленности "телеграммного" типа общения реальным задачам.
ССИ сразу предоставляет идеальный тип канала и ничего больше ненужно добавлять.
Если говорить в общем, то всем задачам и всем пользователям вполне хватит (даже с запасом) сервиса полностью независимых виртуальных каналов с одним источником и любым числом приемников. Данные поступают с предсказуемой скоростью в том порядке как и были отправлены, нет потерь из-за переполнения буферов.
Да могут быть искажения из-за шумов в канале и тд, но на месте искаженного символа будет стоять служебный символ "ошибка передачи".
Про 7 уровней можно забыть, нет если есть желание то без проблем (каких только извращений не придумают - яркий пример это бухгалтерия).
Синхронные данные, это группа данных передаваемая с гарантированной и заранее заданной скоростью передачи и задержкой коммутации.
Асинхронные данные, постоянной скорости передачи и задержек коммутации нет, по таким правилам передаются пакеты в современной сети Ethernet.
Зачем такое усложнение?
В сетях с коммутацией каналов есть минус, если источник данных не предоставил данные для передачи, то выделенная для передачи полоса будет простаивать.
Как то заранее утилизировать эту неиспользуемую пропускную способность нельзя, об отсутствии данных для передачи узнаем в момент когда данные нужно загружать в серилизатор трансивера.
В сети ССИ есть две очереди данных (синхронная и асинхронная), если источник синхронных данных не предоставил данные, то отправляются асинхронные данные.
Для того что бы различить одни данные от других и служит бит атрибута (синхронные асинхронные).
Заполнение "пробелов" трафика происходит индивидуально на передатчике каждого физического канала, на приемной стороне происходит обратное распределение данных по соответствующим очередям.
Можно сделать множество асинхронных очередей (пока только одна).
Число синхронных очередей равно числу виртуальных каналов.
Не до конца вас понимаю, Вы про подписать тип данных ?
Тут все просто данные идут множеством виртуальных потоков (каналов), нужно оптимально реализовать создание (интерпретации структур в передаваемых данных).
Или вы предлагаете поступать как в физике Ethernet, синхропосылка, заголовок контрольная сумма и тд ?
Думаю у Вас слишком узкое понимание данного вопроса.
Изобретение велосипеда.
Флаги приоритета и классы трафика, виртуальные каналы, в том числе изохронные, контрактные интерфейсы, если я правильно понял автора конечно, все это широко используется с 1960х.
Изобретают, только не изобрели еще )))
В 1960х обычный телефон это "палка веревка" и работает очень хорошо, а сейчас это чуть ли не отдельный компьютер со своей операционкой.
В результате : Вы меня слышите, ой давайте подождем абонент исчез.
Особенно изохронный трафик "цветет и пахнет", правда последняя попытка в виде програмно управляемой сети провалилась )))
Наивное летнее дитя, не работавшее как я в заграничном телекоме в рамках подготовки страны к олимпиаде 80...
Х.25, ISDN, FR, это все уже плоды стандартизации. Проприетарные решения были с середины 60х.
Да, я тогда был занят в другом проекте, проводил летние каникулы на даче ))))
А если серьезно, человек с таким опытом должен знать что пакетная коммутация в чистом виде является асинхронной системой.
Да, позволяет разделять единый канал между многими пользователями, но при этом создает неустранимые пульсации трафика, которые невозможно полностью сгладить буфером любого размера. Наличие большого буфера в коммутаторах создает проблему неконтролируемых задержек передачи (после 100 мс очень плохо влияет на голосовой трафик).
Маленький буфер приводит к потерям данных, что еще хуже.
Пакетная коммутация как идея разделить единый канал между пользователями через отказ в обслуживании (передаче) на уровне единичных пакетов очень неплохая, но порождает не устранимые проблемы для пользователей требующих изохронный канал передачи данных. Хотя правильнее сказать, пакетная коммутация никогда и не предназначалась для синхронных систем, скорее она стала жертвой "жадности" (Зачем нам две технологии, пусть будет хоть плохонькая но одна).
Суть моей технологии, это объединить плюсы пакетной и синхронной систем (тип коммутации: канальная).
Отказ в обслуживании вынесен на уровень (момент) создания канала, но в отличии от классической синхронной системы создание канала очень быстрое и не требует проведения процедуры "рукопожатия" заранее. Появилась потребность создать канал, отправил запрос и сразу без паузы можешь передавать данные нового канала. В челом процедура создания нового канала не отличается от передаче пакета: Есть пропускная способность (доступ к среде) - передаем. Да через некоторое время может выясниться, что на каком то промежуточном этапе (коммутаторе) пропускной способности нет, но такое может быть и для обычной пакетной коммутации.
Сегодня у профильных специалистов есть проблема, "клипированный" взгляд на проблему. Большинство вообще не в состоянии понять ничего кроме пакетной системы, меньшая часть знает еще и плезиохронные системы передачи данных (Т1,Е1 и тд).
Понять предлагаемый мной вариант не может никто и виной этому лень и гордыня (базовые принципы очень просты и доступны для понимания школьником).
Я знаю, я почитав ваши статьи так и не понял - а какая в этом проблема?
Ну пульсирует трафик, да и ладно?
Если входящих пакетов мало, ну сделай stuffing путем циклического обхода входных очередей, если в очереди есть кадры - верхний кидается в канал, если нет вместо него кидается кадр-заполнитель.
ничего не пульсирует, заодно непрерывно работает коррекция тактовой частоты и синхронизации приемника, нет ненавистного вам "проскальзывания". По совместительству в эти кадры можно пихать служебную информацию какую-нибудь. Да хоть тестовые паттерны для контроля качества линии.
Для полного счастья можно в конец каждого кадра вставлять коды коррекции, обеспечивающие нечувствительность к потере/вставке/инверсии одного-двух бит на кадр...
А если их слишком много для ёмкости канала, то как ты не организуй канал, как не играй в синхронность или асинхронность, ничего не получится
Пульсирует трафик ...............
Задержка дикая и для того что бы поговорить с собеседником нужно специально паузы делать - диалог в таком режиме крайне не комфортный.
Разговариваете, а тут раз и собеседник начал исчезать (как голос так и видео), а все почему : кто то решил тоже воспользоваться сетью.
Или, что еще хуже есть большая АСУ ТП и случилась нештатная ситуация и трафик резко поменялся появились аварийные уведомления перегрузка сеть упала и вместе с ней умерла промышленная установка.
Пакетную сеть нельзя использовать в критически важной инфраструктуре (она не является сетью реального времени).
Ну и сложность (цена) аппаратуры на порядок меньше, думаю это и убьет пакетную сеть.
И самое главное, будущее вычислительной техники требует передачи маленьких порций информации (16 байт), но со скоростями в сотни триллионов бит с гарантированной минимальной задержкой коммутации без потерь данных и в том порядке как и отправили (как пример технология распределенной памяти DSM).
А вот здесь существенным будет свойство при котором есть минимально гарантированная производительность и есть не гарантированный максимум.
Что позволит строить предсказуемую систему распределения приоритетов.
Задержка большая потому что лОжат на приоритеты большой и толстый все и везде. То же самое про пакетную сеть в критической инфраструктуре.
Проблема административная, а не техническая - если я правильно понял ваши идеи, у вас можно добиться того же самого выставляя ложный символ "ёмкость канала исчерпана". После чего канал рваться не будет, он просто не будет инициализирован. И провайдеры обязательно будут добиваться, если по деньгам это выгодно.
Фактически вы требуете не столько новых протоколов, сколько национализации сетей связи илии как минимум репрессий против не выполняющих некие стандарты.
Если бы это помогало, давно бы проблему решили.
Если совсем примитивно то да. Что бы не злоупотребляли созданием каналов, время жизни канала ограничить.
При создании канала запрашивать гарантированную (минимальную полосу) и указывать максимальную не гарантированную (через размер буфера).
Если сейчас приходится производить буферизацию передаваемых данных в коммутаторе (а это очень накладно), то в моем случае буфер будет у клиента запрашивающего передачу.
Кроме того, если есть несколько альтернативных маршрутов передачи данных, то можно сразу запросить создание канала по нескольким (ненужные сразу удалить)
Ростелеком даже при капитализме самый отстойный провайдер, а что будет если он станет монополистом. Забыли очереди на телефон по 20 лет ?
Еще интересный момент: Все любят рассуждать про эффективность пакетной коммутации в плане использования одного общего канала массой пользователей.
Но как то не слышно голосов, а до какого уровня данная технология может загрузить этот общий канал без коллапса производительности (резкого снижения КПД использования пропускной способности общего канала)
Читал, что моделирование показывает уровень 30%, выше которого производительность резко падает практически до нуля.
Это не техническая проблема.
Вот допустим запросил клиент канал ёмкостью 4кбит/с чтобы по телефону поболтать, провайдер его дал, а через 5 минут провайлер сервера (оператор телефона второго абонента) на другом континенте начал кидать символы из входного fifo коммутатора в /dev/null вместо выходного - и что делать?
ограничение по времени - сделать гарантированное время примерно на порядок больше чем время на передачу (для того что бы запрашиваемый абонент успел ответить), нет ответа гасим канал. В любом случае пакетная связь тоже может слать пакеты " в никуда " или осуществлять спам атаки.
Кстати не обязательно этим заниматься самому абоненту - оператор сам может добавлять в канал кодовые комбинации (не вернулись назад, закрыть канал).
Читайте про то о чем мечтают законодатели технологий:
Первая миля - научно-технический журнал - Первая миля - "СЕТЬ-2030": ВЗГЛЯД МСЭ-Т НА БУДУЩЕЕ СЕТЕЙ ФИКСИРОВАННОЙ СВЯЗИ (lastmile.su)
Цитата: «Следует отметить, что в результате проведенных исследований фокус-группа опубликовала на своем сайте ряд технических отчетов и аналитических обзоров, но никаких проектов рекомендаций МСЭ-Т или дорожных карт разработано не было.»
А Все почему, человек достигший высот в «бюрократическом росте» не может создать чего то принципиально нового.
Все о чем они «мечтают» я реализовал, а всякие недоделанные эксперты даже не попытавшись понять что им передают на экспертизу начинают рассказывать что все это уже есть и ничем не отличается от уже существующего.
Недостатки современных фиксированных сетей
Фокус-группа МСЭ-Т FG NET-2030 выделяет несколько важных проблем современных фиксированных сетей связи, которые необходимо решить при построении "Сети-2030" [6]:
Базовые принципы "Сети-2030"
Фокус-группа FG NET-2030 определила три базовых принципа реализации "Сети-2030" (рис.2) [11]:
Новые сетевые услуги BBE&HPC (Beyond Best Effort and High-Precision Communications – коммуникации с качеством лучше Best Effort и высокоточные), которые описываются следующими характеристиками:
Новые медиа VLV&TIC (Very Large Volume & Tiny Instant Communications – коммуникации с очень большими объемами передаваемых данных и очень маленькие мгновенные коммуникации), которые включают следующие медиа:
Новая сетевая архитектура Many Nets (Many Networks – множество сетей), которая включает следующие сети и сетевые технологии: