общем, NS сценарий начинается с создания экземпляра объекта моделирования.
∙set ns [new Simulator]: создает экземпляр объекта NS Simulator и определяет его переменной ns (здесь и далее курсив используется для переменных и значений). Эта строка делает следующее:
o Инициализирует формат пакета (это пока игнорировать). o Создает планировщика (значение по умолчанию – кален-
дарный планировщик).
o Выбирает формат адреса по умолчанию (это пока игнорировать)
Объект Simulator содержит методы, которые выполняют следующее:
o Создание составных объектов типа узлов и связей (описано позже)
o Подключение созданных объектов сетевых компонентов (исключая. присоединение агентов)
o Установка параметров сетевых компонентов (главным образом для составных объектов)
o Создание соединения между агентами (исключая. создание соединения между "tcp" и "sink")
o Определение опций отображения NAM o И т.д.
Большинство методов существуют для установки моделирования и планирования, однако некоторые из них предназначены для отображения NAM. Реализации методов объекта Simulator
размещены в файле "opt/ns/2.33/ns-2.33/tcl/lib/ns-lib.tcl".
∙$ns color fid color: для установки цвета пакетов для потока, указанного идентификатором потока (fid). Этот метод объекта Simulator - для отображения NAM и не оказывает никакого эффекта на фактическое моделирование.
∙$ns namtrace-all file-descriptor: Этот метод указывает симулятору делать запись трассировки моделирования в формате ввода NAM. Он также дает имя файлу, в который трассировка будет записана позже командой $ns flush-trace. Точно так же метод trace-all используется для записи трассировки моделирования в общем формате.
26
∙proc finish {}: после того, как окончено это моделирование, вызывается командой $ns at 5.0 "finish". В этой функции определены процессы по окончанию моделирования.
∙set n0 [$ns node]: Метод node создает узел. Узел в NS – это составной объект, созданный классификаторами адреса и порта (описанные позже). Пользователи могут создавать узлы, отдельно создавая объекты классификатора порт и адрес и затем соединять их вместе. Однако, этот метод объекта Simulator делает работу более легкой. Подробнее рассмотреть как создан узел можно в файлах: "opt/ns/2.33/ns-
2.33/tcl/libs/ns-lib.tcl" |
и |
"opt/ns/2.33/ns-2.33/tcl/libs/ns- |
node.tcl". |
|
|
∙$ns duplex-link node1 node2 bandwidth delay queue-type: созда-
ет две однонаправленные линии связи указанной пропускной способности и задержки, и подключает к двум указанным узлам. В NS выходная очередь узла выполнена как часть канала, поэтому пользователи должны определить тип очереди при создании линии связи. В рассмотренном сценарии моделирования используется очередь типа DropTail. Если нужно использовать очередь типа RED, следует просто заменить слово DropTail на RED. Реализация линии связи в NS будет показана позже. Так же как и узел, линия связи – составной объект, и пользователи могут создавать его подобъекты и подключать их к узлам. Ссылки на исходные тексты могут быть найдены в файлах "opt/ns/2.33/ns-2.33/tcl/libs/ns-lib.tcl" и "opt/ns/2.33/ns-2.33/tcl/libs/ns-link.tcl". Следует обратить вни-
мание, что в компонент линии связи можно вставлять модули ошибок, чтобы моделировать потери связи (фактически пользователи могут создавать и вставлять любые сетевые объекты). Для того, чтобы выяснить, как делать это, следует обратиться к документации NS.
∙$ns queue-limit node1 node2 number: Эта строка устанавливает ограничение очереди двух однонаправленных линий связи, которые соединяют узлы node1 и node2 указанным числом.
Доступные методы объекта Simulator следует смотреть на
"opt/ns/2.33/ns-2.33/tcl/libs/ns-lib.tcl" и "opt/ns/2.33/ns- 2.33/tcl/libs/ns-link.tcl", либо в NS документации для получе-
27
ния дополнительной информации.
∙$ns duplex-link-op node1 node2 ...: Следующая пара строк используется для отображения NAM. Чтобы видеть эффекты этих строк, пользователи могут прокомментировать эти
строки и попытаться моделировать.
Теперь, когда основная установка сети выполнена, следующее, что нужно сделать – это установить агенты трафика типа TCP и UDP, источники трафика типа FTP и CBR, и прикреплять их, соответственно, к узлам и агентам.
∙set tcp [new Agent/TCP]: Эта строка показывает, как создать TCP агента. Но в общем, пользователи могут таким образом создавать любого агента или источника трафика. Агенты и источники трафика – фактически основные объекты (не составные объекты), главным образом осуществленные в C++ и связанные с OTcl. Однако нет никаких определенных методов объекта Simulator, которые бы создавали эти экземпляры объекта. Чтобы создавать агенты или источники трафика, пользователь должен знать имена классов этих объектов
(Agent/TCP, Agnet/TCPSink, Application/FTP и так далее). Эта информация может быть найдена в NS документации или частично в этом документе. Но один ярлык должен указы-
вать на файл "opt/ns/2.33/ns-2.33/tcl/libs/ns-default.tcl". Этот файл содержит заданные по умолчанию значения конфигурируемых параметров настройки для доступных сетевых объектов. Поэтому это работает как хороший индикатор: какие сетевые объекты доступны в NS и каковы их конфигурируемые параметры.
∙$ns attach-agent node agent: Метод attach-agent прикрепляет созданный объект агента к объекту узла. Фактически, что эта функция вызывает метод attach определенного узла, который прикрепляет к себе данного агента. Поэтому, пользователь может делать такую же самую вещь, например, $n0 attach $tcp. Точно так же, каждый объект агента имеет метод attachagent, который прилагает к себе объект источника трафика.
∙$ns connect agent1 agent2: После того, как созданы два агента, которые будут связаны друг с другом, следующее – это установление логического сетевого соединения между ними.
28
Эта строка устанавливает сетевое соединение, задавая адресатам назначения пару адресов портов.
Полагая, что вся сетевая конфигурация закончена, следующая вещь, которую надо сделать – написать сценарий моделирования (то есть планирование моделирования). Объект моделирования имеет много методов планирования. Однако, тот, который наиболее часто используется – следующей:
$ns at time "string": Этот метод объекта Simulator заставляет планировщика (scheduler_ – это переменная, которая указывает объекту планировщику, созданному командой [new Scheduler] в начале сценария) наметить выполнение указанной строки в данное время моделирования. Например, $ns at 0.1 "$cbr start" заставит планировщика вызвать метод start CBR объекта источника трафика, который запускает CBR для передачи данных. Обычно, в NS источник трафика не передает реальные данные, но он уведомляет нижележащего агента, что он имеет некоторое количество данных для передачи, и агент, зная только сколько данных есть для передачи, формирует пакеты и посылает их.
После того как все описания процедур сетевой конфигурации, планирования и окончания моделирования сделаны, единственное, что остается – это запустить моделирование. Это выполняется с помощью $ns run..
Планирование событий в NS и анализ трассировки
В этом разделе речь идет о дискретных планировщиках событий NS. Главные пользователи планировщика событий – сетевые компоненты, которые моделируют задержку обработки пакета или которым необходимы таймеры. На рисунке 2 показаны сетевые объекты, использующие планировщик событий. Заметим, что есть сетевые объекты, которые выдают событие, и есть объекты, которые обрабатывают событие позднее в намеченное время. Также заметим, что путь данных между сетевыми объектами отличается от пути событий. Действительно, пакеты передаются от одного сетевого объекта другому, используя метод отправителя send(Packet* p) {target_->recv(p)} и метод получате-
ля recv(Packet*, Handler* h = 0).
NS имеет два различных типа реализации планировщиков событий. Это планировщики в реальном масштабе времени и в нереальном масштабе времени. Для планировщика в нереальном
29
масштабе времени, доступны три реализации (List, Heap and Calendar - список, куча и календарь), даже при том, что они - все логически исполняют то же самое. Это - из-за обратной совместимости: некоторые раннее выполненные сетевые компоненты, добавленные пользователем (не оригинальные, включенные в пакет) могут использовать определенный тип планировщика не через общедоступные функции, а внутрисистемным взломом.. По умолчанию в нереальном масштабе времени планировщик установлен в значение Calendar. Планировщик в реальном масштабе времени используется как эмулятор, позволяющий тренажеру взаимодействовать с реальной сетью. В настоящее время эмуляция еще не доработана, хотя экспериментальная версия доступна. Далее приведен пример выбора определенного планировщика событий:
. .
set ns [new Simulator] $ns use-scheduler Heap
. .
Рис 2. Дискретный планировщик событий
Такое же использование планировщика событий – наметить события моделирования, типа того, когда запустить приложение FTP, когда закончить моделирование, или для сценария модели-
30