Учебник по симулатор на мрежата ns-3. Глава 5

глави 1,2
глава 3
глава 4

5 Настройка
5.1 Използване на логиращия модул
5.1.1 Преглед на логиране
5.1.2 Разрешаване на логиране
5.1.3 Добавяне на логиране в кода ви
5.2 Използване на аргументи от командния ред
5.2.1 Овъррайдване на стойностите на атрибутите по подразбиране
5.2.2 Улавяне на собствените ви команди
5.3 Използване на системата за проследяване
5.3.1 ASCII Проследяване
Парсинг на ASCII проследяване
5.3.2 Проследяване на PCAP

Глава 5

Настройка

5.1 Използване на логиращия модул

Вече накратко прегледахме логиращия модул на ns‑3, разглеждайки скрипта. В тази глава ще се вгледаме по-отблизо в възможностите за използване на подсистемата за логиране. first.ccМного големи системи поддържат средства за регистриране на съобщения, и ns‑3 не е изключение. В някои случаи, в 'конзолата на оператора' (която обикновено е stderr в Unix-базирани системи) се записват само съобщения за грешки. В други системи могат да се извеждат предупреждаващи съобщения и по-подробна информация. В някои случаи, средствата за логиране се използват за извеждане на отладъчни съобщения, които могат бързо да 'размият' изхода.

5.1.1 Преглед на логиране

Подходът, използван в ns‑3, предполага, че всички тези нива на информативност са полезни, и предоставяме селективен, многослоен подход за регистрация на съобщения. Логирането може да бъде напълно изключено, включено за отделни компоненти или в глобален мащаб. За това служат настраиваемите нива на информативност. Модулът за логиране на ns‑3 осигурява относително прост начин за получаване на полезна информация от симулацията ви.

Трябва да разберете, че предоставяме универсален механизъм — проследяване — за извличане на данни от моделите ви, който трябва да бъде предпочитан за извеждане при моделиране (за по-подробна информация относно нашата система за проследяване вижте част 5.3). Логирането трябва да бъде предпочитаният метод за получаване на отладъчна информация, предупреждения, съобщения за грешки или за бързо извеждане на съобщения от сценарии или модели по всяко време.

В момента в системата са определени седем нива (типове) съобщения за логиране по възходяща информативност.

LOG_ERROR — регистриране на съобщения за грешки (свързан макрос: NS_LOG_ERROR);

• LOG_ERROR — регистрация на съобщения за грешки (свързан макрос: NS_LOG_ERROR);
• LOG_WARN — регистрация на предупредителни съобщения (свързан макрос: NS_LOG_WARN);
• LOG_DEBUG — регистрация на относително редки специални съобщения за отстраняване на грешки (свързан макрос: NS_LOG_DEBUG);
• LOG_INFO — регистрация на информационни съобщения за напредъка на програмата (свързан макрос: NS_LOG_INFO);
• LOG_FUNCTION — регистрация на съобщения, описващи всяка извикана функция (два свързани макроса: NS_LOG_FUNCTION, използван за член-функции, и NS_LOG_FUNCTION_NOARGS, използван за статични функции);
• LOG_LOGIC — регистрация на съобщения, описващи логическия поток вътре в функцията (свързан макрос: NS_LOG_LOGIC);
• LOG_ALL — регистрация на всичко споменато по-горе (няма свързан макрос).
  За всеки тип (LOG_TYPE) има също тип LOG_LEVEL_TYPE, който, ако се използва, позволява регистрация в допълнение към собствения му ниво на всички нива над него. (Следователно, LOG_ERROR и LOG_LEVEL_ERROR, както и LOG_ALL и LOG_LEVEL_ALL, са функционално еквивалентни.) Например, включването на LOG_INFO ще позволи само съобщения, предоставени от макроса NS_LOG_INFO, а при включване на LOG_LEVEL_INFO ще бъдат включени съобщения, предоставени от макросите NS_LOG_DEBUG, NS_LOG_WARN и NS_LOG_ERROR.

Ние също предоставяме макрос за безусловно регистриране, който е видим винаги, независимо от нивото на логиране или компонента на избор.

• NS_LOG_UNCOND — безусловна регистрация на свързано съобщение (без свързано ниво на логиране).

Каждото ниво може да бъде запитано поотделно или кумулативно. Логирането може да бъде настроено с помощта на променлива sh-среда NS_LOG или чрез регистриране на повик на системна функция. Както беше показано по-рано, системата за логиране има Doxygen-документация и сега е точното време да я прегледате, ако все още не сте.

Сега, след като сте прочели документацията много подробно, нека използваме тези знания, за да извлечем интересна информация от примерния скрипт scratch/myfirst.cc, който вече сте компилирали.

5.1.2 Разрешаване на логиране

Нека използваме променливата на средата NS_LOG, за да стартираме още няколко логове, но първо, просто за ориентиране, стартирайте последния скрипт, както направихте преди,

$ .\/waf --run scratch/myfirst

Трябва да видите вече познатия изход на първата примерна програма ns-3

$ Waf: Влизам в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Излизам от директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build' 'build'\nуспешно завършено (0.413s)\nИзпратени 1024 байта до 10.1.1.2\nПолучени 1024 байта от 10.1.1.1\nПолучени 1024 байта от 10.1.1.2

Оказва се, че «изпратените» и «получените» съобщения, които виждате по-горе, всъщност са регистрирани съобщения от UdpEchoClientApplication и UdpEchoServerApplication. Например, можем да помолим клиентското приложение да отпечата допълнителна информация, като зададем нивото на логване чрез променлива на средата NS_LOG.

От този момент нататък ще предположа, че използвате shell, подобен на sh, който използва синтаксиса «VARIABLE = value». Ако използвате shell, подобен на csh, тогава ще трябва да преобразувате моите примери в синтаксиса «setenv VARIABLE value», изискуван от тези shell.

В момента приложението UDP echo-клиент отговаря на следния ред код в scratch/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Това активира нивото на логване LOG_LEVEL_INFO. Когато предаваме флага на нивото на логване, всъщност включваме това ниво и всичките по-ниски нива. В този случай активирахме NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN и NS_LOG_ERROR. Можем да повишим нивото на логване и да получим повече информация, без да променяме скрипта и да компилираме отново, като зададем променливата на средата NS_LOG по следния начин:

$ export NS_LOG=UdpEchoClientApplication=level_all

Така задаваме следната стойност на променливата NS_LOG на sh-shell-а,

UdpEchoClientApplication=level_all

Лявата част на присвояването е името на компонента, който искаме да регистрираме, а дясната част е флагът, който искаме да приложим за него. В този случай ще активираме всички нива на отстраняване на грешки в приложението. Ако стартирате скрипта с зададена по този начин NS_LOG, системата за логване ns-3 ще приеме промените и трябва да видите следния изход:

Waf: Влизам в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\nWaf: Излизам от директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'\n'build' успешно завършено (0.404s)\nUdpEchoClientApplication:UdpEchoClient()\nUdpEchoClientApplication:SetDataSize(1024)\nUdpEchoClientApplication:StartApplication()\nUdpEchoClientApplication:ScheduleTransmit()\nUdpEchoClientApplication:Send()\nИзпратени 1024 байта до 10.1.1.2\nПолучени 1024 байта от 10.1.1.1\nUdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)\nПолучени 1024 байта от 10.1.1.2\nUdpEchoClientApplication:StopApplication()\nUdpEchoClientApplication:DoDispose()\nUdpEchoClientApplication:~UdpEchoClient()

Допълнителната отладъчна информация, предоставяна от приложението, вече съответства на нивото NS_LOG_FUNCTION. Тя показва всеки случай на извикване на функции по време на изпълнението на скрипта. Обикновено, в методите е предпочитано да се използва (поне)NS_LOG_FUNCTION (this). Използвайте NS_LOG_FUNCTION_NOARGS ()
само в статични функции. Въпреки това, имайте предвид, че в системата ns‑3 няма изисквания за поддържане на каквато и да е функционалност за логване. Решението колко информация да се регистрира остава на разработчика на модела. В случаите на ехо-приложения е налично голямо количество изходни данни за логване.

Сега можете да видите дневника на извикванията на функции, които е направило приложението. Ако погледнете внимателно, ще забележите двоеточие между реда UdpEchoClientApplication и името на метода, на мястото, където бихте очаквали да видите оператора за обхват на C++ (: :). Това е направено умишлено.

Наистина, това не е името на класа, а името на компонента за логване. Когато има съвпадение между изходния файл и класа, обикновено това е името на класа, но трябва да разберете, че всъщност това не е името на класа, и там има едно двоеточие вместо двойно двоеточие. Това е начин да ви помогне по относително фин начин концептуално да отделите името на компонента за логване от името на класа.

Въпреки това, в някои случаи може да бъде трудно да се определи кой метод наистина генерира съобщението за логване. Ако погледнете текста по-горе, ще имате въпроса откъде идва редица "Received 1024 bytes from 10.1.1.2". Можете да разрешите този проблем, като зададете нивото prefix_func в променливата на средата NS_LOG. Опитайте следното,

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Обърнете внимание, че кавичките са необходими, тъй като вертикалната черта, която използваме за обозначаване на операция ИЛИ, също е свързваща операция в Unix. Сега, ако стартирате скрипта, ще видите, че системата за логване осигурява, че всяко съобщение от дадения дневник има префикс с името на компонента.

Waf: Влизане в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Излизане от директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' завърши успешно (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Изпратени 1024 байта до 10.1.1.2
Получени 1024 байта от 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Получени 1024 байта от 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Сега можете да видите, че всички съобщения, постъпващи от UDP ехо-клиент приложението, са идентифицирани като такива. Съобщението „Received 1024 bytes from 10.1.1.2» сега е ясно определено като постъпващо от ехо-клиент приложението. Останалото съобщение трябва да дойде от UDP ехо-сервера. Можем да включим този компонент, като въведем списък от компоненти, разделени с двоеточия, в променливата среда NS_LOG.

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:
               UdpEchoServerApplication=level_all|prefix_func'

Предупреждение: в горния пример текст, ще трябва да премахнете символа за нов ред след двоеточието (:), той е използван за форматиране на документа. Сега, ако стартирате сценария, ще видите всички съобщения в логовете от клиентското и сървърното ехо-приложение. Може да видите, че това може да бъде много полезно при отстраняване на проблеми.

Waf: Влизане в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Излизане от директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' завърши успешно (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Изпратени 1024 байта до 10.1.1.2
UdpEchoServerApplication:HandleRead(): Получени 1024 байта от 10.1.1.1
UdpEchoServerApplication:HandleRead(): Ехо на пакета
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Получени 1024 байта от 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Също така понякога е полезно да можете да видите времето на симулацията, в което е създадено съобщението в логовете. Можете да направите това, като добавите по ИЛИ бит prefix_time:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func|prefix_time: UdpEchoServerApplication=level_all|prefix_func|prefix_time'

Отново, ще трябва да премахнете символа за нов ред по-горе. Ако сега стартирате скрипта, трябва да видите следния изход:

Waf: Влизане в директорията `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
Waf: Излизане от директорията `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
`build` приключи успешно (0.418s) 
0s UdpEchoServerApplication:UdpEchoServer() 
0s UdpEchoClientApplication:UdpEchoClient() 
0s UdpEchoClientApplication:SetDataSize(1024) 
1s UdpEchoServerApplication:StartApplication() 
2s UdpEchoClientApplication:StartApplication() 
2s UdpEchoClientApplication:ScheduleTransmit() 
2s UdpEchoClientApplication:Send() 
2s UdpEchoClientApplication:Send(): Изпратени 1024 байта до 10.1.1.2 
2.00369s UdpEchoServerApplication:HandleRead(): Получени 1024 байта от 10.1.1.1 
2.00369s UdpEchoServerApplication:HandleRead(): Повторно предаване на пакета 
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 
2.00737s UdpEchoClientApplication:HandleRead(): Получени 1024 байта от 10.1.1.2 
10s UdpEchoServerApplication:StopApplication() 
10s UdpEchoClientApplication:StopApplication() 
UdpEchoClientApplication:DoDispose() 
UdpEchoServerApplication:DoDispose() 
UdpEchoClientApplication:~UdpEchoClient() 
UdpEchoServerApplication:~UdpEchoServer()

Обърнете внимание, че конструкторът за UdpEchoServer е бил извикан по време на симулацията 0 секунди. Това всъщност се случва преди началото на симулацията, но това време се показва като нула секунди. Същото важи и за съобщението на конструктора UdpEchoClient.

Waf: Влизане в директорията `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
Waf: Излизане от директорията `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build` 
`build` приключи успешно (0.418s) 
0s UdpEchoServerApplication:UdpEchoServer() 
0s UdpEchoClientApplication:UdpEchoClient() 
0s UdpEchoClientApplication:SetDataSize(1024) 
1s UdpEchoServerApplication:StartApplication() 
2s UdpEchoClientApplication:StartApplication() 
2s UdpEchoClientApplication:ScheduleTransmit() 
2s UdpEchoClientApplication:Send() 
2s UdpEchoClientApplication:Send(): Изпратени 1024 байта до 10.1.1.2 
2.00369s UdpEchoServerApplication:HandleRead(): Получени 1024 байта от 10.1.1.1 
2.00369s UdpEchoServerApplication:HandleRead(): Повторно предаване на пакета 
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0) 
2.00737s UdpEchoClientApplication:HandleRead(): Получени 1024 байта от 10.1.1.2 
10s UdpEchoServerApplication:StopApplication() 
10s UdpEchoClientApplication:StopApplication() 
UdpEchoClientApplication:DoDispose() 
UdpEchoServerApplication:DoDispose() 
UdpEchoClientApplication:~UdpEchoClient() 
UdpEchoServerApplication:~UdpEchoServer()

Нека припомним, че скриптът scratch/first.cc стартира приложението за ехо-сървър една секунда преди началото на симулацията. Сега можете да видите, че методът StartApplication на сървъра всъщност се извиква в първата секунда. Също така можете да забележите, че ехо-клиентът се стартира във втората секунда на симулацията, както поискахме в скрипта.

Сега можете да следите хода на симулацията по извикването на ScheduleTransmit в клиента, което извиква обратното повикване HandleRead в приложението за ехо-сървър. Обърнете внимание, че изминалото време за изпращане на пакета през двуточковата връзка е 3,69 милисекунди. Ясно е, че ехо-сървърът регистрира съобщение, че е отговорил на пакета, а след това, след забавяне на канала, вие виждате, че ехо-клиентът получава ехо-пакета в своя метод HandleRead.

В тази симулация много неща се случват незабелязано за вас. Но можете много лесно да проследите целия процес, като включите всички компоненти за логиране в системата. Опитайте да зададете следното значение на променливата NS_LOG,

$ export 'NS_LOG=*=level_all|prefix_func|prefix_time'

Звездичката по-горе е символ на подмяна за компонента за логиране. Това ще включи всички записи във всички компоненти, използвани в симулацията. Няма да възпроизвеждам изхода тук (в момента на писане той произвежда 1265 реда изход за един ехо-пакет), но можете да пренасочите тази информация в файл и да я прегледате в любимия си редактор.

$ .\/waf --run scratch\/myfirst > log.out 2>&1

Лично аз използвам тази изключително подробна версия на логовете, когато имам проблем и нямам идея къде нещата са тръгнали наопаки. Мога доста лесно да следя изпълнението на кода, без да настройвам точки на спиране и да стъпвам през кода в отладчика. Мога просто да редактирам изхода в любимия си редактор и да търся това, което очаквам, и да виждам как става нещо, което не съм очаквал. Когато имам обща представа какво не е наред, отивам в отладчика за по-подробно разглеждане на проблема. Този вид изход може да бъде особено полезен, когато скриптът ви прави нещо напълно неочаквано. Ако използвате само отладчика, можете напълно да пропуснете неочакван обрат. Логването прави такива обрати забележими.

5.1.3 Добавяне на логиране в кода ви

Можете да добавите нови записи в симулациите си, извиквайки компонента log от няколко макроса. Нека направим това в сценария myfirst.cc, който имаме в „чистата“ директория. Напомням, че сме дефинирали в този сценарий компонента за логване:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Знаете, че можете да активирате логването на всички съобщения на този компонент, като зададете променлива на средата NS_LOG на различни нива. Нека продължим и добавим някои записи в скрипта. Макросът, използван за добавяне на информационни ниво съобщения в логовете, е NS_LOG_INFO. Нека добавим съобщение (точно преди да започнем да създаваме възли), което ви уведомява, че сценарият е на етапа на създаване на топология ("Creating Topology"). Това се прави в следния кодов фрагмент,
Отворете scratch/myfirst.cc в любимия ви редактор и добавете реда,
NS_LOG_INFO ("Creating Topology");
точно преди редовете,

NodeContainer nodes;
nodes.Create (2);

Сега компилирайте скрипта, използвайки waf, и изчистете променливата NS_LOG, за да деактивирате потока на логването, който включихме по-рано:

$ .\/waf
$ export NS_LOG=
Сега, ако стартирате скрипта,
$ .\/waf --run scratch\/myfirst

няма да видите новото съобщение, тъй като свързаният с него компонент за логване (FirstScriptExample) не е бил активиран. За да видите съобщението си, трябва да включите компонента за логване FirstScriptExample на ниво не по-ниско от NS_LOG_INFO. Ако просто искате да видите този конкретен ниво на логване, можете да го активирате така,

$ export NS_LOG=FirstScriptExample=info

Ако вие сега стартирате скрипта, ще видите ново съобщение «Създаване на топология»

Waf: Влизане в директория `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Излизане от директория `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` успешно завърши (0.404s)
Създаване на топология
Изпратени 1024 байта до 10.1.1.2
Получени 1024 байта от 10.1.1.1
Получени 1024 байта от 10.1.1.2

5.2 Използване на аргументи от командния ред

5.2.1 Овъррайдване на стойностите на атрибутите по подразбиране

Друг начин да промените поведението на ns‑3 скриптове без редактиране и компилиране е използването на аргументи от командния ред. Ние предоставяме механизъм за парсене на командния ред и автоматично задаване на локални и глобални променливи въз основа на резултатите.

Първата стъпка при използването на системата за аргументи от командния ред е да се обяви парсер за командния ред. Това е доста просто (в основната ви програма), както следва:

int
main (int argc, char *argv[])
{
...
CommandLine cmd;
cmd.Parse (argc, argv);
...
}

Този прост двуредов фрагмент всъщност е много полезен сам по себе си. Той отваря вратата към глобалната променлива ns‑3 и системата за атрибути. Нека добавим две реда код в началото на главната функция на скрипта scratch/myfirst.cc. След това компилираме скрипта и го стартираме, като при стартиране правим заявка за помощ по следния начин,

$ ./waf --run "scratch/myfirst --PrintHelp"

Тази команда ще помоли Waf да стартира скрипта scratch/myfirst и да му предаде аргумент от командния ред --PrintHelp. Кавичките са необходими, за да покажат за коя програма е предназначен аргументът. Парсерът на командния ред ще открие аргумента --PrintHelp и ще изведе отговор,

Waf: Влизане в директория `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
Waf: Излизане от директория `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build`
`build` успешно завърши (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Обработи аргумент име=PrintHelp стойност=
--PrintHelp: Печата това съобщение за помощ.
--PrintGroups: Печата списъка с групи.
--PrintTypeIds: Печата всички TypeIds.
--PrintGroup=[group]: Печата всички TypeIds на групата.
--PrintAttributes=[typeid]: Печата всички атрибути на typeid.
--PrintGlobals: Печата списъка с глобални.

Сега нека разгледаме опцията --PrintAttributes. Вече споменахме системата за атрибути на ns‑3, при изучаване на скрипта first.cc. Видяхме следните редове код,

PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));

и казахме, че DataRate всъщност е атрибут. PointToPointNetDeviceНека приложим парсера за аргументи от командния ред, за да прегледаме атрибутите. PointToPointNetDeviceСписъкът с помощ предлага, че трябва да предоставим TypeId. Това е името на класа, към който принадлежат интересуващите атрибути. В нашия случай ще бъде ns3::PointToPointNetDevice. Нека продължим напред, въведете,

$ . /waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"

Системата ще отпечата всички атрибути на този тип мрежово устройство. Ще видите, че в списъка с атрибути има,

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
Стандартната скорост на предаване за точкови връзки

Това е стойността по подразбиране, която ще се използва в системата при създаването на обект. PointToPointNetDevice. Ние ще преопределим тази стойност по подразбиране с параметъра Атрибут в PointToPointHelper по-горе. Нека да използваме стойностите по подразбиране за точковите устройства и канали. За целта ще премахнем извикванията на SetDeviceAttribute и SetChannelAttribute от myfirst.cc, които имаме в чистата директория.

Вашият скрипт трябва сега просто да декларира PointToPointHelper и да не извършва никакви операции по настройка, както е показано в примера по-долу,

...
NodeContainer nodes;
nodes.Create (2);
PointToPointHelper pointToPoint;
NetDeviceContainer devices;
devices = pointToPoint.Install (nodes);
...

Продължете и създайте нов скрипт с Waf (. /waf) и нека да се върнем назад и да включим малко запис от UDP echo приложението на сървъра и да включим времевия префикс.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Ако стартирате скрипта, трябва да видите следния изход:

Waf: Влизане в директория ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Излизане от директория ` /home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' приключи успешно (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Изпратени 1024 байта до 10.1.1.2
2.25732s Получени 1024 байта от 10.1.1.1
2.25732s Echoing packet
Получени 1024 байта от 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Спомнете си, че миналия път, когато разглеждахме времето за симулация, моментът на получаване на пакета от echo сървъра беше на 2.00369 секунди.

2.00369s UdpEchoServerApplication:HandleRead(): Получени 1024 байта от 10.1.1.1

Сега той получава пакета в 2.25732 секунди. Това е, защото просто намалихме скоростта на предаване на PointToPointNetDevice от пет мегабита в секунда до стойността по подразбиране, която е 32768 бита в секунда. Ако бяхме задавали нова DataRate с помощта на командния ред, бихме могли отново да ускорим нашето моделиране. Ще направим това по следния начин, съгласно формулата, имплицирана от елемента за помощ:

$ . /waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"

В резултат на това стойността на атрибута DataRate по подразбиране ще се върне на пет мегабита в секунда. Учудени ли сте от резултата? Оказва се, че за да възстановим оригиналното поведение на сценария, трябва да зададем и забавяне на канала, съответстващо на скоростта на светлината. Можем да помолим системата за команден ред да отпечата атрибутите на канала, точно както направихме за мрежовото устройство:

$ .\/waf --run "scratch\/myfirst --PrintAttributes=ns3::PointToPointChannel"

Ще установим, че атрибутът за забавяне на канала е зададен по следния начин:

--ns3::PointToPointChannel::Delay=[0ns]:
Забавянето на предаване през канала

След това можем през системата за команден ред да зададем тези две стойности по подразбиране,

$ .\/waf --run "scratch\/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms"

в този случай възстановяваме времето, което имахме, когато явно задали DataRate и Delay в сценария:

Waf: Влизане в директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Излизане от директория `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' завършен успешно (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Изпратени 1024 байта до 10.1.1.2
2.00369s Получени 1024 байта от 10.1.1.1
2.00369s Отразяване на пакета
Получени 1024 байта от 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Обърнете внимание, че пакета отново е получен от сървъра след 2,00369 секунди. Всъщност, можем да зададим по този начин всякакви атрибути, използвани в сценария. В частност, можем да зададем стойности на атрибутите MaxPackets, различни от единица. UdpEchoClient.

Как бихте използвали това? Опитайте. Не забравяйте, че трябва да коментирате мястото, където ние пренавиваме стойността на атрибута по подразбиране и явно задаваме MaxPackets в сценария. След това трябва да преизградите скрипта. Системата за команден ред също предлага помощ за синтаксиса за задаване на нова стойност на атрибута по подразбиране. След като разберете това, ще можете да управлявате броя на пакетите, отпечатвани в командния ред. Тъй като сме старателни, нашият команден ред трябва да изглежда примерно така:

$ .\/waf --run "scratch\/myfirst
--ns3::PointToPointNetDevice::DataRate=5Mbps
--ns3::PointToPointChannel::Delay=2ms
--ns3::UdpEchoClient::MaxPackets=2"

Естественият въпрос, който възниква тук, е как да научим за съществуването на всички тези атрибути. Отново, системата за команден ред има функция за помощ по този въпрос. Ако поискаме помощ от командния ред, трябва да видим:

$ ./waf --run "scratch/myfirst --PrintHelp"
myfirst [Program Arguments] [General Arguments]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintHelp: Print this help message.

Ако изберете аргумента „PrintGroups“, трябва да видите списък с всички регистрирани групи. TypeId. Имената на групите съвпадат с имената на модулите в изходната директория (но с главна буква). Печатането на цялата информация наведнъж ще бъде твърде обемно, поради което е наличен допълнителен филтър за печат на информация по групи. Така отново фокусирайки се върху модула „точка-точка“:

./waf --run "scratch/myfirst --PrintGroup=PointToPoint"
TypeIds in group PointToPoint:
ns3::PointToPointChannel
ns3::PointToPointNetDevice
ns3::PointToPointRemoteChannel
ns3::PppHeader

Тук можете да намерите наличните имена на TypeId за търсене на атрибути, например в
--PrintAttributes = ns3::PointToPointChannel, както е показано по-горе.

Още един начин да научите за атрибутите е чрез Doxygen ns-3. Там има страница, която изброява всички регистрирани атрибути в симулатора.

5.2.2 Улавяне на собствените ви команди

Можете също така да добавите свои собствени хукове чрез системата за команден ред. Това се прави доста лесно с помощта на метода за парсинг на командния ред. AddValue.
Нека използваме тази възможност, за да зададем броя пакети, които трябва да се показват, по съвсем друг начин. Нека добавим локална променлива с името nPackets в функцию main. Ще я установим на една, за да съответства на предишното ни поведение по подразбиране. За да позволим на парсера за команден ред да промени тази стойност, трябва да я захванем в парсера. Правим това, като добавим извикване на AddValue. Отидете и променете скрипта scratch/myfirst.cc така, че да започнете със следния код,

int
main (int argc, char *argv[])
{
uint32_t nPackets = 1;
CommandLine cmd;
cmd.AddValue("nPackets", "Number of packets to echo", nPackets);
cmd.Parse (argc, argv);
...

Скролирайте надолу до точката в скрипта, където задаваме атрибута MaxPackets и го променете така, че да бъде настроен на променливата nPackets вместо константата 1, както е показано по-долу.

echoClient.SetAttribute ("MaxPackets", UintegerValue (nPackets));

Сега, ако стартирате скрипта и подставите аргумента —PrintHelp, трябва да видите новия аргумент на потребителя, изброен на екрана за помощ. Въведете,

$ .\/waf --run "scratch\/myfirst --PrintHelp"
Waf: Вход в директорию `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Выход из директории `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' завершен успешно (0.403s)
--PrintHelp: Печать этого сообщения помощи.
--PrintGroups: Печать списка групп.
--PrintTypeIds: Печать всех TypeIds.
--PrintGroup=[group]: Печать всех TypeIds группы.
--PrintAttributes=[typeid]: Печать всех атрибутов typeid.
--PrintGlobals: Печать списка глобальных значений.
Пользовательские аргументы:
--nPackets: Количество пакетов для эха

Ако искате да промените количеството предавани пакети, можете да го направите, като зададете аргумент - -nPackets в командния ред,

$ .\/waf --run "scratch\/myfirst --nPackets=2"

Сега трябва да видите

Waf: Вход в директорию `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
Waf: Выход из директории `\/home\/craigdo\/repos\/ns-3-allinone\/ns-3-dev\/build'
'build' завершен успешно (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Отправлено 1024 байта на 10.1.1.2
2.25732s Получено 1024 байта от 10.1.1.1
2.25732s Эхо пакета
Получено 1024 байта от 10.1.1.2
Отправлено 1024 байта на 10.1.1.2
3.25732s Получено 1024 байта от 10.1.1.1
3.25732s Эхо пакета
Получено 1024 байта от 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Вие сега изпратихте два пакета. Доста просто, нали?
Можете да видите, че като потребител на ns‑3 можете да използвате системата от командни аргументи за управление на глобалните стойности и атрибутите. Ако сте автор на модел, можете да добавите нови атрибути към вашите обекти, и те ще бъдат автоматично достъпни за настройка от вашите потребители чрез системата от командни редове. Ако сте автор на скрипт, можете да добавяте нови променливи в вашите скриптове и безпроблемно да ги свързвате с командния ред.

5.3 Използване на системата за проследяване

Основната цел на моделирането е генерирането на данни за по-нататъшно проучване, а системата за проследяване на ns‑3 е основният механизъм за това. Тъй като ns‑3 е програма на C++, могат да се използват стандартните средства за генериране на данни за C++:

#include <iostream>
...
int main ()
{
...
std::cout << "The value of x is " << x << std::endl;
...
}

Можете дори да използвате модула за логране, за да добавите малка структура към вашето решение. Известно е, че много проблеми произтичат от този подход и затова ние предоставихме обща подсистема за проследяване на събития, за да решим тези проблеми.

Основни цели на системата за проследяване ns‑3:

• За основни задачи системата за проследяване трябва да позволява на потребителя да генерира стандартно проследяване за популярни източници и да избере обекти, които генерират проследяването.

• Промежуточните потребители трябва да могат да разширят системата за запис, за да променят генерирания изходен формат или да добавят нови източници за запис, без да е необходимо модифициране на ядрото на симулатора;

• Опитните потребители могат да модифицират ядрото на симулатора, за да добавят нови източници и приемници на запис. Системата за запис ns-3 е изградена на принципите на независими източници на запис и приемници, а също така и унифициран механизъм за свързване на източниците с потребителите.

Системата за запис ns-3 е изградена на принципите на независими източници и приемници на запис, а също така и унифициран механизъм за свързване на източниците с приемниците. Източниците на запис са обекти, които могат да сигнализират за събития, които се случват в симулацията и да предоставят достъп до важни основни данни. Например, източникът на запис може да указва, когато мрежовото устройство получи пакет и предоставя достъп до съдържанието на пакета на заинтересованите приемници на запис.

Източниците на запис сами по себе си са безполезни, ако не са 'свързани' с други части на кода, които всъщност правят нещо полезно с информацията, предоставена от приемника. Записвачите са потребители на събития и данни, предоставени от източниците на запис. Например, може да бъде създаден приемник на запис, който след свързване с източника на запис от предишния пример да отпечата интересуващите части от получения пакет.

Разумната причина за такова явно разделение е да се позволи на потребителите да свързват нови типове приемници към съществуващите източници на запис без необходимост от редактиране и прекомпилиране на ядрото на симулатора. Така, в дадения пример, потребителят може да дефинира нов записвач в своя скрипт и да го свърже с съществуващия източник на запис, дефиниран в ядрото на симулацията, само чрез редактиране на потребителския скрипт.

В това ръководство ще разгледаме някои предварително зададени източници и приемници и ще покажем как да ги настроите с минимални усилия от страна на потребителя. Вижте ръководството ns-3 или разделите с инструкциите за информация относно разширената конфигурация на проследяването, включително разширяване на пространството за имена при проследяване и създаване на нови източници на проследяване.

5.3.1 ASCII Проследяване

ns-3 осигурява помощна функционалност, която предоставя нискоуровнева система за проследяване, за да ви помогне с детайлите при настройка на несложни проследявания на пакети. Ако активирате тази функция, ще видите изходни данни в ASCII файлове. За тези, които са запознати с изхода от ns-2, този тип проследяване е аналогичен out.tr, който се генерира от множество скриптове.

Нека да се захванем за работа и да добавим някои резултати от ASCII проследяването в нашия скрипт scratch/myfirst.cc. Точно преди извикването на Simulator::Run(), добавете следните редове код:
AsciiTraceHelper ascii;

pointToPoint.EnableAsciiAll(ascii.CreateFileStream("myfirst.tr"));

Както в много други идиоми на ns-3, този код използва помощен обект за създаване на ASCII проследявания. Вторият ред съдържа два вложени извиквания на метода. Методът „вътре“ CreateFileStream() използва идиома на анонимен обект, за да създаде обект на файлов поток в стека (без име на обект) и да го предаде на извикания метод. В бъдеще ще се задълбочим в този въпрос, но всичко, което трябва да знаете на този етап, е, че създавате обект, представляващ файл с име myfirst.tr и го предавате на ns-3. Ние оставяме на ns-3 грижата за създадения обект през цялото време на живота му, в течение на който се решават проблемите, причинени от малко известното (преднамерено) ограничение, свързано с копиращите конструктори на потокови обекти C++.

Външното извикване EnableAsciiAll() информира помощника, че искате да активирате ASCII проследяване за всички връзки на устройството точка-точка и че искате, за да (посочените) приемници на проследяване записват информация за движението на пакетите в ASCII формат.

За тези, които са запознати с ns-2, проследяваните събития са еквивалентни на известните точки за проследяване, които записват събития „+“, „-“, „d“ и „r“.
Сега можете да компилирате скрипта и да го стартирате от командния ред:

$ .\/waf --run scratch/myfirst

Колко много пъти преди това, ще видите няколко съобщения от Waf, след което „'build' finished successfully“ (сборката завърши успешно) с известно количество съобщения от работещата програма.

По време на работа, програмата ще създаде файл с име myfirst.tr. Поради особеностите на работа Waf, по подразбиране файлът не се създава в локалната директория, а в директорията на най-високо ниво на репозитория. Ако искате да промените пътя, където се запазват трасетата, можете да зададете допълнителен параметър за Waf --cwd. Ние не направихме това, така че за да прегледаме файла ASCII трасировка myfirst.tr в любимия ви редактор, ще трябва да отидем в директорията на най-високо ниво на нашия репозитория.

Парсинг на ASCII проследяване

Има много информация в доста плътен формат, но първото нещо, което трябва да се обърне внимание, е, че файлът се състои от отделни редове. Това ще стане ясно, ако разширите прозореца на прегледа.

Всеки ред в файла съответства на събитие от трасировка. В този случай трасироваме събития в опашката за предаване, присъстваща във всяко мрежово устройство точка-точка в симулацията. Опашката за предаване е опашка, през която трябва да премине всеки пакет за канала точка-точка. Обърнете внимание, че всеки ред в файла с трасировка започва с един символ (и има интервал след него). Този символ ще има следното значение:

+: в опашката на устройството се е случила операция по поставяне в опашка;
-: в опашката на устройството се е случила операция по извличане на елемент;
d: пакетът е бил отхвърлен, обикновено защото опашката е пълна;
r: пакетът е бил получен от мрежовото устройство.

Нека да разгледаме по-подробно първия ред в файла с трасировка. Ще го разделя на части (с отстъпи за прегледност) и номер на реда отляво:

0 +
1 2
2 \/NodeList\/0\/DeviceList\/0\/$ns3::PointToPointNetDevice\/TxQueue\/Enqueue
3 ns3::PppHeader (\n4   Point-to-Point Protocol: IP (0x0021))\n6   ns3::Ipv4Header (\n7     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]\n8     length: 1052 10.1.1.1 > 10.1.1.2)\n9     ns3::UdpHeader (\n10      length: 1032 49153 > 9)\n11      Payload (size=1024)

Първата част от това разширено събитие от трасировка (ред 0) е операция. Има символ +, което съответства на операция по поставяне в опашка за предаване. Втората част (ред 1) е времето на симулация, изразено в секунди. Може да си спомните, че поискахме UdpEchoClientApplication стартирайте изпращането на пакети след две секунди. Тук виждаме потвърждение, че това наистина се случва.

В следващия раздел на примера за трасировка (от ред 2) се показва кой източник на трасировка е генерирал това събитие (индикатор за пространство от имена). Можете да представяте пространството от имена на трасировката подобно на пространството от имена на файловата система. Коренът на пространството от имена е NodeList. Това съответства на контейнера, управляван основно от кода на ns-3. В него се съдържат всички възли, които се създават в скрипта. Подобно на файловата система, която може да има директории в корена, в NodeList можем да имаме много възли. Така редът /NodeList/0 се отнася до нулевия възел в NodeList, който обикновено разбираме като „възел 0“. Всеки възел има списък с устройства, които са били инсталирани. Този списък се намира след това в пространството от имена. Можете да видите, че това събитие на трасировката произтича от DeviceList/0, което е нулевото устройство, инсталирано на възела.

Следващото подизразяване, $ns3::PointToPointNetDevice, показва кое устройство се намира на нулевата позиция: списъка с устройства на нулевия възел. Напомням, че операцията +, която се намира в ред 0, означава, че в опашката за предаване на устройството е добавен елемент. Това е отразено в последните сегменти на „пътя на трасировката“: TxQueue/Enqueue.

Останалите раздели в трасировката трябва да бъдат достатъчно интуитивни. Редовете 3-4 указват, че пакетът е инкапсулиран в протокола точка-точка. Редовете 5-7 показват, че пакетът има заглавие на версия IP4 и е възникнал на IP адрес 10.1.1.1 и е предназначен за 10.1.1.2. Редовете 8-9 показват, че този пакет има заглавие UDP и накрая ред 10 показва, че полезният товар – очакваните 1024 байта.

Следващият ред в файла с трасировката показва, че същият пакет е извлечен от опашката за предаване на същия възел.

Третият ред в файла с трасировката показва, че пакетът е приет от мрежовото устройство на възела с ехо сървъра. Възпроизвел съм това събитие по-долу.

0 r
1 2.25732
2 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
3   ns3::Ipv4Header (
4     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
5     length: 1052 10.1.1.1 > 10.1.1.2)
6     ns3::UdpHeader (
7       length: 1032 49153 > 9)
8       Payload (size=1024)

Обърнете внимание, че операцията за проследяване вече е r, а времето за симулация е увеличено до 2,25732 секунди. Ако внимателно сте следвали инструкциите на учебника, това означава, че сте оставили DataRate на мрежовите устройства и закъснението на канала на техните стойности по подразбиране. Това време трябва да ви бъде познато, както вече сте го видели в предишната част.

Записът на пространството за имена на източника на трасировка (ред 2) беше променен, за да отрази, че това събитие произлиза от възел 1 (/NodeList/1) и пакет принят источником трассировки (/MacRx). Трябва да ви бъде доста лесно да проследите движението на пакета през топологията, преглеждайки останалите в файла трасировки.

5.3.2 Проследяване на PCAP

Помощниците на устройствата ns-3 също могат да се използват за създаване на файлове за трасировка в формат .pcap. Акронимът pcap (обикновено се пише с малки букви) обозначава улов на пакети и на практика е API, който включва определянето на формата на файла .pcap. Най-популярната програма, която може да чете и визуализира този формат, е Wireshark (преди наричана Ethereal). Въпреки това, има много анализатори на трафик, които използват този формат на пакета. Препоръчваме на потребителите да използват множеството инструменти, налични за анализ на pcap трасировки. В това ръководство ще се съсредоточим върху преглеждането на pcap трасировки с помощта на tcpdump.

Включването на pcap трасировката се извършва с една ред код.

pointToPoint.EnablePcapAll ("myfirst");

Въведете този ред код след кода на ASCII трасировката, който току-що добавихме в scratch/myfirst.cc. Обърнете внимание, че предадохме само реда „myfirst“, а не „myfirst.pcap“ или нещо подобно. Това е, защото параметърът е префикс, а не пълно име на файл. По време на симулацията помощникът всъщност ще създаде файл за трасировка за всяко устройство point-to-point. Имената на файловете ще бъдат изградени с използване на префикса, номера на възела, номера на устройството и суфикса „.pcap».

За нашия примерен сценарий в крайна сметка ще видим файлове с имената „myfirst-0-0.pcap» и «myfirst-1-0.pcap“, които са pcap трасировки за възел 0-устройство 0 и възел 1-устройство 0 съответно. След като добавите реда код за включване на pcap трасировката, можете да стартирате скрипта по обикновения начин:

$ .\/waf --run scratch/myfirst

Ако погледнете в директорията на най-високо ниво на вашето разпределение, трябва да видите три файла: файл за ASCII трасировка myfirst.tr, който разгледахме по-рано, файлове myfirst-0-0.pcap и myfirst-1-0.pcap — нови pcap файлове, които току-що генерирахме.

Четене на изхода с tcpdump

В момента най-лесно е да се използва tcpdump за преглеждане на pcap файловете.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
чета от файла myfirst-0-0.pcap, тип на връзката PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, дължина 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, дължина 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
чета от файла myfirst-1-0.pcap, тип на връзката PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, дължина 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, дължина 1024

В дампа myfirst-0-0.pcap (клиентско устройство) можете да видите, че ехо-пакетът се изпраща след 2 секунди симулация. Ако погледнете втория дамп (myfirst-1-0.pcap), ще видите, че пакетът е получен в момент 2.257324 секунди. Ще видите във втория дамп, че пакетът се връща в момент 2.257324 секунди и, накрая, че пакетът е получен от клиента обратно в първия дамп в момент 2.514648 секунди.

Четене на изхода с Wireshark

Ако не сте запознати с Wireshark, има уебсайт, от който можете да изтеглите програми и документация: http://www.wireshark.org/. Wireshark — това е графичен потребителски интерфейс, който можете да използвате за визуализиране на тези файлове за трасировка. Ако имате Wireshark, можете да отворите който и да е от файловете за трасировка и да визуализирате съдържанието, както ако сте захванали пакети, използвайки анализатор на пакети.

Източник: habr.com