tutorial simulator jaringan ns-3. bagian 5

Bab 1,2
bab 3
bab 4

5 Pengaturan
5.1 Menggunakan modul logging
5.1.1 Ikhtisar pencatatan
5.1.2 Aktifkan pencatatan
5.1.3 Menambahkan logging ke kode Anda
5.2 Menggunakan argumen baris perintah
5.2.1 Mengganti nilai atribut default
5.2.2 Menangkap perintah Anda sendiri
5.3 Menggunakan sistem penelusuran
5.3.1 Penelusuran ASCII
Mengurai jejak ASCII
5.3.2 Jejak PCAP

Bab 5

pengaturan

5.1 Menggunakan modul logging

Kita sudah melihat sekilas modul logging ns-3 dengan melihat skripnya pertama.cc. Dalam bab ini, kita akan melihat lebih dekat kemungkinan penggunaan subsistem logging.

5.1.1 Ikhtisar pencatatan

Banyak sistem besar mendukung beberapa jenis fasilitas pencatatan pesan, dan ns-3 tidak terkecuali. Dalam beberapa kasus, hanya pesan kesalahan yang ditulis ke "konsol operator" (yang biasanya stderr pada sistem berbasis Unix). Pada sistem lain, pesan peringatan mungkin ditampilkan serta informasi lebih rinci. Dalam beberapa kasus, alat logging digunakan untuk mengeluarkan pesan debug yang dapat mengaburkan keluaran dengan cepat.

SubHRD yang digunakan di ns-3 mengasumsikan bahwa semua tingkat konten informasi ini berguna, dan kami menyediakan pendekatan selektif dan berlapis untuk pencatatan pesan. Logging dapat dinonaktifkan sepenuhnya, diaktifkan per komponen, atau secara global. Untuk tujuan ini, tingkat konten informasi yang dapat disesuaikan digunakan. Modul logging ns-3 menyediakan cara yang relatif sederhana untuk memperoleh informasi berguna dari simulasi Anda.

Anda harus memahami bahwa kami menyediakan mekanisme tujuan umum - penelusuran - untuk mengekstraksi data dari model Anda, yang seharusnya menjadi keluaran pilihan untuk simulasi (untuk informasi lebih lanjut tentang sistem penelusuran kami, lihat tutorial bagian 5.3). Pencatatan log harus menjadi metode pilihan untuk mendapatkan informasi debug, peringatan, pesan kesalahan, atau untuk mengeluarkan pesan dengan cepat dari skrip atau model Anda kapan saja.

Saat ini, sistem mendefinisikan tujuh tingkat (jenis) pesan log dalam urutan konten informasi yang meningkat.

• LOG_ERROR - mencatat pesan kesalahan (makro terkait: NS_LOG_ERROR);
• LOG_WARN - Mencatat pesan peringatan (makro terkait: NS_LOG_WARN);
• LOG_DEBUG - Mencatat pesan debug khusus yang relatif jarang (makro terkait: NS_LOG_DEBUG);
• LOG_INFO - pendaftaran pesan informasi tentang kemajuan program (makro terkait: NS_LOG_INFO);
• LOG_FUNCTION - Mencatat pesan yang menjelaskan setiap fungsi yang dipanggil (dua makro terkait: NS_LOG_FUNCTION, digunakan untuk fungsi anggota, dan NS_LOG_FUNCTION_NOARGS, digunakan untuk fungsi statis);
• LOG_LOGIC - mencatat pesan yang menjelaskan aliran logis dalam suatu fungsi (makro terkait: NS_LOG_LOGIC);
• LOG_ALL - Mencatat semua yang disebutkan di atas (tidak ada makro terkait).
  Untuk setiap tipe (LOG_TYPE) juga terdapat LOG_LEVEL_TYPE yang jika digunakan, memungkinkan semua level di atasnya untuk dicatat selain levelnya sendiri. (Sebagai konsekuensinya, LOG_ERROR dan LOG_LEVEL_ERROR, serta LOG_ALL dan LOG_LEVEL_ALL secara fungsional setara.) Misalnya, mengaktifkan LOG_INFO hanya akan mengizinkan pesan yang disediakan oleh makro NS_LOG_INFO, sementara mengaktifkan LOG_LEVEL_INFO juga akan menyertakan pesan yang disediakan oleh makro NS_LOG_DEBUG, NS_LOG_WARN dan NS_LOG_ERROR.

Kami juga menyediakan makro logging tanpa syarat yang selalu ditampilkan, terlepas dari tingkat logging atau komponen pilihannya.

• NS_LOG_UNCOND - Pencatatan log tanpa syarat dari pesan terkait (tidak ada tingkat pencatatan log terkait).

Setiap level dapat ditanyakan secara individual atau kumulatif. Pencatatan log dapat dikonfigurasi menggunakan variabel lingkungan sh NS_LOG atau dengan mencatat panggilan fungsi sistem. Seperti yang ditunjukkan sebelumnya, sistem logging memiliki dokumentasi Doxygen dan sekarang adalah saat yang tepat untuk meninjaunya jika Anda belum melakukannya.

Sekarang setelah Anda membaca dokumentasi dengan sangat detail, mari gunakan pengetahuan tersebut untuk mendapatkan beberapa informasi menarik dari contoh skrip awal/pertama saya.ccyang sudah Anda kompilasi.

5.1.2 Aktifkan pencatatan

Mari kita gunakan variabel lingkungan NS_LOG untuk menjalankan beberapa log lagi, tetapi pertama-tama, untuk memahaminya, jalankan skrip terakhir seperti yang Anda lakukan sebelumnya,

$ ./waf --run scratch/myfirst

Anda akan melihat keluaran yang familiar dari contoh program ns-3 pertama

$ Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build'
finished successfully (0.413s)
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

Ternyata pesan "terkirim" dan "diterima" yang Anda lihat di atas sebenarnya adalah pesan yang dicatat dalam log Aplikasi UdpEchoClient и Aplikasi UdpEchoServer. Misalnya, kita dapat meminta aplikasi klien untuk mencetak informasi tambahan dengan mengatur tingkat logging melalui variabel lingkungan NS_LOG.

Mulai sekarang, saya akan berasumsi bahwa Anda menggunakan shell mirip sh yang menggunakan sintaks "VARIABLE=value". Jika Anda menggunakan shell seperti csh, maka Anda harus mengonversi contoh saya ke sintaks "nilai variabel setenv" yang diperlukan oleh shell tersebut.

Saat ini, aplikasi klien gema UDP merespons baris kode berikut awal/pertama saya.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

Ini mengaktifkan tingkat logging LOG_LEVEL_INFO. Ketika kita meneruskan tanda level logging, kita sebenarnya mengaktifkan level tersebut dan semua level yang lebih rendah. Dalam hal ini, kami telah mengaktifkan NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN dan NS_LOG_ERROR. Kita dapat meningkatkan level logging dan mendapatkan informasi lebih lanjut, tanpa perubahan skrip dan kompilasi ulang, dengan mengatur variabel lingkungan NS_LOG sebagai berikut:

$ export NS_LOG=UdpEchoClientApplication=level_all

Jadi kita atur variabel sh shell NS_LOG ke nilai berikut,

UdpEchoClientApplication=level_all

Sisi kiri penugasan adalah nama komponen log yang ingin kita konfigurasi, dan sisi kanan adalah tanda yang ingin kita terapkan. Dalam hal ini, kami akan mengaktifkan semua tingkat debugging dalam aplikasi. Jika Anda menjalankan skrip dengan NS_LOG yang disetel dengan cara ini, sistem logging ns-3 akan menerima perubahan dan Anda akan melihat output berikut:

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Informasi debug tambahan yang disediakan oleh aplikasi kini berada di level NS_LOG_FUNCTION. Ini menunjukkan setiap contoh pemanggilan fungsi selama eksekusi skrip. Sebagai aturan umum, lebih baik menggunakan (minimal) fungsi metodeNS_LOG_FUNCTION (this)... Menggunakan NS_LOG_FUNCTION_NOARGS ()
hanya dalam fungsi statis. Namun, perhatikan bahwa sistem ns-3 tidak diperlukan untuk mendukung fungsi logging apa pun. Keputusan tentang berapa banyak informasi yang dicatat diserahkan kepada masing-masing pengembang model. Dalam kasus aplikasi gema, tersedia keluaran logging dalam jumlah besar.

Anda sekarang dapat melihat log panggilan fungsi yang dibuat oleh aplikasi. Jika Anda perhatikan lebih dekat, Anda akan melihat titik dua di antara garis tersebut Aplikasi UdpEchoClient dan nama metodenya, yang mungkin Anda harapkan akan melihat operator cakupan C++ (: :). Ini disengaja.

Ini sebenarnya bukan nama kelasnya, tapi nama komponen logging. Ketika ada kecocokan antara file sumber dan kelas, biasanya itu adalah nama kelasnya, namun Anda harus menyadari bahwa itu sebenarnya bukan nama kelasnya, dan yang ada adalah titik dua, bukan titik dua. Ini adalah cara untuk membantu Anda secara konseptual memisahkan nama logging bean dari nama kelas dengan cara yang relatif halus.

Namun, dalam beberapa kasus mungkin sulit untuk menentukan metode mana yang sebenarnya menghasilkan pesan log. Jika Anda melihat teks di atas, Anda mungkin bertanya-tanya di mana baris "Received 1024 bytes from 10.1.1.2" Anda dapat mengatasi masalah ini dengan mengatur level awalan_fungsi ke variabel lingkungan NS_LOG. Coba yang berikut ini:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

Perhatikan bahwa tanda kutip diperlukan karena bilah vertikal yang kita gunakan untuk mewakili operasi OR juga merupakan konektor pipa Unix. Sekarang jika Anda menjalankan skrip, Anda akan melihat bahwa sistem logging memastikan bahwa setiap pesan dalam log tertentu diawali dengan nama komponen.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()

Sekarang Anda dapat melihat bahwa semua pesan yang berasal dari aplikasi klien gema UDP diidentifikasi seperti itu. Pesan "Received 1024 bytes from 10.1.1.2" sekarang diidentifikasi dengan jelas berasal dari aplikasi klien echo. Pesan yang tersisa harus berasal dari aplikasi server gema UDP. Kita dapat mengaktifkan komponen ini dengan memasukkan daftar komponen yang dipisahkan titik dua di variabel lingkungan NS_LOG.

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

Peringatan: Pada contoh teks di atas, Anda perlu menghapus karakter baris baru setelah titik dua (:), yang digunakan untuk memformat dokumen. Sekarang jika Anda menjalankan skrip, Anda akan melihat semua pesan log dari aplikasi gema klien dan server. Anda dapat melihat bahwa ini bisa sangat berguna saat melakukan debug.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.406s)
UdpEchoServerApplication:UdpEchoServer()
UdpEchoClientApplication:UdpEchoClient()
UdpEchoClientApplication:SetDataSize(1024)
UdpEchoServerApplication:StartApplication()
UdpEchoClientApplication:StartApplication()
UdpEchoClientApplication:ScheduleTransmit()
UdpEchoClientApplication:Send()
UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
UdpEchoServerApplication:HandleRead(): Echoing packet
UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
UdpEchoServerApplication:StopApplication()
UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Terkadang berguna juga untuk melihat waktu simulasi saat pesan log dibuat. Anda dapat melakukan ini dengan menambahkan bit OR awalan_waktu:

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

Sekali lagi, Anda harus menghapus karakter baris baru di atas. Jika sekarang Anda menjalankan skrip, Anda akan melihat output berikut:

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (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(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Harap dicatat bahwa konstruktor untuk UdpEchoServer dipanggil selama simulasi 0 detik. Ini sebenarnya terjadi sebelum simulasi dimulai, namun waktu ditampilkan sebagai nol detik. Hal yang sama berlaku untuk pesan konstruktor UdpEchoClient.

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (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(): Sent 1024 bytes to 10.1.1.2
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
10s UdpEchoClientApplication:StopApplication()
UdpEchoClientApplication:DoDispose()
UdpEchoServerApplication:DoDispose()
UdpEchoClientApplication:~UdpEchoClient()
UdpEchoServerApplication:~UdpEchoServer()

Ingatlah bahwa naskahnya awal/pertama.cc memulai aplikasi server gema satu detik sebelum dimulainya simulasi. Sekarang Anda dapat melihat metodenya MulaiAplikasi server sebenarnya dipanggil pada detik pertama. Anda mungkin juga memperhatikan bahwa klien gema dimulai pada detik kedua simulasi, seperti yang kami minta dalam skrip.

Anda sekarang dapat mengikuti kemajuan simulasi saat panggilan JadwalTransmit di klien yang memanggil panggilan balik HandleRead Kirim di aplikasi server gema. Perhatikan bahwa waktu yang berlalu untuk mengirim paket melalui link point-to-point adalah 3,69 milidetik. Anda dapat melihat bahwa server gema mencatat pesan bahwa ia telah merespons paket tersebut, dan kemudian, setelah penundaan saluran, Anda melihat bahwa klien gema menerima paket gema dalam metode HandleRead-nya.

Dalam simulasi ini, banyak hal terjadi tanpa Anda sadari. Namun Anda dapat melacak seluruh proses dengan sangat mudah dengan mengaktifkan semua komponen logging di sistem. Coba atur variabel NS_LOG ke nilai berikut,

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

Tanda bintang di atas adalah karakter wildcard untuk komponen logging. Ini akan mencakup semua entri di semua komponen yang digunakan dalam simulasi. Saya tidak akan mereproduksi keluarannya di sini (pada saat penulisan ini menghasilkan 1265 baris keluaran untuk satu paket gema), tetapi Anda dapat mengarahkan informasi ini ke sebuah file dan melihatnya di editor favorit Anda.

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

Saya pribadi menggunakan versi logging yang sangat bertele-tele ini ketika saya mempunyai masalah dan tidak tahu di mana kesalahannya. Saya dapat mengikuti eksekusi kode dengan cukup mudah tanpa menetapkan breakpoint dan menelusuri kode di debugger. Saya cukup mengedit hasilnya di editor favorit saya dan mencari apa yang saya harapkan dan melihat sesuatu terjadi yang tidak saya duga. Setelah saya memiliki gambaran umum tentang apa yang salah, saya melompat ke debugger untuk menelusuri masalahnya. Jenis keluaran ini bisa sangat berguna ketika skrip Anda melakukan sesuatu yang sama sekali tidak terduga. Jika Anda hanya menggunakan debugger, Anda mungkin melewatkan satu putaran pun. Registrasi membuat perubahan tersebut menjadi nyata.

5.1.3 Menambahkan logging ke kode Anda

Anda dapat menambahkan entri baru ke simulasi Anda dengan melakukan panggilan ke komponen log dari beberapa makro. Mari kita lakukan dalam naskah myfirst.cc, yang kita miliki di direktori “bersih”. Ingatlah bahwa kita mendefinisikan komponen logging dalam skenario ini:

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

Anda menyadari bahwa Anda dapat mengaktifkan pencatatan semua pesan dari komponen ini dengan mengatur variabel lingkungan NS_LOG pada tingkat yang berbeda. Mari lanjutkan dan tambahkan beberapa entri ke skrip. Makro yang digunakan untuk menambahkan pesan tingkat informasi ke log adalah NS_LOG_INFO. Mari tambahkan pesan (sebelum kita mulai membuat node) yang memberitahu Anda bahwa skrip sedang dalam fase "Membuat Topologi". Ini dilakukan dalam cuplikan kode berikut,
Buka awal/pertama saya.cc di editor favorit Anda dan tambahkan baris,
NS_LOG_INFO ("Creating Topology");
tepat sebelum garis,

NodeContainer nodes;
nodes.Create (2);

Sekarang kompilasi skrip menggunakan WAF, dan hapus variabel NS_LOG untuk menonaktifkan aliran logging yang kita aktifkan sebelumnya:

$ ./waf
$ export NS_LOG=
Теперь, если вы запустите скрипт,
$ ./waf --run scratch/myfirst

Anda tidak akan melihat pesan baru karena komponen logging terkait (FirstScriptExample) belum diaktifkan. Untuk melihat pesan Anda, Anda perlu mengaktifkan komponen logging Contoh Skrip Pertama dengan level tidak lebih rendah dari NS_LOG_INFO. Jika Anda hanya ingin melihat level logging spesifik ini, Anda dapat mengaktifkannya seperti ini,

$ export NS_LOG=FirstScriptExample=info

Jika Anda menjalankan skrip sekarang, Anda akan melihat pesan baru “Membuat Topologi”,

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
Creating Topology
Sent 1024 bytes to 10.1.1.2
Received 1024 bytes from 10.1.1.1
Received 1024 bytes from 10.1.1.2

5.2 Menggunakan argumen baris perintah

5.2.1 Mengganti nilai atribut default

Cara lain untuk mengubah perilaku skrip ns-3 tanpa mengedit atau membuat adalah dengan menggunakan argumen baris perintah. Kami menyediakan mekanisme untuk mengurai argumen baris perintah dan secara otomatis menetapkan variabel lokal dan global berdasarkan hasilnya.

Langkah pertama dalam menggunakan sistem argumen baris perintah adalah mendeklarasikan parser baris perintah. Ini cukup mudah dilakukan (di program utama Anda), seperti pada kode berikut,

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

Cuplikan dua baris sederhana ini sebenarnya sangat berguna. Ini membuka pintu ke variabel global dan sistem atribut ns-3. Mari tambahkan dua baris kode ke awal fungsi skrip utama awal/pertama saya.cc. Selanjutnya kita kompilasi scriptnya dan jalankan, saat menjalankannya kita membuat permintaan bantuan sebagai berikut,

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

Perintah ini akan menanyakan Waf menjalankan skrip awal/pertamaku dan berikan argumen baris perintah —Bantuan Cetak. Tanda kutip diperlukan untuk menunjukkan program mana yang dimaksudkan argumen tersebut. Pengurai baris perintah akan mendeteksi argumen —Bantuan Cetak dan akan menampilkan jawabannya,

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.413s)
TcpL4Protocol:TcpStateMachine()
CommandLine:HandleArgument(): Handle arg name=PrintHelp value=
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.

Sekarang mari kita lihat opsinya —PrintAttributes. Kami telah menyebutkan sistem atribut ns-3 saat mempelajari skrip first.cc. Kita telah melihat baris kode berikut,

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

dan mereka mengatakan itu Tarif Data sebenarnya adalah sebuah atribut Perangkat PointToPointNet. Mari gunakan parser argumen baris perintah untuk melihat atribut Perangkat PointToPointNet. Daftar bantuan menyatakan apa yang harus kami sediakan TypeId. Ini adalah nama kelas yang memiliki atribut yang diinginkan. Dalam kasus kami, itu akan terjadi ns3::PointToPointNetDevice. Ayo terus bergerak maju, masuk,

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

Sistem akan mencetak semua atribut jenis perangkat jaringan ini. Anda akan melihat bahwa di antara atribut dalam daftar adalah,

--ns3::PointToPointNetDevice::DataRate=[32768bps]:
The default data rate for point to point links

Ini adalah nilai default yang akan digunakan oleh sistem saat membuat objek Perangkat PointToPointNet. Kami akan mengganti nilai default ini menggunakan parameter Atribut в PointToPointHelper lebih tinggi. Mari gunakan nilai default untuk perangkat dan saluran point-to-point. Untuk melakukan ini, kami akan menghapus panggilan SetelDeviceAttribute и SetChannelAttribute dari myfirst.cc, yang kami miliki di direktori bersih.

Skrip Anda sekarang harus dideklarasikan PointToPointHelper dan jangan melakukan operasi instalasi apa pun seperti yang ditunjukkan pada contoh di bawah ini,

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

Silakan dan buat skrip baru dengan Waf (./melambai) dan mari kembali dan sertakan beberapa entri dari aplikasi server gema UDP dan sertakan awalan waktu.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

Jika Anda menjalankan skrip, Anda akan melihat output berikut:

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.405s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Ingatlah bahwa terakhir kali kita melihat waktu simulasi, saat paket diterima oleh server gema, adalah 2,00369 detik.

2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1

Sekarang dia menerima paket dalam 2.25732 detik. Hal ini karena kami cukup mengatur ulang kecepatan data PointToPointNetDevice dari lima megabit per detik ke nilai default, yaitu 32768 bit per detik. Jika kita mengganti DataRate baru menggunakan baris perintah, kita dapat mempercepat simulasi kita lagi. Kita akan melakukannya sebagai berikut, sesuai dengan rumus yang tersirat dalam elemen bantuan:

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

Ini akan mengembalikan atribut DataRate ke nilai defaultnya yaitu lima megabit per detik. Apakah Anda terkejut dengan hasilnya? Ternyata untuk mengembalikan skrip ke perilaku aslinya, kita juga perlu mengatur penundaan saluran agar sesuai dengan kecepatan cahaya. Kita dapat meminta sistem baris perintah untuk mencetak atribut saluran, seperti yang kita lakukan pada perangkat jaringan:

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

Kita akan menemukan bahwa atribut penundaan saluran diatur sebagai berikut:

--ns3::PointToPointChannel::Delay=[0ns]:
Transmission delay through the channel

Kita kemudian dapat, melalui sistem baris perintah, mengatur kedua nilai default ini.

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

dalam hal ini kami mengembalikan waktu yang kami miliki ketika kami secara eksplisit menyetel DataRate dan Delay di skrip:

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.417s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.00369s Received 1024 bytes from 10.1.1.1
2.00369s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Perhatikan bahwa paket diterima kembali oleh server setelah 2,00369 detik. Kita sebenarnya bisa mengatur atribut apa pun yang digunakan dalam skrip dengan cara ini. Secara khusus, kita dapat mengatur atribut MaxPackets ke nilai bukan satu UdpEchoClient.

Bagaimana Anda menggunakannya? Cobalah. Ingatlah bahwa Anda harus mengomentari tempat kami mengganti nilai atribut default dan menetapkannya secara eksplisit Paket Max dalam naskah. Maka Anda harus membangun kembali skripnya. Anda juga dapat menggunakan baris perintah untuk mendapatkan bantuan sintaksis guna menetapkan nilai atribut default baru. Setelah Anda memahami hal ini, Anda dapat mengontrol jumlah paket yang ditampilkan pada baris perintah. Karena kita adalah orang yang rajin belajar, baris perintah kita akan terlihat seperti ini:

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

Pertanyaan wajar yang muncul pada saat ini adalah bagaimana mengetahui keberadaan semua atribut tersebut. Sekali lagi, sistem baris perintah memiliki fungsi bantuan untuk masalah ini. Jika kita meminta bantuan baris perintah, kita akan melihat:

$ ./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.

Jika Anda memilih argumen "PrintGroups" Anda akan melihat daftar semua grup yang terdaftar TypeId. Nama grup konsisten dengan nama modul di direktori sumber (walaupun menggunakan huruf kapital). Mencetak semua informasi sekaligus akan terlalu banyak, sehingga tersedia filter tambahan untuk mencetak informasi berdasarkan kelompok. Jadi, sekali lagi fokus pada modul point-to-point:

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

Di sini Anda dapat menemukan nama TypeId yang tersedia untuk pencarian atribut, misalnya di
--PrintAttributes = ns3 :: PointToPointChannelseperti yang ditunjukkan di atas.

Cara lain untuk mempelajari atribut adalah melalui Doxygen ns‑3. Ada halaman yang mencantumkan semua atribut yang terdaftar di simulator.

5.2.2 Menangkap perintah Anda sendiri

Anda juga dapat menambahkan hook Anda sendiri melalui sistem baris perintah. Ini dilakukan cukup sederhana dengan menggunakan metode parser baris perintah Tambahkan nilai.
Mari gunakan fitur ini untuk menentukan jumlah paket yang akan ditampilkan dengan cara yang sangat berbeda. Mari tambahkan variabel lokal bernama nPaket menjadi suatu fungsi utama. Kami akan mengaturnya menjadi satu agar sesuai dengan perilaku default kami sebelumnya. Untuk mengizinkan parser baris perintah mengubah nilai ini, kita perlu menangkap nilai ini di parser. Kami melakukan ini dengan menambahkan panggilan Tambahkan nilai. Pergi dan ubah skripnya awal/pertama saya.cc jadi untuk memulai dengan kode berikut,

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);
...

Gulir ke bawah ke titik di skrip tempat kita menyetel atribut MaxPackets dan mengubahnya sehingga disetel ke variabel nPackets alih-alih konstanta 1, seperti yang ditunjukkan di bawah ini.

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

Sekarang jika Anda menjalankan skrip dan memberikan argumen -PrintHelp, Anda akan melihat argumen pengguna baru. tercantum pada tampilan bantuan. Memasuki,

$ ./waf --run "scratch/myfirst --PrintHelp"
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.403s)
--PrintHelp: Print this help message.
--PrintGroups: Print the list of groups.
--PrintTypeIds: Print all TypeIds.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintGlobals: Print the list of globals.
User Arguments:
--nPackets: Number of packets to echo

Jika Anda ingin mengubah jumlah paket yang dikirimkan, Anda dapat melakukannya dengan mengatur argumen baris perintah - -nPackets.

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

Sekarang Anda seharusnya melihatnya

Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
'build' finished successfully (0.404s)
0s UdpEchoServerApplication:UdpEchoServer()
1s UdpEchoServerApplication:StartApplication()
Sent 1024 bytes to 10.1.1.2
2.25732s Received 1024 bytes from 10.1.1.1
2.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
Sent 1024 bytes to 10.1.1.2
3.25732s Received 1024 bytes from 10.1.1.1
3.25732s Echoing packet
Received 1024 bytes from 10.1.1.2
10s UdpEchoServerApplication:StopApplication()
UdpEchoServerApplication:DoDispose()
UdpEchoServerApplication:~UdpEchoServer()

Anda sekarang telah mengirim dua paket. Cukup sederhana, bukan?
Anda dapat melihat bahwa sebagai pengguna ns-3, Anda dapat menggunakan sistem argumen baris perintah untuk memanipulasi nilai dan atribut global. Jika Anda adalah pembuat model, Anda dapat menambahkan atribut baru ke objek Anda dan atribut tersebut akan secara otomatis tersedia untuk dikonfigurasi oleh pengguna Anda melalui sistem baris perintah. Jika Anda seorang penulis skrip, Anda dapat menambahkan variabel baru ke skrip Anda dan menyambungkannya dengan lancar ke sistem baris perintah Anda.

5.3 Menggunakan sistem penelusuran

Inti dari pemodelan adalah untuk menghasilkan keluaran untuk studi lebih lanjut, dan sistem jejak ns-3 adalah mekanisme utama untuk ini. Karena ns-3 adalah program C++, cara standar untuk menghasilkan output dari program C++ dapat digunakan:

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

Anda bahkan dapat menggunakan modul logging untuk menambahkan sedikit struktur pada solusi Anda. Ada banyak masalah yang diketahui disebabkan oleh pendekatan ini, dan oleh karena itu kami telah menyediakan subsistem penelusuran kejadian umum untuk menyelesaikan masalah ini.

Tujuan utama dari sistem penelusuran ns-3 adalah:

• Untuk tugas dasar, sistem penelusuran harus memungkinkan pengguna membuat penelusuran standar untuk sumber populer dan memilih objek yang menghasilkan penelusuran;

• Pengguna perantara harus dapat memperluas sistem penelusuran untuk mengubah format keluaran yang dihasilkan atau memasukkan sumber penelusuran baru, tanpa memodifikasi inti simulator;

• Pengguna tingkat lanjut dapat memodifikasi inti simulator untuk menambahkan sumber jejak dan sink baru. Sistem penelusuran ns-3 dibangun berdasarkan prinsip pelacakan sumber dan penerima independen, serta mekanisme terpadu untuk menghubungkan sumber ke konsumen.

Sistem penelusuran ns-3 dibangun berdasarkan prinsip penelusuran independen sumber dan penerima, serta mekanisme terpadu untuk menghubungkan sumber ke penerima. Sumber jejak adalah objek yang dapat memberi sinyal peristiwa yang terjadi dalam simulasi dan menyediakan akses ke data dasar yang diinginkan. Misalnya, sumber jejak dapat menunjukkan kapan perangkat jaringan menerima paket dan membuat isi paket tersedia bagi penerima jejak yang berkepentingan.

Sumber jejak saja tidak ada gunanya kecuali jika "dipasangkan" dengan bagian lain dari kode yang benar-benar berguna dengan informasi yang disediakan oleh sink. Pelacak adalah konsumen peristiwa dan data yang disediakan oleh sumber penelusuran. Misalnya, Anda dapat membuat trace sink yang akan (saat terhubung ke sumber jejak pada contoh sebelumnya) mencetak bagian yang diinginkan dalam paket yang diterima.

Alasan pemisahan eksplisit ini adalah untuk memungkinkan pengguna menghubungkan jenis sink baru ke sumber jejak yang ada tanpa harus mengedit dan mengkompilasi ulang inti simulator. Jadi dalam contoh di atas, pengguna dapat menentukan pelacak baru dalam skrip mereka dan menghubungkannya ke sumber jejak yang sudah ada yang ditentukan dalam inti simulasi hanya dengan mengedit skrip pengguna.

Dalam tutorial ini, kita akan membahas beberapa sumber dan sink yang telah ditentukan sebelumnya dan menunjukkan bagaimana sumber dan sink tersebut dapat dikonfigurasi dengan sedikit usaha dari pihak pengguna. Lihat bagian Manual atau petunjuk ns-3 untuk informasi tentang konfigurasi pelacakan tingkat lanjut, termasuk memperluas namespace pelacakan dan membuat sumber pelacakan baru.

5.3.1 Penelusuran ASCII

ns-3 menyediakan fungsionalitas pembantu yang menyediakan sistem penelusuran tingkat rendah untuk membantu Anda dengan detail saat menyiapkan pelacakan paket sederhana. Jika Anda mengaktifkan fitur ini, Anda akan melihat hasilnya dalam file ASCII. Bagi mereka yang akrab dengan keluaran ns-2, jenis jejak ini mirip dengan keluar.tr, yang dihasilkan oleh banyak skrip.

Mari mulai berbisnis dan menambahkan beberapa hasil penelusuran ASCII ke skrip scratch/myfirst.cc kita. Tepat sebelum panggilan itu Simulator :: Run (), tambahkan baris kode berikut:
AsciiTraceHelper ascii;

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

Seperti banyak idiom ns-3 lainnya, kode ini menggunakan objek pembantu untuk membuat jejak ASCII. Baris kedua berisi dua pemanggilan metode bersarang. Metode "di dalam". BuatFileStream() menggunakan idiom objek anonim untuk membuat objek aliran file di tumpukan (tanpa nama objek) dan meneruskannya ke metode yang dipanggil. Kita akan membahasnya lebih dalam di masa mendatang, namun yang perlu Anda ketahui saat ini adalah Anda membuat objek yang mewakili file bernama pertamaku.tr dan mentransfernya ke ns-3. Kami mempercayakan ns-3 untuk merawat objek yang dibuat sepanjang masa pakainya, di mana ia memecahkan masalah yang disebabkan oleh batasan yang tidak banyak diketahui (disengaja) terkait dengan konstruktor salinan objek aliran C++.

Panggilan eksternal AktifkanAsciiAll() memberi tahu asisten bahwa Anda ingin menyertakan pelacakan ASCII dalam simulasi Anda untuk semua koneksi perangkat point-to-point dan Anda ingin (ditentukan) penerima pelacakan mencatat informasi pergerakan paket dalam format ASCII.

Bagi mereka yang akrab dengan ns-2, peristiwa yang dilacak setara dengan titik jejak yang diketahui yang mencatat peristiwa "+", "-", "d" dan "r".
Sekarang Anda dapat membuat skrip dan menjalankannya dari baris perintah:

$ ./waf --run scratch/myfirst

Seperti sebelumnya, Anda akan melihat beberapa pesan dari Waf, dan kemudian “'build' selesai dengan sukses” dengan beberapa pesan dari program yang sedang berjalan.

Saat dijalankan, program akan membuat file bernama pertamaku.tr. Karena sifat pekerjaannya Waf, secara default, file tersebut dibuat bukan di direktori lokal, tetapi di direktori tingkat atas repositori. Jika Anda ingin mengubah jalur penyimpanan jejak, Anda dapat menggunakan parameter Waf untuk menentukannya --cwd. Kami belum melakukan ini, jadi untuk melihat file jejak ASCII myfirst.tr di editor favorit Anda, kami perlu menavigasi ke direktori tingkat atas repositori kami.

Mengurai jejak ASCII

Ada banyak informasi di sana dalam bentuk yang cukup padat, tetapi hal pertama yang perlu Anda perhatikan adalah file tersebut terdiri dari baris-baris individual. Ini akan terlihat jelas jika Anda memperluas jendela tampilan lebih lebar.

Setiap baris dalam file berhubungan dengan peristiwa jejak. Dalam hal ini, kami melacak peristiwa dalam antrian transmisi yang ada di setiap perangkat jaringan point-to-point dalam simulasi. Antrian transmisi adalah antrian yang harus dilalui setiap paket untuk mendapatkan link point-to-point. Perhatikan bahwa setiap baris dalam file jejak dimulai dengan satu karakter (dan memiliki spasi setelahnya). Simbol ini mempunyai arti sebagai berikut:

+: terjadi operasi antrian pada antrian perangkat;
-: operasi pengambilan elemen terjadi dalam antrian perangkat;
d: paketnya terjatuh, biasanya karena antriannya penuh;
r: Paket diterima oleh perangkat jaringan.

Mari kita lihat lebih dekat baris pertama di file jejak. Saya akan membaginya menjadi beberapa bagian (dengan lekukan agar lebih jelas) dan nomor baris di sebelah kiri:

0 +
1 2
2 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
3 ns3::PppHeader (
4   Point-to-Point Protocol: IP (0x0021))
6   ns3::Ipv4Header (
7     tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
8     length: 1052 10.1.1.1 > 10.1.1.2)
9     ns3::UdpHeader (
10      length: 1032 49153 > 9)
11      Payload (size=1024)

Bagian pertama dari kejadian jejak yang diperluas ini (baris 0) adalah operasi. Kami memiliki simbol + di sini, yang berhubungan dengan pengoperasian antrian untuk transmisi. Bagian kedua (baris 1) adalah waktu simulasi, dinyatakan dalam detik. Anda mungkin ingat apa yang kami tanyakan Aplikasi UdpEchoClient mulai mengirim paket dalam dua detik. Di sini kita melihat konfirmasi bahwa hal ini memang terjadi.

Bagian berikutnya dari contoh pelacakan (dari baris 2) menunjukkan sumber jejak mana yang menghasilkan peristiwa ini (menunjukkan jejak namespace). Anda dapat memikirkan ruang nama jejak seperti halnya ruang nama sistem file. Akar dari namespace adalah Daftar Node. Ini sesuai dengan kontainer yang dikelola dalam kode ns-3 utama. Ini berisi semua node yang dibuat dalam skrip. Sama seperti sistem file yang dapat memiliki direktori pada akarnya, Daftar Node kita dapat memiliki banyak node. Jadi baris /NodeList/0 mengacu pada node nol di NodeList, yang biasanya kita anggap sebagai "node 0". Setiap node memiliki daftar perangkat yang telah diinstal. Daftar ini terletak di sebelah namespace. Anda dapat melihat dari mana peristiwa jejak ini berasal Daftar Perangkat/0, yang merupakan perangkat null yang dipasang di node.

Substring berikutnya, $ ns3 :: PointToPointNetDevice, memberi tahu perangkat mana yang berada di posisi nol: daftar perangkat di node nol. Ingat bahwa operasi + yang ditemukan pada baris 0 berarti bahwa sebuah elemen ditambahkan ke antrian transmisi perangkat. Hal ini tercermin dalam segmen terakhir dari “jalur lintasan”: TxAntrian/Antrian.

Bagian yang tersisa dalam penelusuran seharusnya cukup intuitif. Baris 3-4 menunjukkan bahwa paket dienkapsulasi dalam protokol point-to-point. Baris 5-7 menunjukkan bahwa paket tersebut memiliki header versi IP4 dan berasal dari alamat IP 10.1.1.1 dan ditujukan untuk 10.1.1.2. Baris 8-9 menunjukkan bahwa paket ini memiliki header UDP dan terakhir baris 10 menunjukkan bahwa payload yang diharapkan adalah 1024 byte.

Baris berikutnya dalam file jejak menunjukkan bahwa paket yang sama ditarik dari antrian transmisi pada node yang sama.

Baris ketiga dalam file jejak menunjukkan bahwa paket telah diterima oleh perangkat jaringan di host server gema. Saya telah mereproduksi acara di bawah ini.

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)

Perhatikan bahwa operasi penelusuran sekarang r dan waktu simulasi telah ditingkatkan menjadi 2,25732 detik. Jika Anda mengikuti tutorial dengan cermat, ini berarti Anda membiarkan DataRate dan Link Delay perangkat jaringan pada nilai defaultnya. Tenses ini seharusnya familiar, seperti yang Anda lihat di bagian sebelumnya.

Entri namespace sumber jejak (baris 2) telah dimodifikasi untuk mencerminkan bahwa peristiwa ini berasal dari simpul 1 (/Daftar Node/1) dan paket diterima oleh sumber jejak (/MacRx). Seharusnya cukup mudah bagi Anda untuk mengikuti pergerakan paket melalui topologi dengan melihat jejak yang tersisa di file.

5.3.2 Jejak PCAP

NS-3 Device Helpers juga dapat digunakan untuk membuat file jejak dalam format .pcap. Akronim pcap (biasanya ditulis dalam huruf kecil) adalah singkatan dari packet capture dan sebenarnya merupakan API yang mencakup pendefinisian format file .pcap. Program paling populer yang dapat membaca dan menampilkan format ini adalah Wireshark (sebelumnya dipanggil Sangat halus). Namun, ada banyak penganalisis jejak lalu lintas yang menggunakan format paket ini. Kami mendorong pengguna untuk menggunakan banyak alat yang tersedia untuk menganalisis jejak pcap. Dalam tutorial ini kita akan fokus melihat jejak pcap menggunakan tcpdump.

Mengaktifkan pelacakan pcap dilakukan dengan satu baris kode.

pointToPoint.EnablePcapAll ("myfirst");

Tempelkan baris kode ini setelah kode jejak ASCII yang baru saja kita tambahkan awal/pertama saya.cc. Perhatikan bahwa kami hanya meneruskan string "myfirst", bukan "myfirst.pcap" atau yang serupa. Hal ini karena parameternya adalah awalan, bukan nama file lengkap. Selama simulasi, asisten sebenarnya akan membuat file jejak untuk setiap perangkat point-to-point. Nama file akan dibuat menggunakan awalan, nomor node, nomor perangkat, dan akhiran ".pcap'.

Sebagai contoh skrip kita, kita akan melihat file bernama "myfirst-0-0.pcap"Dan"myfirst-1-0.pcap", yang merupakan jejak pcap untuk masing-masing node 0-perangkat 0 dan node 1-perangkat 0. Setelah Anda menambahkan baris kode untuk mengaktifkan penelusuran pcap, Anda dapat menjalankan skrip dengan cara biasa:

$ ./waf --run scratch/myfirst

Jika Anda melihat direktori tingkat atas distribusi Anda, Anda akan melihat tiga file: file jejak ASCII pertamaku.tr, yang sebelumnya kita pelajari, file myfirst-0-0.pcap и myfirst-1-0.pcap - file pcap baru yang baru saja kita buat.

Membaca keluaran dengan tcpdump

Untuk saat ini cara termudah untuk melihat file pcap adalah dengan menggunakan tcpdump.

$ tcpdump -nn -tt -r myfirst-0-0.pcap
reading from file myfirst-0-0.pcap, link-type PPP (PPP)
2.000000 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.514648 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
tcpdump -nn -tt -r myfirst-1-0.pcap
reading from file myfirst-1-0.pcap, link-type PPP (PPP)
2.257324 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 1024
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024

Di tempat pembuangan sampah myfirst-0-0.pcap (perangkat klien) Anda dapat melihat paket gema dikirim setelah 2 detik simulasi. Jika Anda melihat dump kedua (myfirst-1-0.pcap), Anda akan melihat bahwa paket diterima dalam 2,257324 detik. Anda akan melihat di dump kedua bahwa paket dikembalikan dalam 2.257324 detik, dan terakhir paket diterima kembali oleh klien di dump pertama dalam 2.514648 detik.

Membaca Output dengan Wireshark

Jika Anda belum familiar dengan Wireshark, ada situs web tempat Anda dapat mengunduh program dan dokumentasi: http://www.wireshark.org/. Wireshark adalah GUI yang dapat digunakan untuk menampilkan file jejak ini. Jika Anda memiliki Wireshark, Anda dapat membuka file jejak apa pun dan menampilkan isinya seolah-olah Anda telah menangkap paket menggunakan packet sniffer.

Sumber: www.habr.com