LLTR Часть 1: Первые шаги в OMNeT++ и INET

OMNeT++ (Objective Modular Network Testbed in C++) Discrete Event Simulator – это модульная, компонентно‑ориентированная ^[1] C++ библиотека и фреймворк для дискретно‑событийного моделирования, используемая прежде всего для создания симуляторов сетей. Попросту говоря это “симулятор дискретных событий”, включающий: IDE для создания моделей, и сам симулятор (GUI).

INET Framework – “библиотека” сетевых моделей ^[2] для OMNeT++.

Полная версия GIF (15.7 MiB) ^[3]

В предыдущих частях…

0. Автоматическое определение топологии сети и неуправляемые коммутаторы. Миссия невыполнима? ^[4] (+ classic Habrahabr UserCSS ^[5])

В этой части:

• создадим “свой первый” протокол (на примере LLTR Basic);
• выберем подходящий симулятор сити для отладки протокола (и создания его модели);
• познаем тонкости настройки окружения для симулятора и его IDE (конфигурирование, компиляция, линковка, тюнинг, патчинг, игнорирование устаревшей документации; и другие англицизмы в большом количестве);
• столкнемся со всем, с чем можно столкнуться, при создании своей первой модели своего первого протокола в не своем незнакомом симуляторе сети;
• пройдем весь путь вместе:
  • от счастья, принесенного успешной (наконец!) компиляции первого проекта с пустой сетью,
  • до полного погружения в эксперименты с функционирующей моделью протокола;
• tutorial, все описано в виде tutorial – мы будем учиться на ошибках – будем совершать их, и будем понимать их (природу), дабы элегантно/эффективно с ними справится;
• репозиторий (git ), в коммитах и тегах которого сохранены все шаги (“Add …”, “Fix …”, “Fix …”, “Modify …”, “Correct …”, …), от начала и до конца.

Note: дополнительная информация ^[6] для читателей хаба “Mesh-сети”.

{ объем изображений: 2.2+(2.1) MiB; текста: 484 KiB; смайликов: 22 шт. }

Note: [про используемую структуру разделов] структура разделов tutorial/how‑to обычно отличается от структуры разделов в справочнике: в справочнике – структура разделов позволяет за минимальное количество шагов дойти до искомой информации (сбалансированное дерево); в tutorial/how‑to, где разделы сильно связаны логически, а отдельный раздел, по сути, является одним из шагов в последовательности шагов, структура представляет собой иерархию закладок (якорей), которая позволяет в любом месте tutorial/how‑to напомнить (сослаться) о фрагменте описанном ранее.

body>section>h2                                 { heading-level: 1; font-size: 1.8em;  }
body>section>section>h2                         { heading-level: 2; font-size: 1.4em;  }
body>section>section>section>h2                 { heading-level: 3; font-size: 1.17em; }
body>section>section>section>section>h2         { heading-level: 4; font-size: 1em;    }
body>section>section>section>section>section>h2 { heading-level: 5; font-size: 0.83em; }

body>section                                 { heading-level: 1; }
body>section>section                         { heading-level: 2; }
body>section>section>section                 { heading-level: 3; }
body>section>section>section>section         { heading-level: 4; }
body>section>section>section>section>section { heading-level: 5; }

# ^[16] Первые шаги: “перед моделированием” / “мозговой штурм”

^НЛО_{прилетело}и^{оставило}_этот^пробел_здесь? Обратная сторона листочка из предыдущей статьи ^[17].

# ^[18] Детализация протокола

В начале определим, что нам нужно включить в протокол. На примере LLTR Basic.

Основа LLTR – это итерации сбора статистики на множестве хостов во время сканирования сети. Итераций в LLTR много ( >1), поэтому первое, что нужно включить в протокол – управление запуском и остановкой каждой итерации. Если учесть, что хостов тоже много ( >1), то управление будет заключаться в том, чтобы определенным способом сообщать всем хостам время начала итерации и время окончания итерации. То есть синхронизировать все хосты.

В каждой итерации есть свой unicast src хост и unicast dst хост, поэтому следующее, что нужно включить – способ назначения для каждой итерации unicast src и dst. То есть в каждой итерации один из хостов должен “осознавать” себя unicast src хостом, цель которого посылать трафик на unicast dst хост.

И последнее. По завершению всех итераций, всю собранную статистику со всех хостов нужно отправить на один хост для обработки. Этот хост проанализирует собранную статистику, и построит топологию сети.

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

Все остальные делали реализации, определятся сами, в процессе создания модели. То есть, конечно, можно сразу же продумать все до мелочей, но при этом есть риск “скатится в локальный оптимум”, и не заметить “более лучший” вариант реализации. Хорошо, когда моделей будет несколько – если для каждого варианта реализации будет своя модель, то появится возможность комбинировать модели, и шаг за шагом приходить к лучшей реализации. Вспоминая генетический алгоритм ；）. Например, в одной реализации/модели может быть централизованное управление, в другой – децентрализованное, в третей – комбинация лучших частей из предыдущих двух вариантов.

# ^[19] Выбор симулятора сети

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

В основном, от симулятора сети нам нужна возможность реализации “своего” протокола. Не все симуляторы позволяют легко это сделать.

А вот присутствие эмуляторов ОС реального сетевого оборудования “мировых брендов”, наоборот – не нужно. Скорее всего, эмуляторы создадут множество ограничений, которые будут только мешать в ходе экспериментов.

С выбором симулятора мне помогла статья Evaluating Network Simulation Tools ^[20] (наши требования к симулятору во многом совпадали) и OMNeT++ General 'Network' Simulation ^[21].

# ^[22] Установка OMNeT++ и INET

Загружаем OMNeT++ ^[23] 5.0 ^[24].

И так как OMNeT++ – это всего лишь “симулятор дискретных событий”, то понадобится еще и INET ^[2] – библиотека сетевых моделей (протоколы и устройства). Качаем INET ^[25] 3.4.0 ^[26]. На самом деле его можно было установить из IDE ^[27], но я рекомендую поставить вручную (позже будет ясно почему).

Установка в *nix и в Windows мало чем отличается. Продолжу на примере Windows.

Распаковываем OMNeT++ в %ProgramData% (C:ProgramData), и открываем файл INSTALL.txt (C:ProgramDataomnetpp-5.0INSTALL.txt). В нем сказано, что подробная инструкция находится в “doc/InstallGuide.pdf”, дальше написано, что если не хотите ее читать, то просто выполните:

$. setenv
$ ./configure
$ make

Но не спешите это делать!

Во‑первых, обратите внимание на первую команду “. setenv”. В директории “omnetpp-5.0” нет файла “setenv” (в версии 5.0b1 он был). Он и не нужен (для Windows), поэтому просто запускаем “mingwenv.bat” (советую перед запуском посмотреть, что он делает… во избежание ^[28] внезапного rm ^[29] ). По окончании отколется терминал (mintty).

Во‑вторых, советую немного подправить файл “configure.user” (если упомянутый параметр закомментирован в файле, то его нужно раскомментировать):

• Если хотите использовать Clang (по умолчанию), то оставьте
  PREFER_CLANG=yes
  и настройте:
  • CFLAGS_RELEASE (опции компилятора):
    CFLAGS_RELEASE='-O2 -march=native -DNDEBUG=1'
• Если хотите использовать GCC вместо Clang (а вы, скорее всего, захотите использовать именно GCC, увидев, что написано в 398 строчке файла “configure.in”), то установите
  PREFER_CLANG=no
  и настройте:
  • CFLAGS_RELEASE (опции компилятора). Можно выбрать или
    CFLAGS_RELEASE='-O2 -mfpmath=sse,387 -ffast-math -fpredictive-commoning -ftree-vectorize -march=native -freorder-blocks-and-partition -pipe -DNDEBUG=1'
    или
    CFLAGS_RELEASE='-O2 -fpredictive-commoning -march=native -freorder-blocks-and-partition -pipe -DNDEBUG=1'
    или
    CFLAGS_RELEASE='-O2 -march=native -freorder-blocks-and-partition -pipe -DNDEBUG=1'
    (расположено в порядке уменьшения вероятности возникновения глюков).
  • Также стоит добавить CXXFLAGS в виде '-std=c++11 '+CFLAGS_RELEASE. Например:
    CXXFLAGS='-std=c++11 -O2 -fpredictive-commoning -march=native -freorder-blocks-and-partition -pipe -DNDEBUG=1'
  • JAVA_CFLAGS (просто раскомментируем):
    JAVA_CFLAGS=-fno-strict-aliasing
• PREFER_QTENV=yes
• Отключаем 3D визуализацию:
  WITH_OSG=no
  Она конечно красивая ^[30], но нам не понадобится.
• Параллельное (на множестве CPU) выполнение симуляции (WITH_PARSIM), к сожалению, тоже стоит отключить, однако без него компоновка (linker) завершается неудачей, поэтому оставим включенным:
  WITH_PARSIM=yes

Теперь в терминале (mintty) можно выполнить:

./configure && make clean MODE=release
make MODE=release –j17

Note: “17” следует заменить на количество ядер CPU + 1, либо на 1.5×ядер.

OMNeT++ использует Eclipse в качестве IDE. Для удобства можно создать ярлык на IDE “%ProgramData%omnetpp-5.0ideomnetpp.exe”, и расположить его в легкодоступном месте. В директории “ide/jre/” находится JRE v1.8.0_66-b18. Если в системе уже установлен совместимый JRE/JDK, то директорию “ide/jre/” можно спокойно удалить, заменив символьной ссылкой ^[48] на местоположение системного JRE.

При первом запуске Eclipse предлагает поместить workspace в директорию “samples”, однако лучше расположить ее в любой другой удобной вам директории вне “%ProgramData%”. Главное, чтобы в пути к новой директории использовались только латинские буквы (+ символы), и не было пробелов.

После закрытия Welcome, IDE предложит установить INET (как было написано выше), и импортировать примеры – откажитесь от обоих пунктов.

Настройки Eclipse, опции JVM, дополнительные плагины и темы

---

Опции JVM. Добавить в файл “ide/omnetpp.ini” (для правки подойдет любой редактор, понимающий LF перевод строки; notepad не подойдет), сохранив пустую последнюю строку:

-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+AggressiveOpts
-XX:+TieredCompilation
-XX:CompileThreshold=100

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

---

Настало время установить INET. Директорию “inet” из скаченного ранее архива (inet-3.4.0-src.tgz) нужно перенести в workspace. В директории есть файл “INSTALL” с пошаговым описанием установки. Можно воспользоваться им (раздел “If you are using the IDE”), но только не собирайте (Build) проект!

Импортируем INET:

1. В Eclipse открыть: File > Import.
2. Выбрать: General / Existing Projects to the Workspace.
3. В качестве “root directory” выбрать местоположение workspace.
4. Удостоверьтесь, что опция “Copy projects into workspace” выключена.
5. После нажатия на кнопку “Finish”, дождитесь окончания индексации проекта (% выполнения см. внизу, в строке статуса – “C/C++ Indexer”).

Настроим проект:

• A. отключим ненужные для LLTR компоненты;
• B. переключим сборку на релиз;
• C. избавимся от глюков “OMNeT++ Make Builder” (opp_makemake) – раньше, при его выборе, часто происходила перегенерирация Makefile, даже когда этого не требовалось;
• D. включим параллельную компиляцию ^[49];
• E. включим оптимизации;
• F. включим подсветку синтаксиса для c++11, в нескольких местах;
• G. подправить баг связанный с “#include” (случается, если несколько раз менять “Current builder”; может случиться и в других случаях).

Перед настройкой {A} надо подправить один из файлов проекта. В файле “inet/.oppfeatures” есть строка “inet.examples.visualization” нужно добавить после нее пустую строку, в которой написать “inet.tutorials.visualization”, желательно сохранив отступ слева (по аналогии с другими параметрами “nedPackages” в файле). Если это не сделать, то ничего страшного не случится, просто после настройки в “Problems” (Alt+Shift+Q,X) будут всегда висеть ошибки, связанные с “inet.tutorials.visualization”. Можно вначале сделать {A}, и посмотреть на ошибки, а затем подправить файл “inet/.oppfeatures” – при этом Eclipse предупредит о нарушении целостности в настройках, и предложит профиксить их (соглашаемся на это).

Приступим (панель “Project Explorer” > проект “inet” > контекстное меню > Properties):

1. Раздел “OMNeT++” > подраздел “Project Features”
   1. {A} убираем все, кроме:
      • TCP Common
      • TCP (INET)
      • IPv4 protocol
      • UDP protocol
      • Ethernet
   2. кнопка “Apply”.
2. Раздел “С/С++ Build”:
   1. кнопка “Manage Configurations…” > сделать активным “gcc-release” {B};
   2. выбрать конфигурацию “gcc-release [ Active ]” {B}.
   3. Подраздел “Tool Chain Editor”:
      1. в качестве “Current builder” выбрать “GNU Make Builder” для обеих конфигураций: “gcc-debug” и “gcc-release” {C}, внимание: если в будущем изменить “Current builder”, то все придется перенастраивать заново!
      2. кнопка “Apply”.
   4. Вкладка “Behavior” (вернутся в корень раздела “С/С++ Build”):
      1. использовать все ядра CPU для компиляции ^[50] {D} (настраиваем для “gcc-debug” и “gcc-release”).
   5. Вкладка “Build Settings”:
      1. отключить “Use default build command”;
      2. строку “Build command” заменить на “make MODE=release CONFIGNAME=${ConfigName} -j17” (“17” заменить на предыдущее значение в строке, т.е. на выбранный N) {E}, то же самое можно сделать и для конфигурации “gcc-debug”, заменив в строке “MODE=release” на “MODE=debug”, после этого не забудь переключиться обратно на “gcc-release [ Active ]”.
   6. кнопка “Apply”.
3. Раздел “С/С++ General”:
   1. Подраздел “Paths and Symbols”:
      1. Вкладка “Includes”:
         1. кнопка Add: добавить директорию “../src” с выбранными “Add to all configurations” и “Add to all languages” {G} – изначально “../src” есть в языке “GNU C++”, но, в неопределенный момент, он может стереться из списка;
         2. кнопка “Apply”, и проверь, что “../src” появилось во всех языках и конфигурациях.
      2. Вкладка “Symbols”:
         1. кнопка Add: добавить символ “__cplusplus” со значением “201103L” и выбранными “Add to all configurations” и “Add to all languages” – {F} подробнее ^[51];
         2. кнопка “Apply”, и проверь, что в конфигурации “gcc-debug” у “__cplusplus” значение “201103L”.
      3. Вкладка “Source Location”:
         1. Проверь, что в списке один пункт, и он указывает на “/inet/src” {G}, если там что‑то другое (например, просто “/inet”), то удаляй то, что есть и добавь (“Add Folder…”) “/inet/src”. Затем кнопка “Apply”, и возвращение к {A}, т.к. все фильтры при удалении были стерты. Кстати, “/inet” на самом деле можно оставить – с ним тоже все нормально собирается, но лучше сузить до оригинального “/inet/src”.
   2. Подраздел “Preprocessor Include Paths, Marcos etc.” > вкладка “Providers”:
      1. Выбрать “CDT GCC Build-in Compiler Settings”:
         1. В группе “Language Settings Provider Options” нажать на ссылку “Workspace Settings”:
            1. вкладка “Discovery”: опять выбрать “CDT GCC Build-in Compiler Settings”, и добавить “-std=c++11 ” перед “${FLAGS}” в “Command to get compiler specs”, должно получится примерно так `${COMMAND} -std=c++11 ${FLAGS} -E -P -v -dD "${INPUTS}"` {F}, подробнее здесь ^[52] и здесь ^[53];
            2. кнопка “Apply”, “Ok” (закрываем окно).
         2. переместить “CDT GCC Build-in Compiler Settings” выше “CDT Managed Build System Entries” (для обеих конфигураций: “gcc-release” и “gcc-debug”) {F}, подробнее ^[54] – после этого мы потеряем возможность переопределять символы “CDT GCC Build-in Compiler Settings” через “CDT Managed Build System Entries” (“С/С++ General” > “Paths and Symbols” > “Symbols”), переопределить можно будет только через добавление значений в “CDT User Settings Entries” во вкладке “Entries” для каждого языка по отдельности (альтернатива: не меняем порядок, т.к. в “CDT Managed Build System Entries” уже исправили значение “__cplusplus”; не меняем порядок, удаляем все упоминания “__cplusplus” из “CDT Managed Build System Entries”, и следим, чтобы он там не появлялся в будущем);
         3. кнопка “Apply”, и проверить, что во вкладке “Entries” у языка “GNU C++” в “CDT GCC Build-in Compiler Settings” (чекбокс [в нижней части окна] “Show build-in values” должен быть включен) есть запись “__cplusplus=201103L” (она будет ближе к концу).
   3. Подраздел “Indexer”:
      1. в качестве “Build configuration for indexer” выбрать “gcc-release” {B};
      2. кнопка “Apply”.

Некоторые проблемы могут возникнуть с {E}. Поясню. Если все нормально, то Eclipse должен подхватить ^[55] те настройки, которые были заданы в “configure.user” перед конфигурированием OMNeT++ (./configure). В таком случае Eclipse передаст нужные параметры в g++ через make. Однако не всегда все идет, как планировалось, и лучше проверить, что происходит в реальности. Проверить можно, дописав в “Build command” {E} “--just-print ^[56]” или “--trace ^[57]”, и, запустив сборку (панель “Project Explorer” > проект “inet” > контекстное меню > “Clean Project” и “Build Project”), открыть “Console” (Alt+Shift+Q,C), в нем должно выводится что‑то похожее на “g++ -c -std=c++11 -O2 -fpredictive-commoning -march=native -freorder-blocks-and-partition -pipe -DNDEBUG=1 …”. Если этого нет, то можно последовать совету из уже упомянутой статьи ^[55].

Кстати, при некоторой сноровке, параметры запуска g++ можно было посмотреть, не используя флаги “--just-print ^[56]” и “--trace ^[57]”, а используя Process Explorer ^[58]. В Process Explorer также можно посмотреть, во что раскрывается “-march=native” при передаче в “cc1plus.exe”.

Теперь, наконец, можно собрать INET! Проверьте, что сейчас активна конфигурация “gcc-release” {B}, и если добавляли ранее флаги “--just-print ^[56]” или “--trace ^[57]” для проверки {E}, то их нужно убрать. Собираем (панель “Project Explorer” > проект “inet” > контекстное меню > “Clean Project” и “Build Project”), за процессом можно наблюдать в “Console” (Alt+Shift+Q,C).

Если все прошло хорошо, то рекомендую закрыть Eclipse, и сделать бекап файла “.cproject” и директории “.settings” с настройками проекта {B-G}, а также файлов: “.oppfeatures”, “.oppfeaturestate”, “.nedexclusions” – {A}.

Наконец, настройка завершена, и можно перейти к самому интересному.

# ^[59] Создание первого проекта

Note: Первое, что я сделал после настройки окружения – стал изучать содержимое директории “doc” у OMNeT++ и INET. Это были Simulation Manual и User Guide, позже к ним присоединился Stack Overflow (в виде stackoverflow.com, и в виде состояния мозга ^[60]). Ниже я покажу, как можно сделать первые шаги, не читая всю документацию, и расскажу, с какими “особенностями” можно столкнуться.

Note: Для тех, кто еще не успел установить себе OMNeT++ и INET, но уже хочет посмотреть на код, текст ниже содержит ссылки на исходники INET в GitHub. Все ссылки ведут на исходники версии 3.4.0 (эти ссылки будут доступны всегда, даже если в будущих версиях расположение файлов в INET изменится).

Перед созданием своего проекта хорошо бы посмотреть на уже готовые модели в INET, посмотреть, как они устроены. Может в нем уже реализовано то, что нам нужно?

После непродолжительного блуждания по дереву INET в “Project Explorer”, можно наткнуться на директорию “inet/src/inet/applications”, и обнаружить в ней “udpapp ^[61]” (UDP Application). UDP пригодится нам для broadcast рассылки. Внутри директории лежат несколько моделей, и, судя по названию и размеру исходников, самый простой из них, это “UDPEchoApp ^[62]”. Там есть еще и “UDPBasicApp”, но он оказался ^[63] не таким уж и “Basic”. Каждая модель состоит из “.cc”, “.h” и “.ned” файлов. Пока не ясно, зачем нужны “.ned” файлы, но судя по их содержанию (наличию строчки “parameters:” ^[64]) в них могут описываться параметры модели.

Продолжим поиски интересных моделей. Посмотрим, какие примеры (inet/examples ^[65]) есть в INET. И нам повезло, в нем есть пример с названием “broadcast” (inet/examples/inet/broadcast ^[66])! Этот пример помимо файлов “.cc”, “.h” и “.ned”, содержит еще “.ini” и “.xml” файлы. Пора разобраться, зачем эти файлы нужны:

• .ned – файл/язык ^[67], описывающий либо модель сети (Network ^[68]), либо простейшие блоки (Simple modules ^[69]) “кирпичики”, из которых можно собирать модули (Compound module ^[70]). В целом это выглядит так ^[71] (картинка), т.е. можно собрать модель сети, и провести несколько экспериментов не написав ни одной строчки на C++.
• omnetpp.ini – файл ^[72], в котором можно задать/переопределить ^[73] параметры модели. Если нужно провести несколько экспериментов с разными параметрами, то всех их можно перечислить (Named Configurations ^[74]) в этом же файле.
• .xml – просто файл ^[75] с настройками ^[76], которые считывает один из используемых модулей (IPv4NetworkConfigurator ^[77]).

К сожалению, этот пример (“broadcast”) нам не подойдет, т.к. в его сеть включены маршрутизаторы ^[78]. Однако, по аналогии с ним, можно создать свой проект.

Simulation Manual ^[79]. Как видите, он достаточно большой, браузеру требуется время (и RAM) для его открытия. Для решения этой проблемы я сделал небольшой JS ^[80]‑bookmark ^[81]let ^[82]. После его ^[83] запуска все ссылки, ведущие на разделы Simulation Manual, перестанут плодить вкладки (пожирая ресурсы), и начнут переключать разделы в одной единственной дополнительной вкладке (на самом деле он просто прописывает target для каждой ссылки на Simulation Manual). Bookmarklet расположен в первом комментарии ^[83] к этой статье. И, для того, чтобы отличить ссылки на Simulation Manual от остальных ссылок, bookmarklet изменяет их цвет.

# ^[84] Создаем проект

Пустой проект “LLTR”, с директориями “src” и “simulations”, и единственной конфигурацией “gcc-release” (File → New → OMNeT++ Project…):

Осталось настроить проект также как и “inet”, и можно будет двигаться дальше. В основном, настройка будет отличаться отсутствием необходимости настраивать “gcc-debug” (т.к. он отсутствует в “LLTR”), и добавлением в зависимости “inet”. Более конкретно: вместо {A,B,G} надо открыть раздел “Project References”, и включить зависимость от “inet”.

# ^[85] Структура проекта

Если посмотрите на файлы, которые создал Wizard, то увидите, что файл “package.ned” встречается дважды: в директории “src”, и в “simulations”. Содержимое тоже отличается – “package lltr;” и “package lltr.simulations;” соответственно. Один из этих файлов нам не понадобится.

Если провести аналогию со структурой проекта INET, то директория “inet/src” – это “LLTR/src”, а “inet/examples” – это “LLTR/simulations”. То есть в “LLTR/simulations” лучше размещать файлы “.ned” c Network ^[68], а в “LLTR/src” – составные части сети (модули).

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

В свете вышеописанного, “.ned” в директории “LLTR/src” нам не нужен (все будет в “inet/src”), также как и не нужен дополнительный подпакет “package lltr.simulations;” в “LLTR/simulations”. Поэтому переносим “package.ned” из “LLTR/src” в “LLTR/simulations”.

# ^[86] Пробный запуск

Попробуйте запустить LLTR. Для этого достаточно открыть файл “LLTR/simulations/omnetpp.ini”, и нажать (Run > Run As > 1 OMNeT++ Simulation):

При этом Eclipse предложит создать новую конфигурацию “simulations” для запуска симулятора. Соглашаемся, и сразу же сталкиваемся с проблемой: “LLTR/src/LLTR.exe” не был найден. Все верно, ведь “LLTR.exe” никто не собирал, поэтому вначале собираем проект (меню Project → Build Project), а затем опять запускаем симулятор (тем же самым способом).

После запуска симулятора появилось предупреждение “No network specified in the configuration.”, его можно исправить, добавив строку “network = lltr.Network” в секцию “[General]” файла “omnetpp.ini”, и добавив строку “network Network {}” в конец файла “package.ned”. Этим мы создали пустую сеть (в “.ned” файле), и настроили (в “.ini” файле) симулятор на загрузку этой сети (Network – имя сети) при запуске.

Теперь можно попробовать опять запустить симулятор (Run > Run As > 1 OMNeT++ Simulation), и вместо ошибки должно открыться серое поле (прямоугольник) сети Network на зеленом фоне.

Note: Есть различие между запуском через (Run > Run As > 1 OMNeT++ Simulation), и через (Run > 1 simulations): в первом случае запуск проходит быстрее, т.к. во втором случае, перед запуском симулятора, Eclipse начинает собирать проект.

тег a1_v0.1.0 ^[87] (“a” – article) “git checkout -b ‹my_branch› tags/a1_v0.1.0 ^[88]”) ^[87]

# ^[89] Рекомендации по использованию репозитория

Репозиторий я создавал таким образом, чтобы:

• каждый шажок из tutorial совпадал с коммитом в git;
• можно было легко сослаться из tutorial на конкретный коммит – для этого каждый значимый коммит имеет свой тег;
• можно было клонировать (скачать) к себе только коммиты, относящиеся к текущей части (article) – для этого каждая часть имеет свою ветку (формат имени: “article_#”), указывающую на последний коммит/тэг части;
• любой смог легко создавать свою версию исходного кода из репозитория, “шагая” по tutorial.

Note: без веток “article_#” можно было бы обойтись, и указывать, при клонировании, название последнего тега части (которое еще надо найти), но с веткой проще/быстрее.

Как забрать репозиторий “к себе”? Лучше всего, вначале его форкнуть на GitHub ^[90], а затем свой форк:

• либо клонировать весь “git clone”;
• либо клонировать только коммиты по текущую часть “git clone --branch ‹article_#› --single-branch ^[91]” (без использования “--depth ^[92]”), а для получения коммитов следующей части использовать “git remote set-branches –add ^[93]” (и если что‑то пойдет не так… ^[94])

Далее, для создания личной ветки на основе конкретного тега, можно использовать “git checkout -b ‹my_branch› tags/‹tag_name› ^[88]”.

Как создавать свою версию кода, т.е. изменять код? Если в будущем не возникнет желания сделать Pull Request, то ничего вам не мешает делать с форком что хотите >:-), однако я советую, при появлении изменений, которые хочется сохранить, делать так):

Одинаковая схема наименования тегов поможет в будущем избежать коллизий, даже не смотря на то, что теги при Pull Request не переносятся ^[95].

Note: Если я в будущем буду вносить изменения в репозиторий, то я поступлю также: оригинальный код сохранится, а измененный будет идти параллельно оригинальному (с “накатанными” всеми изменениями из остальных (будущих) тегов, и с новыми именами тегов). Только вместо добавления “-u” к именам новых тегов тегам, я буду увеличивать номер. Например, теги оригинального кода “a1_v0.1.0”, “a1_v0.2.0”, … – теги измененного кода “a1_v0.1.1”, “a1_v0.2.1”, … При следующем изменении, номер еще раз увеличится: “a1_v0.1.2”, “a1_v0.2.2”, …

Note: в tutorial все места, завершающие очередной “шажок”, помечены значком git , и рядом с ним будет ссылка на соответствующий git tag.

Note: git diff использовался стандартный, патчи генерировались автоматически, и они редко будут показывать логической связи в произошедших изменениях (в частности, при добавлении нового кода и изменении уровня вложенности / форматирования существующего кода) (здесь бы пригодилось отслеживание изменений на уровне AST ^[96]), похожее на этот проект для Java ^[97].

# ^[98] Создание первой модели (Link Layer Topology Reveal)

# ^[99] Шаг −1: собираем сеть

Откроем “package.ned” в режиме графического редактирования схемы (вкладка “Design” снизу), и попробуем набросать сеть из КДПВ ^[100]:

Сеть построена из тех же модулей, которые были использованы в примере broadcast ^[101]:

• хосты – StandardHost;
• свитчи – EtherSwitch.

А вот в качестве “провода” (канала связи) выбран Eth100M (скорость: 100 Mbps; длина: 10 метров). Кстати, почему именно 10 метров, где они задаются, и можно ли поменять это значение? (ответ чуть ниже)

увидеть примерно это (git tag a1_v0.2.0) ^{[102] [103]}. Пояснение структуры:

package ‹<a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-ref:packages">имя пакета</a>›; //<a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-ref:directory-structure">особенности наименования</a>

import ‹<a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-lang:imports-and-name-resolution">имя подключаемого пакета</a>›;

network ‹<a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-lang:warmup:network">название описываемой сети</a>›
{
    @display(‹визуальные параметры сети, например, размер области›);
    <a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-ref:submodules">submodules</a>:
        ‹<a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-lang:submodules">название узла</a>›: ‹тип узла› { @display(‹визуальные параметры узла, например, местоположение›); }
    <a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-ref:connections">connections</a>:
        ‹название узла›.‹<a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-lang:gates">точка соединения</a>› <--> ‹тип канала связи› <--> ‹название узла›.‹точка соединения›;
}

Warning: К сожалению Хабр пока не поддерживает вставку ссылок при помощи тега <a>...</a> – вместо ссылок сейчас в код “вставляются” сами теги. И так происходит не только с этим блоком кода, но и со всеми ниже, в которых использовалась вставка ссылок, либо выделение частей кода при помощи тегов (<strong>...</strong>, <em>...</em>).

Отдельно стоит сказать про “точки соединения” (Gates) и каналы связи ^[111]:

1. Gates могут быть объявлены как векторы ^[112], в этом случае подключатся к ним можно явно, указав номер gate ^[109] “‹название узла›.‹gate›[‹номер›]”, либо автоматически – инкрементально ^[109] “‹название узла›.‹gate›++”.
2. Параметры канала либо могут быть заданы в месте использования ^[113] (например: “… <--> { delay = 100ms; } <--> …”), либо могут иметь имя/тип ^[114], на которое можно ссылаться ^[115] (как в примере broadcast ^[116]: “… <--> C <--> …”), либо могут иметь тип и быть переопределены на месте ^[117] (например: “… <--> FastEthernet {per = 1e-6;} <--> …”), либо… ^[118]
3. Gates могут быть однонаправленными (тип при объявлении: output / input; соединители при подключении: --> / <--), и двунаправленными ^[119] (тип при объявлении: inout; соединитель при подключении: <--> ). Двунаправленные состоят из двух однонаправленных, к которым можно обратиться напрямую, дописав суффикс “$i” либо “$o” ^[120].

Warning: К сожалению парсер Хабра пока смог обработать только ¹⁄₃ публикации за отведенные ему 20 секунд (приходит ошибка 504 “Gateway Time-out”). Но даже эти ¹⁄₃ позволили обнаружить еще один баг в парсере. Небольшой пример (исходная разметка):

Выполните в точности эту <a href="#set">команду: “<code>set: p=1.87548</code>”</a> в терминале своего портативного ядерного реактора.

После парсера:

Выполните в точности эту <a href="#set"><code>команду: “set: p=1.87548</code>”</a> в терминале своего портативного ядерного реактора.

Увидеть этот баг в действии можно, взглянув на конец 3‑го пункта в списке выше. Его оригинальная разметка выглядела так:

можно обратиться напрямую, <a href="https://omnetpp.org/doc/omnetpp/manual/#sec:ned-ref:inout-gates">дописав суффикс “<strong><code>$i</code></strong>” либо “<strong><code>$o</code></strong>”</a>.

Хорошая новость в том, что парсер ^[121] сейчас переписывают ^[122]. И, чтобы не ждать окончания этого процесса, я разместил полную версию публикации на GitHub Pages:

^[123]

Note: В полной версии я упростил активацию target у ссылок на Simulation Manual – вместо запуска bookmarklet'а, достаточно нажать на кнопку здесь ^[124]. К тому же при открытии полной версии через кнопку «Читать дальше →», активация произойдет автоматически.

Note: Разметка, CSS и JS этой страницы могут показаться странными – все дело в том, что процесс подготовки публикации у меня разбит на 3 этапа, и в GitHub Pages находится немного измененный результат 2‑го этапа (обычный HTML, пригодный для просмотра в браузере, и, при этом, максимально близкий к хабра‑разметке). 3‑й этап – это модификация разметки под Хабр.

# ^[125] В следующих частях / To be continued…

• 2. Алгоритм определения топологии сети по собранной статистике
• 3. OMNeT++ продолжение
• 4. Математика
• 5. OMNeT++ продолжение 2
• 6. Реализация
• 7. Эксперимент (название‑спойлер: “в конце Джон умрет ^[126]”)

# ^[127] Обратная связь

Небольшой опрос. Первый вопрос поможет мне лучше определить время для публикации следующей части. Второй – улучшить статью. Остальные вопросы – чистое любопытство.

Автор: ZiroKyl

Источник ^[128]