Материал: 1308

рования, порожденного прежде выполнения моделирования. Объект планировщик событий должен сам моделировать методы планирования такие как at time "string", который выпускает специальное событие, называемое AtEvent, в указанное время моделирования " time".. Событие "AtEvent" – фактически потомок класса “Event", который имеет дополнительную переменную для поддержки данной строки "string". Однако, он обработан так же, как нормальный (связанный с пакетом) случай в пределах планировщика событий. Когда моделирование начато, и как только наступает намеченное время для "AtEvent" в очереди событий, "AtEvent" пропускают к обработчику "AtEvent handler" который создан один раз и обрабатывает все AtEvents и OTCL команды, указанные полем "string" метода "AtEvent" для выполнения. Далее –- версия рассмотренного выше примера с добавленной строкой планирования события моделирования.

. . .

set ns [new Simulator] $ns use-scheduler Heap

$ns at 300.5 "complete_sim"

. . .

proc complete_sim {} {

. . .

}

Из приведенного примера можно заметить, что at time "string" – метод объекта Simulator (set ns [new Simulator]). Но следует помнить, что объект Simulator действует только как интерфейс пользователя, и он фактически вызывает методы сетевых объектов или объектов планирования, которые и делают реальную работу. Следующие строки – частичный список и краткое описание методов объекта Simulator, которые связаны интерфейсом с методами планировщика:

# возвращает понятие планиров-

# намечает выполнение програм-

Simulator instproc at-now args # намечает выполнение про-

граммы теперь

31

Simulator instproc after n args # намечает выполнение про-

Рассмотренный ниже раздел демонстрирует пример анализа результатов моделирования. В качестве примера используется тот же самый OTcl сценарий с добавлением нескольких строк для того, чтобы открыть файл трассировки и записывать в него ход моделирования. Сетевая топология и сценарий моделирования формируются также в соответствии с рисунком 1. Для выполнения этого сценария загрузить в свой каталог файл "ns- simple-trace.tcl", размещенный в папке

S:\БогомоловСИ\NS\Lab3\Metod\, и набрать в командной строке "ns ns-simple-trace.tcl". (Оригинал программы доступен по адресу

<http://nile.wpi.edu/NS/Example/ns-simple-trace.tcl>.

Рис.3. Изменения, вносимые в программу для трассировки

32

При выполнении Otcl сценария формируется файл трассировки NAM, который будет использован для ввода в NAM и файл трассировки, называемый "out.tr", который будет использован для анализа результатов моделирования. На рисунке 4 представлен формат файла трассировки а также пример возможных данных трассировки из файла "out.tr".

Рис. 4. Пример формата трассировки

Каждая строка трассировки начинается с дескриптора события (+,-, d, r), сопровождаемого временем моделирования (в секундах) этого события, и номерами узлов отправителя и получателя, идентифицирующие линию связи, на которой произошло событие. Здесь приняты следующие условные обозначения: “r” – получение пакета, “+” – добавление пакета к очереди, “-” – снятие пакета из очереди, “d” – удаление пакета из сети. После сведений о типе пакета и его размере (в байтах) следует информации об установленных флагах (в примере показано как"------", поскольку не установлены никакие флаги. В настоящее время, NS применяет только бит уведомления о явной перегрузке (ECN), а остальные биты не используются. Следующее поле – поток идентификаторов (fid) IPv6, которые пользователь может устанавливать для каждого потока при вводе OTcl сценария. Даже в том случае, если поле fid не использовано при моделировании, пользователи могут использовать это поле для целей анализа. Поле fid также используется при задании цвета потока для

33

дисплея NAM. Следующие два поля – адреса источника и приемника в формате "узел.порт". Следующее поле показывает номер последовательности пакета протокола сетевого уровня. Заметим, что даже несмотря на то, что UDP реализация не использует номер последовательности, NS сохраняет строчку UDP номеров последовательности пакетов для целей анализа. Последнее поле показывает уникальный идентификатор пакета.

Динамика сетей

В этом разделе приведен пример динамичной сети, где маршрутизация приспосабливается к повреждениям связи. Попутно показано, как можно выполнить большое количество узлов в Tcl массиве вместо предоставления каждому узлу его собственного названия.

Предлагается назвать Tcl сценарий для этого примера 'example3.tcl'. В файл уже может быть вставлен шаблон example.tcl из каталога Lab2.

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

for {set i 0} {$i < 7} {incr i} { set n($i) [$ns node]

}

Циклы 'for'используются и в других языках программирования, так, что структура понятна. Следует обратить внимание, что массивы, точно так же, как другие переменные в Tcl, не должны быть объявлены первыми.

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

for {set i 0} {$i < 7} {incr i} {

$ns duplex-link $n($i) $n([expr ($i+1)%7]) 1Mb 10ms Drop-

Tail

}

Этот цикл 'for' соединяет каждый узел массиве со следующим узлом за исключением последнего узла, который соединяется с первым. Чтобы это выполнять, использован оператор '%' (по модулю).

34

Теперь при запуске программы топология в NAM сначала может выглядеть немного странной, но после нажатия кнопки 're-layout'схема примет более привычный вид.

Следующим шагом является пересылка некоторых данных от узла n0 к узлу n3.

#Create a UDP agent and attach it to node n(0) set udp0 [new Agent/UDP]

$ns attach-agent $n(0) $udp0

# Create a CBR traffic source and attach it to udp0 set cbr0 [new Application/Traffic/CBR]

$cbr0 set packetSize_ 500 $cbr0 set interval_ 0.005 $cbr0 attach-agent $udp0

set null0 [new Agent/Null] $ns attach-agent $n(3) $null0

$ns connect $udp0 $null0

$ns at 0.5 "$cbr0 start" $ns at 4.5 "$cbr0 stop"

Представленная выше программа должна выглядеть уже знакомой к этому времени. Единственное различие от прошлых разделов в том, что теперь используются элементы массива узлов.

Если теперь запустить сценарий (предварительно сохранив его под именем 'example3a.tcl'), будет видно, что поток информации выбирает самый короткий путь от узла n0 к узлу n3 через узлы n1 и n2, как и следовало ожидать. Затем добавляется другая интересная особенность. Предполагается нарушение связи между узлами n1 и n2 (которые используются трафиком) в течение секунды.

$ns rtmodel-at 1.0 down $n(1) $n(2)

$ns rtmodel-at 2.0 up $n(1) $n(2)

Вероятно, не слишком трудно понять эти две строки. Теперь можно стартовать сценарий снова (предварительно сохранив его под именем 'example3b.tcl'), и можно будет видеть, что между

35