Хорошо, я расскажу еще одну сказку. Про то, как я создаю системы с сотнями тысяч узлов, где IP почти не используется. Он там есть, но от него больше проблем, чем пользы.
Посмотри сюда — Формат кадра Ethernet — тут есть все, что нужно — адрес отправителя, адрес получателя, данные, контрольная сумма. Еще можно добавить адрес подсети VLAN. И работает это в масштабах оператора связи. В моем случае сеть состоит из приборов и центральных узлов, к которым эти приборы подключаются. При желании можно и между сетями связь сделать, но такая задача у меня не стоит.
Физический уровень — это прием и передача отдельных битов. Это дороги, мосты, площади. Канальный уровень — это обмен битами (байтами, пакетами) между устройствами физического уровня. Это как пешеходы и автомобили.
А IP это тупо контейнер, ящик для почтовой посылки. Без канального и физического уровней он не сможет даже покинуть здание (узел связи, компьютер). Драйвер, который вы показываете — это даже не драйвер, а «заглушка», которая все принятое передает обратно.
Именно поэтому в модели TCP/IP (которая, в отличие от модели OSI описывает реально существующие сети) есть отдельный уровень для всего этого — канальный (он же — физический).
Хорошо, допустим. Покажите мне канальный/физический уровень при использовании TCP внутри одной машины (localhost) без сетевых карт, портов и прочих устройств связи.
Модель достаточно хорошо описывает разные уровни абстракции передачи данных, но не учитывает, что в реальных условиях некоторых уровней может и не быть, они идут не по порядку или совмещены вместе.
Стек TCP/IP никак не учитывает физический и канальный уровни, полагая, что пакеты магическим образом доставляются из точки А в точку Б. Если вы его засунете в физический канал, где больше двух точек (например, в радиоэфир или шину), то возникнет сразу куча проблем с коллизиями, синхронизацией, итд, которые TCP/IP в принципе никак не может решать.
Похоже, я жестоко ошибся в версиях, Delphi10 это на самом деле Delphi 2007, в которой еще даже уникода нет. Для современной Delphi 10.2 потребовались ощутимые доработки, поскольку огромное количество кода предназначено для поддержки совместимости с Delphi 2, где некоторых привычных функций и контролов еще не было. Например, TToolBar и TToolButton определены заново. А еще оно рассчитано на установку из бинарников, а не из исходников.
Я не хочу сказать, что модель OSI хороша, но других пока не придумали. Если допустить, что уровни/слои не обязаны быть иерархичными, то модель вполне работоспособна и удобна.
Взял на официальном сайте — www.fast-report.com/en/product/free-report-vcl
А где можно глянуть вашу версию? Сходу найти не получается. Попробую ее сконвертировать под Delphi 10.2 и Lazarus, у меня в этом есть опыт.
У меня FR 2.3 (свежее не нашел), и там для совместимости с новыми версиями достаточно в файле FR.INC отключить поддержку InterBase и ADO и включить режим Delphi10.
Реально проблемы только с портирования совсем древнего Паскалевского кода, где много ассемблера и вызовов функций Windows. Обычно этот код — калька с сишного. Просто потому, что в Windows и Unix были готовые библиотеки и заголовки для Си, а разработчикам на Паскале приходилось все адаптировать. Delphi 7 уже был спроектирован под реальную кроссплатформенность Windows/Linux. А в FreePascal/Lazarus кроссплатформенность довели до совершенства — write once, compile anywhere.
Отладка протокола занимает ничтожное время по сравнению с общим объемом эксплуатации, и есть множество готовых инструментов для разбора бинарных пакетов — тот же Wireshark. А если сделать режим отладки с логированием расшифровки пакетов и состояний, то проблем с отладкой в полевых условиях совсем не возникает. Вам часто приходится отлаживать канальные протоколы — UART, USB или даже UDP? Потому что там принцип простой, отправил и забыл, ломаться нечему. А в TCP или Bluetooth все сложно by design, всякие состояния, условия, режимы и контексты. И дело вовсе не в формате пакета.
Есть полу-бинарные варианты кодирования, которые можно читать глазами и при этом они не особо избыточны. Это кодирование чисел в BCD и использование буквенных HEX-кодов как маркеры, сериализация в Bencode, итд… Только почему-то они не особо популярны.
То есть, подобрать условия и ограничить количество возможных решений? Но зачем? Только для экспресс-тестирования или гарантированного получения неопределенных результатов? Это как-то… мелко… Напоминает детские развлечения с калькулятором, для получения ЕГГОГ.
А я понял так, что пытаются вычислить состояния скрытых от наблюдения битов. Примерно как попытаться вычислить неизвестное состояние регистра флагов процессора (знак переноса, минуса, переполнения, четности, итд..) при помощи выполнения ряда «калибровочных» операций, результаты которых зависят от флагов. А вот зачем это делать, я так и не понял.
Проще сказать, что в квантовом компьютере программируются действия над случайным набором данных, которые отфильтровывают только определенные комбинации. То есть, не единственно верный результат, а любые результаты, подходящие под заданное условие.
Я не понял, как они сделали квантовую необратимость. Ведь все операции, проводимые на квантовом компьютере, обратимы, иначе сам компьютер «ломается», переходит в непредсказуемое состояние. Это как вслепую пользоваться арифмометром, ориентируясь только на «щелчки». После каждого вычисления нужно «отмотать» все в обратном порядке, иначе последующие вычисления будут непредсказуемыми.
Но если нужно только криптографическое применение, то полная обратимость не нужна. Это как если мы на том же арифмометре выставляем нужный результат, а потом крутим в обратную сторону и получаем исходные данные. Вернее, одну из возможных комбинаций исходных данных, которые подходят под заданный результат. Тот самый поиск данных под заданный хеш, что и в майнинге.
Программист стесняется штрихкодов… Штаа?! Какой гуманитарий это написал? А чем тогда программист гордится, порнушкой?
И мне-таки тоже интересно, как штрихкод поможет навести порядок на складе? Он нужен для ускорения считывания номеров. А если это склад мебели или стройматериалов, то там от штрихкодов будет больше вреда, чем пользы.
Вроде и понятно, что текст про человеческие отношения, но такие «стрелки осциллографов» очень режут глаз.
Посмотри сюда — Формат кадра Ethernet — тут есть все, что нужно — адрес отправителя, адрес получателя, данные, контрольная сумма. Еще можно добавить адрес подсети VLAN. И работает это в масштабах оператора связи. В моем случае сеть состоит из приборов и центральных узлов, к которым эти приборы подключаются. При желании можно и между сетями связь сделать, но такая задача у меня не стоит.
Канальный уровень — это обмен битами (байтами, пакетами) между устройствами физического уровня. Это как пешеходы и автомобили.
А IP это тупо контейнер, ящик для почтовой посылки. Без канального и физического уровней он не сможет даже покинуть здание (узел связи, компьютер). Драйвер, который вы показываете — это даже не драйвер, а «заглушка», которая все принятое передает обратно.
Хорошо, допустим. Покажите мне канальный/физический уровень при использовании TCP внутри одной машины (localhost) без сетевых карт, портов и прочих устройств связи.
Стек TCP/IP никак не учитывает физический и канальный уровни, полагая, что пакеты магическим образом доставляются из точки А в точку Б. Если вы его засунете в физический канал, где больше двух точек (например, в радиоэфир или шину), то возникнет сразу куча проблем с коллизиями, синхронизацией, итд, которые TCP/IP в принципе никак не может решать.
github.com/VencejoSoftware/FreeReport
github.com/jciberta/FreeReport
А где можно глянуть вашу версию? Сходу найти не получается. Попробую ее сконвертировать под Delphi 10.2 и Lazarus, у меня в этом есть опыт.
Есть полу-бинарные варианты кодирования, которые можно читать глазами и при этом они не особо избыточны. Это кодирование чисел в BCD и использование буквенных HEX-кодов как маркеры, сериализация в Bencode, итд… Только почему-то они не особо популярны.
Но если нужно только криптографическое применение, то полная обратимость не нужна. Это как если мы на том же арифмометре выставляем нужный результат, а потом крутим в обратную сторону и получаем исходные данные. Вернее, одну из возможных комбинаций исходных данных, которые подходят под заданный результат. Тот самый поиск данных под заданный хеш, что и в майнинге.
И мне-таки тоже интересно, как штрихкод поможет навести порядок на складе? Он нужен для ускорения считывания номеров. А если это склад мебели или стройматериалов, то там от штрихкодов будет больше вреда, чем пользы.
Вроде и понятно, что текст про человеческие отношения, но такие «стрелки осциллографов» очень режут глаз.