Compare commits
1750 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| c994aa10d8 | |||
| 47e3b01c82 | |||
| 55501d239e | |||
| fdfece661a | |||
| 9f77006419 | |||
| 52567ff22b | |||
| d01fcfd9ab | |||
| 9b1f7c5b4b | |||
| 4ea5aa6f01 | |||
| 8e781d4d16 | |||
| 1bfd17915d | |||
| a39ea72650 | |||
| 1d0b7ff106 | |||
| 9cfe687e4a | |||
| 45b1b3daa1 | |||
| 4394d1d4ba | |||
| 5b1096a52a | |||
| 161c703a1f | |||
| 6674f95bc1 | |||
| 066e14f83f | |||
| 3d1daf7c5a | |||
| 070e2da241 | |||
| 3048ebcced | |||
| 077579b060 | |||
| 2cafbd6dbd | |||
| e2f347c513 | |||
| 884ad61823 | |||
| 3a872a1d8c | |||
| cc9e4d787b | |||
| 80c9d1e629 | |||
| fb59f7982a | |||
| bc68d4f0e0 | |||
| 9133c72c96 | |||
| cbc91604dd | |||
| fafad95f72 | |||
| f17bd8c546 | |||
| 274fcc293a | |||
| 8d4db65927 | |||
| f627ad5df2 | |||
| 9db13b8df4 | |||
| 87c3097be5 | |||
| bb457316d4 | |||
| d4901ad3b0 | |||
| bf9893dbf3 | |||
| 15333eaf9a | |||
| a80337baab | |||
| 8443885e88 | |||
| d559ff6c4c | |||
| 0950f7f943 | |||
| b6d33fd296 | |||
| 1857322c43 | |||
| 208fdf2681 | |||
| 65d1ba667b | |||
| ae9fbb2eaa | |||
| b489a41127 | |||
| 9d2770100d | |||
| 287bda5b7e | |||
| 98945439e1 | |||
| 3ae1348425 | |||
| a0fefe1074 | |||
| 5072f3a3c6 | |||
| 68a33cd7ba | |||
| f6fc901227 | |||
| 74f0cf7073 | |||
| a9ef49d196 | |||
| a64d69ce19 | |||
| 07357e4048 | |||
| 4c20e1b099 | |||
| 153479dac9 | |||
| 16e4f9b004 | |||
| 6b05c585d1 | |||
| 07364f0e31 | |||
| b4a48d02b2 | |||
| bd8c6c8a32 | |||
| d3ff87aeb2 | |||
| 47d531fb41 | |||
| 81820dd14f | |||
| c69d0bfe09 | |||
| 07040f354c | |||
| 51aa7c22a4 | |||
| dda7b43d44 | |||
| 6d42b5f6c1 | |||
| 8225948ffd | |||
| be8cd47fc8 | |||
| 6ac283a20b | |||
| 35f32fe073 | |||
| 62eaf4f7cb | |||
| af37384cff | |||
| 16af384434 | |||
| e34b13367b | |||
| fb985d0860 | |||
| 97f06df836 | |||
| 06fe039cd9 | |||
| e22f7b5958 | |||
| 27e7935c6c | |||
| b8b676a8d7 | |||
| fa19c3d5e3 | |||
| 60505541ec | |||
| 894e118a3b | |||
| 49bf6a544f | |||
| 2d79be2427 | |||
| fbad78fbb4 | |||
| 10269d0a5b | |||
| fe90df6c23 | |||
| 9a8bbca8df | |||
| d762f84977 | |||
| c53882872b | |||
| 6af34ad829 | |||
| e3729362c9 | |||
| 691b9f892f | |||
| f0d6341ddf | |||
| f8bb25d058 | |||
| e4f944939c | |||
| 005ea81ecf | |||
| 9fd85ad079 | |||
| b3a080b633 | |||
| 4078d90539 | |||
| 19653b4a77 | |||
| 057f56133b | |||
| fe5ee0c29b | |||
| 4af772ceaa | |||
| 7ec65a1816 | |||
| b397d2775e | |||
| 31f05a6594 | |||
| d7731afca3 | |||
| 16671aa50d | |||
| aa3a17d3e5 | |||
| 7716182610 | |||
| a0be1da4b5 | |||
| 6bde2bde12 | |||
| b7a3cff456 | |||
| 69d284bc83 | |||
| 5a3b3d38e3 | |||
| 71d0c0f554 | |||
| 060d270a04 | |||
| e6fc8c2ad2 | |||
| 14ee3219ae | |||
| 5a00199a04 | |||
| eac8c0a104 | |||
| b9b6bacc5f | |||
| ba584e1ac1 | |||
| 2a1014565d | |||
| 620d770f3c | |||
| 15a9d1bb55 | |||
| 131381a91a | |||
| 50cb988c49 | |||
| f80a00ba88 | |||
| b5f51f5366 | |||
| 243e8a0645 | |||
| b6a990f767 | |||
| 0c9e87a440 | |||
| c9051e4101 | |||
| c9c31cce11 | |||
| 70f3450c5e | |||
| b9c2b3087c | |||
| 0cc9e25227 | |||
| 17ef04d50b | |||
| d1171adee8 | |||
| fe5b9e2242 | |||
| f5b4f0961e | |||
| f32803f7b9 | |||
| e77f033498 | |||
| e74cb7f6cd | |||
| 23a3e5f751 | |||
| 1164685c68 | |||
| cd8eaad8cb | |||
| 23a41e0e22 | |||
| 7867d64876 | |||
| ddd060a1cc | |||
| 894699eccf | |||
| 2661df4606 | |||
| 6fcc641c25 | |||
| c4269df612 | |||
| c612a2b43a | |||
| ea04312f27 | |||
| d9e06f64fa | |||
| 8604dad16c | |||
| 7dbc7f63e4 | |||
| d746b4a9d9 | |||
| a43d770825 | |||
| 84d277bfa3 | |||
| 08a075ef1d | |||
| ff1f9f9c5f | |||
| 2c89f96f00 | |||
| e0bb22b2f2 | |||
| 20e713630a | |||
| 022360d1f3 | |||
| 2d87ec3973 | |||
| 57889369b1 | |||
| 2d90b21794 | |||
| fa763e41c5 | |||
| 1e7427bab1 | |||
| 74081e597a | |||
| 45884e4786 | |||
| 95b22341a9 | |||
| 7059e4d396 | |||
| d53f68be0c | |||
| ce1c08f9a7 | |||
| cc1ff6ac3b | |||
| 2eda1ac2e6 | |||
| 6ded61e205 | |||
| bdbf0fd6e7 | |||
| 42ccc4e1dc | |||
| b5f0ebcab2 | |||
| e49d50c75a | |||
| 9c76f9ff43 | |||
| a6316eb5a3 | |||
| c6f406fe8a | |||
| f9fedcc59e | |||
| c65a263dbd | |||
| f6ad02364e | |||
| 1e75a2cb6b | |||
| 92b2936c5d | |||
| d486f26151 | |||
| 6c6dcbaf31 | |||
| e0d8349d71 | |||
| 7b51212b96 | |||
| 65d236b00a | |||
| 29e97984bd | |||
| 4507193d46 | |||
| 62afc9063e | |||
| 29f5bd43f3 | |||
| a32593c948 | |||
| 4737871613 | |||
| 74d8c0d6c7 | |||
| ff799f5cbd | |||
| 90dc67f344 | |||
| f4b5e5e4e2 | |||
| 131f31f56a | |||
| b5d3e81f81 | |||
| ba22dba981 | |||
| 5084f6a5af | |||
| c162fcb75b | |||
| b5735684f1 | |||
| b1c73cc5d5 | |||
| a9c97531cc | |||
| ad4c214b8a | |||
| 6c81abe28a | |||
| 39d721981d | |||
| db23930d21 | |||
| 2ce9615e73 | |||
| 123caf7cf3 | |||
| 9ce6ffeb61 | |||
| 1051191967 | |||
| a4f7e7dc47 | |||
| 97494a63ff | |||
| 50dce179c6 | |||
| eae942732d | |||
| cc655b5c49 | |||
| 341fcd0ce8 | |||
| 5894f2b28b | |||
| 63445557bc | |||
| b5108b031d | |||
| 5df093ae50 | |||
| 2b72b059ae | |||
| b24053a707 | |||
| 7885a9a847 | |||
| a8caac4db1 | |||
| 22fe0b7120 | |||
| f593f652a1 | |||
| 472839ca28 | |||
| 27967f1c68 | |||
| 926f89eea2 | |||
| 6acf41814e | |||
| 7d415cd3ba | |||
| e22f63ffe4 | |||
| 58235a7b39 | |||
| fc244dde4d | |||
| eaa124d2bb | |||
| ff91dd3e26 | |||
| c9e7103635 | |||
| 7689fdc0de | |||
| 6ca7bc423e | |||
| 80382ac6db | |||
| b19046c64a | |||
| 460eea1be5 | |||
| 216983828c | |||
| ebe45e5924 | |||
| 4b7cf8f4e4 | |||
| 1558d08adf | |||
| 762131e218 | |||
| 88fd0f04eb | |||
| d0391be1b2 | |||
| 16deeeaa4f | |||
| 03d493b128 | |||
| 1e81e10718 | |||
| 08f30e7815 | |||
| 96a259dec6 | |||
| 4668c18e0d | |||
| 82ba393469 | |||
| 63ebe3e674 | |||
| 9852907d33 | |||
| 69091e3dbe | |||
| f7fc0542e6 | |||
| ef51173b0f | |||
| 013f400365 | |||
| 54947ecb22 | |||
| d352331827 | |||
| 16219843f0 | |||
| 8ef0956af1 | |||
| ad1ef6acc0 | |||
| e7cfaab44d | |||
| d72152fb05 | |||
| 6c16817c8c | |||
| bf7c850715 | |||
| e06996f8a4 | |||
| 0ff3f5a861 | |||
| 3647146e3c | |||
| 509541bc27 | |||
| 46f613cb48 | |||
| 1951adcd6c | |||
| 8ef28580f8 | |||
| 3c2f2a51ca | |||
| e852bd8b8f | |||
| e06d00b0ec | |||
| ef975e2309 | |||
| 2937461f0d | |||
| 73744f4af1 | |||
| 61ad9eedb4 | |||
| 06beb889b1 | |||
| ef9dc2aadc | |||
| 9499558186 | |||
| 865faaa288 | |||
| 89c36100ae | |||
| 26b060e979 | |||
| c612fe086a | |||
| 5cb5bc407f | |||
| 4251cddf3d | |||
| 31b66adf3d | |||
| ae1c7e1209 | |||
| 6ee55d25a2 | |||
| 2a479f198a | |||
| 198b05a384 | |||
| d2a821bfa7 | |||
| bafc4932e7 | |||
| 1f05126531 | |||
| a8305cea49 | |||
| f27ed705b5 | |||
| 229afd99d0 | |||
| c1c272ccef | |||
| f780559565 | |||
| df005f262e | |||
| c9d57eae6d | |||
| 0e2e602eb6 | |||
| ed1bf7577e | |||
| ca69a3255e | |||
| 43fb06b64c | |||
| b6b1371fd1 | |||
| 1cc097b05a | |||
| 1cb6b1dc86 | |||
| d0a414b7d5 | |||
| bb98e9ad55 | |||
| 668d3df3e5 | |||
| 9106524e8c | |||
| 6c601767c8 | |||
| 82fb571d05 | |||
| 0de0dbca1d | |||
| 044cba4bbd | |||
| f1f6d27091 | |||
| bd6c92c79f | |||
| de5acedb80 | |||
| 649862bd07 | |||
| 24c15324a0 | |||
| c60bb0e13c | |||
| ba992c272d | |||
| 89ad730710 | |||
| 905ba123eb | |||
| d26723ce24 | |||
| 6c331e9627 | |||
| 70422516a9 | |||
| 9dd092a374 | |||
| cc5715fc43 | |||
| 28906f3245 | |||
| dd20c79584 | |||
| a3e7cb04e6 | |||
| 9d0747d32c | |||
| 331a645768 | |||
| ad96327325 | |||
| 5a1d345b0e | |||
| aa302c54f5 | |||
| c05f78550c | |||
| 71d515c83d | |||
| 0c7f5ca3d2 | |||
| 4ce28e76f1 | |||
| dd7459606e | |||
| ad2239fe80 | |||
| adb677eddd | |||
| a3f979febf | |||
| 0f42e4c34c | |||
| da4b470778 | |||
| 2290a2beef | |||
| 1f27f3f987 | |||
| c56b925dff | |||
| afdb830d5c | |||
| 7315243e84 | |||
| cc8ccb3cc3 | |||
| 639d8a219f | |||
| 36d7a434dc | |||
| 66d2f1225c | |||
| 763e433c88 | |||
| 5bea383284 | |||
| 4c879da5c3 | |||
| 32aba6de7d | |||
| 6a1e4a9f17 | |||
| 42f5949410 | |||
| 11f6f2330f | |||
| 2b751f4a2e | |||
| c7ba3a551e | |||
| e2971f7a72 | |||
| 5a2488e6db | |||
| d75ff3559e | |||
| cce3b82113 | |||
| 1c3e6149ab | |||
| 578f3a1f04 | |||
| b0640f8065 | |||
| 2fa1712985 | |||
| 4213b79edd | |||
| ea4c4c364e | |||
| fb295e22c9 | |||
| 31652e9763 | |||
| 3cde3fa84b | |||
| df6271a1da | |||
| 6da37422ba | |||
| 4e950036c8 | |||
| 513740a776 | |||
| 52f8515147 | |||
| 0c7f6ff413 | |||
| 9fdf10eb97 | |||
| 0b57da4bec | |||
| faa1fb3db2 | |||
| b119930437 | |||
| d930bb83f4 | |||
| ce9e267057 | |||
| a644406aad | |||
| 0aa9708044 | |||
| 55c4718c70 | |||
| ec958d44bb | |||
| 5c26030558 | |||
| 10381f6af1 | |||
| 4e6c8358f8 | |||
| f6e90ca97a | |||
| 8b12936806 | |||
| 85b60bc541 | |||
| fe8adfc8f3 | |||
| fa3e0c1f6f | |||
| 3d17935885 | |||
| ab92594cff | |||
| 0cb3414e5a | |||
| 47b12b8bec | |||
| c4c297ad85 | |||
| cd7f7154b1 | |||
| bd657c5267 | |||
| 32b19bd983 | |||
| b76e585613 | |||
| f781366d2e | |||
| 05561c4e71 | |||
| 170467f247 | |||
| 6d96614e35 | |||
| efc6f7e6c8 | |||
| 556c5ee911 | |||
| e57ef0d520 | |||
| 119acded67 | |||
| 4a465e8a9b | |||
| c2bd12e525 | |||
| b2d76a1887 | |||
| f0b9a19317 | |||
| 4578107371 | |||
| 2988c8d395 | |||
| 92f915bd79 | |||
| dcd708c846 | |||
| 1f74b54e1d | |||
| c67bd2b301 | |||
| 9fc8e11e00 | |||
| cceac0b037 | |||
| 1485913f48 | |||
| 5848465aac | |||
| ef1281e826 | |||
| 7607136792 | |||
| 2a3f610eb9 | |||
| c2317d7c75 | |||
| 04ecaa54cf | |||
| a435cd4cf5 | |||
| 12b08d2185 | |||
| a97e64ba17 | |||
| 990cf5a7a7 | |||
| 66c7642cb8 | |||
| 22923b5758 | |||
| 5b678ac051 | |||
| abaa48b238 | |||
| ff815a368b | |||
| 778a19b330 | |||
| 41d7f8e590 | |||
| 735a0183a7 | |||
| 336f420bc5 | |||
| be1cd514a5 | |||
| 1fab1d96bd | |||
| b028c9ef84 | |||
| 1e6493c8ee | |||
| 397689f94e | |||
| c1d598d496 | |||
| 70970ce418 | |||
| d60e59b608 | |||
| 905cd7ccb8 | |||
| 1d0d1555ad | |||
| 583968784f | |||
| 0784acd280 | |||
| dde6f449c2 | |||
| 6af79bf7df | |||
| fb55f9a6b3 | |||
| 382fa53396 | |||
| 47f185eab0 | |||
| 2d06f4dbc8 | |||
| c788e2ff5b | |||
| ae2fd7e6bd | |||
| c5971345d1 | |||
| 3bcc2c7ebc | |||
| 316ab795a9 | |||
| eb3161e4ac | |||
| c16f4fa7c9 | |||
| e9f60429c1 | |||
| b0ce8acbea | |||
| 14cf6679c8 | |||
| 7f3d01b337 | |||
| 142714de02 | |||
| 87fa62c388 | |||
| 64a768a21e | |||
| f5131a37c0 | |||
| 6f6a15457d | |||
| f60d2f14a3 | |||
| 48aabc2171 | |||
| d08cdaddde | |||
| 0ad82ab3b4 | |||
| 41500833ab | |||
| 6b68862bbd | |||
| a4e2db1b6d | |||
| 154d5b3ad2 | |||
| 623ae3c6b6 | |||
| 5ee85fd7d0 | |||
| bc2465e148 | |||
| fb8816e2e8 | |||
| f765bcff0f | |||
| b7d694683f | |||
| aa99130b08 | |||
| 27a2582c37 | |||
| 3a3299d6eb | |||
| 611e124f5c | |||
| 50e72aaad2 | |||
| 8168cfac18 | |||
| 1d8322b8e3 | |||
| 0389cc8021 | |||
| d6288badf4 | |||
| f4939928e0 | |||
| e48f3466b1 | |||
| e3bc429a38 | |||
| 94507fe6f1 | |||
| 11f8a59286 | |||
| 9b73661ef8 | |||
| 67e43c7ea1 | |||
| 11323e4c2c | |||
| 42935dffca | |||
| e83db03597 | |||
| 3fb1d11a1e | |||
| eba69d2728 | |||
| 39f6b03211 | |||
| fbf500f9b0 | |||
| ffcfd9de72 | |||
| 85e9ba3b48 | |||
| d1ce1beb67 | |||
| 66d87a0340 | |||
| 0945bb9e1b | |||
| 1e9031deba | |||
| a972f2609b | |||
| eab5416dd9 | |||
| 80422e7161 | |||
| d006cf014f | |||
| ae9ea26142 | |||
| 21e900f3e5 | |||
| 9b60ad3617 | |||
| 31aac3aea7 | |||
| 61903c64b2 | |||
| 8695d856a1 | |||
| 20c79bb05e | |||
| 06f653f1b5 | |||
| 2df5bc99df | |||
| d90a395329 | |||
| c5db2d45ac | |||
| c5d79310d3 | |||
| a0dc2bf45b | |||
| c0d6f58a71 | |||
| 82525eadf4 | |||
| 4a6adc5e51 | |||
| 0e5a67fd20 | |||
| 9bc367b99f | |||
| 5adb032add | |||
| 490bd45706 | |||
| 08e8705d2b | |||
| 9c172a5b81 | |||
| ef45e91592 | |||
| cb27e3276b | |||
| f9f3110086 | |||
| 47a985c9ca | |||
| a6857b4ec7 | |||
| b4828adb74 | |||
| 92b58436dd | |||
| 085a0eea39 | |||
| 8ae2fe07e2 | |||
| 41f1d3a0f1 | |||
| 81d40b0d40 | |||
| 7dea6107f3 | |||
| c9e45e84a4 | |||
| 4674443c4e | |||
| e90499b800 | |||
| 54564e2fa6 | |||
| 3f302f67cf | |||
| 3b1c9d0196 | |||
| 7fa99399c8 | |||
| d68107aa9d | |||
| 5a3a2f13d5 | |||
| 72471f5f33 | |||
| 9778d30bb8 | |||
| 698380bda5 | |||
| 404dd583fa | |||
| 7c0d6d1255 | |||
| 29e45d8e8a | |||
| 8831c14c0c | |||
| a8673b52f2 | |||
| eab4931585 | |||
| 3ad66df568 | |||
| e46947d777 | |||
| 82d158cfc0 | |||
| 60031116c0 | |||
| 40b4dcf18a | |||
| f6cd092201 | |||
| 45cba68616 | |||
| 6d4c290170 | |||
| abe882ea95 | |||
| bd0dd3aae6 | |||
| dfe28a253f | |||
| 9100b307dc | |||
| dbc19eb9f0 | |||
| a4a7b6b277 | |||
| 6db0fffd14 | |||
| dc3ef42bbd | |||
| 697755b1fe | |||
| 240004bc54 | |||
| e1f1e9a1ad | |||
| 42f18e7854 | |||
| 19c09725a9 | |||
| d14530f0ca | |||
| 0ae8b1cb8d | |||
| 6385919add | |||
| 83e2874283 | |||
| 53c2bea724 | |||
| 3c12e54cb1 | |||
| 5714732a0b | |||
| 77e292a965 | |||
| b4c068cfbb | |||
| a7c242aba7 | |||
| fbfe7f7838 | |||
| 54f181a609 | |||
| 17b897750c | |||
| 8196d37bc1 | |||
| 3439967223 | |||
| a3eadefe4b | |||
| 880a48f0b9 | |||
| a7327aa9f0 | |||
| 9c58ae0a94 | |||
| 01466f3e10 | |||
| cdffe69512 | |||
| 3294c71024 | |||
| 6592bc8f58 | |||
| 0b7929d6b4 | |||
| 4eda3b7ea1 | |||
| baffd79c30 | |||
| ac7c84ab0b | |||
| 9f77e699cb | |||
| 9659e95a7d | |||
| eddab79fdb | |||
| 587cee5600 | |||
| 927f09c1cc | |||
| 0303e6476b | |||
| 391d935aee | |||
| c1adaa985d | |||
| c2f53b8cb6 | |||
| f49c7968a5 | |||
| 9ee33b67ca | |||
| 170901724a | |||
| a4d2065f8c | |||
| 741eb67a6d | |||
| cf8ee5fccb | |||
| d5e3a76b27 | |||
| 82e00f603e | |||
| c8cdd17d4d | |||
| 020b61615e | |||
| 17e7d24deb | |||
| f2eaddb1c8 | |||
| ce46777402 | |||
| 164b71ff79 | |||
| 45df4eb9d0 | |||
| d34a027551 | |||
| 73237d891a | |||
| 77c6927bbb | |||
| 73a35c8397 | |||
| 2a08426b17 | |||
| fe13017646 | |||
| 7bcffef2ad | |||
| 97646e6481 | |||
| 24f144493f | |||
| ca0a436d75 | |||
| 8614ce3317 | |||
| 3847257057 | |||
| bc943dd161 | |||
| c703785f9e | |||
| 9e78ee4ac0 | |||
| 8eba44bacb | |||
| 0b24f2aa4b | |||
| be82a8ad39 | |||
| ea8ef52522 | |||
| fc07a2195e | |||
| ab023f5a25 | |||
| 46415c3ef0 | |||
| 0bdefa312e | |||
| 9f0ba0f883 | |||
| f25ecbfd4e | |||
| 6550570e50 | |||
| f2cd231aec | |||
| 4b09ce3268 | |||
| 546d448cb3 | |||
| a604e2d91f | |||
| 4d5a2a9be7 | |||
| 51f3d778ff | |||
| 33ca445f98 | |||
| 03b293375a | |||
| 0810c53b4e | |||
| f90dfe8259 | |||
| 2ffc089b6f | |||
| 5f541bc22f | |||
| 7553c905c7 | |||
| 04ab26cb84 | |||
| c9459d9ce2 | |||
| 6fdebea333 | |||
| a93301ab5f | |||
| b5891dce41 | |||
| 4051839d03 | |||
| d17fd41e3b | |||
| f97431bf10 | |||
| 80098cdd1c | |||
| 9659c4528e | |||
| bf886d696f | |||
| bd435c4fc7 | |||
| 9c67c38609 | |||
| 17a86900e0 | |||
| b47d4aac23 | |||
| 585b1ced9e | |||
| cfbc5a524a | |||
| c35b78f59f | |||
| daefbadea4 | |||
| 12ea93c5a1 | |||
| e3611c4078 | |||
| 7118ff0dc9 | |||
| 884814cc86 | |||
| a7d87403f6 | |||
| e468df69c9 | |||
| aca9b556d5 | |||
| b58678ee11 | |||
| 63809ba7b9 | |||
| 5a238088be | |||
| 7ae10a085b | |||
| dd59b7acb3 | |||
| a0b74cea40 | |||
| 30fc97d8b2 | |||
| 9a9dfcd1ad | |||
| 8a8559d63c | |||
| dbe5bad5bd | |||
| 7f81232309 | |||
| 3e7b4c0636 | |||
| 9d2bf09460 | |||
| 512d2c2d9e | |||
| a05600515e | |||
| 172e7aff8f | |||
| 46b47877e5 | |||
| 6f4d7a2990 | |||
| 9ef9da1519 | |||
| 4e208dae3c | |||
| 198d9f8ce9 | |||
| 351249c559 | |||
| f14f746227 | |||
| 397b75c1b4 | |||
| a6f3de6043 | |||
| e0d555f72f | |||
| c49c678cbc | |||
| e4e367ad27 | |||
| b589986de5 | |||
| 6883144780 | |||
| 0948488e79 | |||
| b9a1aefc2b | |||
| 00e9365a2d | |||
| 994ed53c08 | |||
| e83e0ee9f8 | |||
| f91ad6f841 | |||
| e2032bcc90 | |||
| 561e156ce3 | |||
| 7ff45b07d0 | |||
| 9a5004d4cd | |||
| 209ecc9f3f | |||
| 0ef013fc85 | |||
| 34558334e8 | |||
| 8c205db428 | |||
| eb12357011 | |||
| 11bbca6467 | |||
| 96fe3c2132 | |||
| b11234bba3 | |||
| 5f1a54818f | |||
| 186893dc20 | |||
| 818c0aa6e1 | |||
| cde30ab205 | |||
| 662f996003 | |||
| b9eafb57e3 | |||
| 3d8b10622a | |||
| 9c99b5e988 | |||
| 727abcda3e | |||
| 70f2ea6e92 | |||
| ffd2a5f0b1 | |||
| 8159a8ec39 | |||
| 0f657f5a6a | |||
| 63606febe2 | |||
| 2180f8ad5d | |||
| 7477fb5d43 | |||
| 5b536a7932 | |||
| 1071fd3d46 | |||
| 201f7e084a | |||
| eb8227f290 | |||
| 3d8c969762 | |||
| ebd5e131a2 | |||
| 3d834776de | |||
| 0048098e04 | |||
| 1937502efe | |||
| 0292598490 | |||
| 7f9ede9841 | |||
| 8fcd718f03 | |||
| 88e80b4b9f | |||
| 4c6280072c | |||
| dc9c9f08f4 | |||
| 38a03c2802 | |||
| 2b4ec72110 | |||
| 744b0617a5 | |||
| 42c055f11b | |||
| 5c2c064772 | |||
| 0c979225db | |||
| 54805f0915 | |||
| e7475e5552 | |||
| 176d7dfdb5 | |||
| 694f70284d | |||
| 71e266473d | |||
| 66120cc3fc | |||
| f195e9a146 | |||
| c55d9ac5a9 | |||
| 39ff2c926b | |||
| 433a24d419 | |||
| 1bca805862 | |||
| 51550a9e39 | |||
| bc13311955 | |||
| 881223720e | |||
| 6b39f62563 | |||
| c1fe8b8558 | |||
| 8805d8bd46 | |||
| 18269c91d6 | |||
| bce8b491aa | |||
| 9f88fcc217 | |||
| 67fe1d4001 | |||
| efd46793d4 | |||
| 58b5a3b10b | |||
| 205297a4dd | |||
| 7fade6a4c8 | |||
| 4f20392af0 | |||
| 54d457f233 | |||
| 4998f46162 | |||
| 5cd2be069a | |||
| 6eab23c955 | |||
| 2494bfbda4 | |||
| 4984b6d7df | |||
| e2d75baa53 | |||
| 956fe90da4 | |||
| ab18b7e466 | |||
| 7750a2adc5 | |||
| c02c9173cb | |||
| 74542bd5f5 | |||
| dac21f5413 | |||
| ab03dfed2a | |||
| 069d7a8a46 | |||
| 5712203a80 | |||
| 2d8ec2bcb8 | |||
| 9c68edd4a7 | |||
| 2872697f37 | |||
| d7e61e2f49 | |||
| c0e64dac61 | |||
| 6ed5900d07 | |||
| 2ba351d305 | |||
| 15ada60263 | |||
| 86109ec9b5 | |||
| d8a560820b | |||
| e220b67e28 | |||
| 3d801cc939 | |||
| 6e29432524 | |||
| 78b9cd962b | |||
| 01136df80f | |||
| a76c71b970 | |||
| 2ec593d861 | |||
| 3721bcf588 | |||
| 428db68f40 | |||
| 957d41063d | |||
| 666bcc699f | |||
| 79b5c59706 | |||
| 62e7de83a2 | |||
| 258eba0cf3 | |||
| f8bd5c208f | |||
| 423b193696 | |||
| 4fc79291b9 | |||
| 686bd41f4a | |||
| 1a8c217c9a | |||
| 8ffa0f7c30 | |||
| 448c32aeec | |||
| d99b767e7f | |||
| 5920bdc24d | |||
| 84126f97be | |||
| 9ef6072262 | |||
| bcfcc5a3f4 | |||
| 9ae3e7d5db | |||
| 74a3079c12 | |||
| 2516df45bb | |||
| 572eaccd20 | |||
| 403d97e6f3 | |||
| 9ee67412c4 | |||
| 3bc4f0efd0 | |||
| 87819c2734 | |||
| beb2763dd1 | |||
| 138d242a9d | |||
| 80b15ea83f | |||
| 764cedd639 | |||
| 6d84519cc7 | |||
| 8ce493fd02 | |||
| 2af3c22d07 | |||
| a4917e8935 | |||
| a8745360c4 | |||
| 51eb08677b | |||
| 4a1b70f220 | |||
| 426f22be0c | |||
| 71f388c000 | |||
| 263ea7bc9b | |||
| 332bea261e | |||
| 2adafe2e40 | |||
| 15058e8967 | |||
| 76c91ed1f4 | |||
| 3b0c201a73 | |||
| 0aef09f336 | |||
| 9633b4aa3f | |||
| 6a67bed074 | |||
| 71614226c9 | |||
| e34dbfd8bd | |||
| 568cd20be1 | |||
| 96df08adc5 | |||
| 60f6a47e55 | |||
| 81a807237d | |||
| b00e7d6290 | |||
| 13378fbc3a | |||
| 0b58e7b0b6 | |||
| d9d8ea3ee4 | |||
| 3db7072e29 | |||
| 34f2c03726 | |||
| 4171a6801c | |||
| 804ff9b528 | |||
| bbb631cb98 | |||
| b1f05f2a33 | |||
| 0e8b81cd09 | |||
| 7f9e7150fc | |||
| 6c4218520a | |||
| 1cc284f597 | |||
| 45da88b852 | |||
| a6f30c16a6 | |||
| 7d87d6b3cf | |||
| 14ae4b6072 | |||
| fddee3b927 | |||
| f50c6fe33a | |||
| 345421623c | |||
| 1cd5127d1c | |||
| 9d2ec5d5ea | |||
| 15504bc3b5 | |||
| c630cbbc76 | |||
| e39173ac22 | |||
| 40f6318eea | |||
| a7ae0c3b86 | |||
| b615a67055 | |||
| 72b4166e2c | |||
| a8065eb589 | |||
| f81e8ee7fd | |||
| 6b5386116e | |||
| a84f02b031 | |||
| 8070ec10a6 | |||
| c2122bd624 | |||
| f81f265cbd | |||
| 7ef4ed658a | |||
| cd6f68ba0a | |||
| e59ba1eb4e | |||
| 1c9cc57989 | |||
| 1515ac2016 | |||
| 9f5b066d04 | |||
| 87928cdfcd | |||
| a1ca5ae43b | |||
| aff43b376b | |||
| 32e9fe59bd | |||
| 1c0d6edb8d | |||
| b72c268305 | |||
| 5b6db3ec12 | |||
| 59d75a4686 | |||
| 1962e78524 | |||
| 7e79ae8c71 | |||
| 32f00291e7 | |||
| 77b0af3971 | |||
| 6ad306b66c | |||
| 077b8e3e02 | |||
| f07d1611be | |||
| 4d0b8b05d8 | |||
| b77fb7f40c | |||
| 2e20d86a39 | |||
| 3a8d684c9e | |||
| 49eb8e5a9f | |||
| 21f96dc635 | |||
| 53ec6a479e | |||
| 14506d5d6e | |||
| 0dc496c3bf | |||
| 31bbdfaa06 | |||
| 898e505917 | |||
| f195a9749f | |||
| 1441720339 | |||
| 4f16a0636a | |||
| 0ea5de1d3d | |||
| f032b50b75 | |||
| 2000b34287 | |||
| dfc8ac57cc | |||
| a0c2d78fcf | |||
| d1db79ea46 | |||
| eeba9f6f46 | |||
| a150788e36 | |||
| b1d109aa4d | |||
| 72b1b7d471 | |||
| b26bf2f89c | |||
| e06ea97140 | |||
| 6919cef0b3 | |||
| e5cd4dbd4e | |||
| bc8f57b261 | |||
| b915879b60 | |||
| 07d9e5d834 | |||
| 705e004083 | |||
| e950cf14c4 | |||
| 25e4cdd44a | |||
| 1e522e9f35 | |||
| 89e67bbb33 | |||
| e3c761946f | |||
| b0f38b1426 | |||
| 5e3ea98a77 | |||
| e3314476d3 | |||
| 5ed895c05b | |||
| ea9118adf9 | |||
| ea6468786d | |||
| f51e3a6502 | |||
| 900e65959d | |||
| b2b1bdaad6 | |||
| 86fad498bd | |||
| 01c8b6d832 | |||
| c7aaebd977 | |||
| 744f1fbcf3 | |||
| 77db8bedb8 | |||
| 44e8b40ac9 | |||
| 4c6177b671 | |||
| 792e59bf38 | |||
| 346a725240 | |||
| 41cc7abc1e | |||
| b656a0cab7 | |||
| 103cf1e732 | |||
| d99210342f | |||
| c7a138ec2a | |||
| e556466860 | |||
| 768ffadde6 | |||
| d0f70a008d | |||
| 643d8361e0 | |||
| de87e87a8b | |||
| 9f21cd9786 | |||
| e3746a4ae9 | |||
| f90477b203 | |||
| ec787b2d61 | |||
| a21e1e18ae | |||
| 4acc107d97 | |||
| 3f41bbf326 | |||
| 4b9945b8f1 | |||
| 72c10bfaba | |||
| c9db3544f0 | |||
| 81b51a81ef | |||
| 73ae780748 | |||
| b63880e127 | |||
| 9f271d4aad | |||
| 604ffbe4c4 | |||
| f869e06975 | |||
| fad8e79116 | |||
| 453b8d5ece | |||
| 86139b9470 | |||
| 0e169c157f | |||
| bbdb4231b3 | |||
| df67c9c116 | |||
| bf393eb7d7 | |||
| 64eb45017f | |||
| d2f222fb91 | |||
| eabfc6f5e2 | |||
| c9152825c2 | |||
| 0355008a71 | |||
| b3b3fa9e22 | |||
| 80fe6e05ba | |||
| 9aeb7bbe5b | |||
| c1c08b45a7 | |||
| a5ea699a83 | |||
| 3eb95d8366 | |||
| dc48a27426 | |||
| a9b63c88da | |||
| e2e83a7090 | |||
| 0d14fd57b6 | |||
| a4ac0f8915 | |||
| a54c1bac4c | |||
| b69928a648 | |||
| 4a169e73cd | |||
| f4f7c705c7 | |||
| 6a44c41e2a | |||
| ae7af15b04 | |||
| f44692549a | |||
| d999b6f255 | |||
| 676215d236 | |||
| 4cd736f4b3 | |||
| f6ddb71154 | |||
| b27c56347a | |||
| 5d2eb34994 | |||
| 6a483a34d0 | |||
| 949bd26ebc | |||
| 602ad906c4 | |||
| e040356d56 | |||
| e23676c7ab | |||
| 218f51e7bd | |||
| 58b1557ea8 | |||
| 5e2d3e7604 | |||
| 67735b8043 | |||
| e817303424 | |||
| 9e0d8380b2 | |||
| 05339df83c | |||
| 6e8ad06814 | |||
| ed39332ff9 | |||
| 8d85a0a3fe | |||
| 220fcb9fb0 | |||
| 78edd57c3a | |||
| 384b5764ea | |||
| 81154d2ede | |||
| ee6d9ad3c6 | |||
| aae622cc21 | |||
| 5cd08ae49e | |||
| 33f5e0a7a8 | |||
| 0a38e28ee4 | |||
| 34ef42a780 | |||
| c5350bf3a6 | |||
| caee1492b9 | |||
| 2a11e10b41 | |||
| 1fcca9ad52 | |||
| 4435ace673 | |||
| ba34b20cbe | |||
| e6fb446261 | |||
| c597e76303 | |||
| 9f75484b4e | |||
| 6df8802b63 | |||
| 176377ae10 | |||
| 9b7b867d6d | |||
| c6dd7d36b2 | |||
| 1994e334db | |||
| c925e214bb | |||
| fb072bec6e | |||
| a30f26fe74 | |||
| 764063bcfb | |||
| a726e18f04 | |||
| 51a2984059 | |||
| d9f638d211 | |||
| fabd3bf731 | |||
| a209590c80 | |||
| ca77250693 | |||
| 1468df1fdb | |||
| b694b18c55 | |||
| 7c4275b5a9 | |||
| 5621b104a7 | |||
| 9b1edab9ab | |||
| 0e4a2fc5d4 | |||
| 0b4876ca1d | |||
| 870ac2024e | |||
| ef2f84ea71 | |||
| 168e87360a | |||
| cbbeb1f8af | |||
| 0442d2b3ae | |||
| 48fef4ba27 | |||
| 5fce672663 | |||
| 585a88c9cc | |||
| ebb86d9604 | |||
| 3aa5c40945 | |||
| 9f8d43efab | |||
| 00b1f30b73 | |||
| aeea8540ea | |||
| 99861b69c9 | |||
| d75875fd28 | |||
| 240345a0c6 | |||
| ddfd9131e8 | |||
| 6f03fdaf7e | |||
| 7cb986ad35 | |||
| 35f0e489aa | |||
| 75e31957da | |||
| 80ca7c14a3 | |||
| 1e1afdfb9e | |||
| a58d3c49f1 | |||
| 0ce765ba95 | |||
| c5ec6accb4 | |||
| c71b134f76 | |||
| b06db11580 | |||
| 7ddb24742e | |||
| f2a3afcc2c | |||
| ceda10db66 | |||
| fd1052e567 | |||
| e036dd6f52 | |||
| d1ba713861 | |||
| 0830e733f4 | |||
| 639c3d2931 | |||
| c27057c920 | |||
| ac9541236d | |||
| dc04201844 | |||
| 23a1ef0817 | |||
| 6c6466134b | |||
| ec4007ca27 | |||
| 343c15bfd3 | |||
| cb5875e24b | |||
| de65d3dbce | |||
| b0466cd2f9 | |||
| 40e4b9fda5 | |||
| 6e7a49b984 | |||
| 338ceea7e5 | |||
| 7eb7baca61 | |||
| 1ae438fd32 | |||
| 838e2ccbb7 | |||
| e5b2e517e4 | |||
| 94d537dda4 | |||
| 1b4ce07e04 | |||
| 68014c1c6b | |||
| 06dee432a9 | |||
| 3ac4705a4b | |||
| ac07c73d9a | |||
| fbf4d13579 | |||
| 4d0275a34a | |||
| de78d418b4 | |||
| 59400fdb59 | |||
| f19b3a61d8 | |||
| 616cf16c19 | |||
| 9b51ed90df | |||
| 6c9e2f50cb | |||
| 1dc35c48b6 | |||
| bb4959adab | |||
| 8d617c69ba | |||
| 26626f2c2b | |||
| d5f21cb323 | |||
| 1a130c541c | |||
| 865cee1deb | |||
| 180c87d084 | |||
| 85dd7bcf63 | |||
| 2aaa84294a | |||
| 72c7e17ee8 | |||
| f7a995ac7e | |||
| 7c2327c313 | |||
| d73d21489e | |||
| 69165f3125 | |||
| bbb11b6e74 | |||
| 1ab6cd616f | |||
| 1d1815ed2d | |||
| 1bf68e5219 | |||
| 9ec98809da | |||
| f986dff488 | |||
| df0417a5df | |||
| b936760604 | |||
| b808e7b856 | |||
| 81e8199503 | |||
| 8f44f09636 | |||
| e99b43d230 | |||
| d1532d5a25 | |||
| 3a1b1e3698 | |||
| 94d3648767 | |||
| ac157ff4ba | |||
| 928431b698 | |||
| 683af560b1 | |||
| 2ab956e17c | |||
| e0a4b32640 | |||
| d43adf4f17 | |||
| 9ad7e663fb | |||
| 439e1f1707 | |||
| 956f3254dc | |||
| 955a923b72 | |||
| da4b1fc992 | |||
| 56b94c41a1 | |||
| 9eacfbcbed | |||
| 2cfe27f9a7 | |||
| 93596c5ba8 | |||
| 9d82db382e | |||
| 444648d7ff | |||
| 7622a4cebd | |||
| 1e05dd7f5d | |||
| 758c0a6786 | |||
| 12b19fe028 | |||
| 2cce4ea3f1 | |||
| f1124227b6 | |||
| bfee17058a | |||
| a86c5d54ca | |||
| 69d650520e | |||
| 8b8d9e8e84 | |||
| c9d6773fda | |||
| 93c679efdc | |||
| 0629f3dce2 | |||
| 1b02f7a968 | |||
| 93b7f13da1 | |||
| 5260aa0805 | |||
| 54a49137d5 | |||
| 96f313e16c | |||
| 52687b8806 | |||
| 62293b230e | |||
| c9162a6697 | |||
| dd0776b9e4 | |||
| 36399f6722 | |||
| e63700a6f8 | |||
| f85d20d953 | |||
| 7da6dba082 | |||
| f6f329f3db | |||
| 0c747045f8 | |||
| e408d02eab | |||
| 2706cf9190 | |||
| 7aed1c665a | |||
| a7c6503563 | |||
| 15057b0a4e | |||
| 9b5ceb07af | |||
| af16e80727 | |||
| 741dea259d | |||
| 11018e6f9b | |||
| f52da012a0 | |||
| f06fe492e5 | |||
| 5a58dd7269 | |||
| ec7fac9f5c | |||
| 63ed77709e | |||
| 6876438790 | |||
| 2f0f5a7d72 | |||
| 2c43de144e | |||
| 8a093dff2d | |||
| b540d0e815 | |||
| 6f55741bf7 | |||
| 2fa9d9a22c | |||
| 6ed1582bed | |||
| db39e9df6f | |||
| 5d1c0bf64f | |||
| a059f89a8b | |||
| ac1081f276 | |||
| b8cf3ebefa | |||
| 874a1d2a4c | |||
| cca38b6b18 | |||
| c7a3efd93e | |||
| 82e2613d41 | |||
| 2fb9b625a4 | |||
| aa7f2b22ef | |||
| 6f1dca9a6a | |||
| 4af4de9b5e | |||
| 2fe903ea7b | |||
| 401ce63113 | |||
| 940f18c6ac | |||
| beb48e14c6 | |||
| 96acc58160 | |||
| fbc7386719 | |||
| 8109e25f97 | |||
| 1ae09e8998 | |||
| 29af8761f1 | |||
| 833e74f87d | |||
| b0e4d03781 | |||
| 188befaa56 | |||
| 633f099ac0 | |||
| d6ae2a3e6f | |||
| d70da38592 | |||
| 8719871e90 | |||
| 8d73a3c194 | |||
| 51579f69d2 | |||
| b312048df0 | |||
| 9348f7aa57 | |||
| 95c0e1c605 | |||
| 384c2ca9b1 | |||
| 7829a4fb34 | |||
| 40c367e613 | |||
| 5962ee0c9e | |||
| 277c47cd3f | |||
| ef7397eee6 | |||
| 52f2039d48 | |||
| 28d3ba7507 | |||
| 321f1489ed | |||
| 2b27fb15df | |||
| 3a4b83030a | |||
| 7cfd221841 | |||
| 40aefa653c | |||
| 983311d972 | |||
| afcd6d74e5 | |||
| 34ce8277e5 | |||
| d841a9b664 | |||
| 9d174b6fa6 | |||
| 9bf3316f0b | |||
| 55699e9154 | |||
| 4fbbbb2750 | |||
| ce7b08f209 | |||
| 4c352d887e | |||
| 44a25859e1 | |||
| 3d1f13b075 | |||
| 4db1640e60 | |||
| 0b1f06e91a | |||
| f8b7a5b24c | |||
| 52bca77b0c | |||
| e7740eb238 | |||
| 679e032516 | |||
| e97639893e | |||
| 081da74f0f | |||
| c4cdda1917 | |||
| b2c617b0d9 | |||
| 3ce181f277 | |||
| 97ac9478c0 | |||
| e6638c76ac | |||
| edf61b954e | |||
| ff88dd3a93 | |||
| d71c34afdb | |||
| ef2a1a7260 | |||
| 4783d8a152 | |||
| 6ee55e3435 | |||
| 7f4ee87795 | |||
| 02b3453180 | |||
| bf9786aeb8 | |||
| b4c0f917fb | |||
| a34efdbbba | |||
| d830fc0dc3 | |||
| 172ba04824 | |||
| 35e62e96c9 | |||
| 31a6582f0a | |||
| 3416d79248 | |||
| 89180e5eae | |||
| 01298fe6d9 | |||
| 56926b4864 | |||
| 1e27ee0a90 | |||
| 5103399d47 | |||
| b5d82e8d98 | |||
| 9d2c04d44c | |||
| 8b173f7c1c | |||
| 204ddb280d | |||
| 2d37cbfb0b | |||
| c33ceaad3d | |||
| 26dc6705de | |||
| bd460539c8 | |||
| 68f9b57370 | |||
| 0d781f8967 | |||
| 89596e6f53 | |||
| 760237b0e5 | |||
| 6839492433 | |||
| 1c95b22c76 | |||
| f7e0c5f083 | |||
| c188625885 | |||
| 49e60955f3 | |||
| 98749fc6a6 | |||
| 5c4da02bdd | |||
| 7d77353f24 | |||
| 0b9a42ce27 | |||
| 82ef00ebaa | |||
| d8e3ee222e | |||
| c7b3881aab | |||
| 6baa8583c2 | |||
| 7b0d6c3dc8 | |||
| 4465aaf27b | |||
| 44395ab630 | |||
| 7ce8782ecd | |||
| 5d913a43a5 | |||
| 4f07e0b56e | |||
| 4dac132281 | |||
| ed7a9704d8 | |||
| eaed29f033 | |||
| 113226d190 | |||
| f0f647b9b5 | |||
| 7639d631a6 | |||
| 18c3badd05 | |||
| a1a1c6d36d | |||
| 6a0691f121 | |||
| 8a5e56e414 | |||
| b26e2d5fb2 | |||
| 06addb49e0 | |||
| a10b29e1fd | |||
| 2ecedb3e87 | |||
| 8243868539 | |||
| 83ccafd97d | |||
| 4b9a304277 | |||
| efe21f7763 | |||
| 71f5e2d9ea | |||
| 6a6b5699b8 | |||
| c7c2e78add | |||
| 705906ef5e | |||
| 00ae7f99a0 | |||
| 674f613678 | |||
| 94d417c60f | |||
| 62fd21d15a | |||
| fe70b486a9 | |||
| a2019b566f | |||
| 0564f7e024 | |||
| 1b09cf3092 | |||
| a45d3cfa70 | |||
| c955dd2101 | |||
| dd46aa3d5f | |||
| ba16796cd8 | |||
| 38c7bd4375 | |||
| 5409383519 | |||
| 6a3fb438df | |||
| fbe2271ac4 | |||
| 86d2f3bd08 | |||
| 690fb3f7b6 | |||
| 105c20e26c | |||
| b37a8d7002 | |||
| 4a6e736f65 | |||
| 41b604adff | |||
| 9d7a6988d2 | |||
| 44f861089e | |||
| 6d5c0a319a | |||
| 83969274e3 | |||
| 086d6adb62 | |||
| 333e48f897 | |||
| e7faf1b3a6 | |||
| 2458fcab71 | |||
| 3927f5fd92 | |||
| 17b6ce6fc5 | |||
| 625525258c | |||
| e8cbb95ab2 | |||
| 113aabd54d | |||
| e32530995a | |||
| 144067b9e0 | |||
| 9c48c4df9d | |||
| d50f0ff13a | |||
| cd3c9b9b98 | |||
| b1418abe84 | |||
| e73397daaf | |||
| 0510ed8e43 | |||
| 6117f884d3 | |||
| 1d9bdcf611 | |||
| 1958299bef | |||
| 79230ab8ee | |||
| 740a78acfe | |||
| f3ddd077d9 | |||
| b88c66e594 | |||
| acdf683569 | |||
| 5f548622a3 | |||
| c212d885fc | |||
| 547378d4b7 | |||
| 904ec5856d | |||
| 72b1d8e21f | |||
| 9241d89dc1 | |||
| 44d63447e8 | |||
| c05484e4fa | |||
| 449bffe6c6 | |||
| d046808859 | |||
| 4e9a707464 | |||
| f91e248194 | |||
| fdd4db0624 | |||
| 93ca4beb8f | |||
| 0cd22f5536 | |||
| 10703d8f90 | |||
| 680d4d0664 | |||
| 0c1fd6c65c | |||
| 2617931f84 | |||
| f78dd67e5f | |||
| 76731b5135 | |||
| 68f2ff0c84 | |||
| 790109a67a | |||
| e71b192082 | |||
| e4ed803ad5 | |||
| a81a4848b3 | |||
| a030fb77d2 | |||
| 2ea6e56956 | |||
| e260786566 | |||
| 8d895fc3c3 | |||
| e9dc5fbd4c | |||
| 8f70c1a43f | |||
| a2530396bc | |||
| b7fcb225c0 | |||
| de76eadb10 | |||
| 3550c2b524 | |||
| df701c4acd | |||
| bf33d1ef47 | |||
| 40464355bf | |||
| 4390e6d3f6 | |||
| a058791ec8 | |||
| 7dac9eb96a | |||
| c0df618b61 | |||
| 9984ad30f3 | |||
| 333f9a9b87 | |||
| 52f8eeff77 | |||
| c1594a2345 | |||
| 13fd77fafe | |||
| 019e83b145 | |||
| cd84b395ea | |||
| 30f340ccb8 | |||
| 295a14554a | |||
| 3d88eb402e | |||
| ef0d1a5874 | |||
| d979a890ab | |||
| 12eb37ce81 | |||
| 70724a71c7 | |||
| 7d6b1c0f45 | |||
| 836554566a | |||
| c22af97eaa | |||
| 9dda9d4e4f | |||
| 291e4fe17e | |||
| 6683fd2808 | |||
| 8d8ddb4357 | |||
| 815135981d | |||
| f74b34aac2 | |||
| 1acbf3eb64 | |||
| 9a66307754 | |||
| d7bd267c7e | |||
| a15640d10e | |||
| b314b544e5 | |||
| 1c8972af9d | |||
| ae5d2c7131 | |||
| 058c71d944 | |||
| c75d24d0d3 | |||
| f30b671683 | |||
| 3588837aa6 | |||
| f7e18f35b4 | |||
| af31d858d2 | |||
| 16187bdb69 | |||
| f7769e0ea0 | |||
| 2834944fc2 | |||
| 2f07ece0bb | |||
| 9d815d019d | |||
| 6fc2de6382 | |||
| aa5b099870 | |||
| ae5bc1b527 | |||
| 9193ac9dd7 | |||
| 1abd142de9 | |||
| f3a3fb85b1 | |||
| 45530120f2 | |||
| 210aefc777 | |||
| de004b4c7d | |||
| afb50f1c25 | |||
| f625c86e22 | |||
| 7feb0b73c8 | |||
| a88ee6e269 | |||
| 9b31bc95cb | |||
| 9afed6b932 | |||
| 226c9005c3 | |||
| edc382137b | |||
| cb9eeb2af2 | |||
| be090649a2 | |||
| cb1f9a0c9f | |||
| d25133fd5e | |||
| efccb54a60 | |||
| c6ccba38d4 | |||
| 0a3856e45c | |||
| c04ebb1c5f | |||
| 7c6b38c6f4 | |||
| 1ff598b75c | |||
| 19e595c09f | |||
| 03d268196b | |||
| 384eb5a622 | |||
| d9a09ae2f3 | |||
| a2e81e7341 | |||
| fa320437c0 | |||
| 72cea610f0 | |||
| 36368b6db9 | |||
| 701d152d37 | |||
| 1b4424dbcc | |||
| 19db0e31cb | |||
| 4517c16fe7 | |||
| cf7605fafc | |||
| a274c8ea37 | |||
| 5469adc1a4 | |||
| cd3da7143d | |||
| 104ff32b23 | |||
| bfeb265434 | |||
| f647edb0e5 | |||
| 57ccecc74d | |||
| 661b5c9144 | |||
| ff3054b592 | |||
| 60e2a6c117 | |||
| 89b3183f65 | |||
| cb559e2947 | |||
| 851b2f961c | |||
| b43ee31622 | |||
| 3c032987f0 | |||
| 94a4233910 | |||
| 52da92bf5b | |||
| 3e16d73f38 | |||
| 50317fc036 | |||
| 727fa3f326 | |||
| 0ba37f72a9 | |||
| 44e6ff72b0 | |||
| b24df55aa8 | |||
| 8a5d58beda | |||
| 3ec3b6a878 | |||
| 22e31f0c68 | |||
| 7daf507a80 | |||
| 1bc5e2265a | |||
| 9ce5538ff4 | |||
| 28ac4c7f40 | |||
| 98ec76d941 | |||
| 410b30f6fd | |||
| 65bf9d35e8 | |||
| 4faabb5898 | |||
| 73ceda8109 | |||
| 13176beb94 | |||
| 63d8c0f509 | |||
| 4f03cb0b56 | |||
| bee049436d | |||
| 7b9f3873da | |||
| 208294924d | |||
| 8181d545fd | |||
| 4a5acb6109 | |||
| eba6d81509 | |||
| 1a54ac7031 | |||
| 8d73d7448e | |||
| 900d3ace25 | |||
| 1b2b22150b | |||
| 03fe7f5b3a | |||
| 4ef03c0719 | |||
| 1e4e8e1a11 | |||
| 3de55e7d5e | |||
| e367628f60 | |||
| f3631afcf7 | |||
| 7d8eea6cce | |||
| a6eea770e2 | |||
| 7ed263378e | |||
| 8f6bcf630c | |||
| 7fe84f050c | |||
| f332b3cc2e | |||
| dd3118a745 | |||
| 0d2691af8b | |||
| 9e3bec943f | |||
| 678da4f186 | |||
| 022f3ad024 | |||
| d8d337c3d4 | |||
| ffba6c64ee | |||
| 3a447bbcc0 | |||
| bbb25ddb08 | |||
| 32a11da551 | |||
| 281f06e639 |
@@ -20,10 +20,13 @@
|
||||
\.pcap$
|
||||
\.mob$
|
||||
\.routes$
|
||||
^seventh-packet-byte-count.png
|
||||
\.cwnd
|
||||
^doc/doxygen.log$
|
||||
^doc/doxygen.warnings.log$
|
||||
^doc/(manual|models|tutorial|tutorial-pt-br)/build
|
||||
^doc/(manual|models|tutorial|tutorial-pt-br)/figures/.*\.(eps|pdf|png)$
|
||||
^doc/manual/source-temp
|
||||
^doc/models/source-temp
|
||||
^doc/ns3_html_theme/static/ns3_version.js$
|
||||
^src/.*/doc/build
|
||||
@@ -35,5 +38,11 @@ massif.*
|
||||
\.patch$
|
||||
\.diff$
|
||||
\.tr$
|
||||
\.dat$
|
||||
\.plt$
|
||||
\#[^\#/]+\#$
|
||||
^coverity
|
||||
^(D|U)l[A-Z][a-z]*Stats.txt$
|
||||
syntax: glob
|
||||
TAGS
|
||||
waf
|
||||
|
||||
@@ -63,3 +63,8 @@ e48ed3aabca6ad71c8c49e4604c0f83345eda6a8 ns-3.11-RC3
|
||||
9007193fbb8d18b69a1feb6aec16501dcf138b6f ns-3.13
|
||||
ae540de68a2534213342c5e0b12afb47d7518a90 ns-3.14
|
||||
26a511d6dbad7284e66de0f3b2ad5bebe6b76405 ns-3.15
|
||||
49d343e55caec257bb01e400eef6c14522f37e1b ns-3.16
|
||||
b4a70b99171ade6e9628a87780994238950a1df1 ns-3.17
|
||||
cfbc9491d7e7c9d346cc042fd35b8afb8836e81f ns-3.18
|
||||
322102df792e2be6c74df74f776b3470fb1db795 ns-3.19
|
||||
da0eb48df23f96335f32a37f047a6bc27e197c8d ns-3.20
|
||||
|
||||
@@ -2,6 +2,8 @@ Alexander Afanasyev (alexander.afanasyev@ucla.edu)
|
||||
Rohit Agarwal (mindprince@gmail.com)
|
||||
Kirill Andreev (andreev@iitp.ru)
|
||||
Dean Armstrong (deanarm@gmail.com)
|
||||
Stefano Avallone (stefano.avallone@unina.it)
|
||||
Ghada Badawy (gbadawy@gmail.com)
|
||||
Nicola Baldo (nbaldo@cttc.es)
|
||||
Mirko Banchi (mk.banchi@gmail.com)
|
||||
Peter D. Barnes, Jr. (barnes26@llnl.gov)
|
||||
@@ -10,28 +12,42 @@ Mehdi Benamor (mehdi.benamor@telecom-bretagne.eu)
|
||||
Raj Bhattacharjea (raj.b@gatech.edu)
|
||||
Timo Bingmann (timo.bingmann@student.kit.edu)
|
||||
Julien Boite (juboite@gmail.com)
|
||||
Biljana Bojovic (bbojovic@cttc.es)
|
||||
Elena Borovkova (borokovaes@iitp.ru)
|
||||
Pavel Boyko (boyko@iitp.ru)
|
||||
Dan Broyles (muxman@sbcglobal.net)
|
||||
Jonathan Brugge (j.d.brugge@student.utwente.nl)
|
||||
Junling Bu (linlinjavaer@gmail.com)
|
||||
Elena Buchatskaia (borovkovaes@iitp.ru)
|
||||
Gustavo Carneiro (gjc@inescporto.pt, gjcarneiro@gmail.com)
|
||||
Scott Carpenter (scarpen@ncsu.edu)
|
||||
Egemen K. Cetinkaya (ekc@iitc.ku.edu)
|
||||
Angelos Chatzipapas (chatzipa@ceid.upatras.gr)
|
||||
Eugene Chemeritskiy (echemeritskiy@arccn.ru)
|
||||
Yufei Cheng (yfcheng@ittc.ku.edu)
|
||||
Andrey Churin (aachurin@gmail.com)
|
||||
Salva Climent (jocliba@gmail.com)
|
||||
Luis Cortes (cortes@gatech.edu)
|
||||
Luca Costantino (luca.costantino@gmail.com)
|
||||
Alexander D'souza (moijes12@gmail.com)
|
||||
Sébastien Deronne (sebastien.deronne@gmail.com)
|
||||
Craig Dowell (craigdo@ee.washington.edu)
|
||||
Gilaras Drakeson (gilaras@gmail.com)
|
||||
Christian Facchini (c.facchini@gmail.com)
|
||||
Denis Fakhriev (fakhriev@iitp.ru)
|
||||
Jahanzeb Farooq (Jahanzeb.Farooq@inria.fr, Jahanzeb.Farooq@gmail.com)
|
||||
Luca Favatella (slackydeb@gmail.com)
|
||||
Margherita Filippetti (morag87@gmail.com)
|
||||
Pedro Fortuna (pedro.fortuna@inescporto.pt)
|
||||
Juliana Freitag Borin (juliana.freitag@gmail.com)
|
||||
Piotr Gawlowicz (gawlowicz.p@gmail.com)
|
||||
Eric Gamess (egamess@gmail.com)
|
||||
Yida Gao (yidapb@gmail.com)
|
||||
Thomas Geithner (thomas.geithner@dai-labor.de)
|
||||
Ashim Ghosh (ashim.atiit@gmail.com)
|
||||
Martin Giachino (martin.giachino@gmail.com,giachino@fing.edu.uy)
|
||||
Tom Goff (tgoff@tgoff.net)
|
||||
Juan C. Granda (jcgranda@uniovi.es)
|
||||
David Gross (gdavid.devel@gmail.com)
|
||||
Maja Grubišić (maja.grubisic@live.com)
|
||||
Charline Taibi Guguen (charline.guguen@gmail.com)
|
||||
@@ -39,39 +55,65 @@ Daniel Halperin (daniel@halper.in)
|
||||
Bruno Haick (bghaick@hotmail.com)
|
||||
Frank Helbert (frank@ime.usp.br)
|
||||
Tom Henderson (tomhend@u.washington.edu)
|
||||
Budiarto Herman (budiarto.herman@magister.fi)
|
||||
Tom Hewer (tomhewer@mac.com)
|
||||
Kristian A. Hiorth (kristahi@ifi.uio.no)
|
||||
Kim Højgaard-Hansen (kimrhh@gmail.com)
|
||||
Chris Hood (chood8@gatech.edu)
|
||||
Blake Hurd (naimorai@gmail.com)
|
||||
ishan (ishan.chhabra@gmail.com)
|
||||
Mohamed Amine Ismail (amine.ismail@inria.fr, iamine@udcast.com)
|
||||
Jared Ivey (j.ivey@gatech.edu)
|
||||
Atishay Jain (atishayjain25@gmail.com)
|
||||
Sascha Alexander Jopen (jopen@informatik.uni-bonn.de)
|
||||
Sam Jansen (sam.jansen@gmail.com)
|
||||
Liu Jian (liujatp@gmail.com)
|
||||
Joe Kopena (tjkopena@cs.drexel.edu)
|
||||
Piotr Jurkiewicz (piotr.jerzy.jurkiewicz@gmail.com)
|
||||
Evgeny Kalishenko (ydginster@gmail.com)
|
||||
Konstantinos Katsaros (dinos.katsaros@gmail.com)
|
||||
Morteza Kheirkhah (m.kheirkhah@sussex.ac.uk)
|
||||
Flavio Kobuta (flaviokubota@gmail.com)
|
||||
Joe Kopena (tjkopena@cs.drexel.edu)
|
||||
Christopher Kosecki (christopher.l.kosecki.ctr@mail.mil)
|
||||
Aleksey Kovalenko (kovalenko@iitp.ru)
|
||||
Mathieu Lacage (mathieu.lacage@inria.fr)
|
||||
Emmanuelle Laprise (emmmanuelle.laprise@bluekazoo.ca)
|
||||
Kristijan Lenković (k.lenkovic@me.com)
|
||||
Daniel Lertpratchya (nikkipui@gmail.com)
|
||||
Björn Lichtblau (lichtbla@informatik.hu-berlin.de)
|
||||
Timo Lindhorst (tlnd@online.de)
|
||||
Erwan Livolant (erwan.livolant@inria.fr)
|
||||
Keith Ma (keith.nwsuaf@gmail.com)
|
||||
Federico Maguolo (maguolof@dei.unipd.it)
|
||||
Antti Makela (zarhan@cc.hut.fi)
|
||||
Francesco Malandrino (francesco.malandrino@gmail.com)
|
||||
Rubén Martínez (rmartinez@deic.uab.cat)
|
||||
Fabian Mauchle (f1mauchl@hsr.ch)
|
||||
Andrey Mazo (mazo@iitp.ru)
|
||||
Jonathan McCrohan (jmccroha@tcd.ie)
|
||||
Andrew McGregor (andrewmcgr@gmail.com)
|
||||
Vedran Miletić (rivanvx@gmail.com)
|
||||
Jens Mittag (jens.mittag@kit.edu)
|
||||
Marco Miozzo (mmiozzo@cttc.es)
|
||||
Faker Moatamri (faker.moatamri@inria.fr)
|
||||
Edvin Močibob (edvin.mocibob@gmail.com)
|
||||
Mike Moreton (mjvm_ns@hotmail.com)
|
||||
Michele Muccio (michelemuccio@virgilio.it)
|
||||
Sidharth Nabar (snabar@uw.edu)
|
||||
Hemanth Narra (hemanth@ittc.ku.edu)
|
||||
Roman Naumann (naumann@informatik.hu-berlin.de)
|
||||
Andreas Nilsson (andrnils@gmail.com)
|
||||
Jaume Nin (jnin@cttc.es)
|
||||
Michael Nowatkowski (nowatkom@gmail.com)
|
||||
Anh Nguyen (annguyen@ittc.ku.edu)
|
||||
Duy Nguyen (duy@soe.ucsc.edu)
|
||||
Lluís Parcerisa (parcerisa@gmail.com)
|
||||
Natale Patriciello (natale.patriciello@gmail.com)
|
||||
Tommaso Pecorella (tommaso.pecorella@unifi.it)
|
||||
Vikas Pushkar (vikaskupushkar@gmail.com)
|
||||
Josh Pelkey (jpelkey@gatech.edu)
|
||||
Per (per_e_lists@rocketmail.com)
|
||||
Fernando Pereira (ferdonfeup@gmail.com)
|
||||
Colin Perkins (csp@csperkins.org)
|
||||
Giuseppe Piro (g.piro@poliba.it)
|
||||
Yana Podkosova (yanapdk@rambler.ru)
|
||||
@@ -81,21 +123,33 @@ Bruno Ranieri (Yrrsinn@googlemail.com)
|
||||
Ken Renard (kenneth.renard@arl.army.mil)
|
||||
Manuel Requena (mrequena@cttc.es)
|
||||
George F. Riley (riley@ece.gatech.edu)
|
||||
Juergen Rinas (jrinas@gmx.de)
|
||||
Sebastian Rohde (sebastian.rohde@tu-dortmund.de)
|
||||
Karsten Roscher (sfx@rocktale.de)
|
||||
Bill Roome (wdr@bell-labs.com)
|
||||
David (david.rua@gmail.com)
|
||||
Andrea Sacco (andrea.sacco85@gmail.com)
|
||||
Lynne Salameh (l.salameh@cs.ucl.ac.uk)
|
||||
Providence Salumu Munga (Providence.Salumu@gmail.com, Providence.Salumu_Munga@it-sudparis.eu)
|
||||
Francisco Javier Sánchez-Roselly (fnavarro@ujaen.es)
|
||||
Florian Schmidt (Florian.Schmidt@cs.rwth-aachen.de)
|
||||
Guillaume Seguin (guillaume.seguin@inria.fr)
|
||||
Tomasz Seweryn (tomasz.seweryn7@gmail.com)
|
||||
Dmitrii Shakshin (d.shakshin@gmail.com)
|
||||
Kulin Shah (m.kulin@gmail.com)
|
||||
Guowang Shi (shiguowang2007@gmail.com)
|
||||
Phillip Sitbon (phillip.sitbon@gmail.com)
|
||||
Anirudh Sivaraman (sk.anirudh@gmail.com)
|
||||
Steven Smith (smith84@llnl.gov)
|
||||
Andrew Stanton (acstanton515@gmail.com)
|
||||
Ewgenij Starostin (estar@cs.tu-berlin.de)
|
||||
YunQiang Su (wzssyqa@gmail.com)
|
||||
Brian Swenson (bswenson3@gatech.edu)
|
||||
Lalith Suresh (suresh.lalith@gmail.com)
|
||||
Dave Taht (dave.taht@bufferbloat.net)
|
||||
Marcos Talau (talau@users.sourceforge.net)
|
||||
Adrian S. W. Tam (adrian.sw.tam@gmail.com)
|
||||
Cristiano Tapparello (cristiano.tapparello@rochester.edu)
|
||||
Hajime Tazaki (tazaki@sfc.wide.ad.jp)
|
||||
Wilson Thong (wilsonwk@ee.cityu.edu.hk)
|
||||
Mauro Tortonesi (mauro.tortonesi@unife.it)
|
||||
|
||||
+572
-11
@@ -23,6 +23,13 @@ the impact of these changes on users by documenting these changes in a
|
||||
single place (this file), and not by providing a temporary or permanent
|
||||
backward-compatibility software layer. </p>
|
||||
<p>
|
||||
A related file is the RELEASE_NOTES file in the top level directory.
|
||||
This file complements RELEASE_NOTES by focusing on API and behavioral
|
||||
changes that users upgrading from one release to the next may encounter.
|
||||
RELEASE_NOTES attempts to comprehensively list all of the changes
|
||||
that were made. There is generally some overlap in the information
|
||||
contained in RELEASE_NOTES and this file. </p>
|
||||
<p>
|
||||
The goal is that users who encounter a problem when trying to use older
|
||||
code with newer code should be able to consult this file to find
|
||||
guidance as to how to fix the problem. For instance, if a method name
|
||||
@@ -43,6 +50,560 @@ the cracks, unfortunately. If you, as a user, can suggest improvements
|
||||
to this file based on your experience, please contribute a patch or drop
|
||||
us a note on ns-developers mailing list.</p>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.20 to ns-3.21</h1>
|
||||
<h2>New API:</h2>
|
||||
<ul>
|
||||
<li> New "const double& SpectrumValue:: operator[] (size_t index) const".
|
||||
</li>
|
||||
<li> A new TraceSource has been added to TCP sockets: SlowStartThreshold.
|
||||
</li>
|
||||
<li> New method CommmandLine::AddValue (name, attibutePath) to provide a
|
||||
shorthand argument "name" for the Attribute "path". This also has
|
||||
the effect of including the help string for the Attribute in the
|
||||
Usage message.
|
||||
</li>
|
||||
<li> The GSoC 2014 project in the LTE module has brought some additional APIs:
|
||||
<ul>
|
||||
<li>a new abstract class LteFfrAlgorithm, which every future
|
||||
implementation of frequency reuse algorithm should inherit from</li>
|
||||
<li>a new SAPs: one between MAC Scheduler and FrAlgorithm, one between
|
||||
RRC and FrAlgorithm</li>
|
||||
<li>new attribute to enable Uplink Power Control in LteUePhy</li>
|
||||
<li>new LteUePowerControl class, an implementation of Uplink Power Control, which is
|
||||
configurable by attributes. ReferenceSignalPower is sent by eNB in SIB2.
|
||||
Uplink Power Control in Closed Loop Accumulative Mode is enabled by default</li>
|
||||
<li>seven different Frequency Reuse Algorithms (each has its own attributes): </li>
|
||||
<ul>
|
||||
<li>LteFrNoOpAlgorithm</li>
|
||||
<li>LteFrHardAlgorithm</li>
|
||||
<li>LteFrStrictAlgorithm</li>
|
||||
<li>LteFrSoftAlgorithm</li>
|
||||
<li>LteFfrSoftAlgorithm</li>
|
||||
<li>LteFfrEnhancedAlgorithm</li>
|
||||
<li>LteFfrDistributedAlgorithm</li>
|
||||
</ul>
|
||||
<li>attribute in LteFfrAlgorithm to set FrCellTypeId which is used in automatic
|
||||
Frequency Reuse algorithm configuration</li>
|
||||
<li>LteHelper has been updated with new methods related to frequency reuse algorithm:
|
||||
SetFfrAlgorithmType and SetFfrAlgorithmAttribute</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li> A new SimpleNetDeviceHelper can now be used to install SimpleNetDevices.
|
||||
</li>
|
||||
<li> New PacketSocketServer and PacketSocketClient apps, meant to be used in tests.
|
||||
</li>
|
||||
<li> Tcp Timestamps and Window Scale options have been added and are enabled by default (controllable by attribute).
|
||||
</li>
|
||||
<li> A new CoDel queue model has been added to the 'internet' module.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to existing API:</h2>
|
||||
<ul>
|
||||
<li> "Icmpv6L4Protocol::ForgeEchoRequest" is now returning a packet with the proper IPv6 header.
|
||||
</li>
|
||||
<li> The TCP socket Attribute "SlowStartThreshold" has been renamed "InitialSlowStartThreshold" to
|
||||
clarify that the effect is only on the initial value.
|
||||
</li>
|
||||
<li> all schedulers were updated to interact with FR entity via FFR-SAP. Only PF, PSS, CQA,
|
||||
FD-TBFQ, TD-TBFQ schedulers supports Frequency Reuse functionality. In the beginning
|
||||
of scheduling process, schedulers ask FR entity for avaiable RBGs and then ask if UE
|
||||
can be scheduled on RB</li>
|
||||
<li> eNB RRC interacts with FFR entity via RRC-FFR SAP</li>
|
||||
<li> new DL-CQI generation approach was implemented. Now DL-CQI is computed from control channel as signal
|
||||
and data channel (if received) as interference. New attribute in LteHelper was added to specify
|
||||
DL-CQI generation approach. New approach is default one in LteHelper </li>
|
||||
<li> RadioEnvironmentMap can be generated for Data or Control channel and for specified RbId;
|
||||
Data or Control channel and RbId can be configured by new attributes in RadioEnvironmentMapHelper </li>
|
||||
<li> lte-sinr-chunk-processor refactored to lte-chunk-processor. Removed all lte-xxx-chunk-processor
|
||||
implementations</li>
|
||||
<li> BindToNetDevice affects also sockets using IPv6.</li>
|
||||
<li> BindToNetDevice now calls implicitly Bind (). To bind a socket to a NetDevice and to a specific address,
|
||||
the correct sequence is Bind (address) - BindToNetDevice (device). The opposite will raise an error.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to build system:</h2>
|
||||
<ul>
|
||||
<li> None for this release. </li>
|
||||
</ul>
|
||||
|
||||
<h2>Changed behavior:</h2>
|
||||
<ul>
|
||||
<li> Behavior will be changed due to the list of bugs fixed (listed in RELEASE_NOTES); users are requested to review that list as well.
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.19 to ns-3.20</h1>
|
||||
<h2>New API:</h2>
|
||||
<ul>
|
||||
<li> Models have been added for low-rate, wireless personal area networks
|
||||
(LR-WPAN) as specified by IEEE standard 802.15.4 (2006). The current
|
||||
emphasis is on the unslotted mode of 802.15.4 operation for use in Zigbee,
|
||||
and the scope is limited to enabling a single mode (CSMA/CA) with basic
|
||||
data transfer capabilities. Association with PAN coordinators is not yet
|
||||
supported, nor the use of extended addressing. Interference is modeled as
|
||||
AWGN but this is currently not thoroughly tested. The NetDevice Tx queue
|
||||
is not limited, i.e., packets are never dropped due to queue becoming full.
|
||||
They may be dropped due to excessive transmission retries or channel access
|
||||
failure. </li>
|
||||
<li> A new IPv6 routing protocol has been added: RIPng. This protocol is
|
||||
an Interior Gateway Protocol and it is available in the Internet module. </li>
|
||||
<li> A new LTE MAC downlink scheduling algorithm named Channel and QoS
|
||||
Aware (CQA) Scheduler is provided by the new "ns3::CqaFfMacScheduler" object.
|
||||
</li>
|
||||
<li> Units may be attached to Time objects, to facilitate specific output
|
||||
formats (see Time::As()) </li>
|
||||
<li> FlowMonitor "SerializeToXml" functions are now directly available
|
||||
from the helper. </li>
|
||||
<li> Access to OLSR's HNA table has been enabled </li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to existing API:</h2>
|
||||
<ul>
|
||||
<li> The SixLowPan model can now use uncompressed IPv6 headers. An option to
|
||||
define the minimum compressed packet size has been added. </li>
|
||||
<li> MinDistance wsa replaced by MinLoss in FriisPropagationLossModel, to
|
||||
better handle conditions outside of the assumed far field region. </li>
|
||||
<li> In the DSR model, the attribute DsrOptionRerrHeader::ErrorType" has
|
||||
been removed. </li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to build system:</h2>
|
||||
<ul>
|
||||
<li> Python 3.3 is now supported for Python bindings for ns-3. Python 3.3
|
||||
support for API scanning is not supported. Python 3.2 is not supported.</li>
|
||||
<li> Enable selection of high precision int64x64_t implementation
|
||||
at configure time, for debugging purposes.</li>
|
||||
<li> Optimized builds are now enabling signed overflow optimization
|
||||
(-fstrict-overflow) and for gcc 4.8.2 and greater, also warning for cases
|
||||
where an optimizization may occur due to compiler assumption that
|
||||
overflow will not occur. </li>
|
||||
</ul>
|
||||
|
||||
<h2>Changed behavior:</h2>
|
||||
<ul>
|
||||
<li> The Internet FlowMonitor can now track IPv6 packets. </li>
|
||||
<li> Ipv6Extension::m_dropTrace has been removed. Ipv6L3Protocol::m_dropTrace
|
||||
is now fired when appropriate. </li>
|
||||
<li> IPv4 identification field value is now dependent on the protocol
|
||||
field. </li>
|
||||
<li> Point-to-point trace sources now contain PPP headers </li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.18.1 to ns-3.19</h1>
|
||||
|
||||
<h2>New API:</h2>
|
||||
<ul>
|
||||
<li> A new wifi extension for vehicular simulation support is available in the
|
||||
src/wave directory. The current code represents an interim capability to
|
||||
realize an IEEE 802.11p-compliant device, but without the WAVE extensions
|
||||
(which are planned for a later patch). The WaveNetDevice modelled herein
|
||||
enforces that a WAVE-compliant physical layer (at 5.9 GHz) is selected, and
|
||||
does not require any association between devices (similar to an adhoc WiFi
|
||||
MAC), but is otherwise similar (at this time) to a WifiNetDevice. WAVE
|
||||
capabililties of switching between control and service channels, or using
|
||||
multiple radios, are not yet modelled.
|
||||
</li>
|
||||
<li>New SixLowPanNetDevice class providing a shim between
|
||||
IPv6 and real NetDevices. The new module implements 6LoWPAN:
|
||||
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks" (see
|
||||
<a href="http://www.ietf.org/rfc/rfc4944.txt">RFC 4944</a> and
|
||||
<a href="http://www.ietf.org/rfc/rfc6262.txt">RFC 6262</a>),
|
||||
resulting in a heavy header compression for IPv6 packets.
|
||||
The module is intended to be used on 802.15.4 NetDevices, but
|
||||
it can be used over other NetDevices. See the manual for
|
||||
further discussion.
|
||||
</li>
|
||||
<li> LteHelper has been updated with some new APIs:
|
||||
<ul>
|
||||
<li>new overloaded Attach methods to enable UE to automatically determine
|
||||
the eNodeB to attach to (using initial cell selection);</li>
|
||||
<li>new methods related to handover algorithm: SetHandoverAlgorithmType
|
||||
and SetHandoverAlgorithmAttribute;</li>
|
||||
<li>a new attribute AnrEnabled to activate/deactivate Automatic Neighbour
|
||||
Relation (ANR) function; and</li>
|
||||
<li>a new method SetUeDeviceAttribute for configuring LteUeNetDevice.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li> The GSoC 2013 project in the LTE module has brought some additional APIs:
|
||||
<ul>
|
||||
<li>a new abstract class LteHandoverAlgorithm, which every future
|
||||
implementation of automatic handover trigger should inherit from;</li>
|
||||
<li>new classes LteHandoverAlgorithm and LteAnr as sub-modules of
|
||||
LteEnbNetDevice class; both interfacing with the LteEnbRrc sub-module
|
||||
through Handover Management SAP and ANR SAP;</li>
|
||||
<li>new attributes in LteEnbNetDevice and LteUeNetDevice classes related
|
||||
to Closed Subscriber Group (CSG) functionality in initial cell
|
||||
selection;</li>
|
||||
<li>new attributes in LteEnbRrc for configuring UE measurements' filtering
|
||||
coefficient (i.e., quantity configuration);</li>
|
||||
<li>a new public method AddUeMeasReportConfig in LteEnbRrc for setting up
|
||||
custom UE measurements' reporting configuration; measurement reports
|
||||
can then be captured from the RecvMeasurementReport trace source;
|
||||
and</li>
|
||||
<li>new trace sources in LteUeRrc to capture more events, such as System
|
||||
Information messages (MIB, SIB1, SIB2), initial cell selection, random
|
||||
access, and handover.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>A new parallel scheduling algorithm based on null messages, a common
|
||||
parallel DES scheduling algorithm, has been added. The null message
|
||||
scheduler has better scaling properties when running on some scenarios
|
||||
with large numbers of nodes since it does not require a global
|
||||
communication.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to existing API:</h2>
|
||||
<ul>
|
||||
<li> It is now possible to use Ipv6PacketInfoTag from UDP applications in the
|
||||
same way as with Ipv4PacketInfoTag. See Doxygen for current limitations in
|
||||
using Ipv[4,6]PacketInfoTag to set IP properties.</li>
|
||||
<li>A change is introduced for the usage of the EpcHelper
|
||||
class. Previously, the EpcHelper class included both the API
|
||||
definition and its (only) implementation; as such, users would
|
||||
instantiate and use the EpcHelper class directly in their
|
||||
simulation programs. From now on,
|
||||
EpcHelper is just the base class defining the API, and the
|
||||
implementation has been moved to derived classes; as such,
|
||||
users are now expected to use one of the derived classes in
|
||||
their simulation program. The implementation previously
|
||||
provided by the EpcHelper class has been moved to the new
|
||||
derived class PointToPointEpcHelper.</li>
|
||||
<li> The automatic handover trigger and ANR functions in LTE module have been
|
||||
moved from LteEnbRrc class to separate classes. As a result, the related
|
||||
attributes, e.g., ServingCellHandoverThreshold, NeighbourCellHandoverOffset,
|
||||
EventA2Threshold, and EventA4Threshold have been removed from LteEnbRrc
|
||||
class. The equivalent attributes are now in A2A4RsrqHandoverAlgorithm and
|
||||
LteAnr classes.</li>
|
||||
<li> Master Information Block (MIB) and System Information Block Type 1 (SIB1)
|
||||
are now transmitted as LTE control messages, so they are no longer part of
|
||||
RRC protocol.</li>
|
||||
<li> UE RRC state model in LTE module has been considerably modified and is
|
||||
not backward compatible with the previous state model.</li>
|
||||
<li> Additional time units (Year, Day, Hour, Minute) were added to the time
|
||||
value class that represents simulation time; the largest unit prior to
|
||||
this addition was Second.
|
||||
</li>
|
||||
<li> SimpleNetDevice and SimpleChannel are not so simple anymore. SimpleNetDevice can be now a
|
||||
Broadcast or PointToPoint NetDevice, it can have a limited bandwidth and it uses an output
|
||||
queue.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to build system:</h2>
|
||||
|
||||
<h2>Changed behavior:</h2>
|
||||
<ul>
|
||||
<li> For the TapBridge device, in UseLocal mode there is a MAC learning function. TapBridge has been waiting for the first packet received from tap interface to set the address of the bridged device to the source address of the first packet. This has caused problems with WiFi. The new behavior is that after connection to the tap interface, ns-3 learns the MAC address of that interface with a system call and immediately sets the address of the bridged device to the learned one. See <a href="https://www.nsnam.org/bugzilla/show_bug.cgi?id=1777">bug 1777</a> for more details.</li>
|
||||
<li> TapBridge device now correctly implements IsLinkUp() method.</li>
|
||||
<li> IPv6 addresses and routing tables are printed like in Linux "route -A inet6" command.</li>
|
||||
<li> A change in Ipv[4,6]Interface enforces the correct behaviour of IP
|
||||
when a device do not support the minimum MTU requirements.
|
||||
This is set to 68 and 1280 octects respectively. IP simulations that
|
||||
may have run over devices with smaller MTUs than 68 or 1280, respectively,
|
||||
will no longer be able to use such devices.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.18 to ns-3.18.1</h1>
|
||||
<h2>New API:</h2>
|
||||
<ul>
|
||||
<li> It is now possible to randomize the time of the first beacon from an
|
||||
access point. Use an attribute "EnableBeaconJitter" to enable/disable
|
||||
this feature.
|
||||
</li>
|
||||
<li> A new FixedRoomPositionAllocator helper class is available; it
|
||||
allows one to generate a random position uniformly distributed in the
|
||||
volume of a chosen room inside a chosen building.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to existing API:</h2>
|
||||
<ul>
|
||||
<li> Logging wildcards: allow "***" as synonym for "*=**" to turn on all logging.
|
||||
</li>
|
||||
<li> The log component list ("NS_LOG=print-list") is now printed alphabetically.
|
||||
</li>
|
||||
<li> Some deprecated IEEE 802.11p code has been removed from the wifi module
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to build system:</h2>
|
||||
<ul>
|
||||
<li> The Python API scanning system (./waf --apiscan) has been fixed (bug 1622)
|
||||
</li>
|
||||
<li> Waf has been upgraded from 1.7.11 to 1.7.13
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changed behavior:</h2>
|
||||
<ul>
|
||||
<li> Wifi simulations have additional jitter on AP beaconing (see above) and some bug fixes have been applied to wifi module (see RELEASE_NOTES)
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.17 to ns-3.18</h1>
|
||||
|
||||
<h2>New API:</h2>
|
||||
<ul>
|
||||
<li>New features have been added to the LTE module:
|
||||
<ul>
|
||||
<li>PHY support for UE measurements (RSRP and RSRQ)</li>
|
||||
<li>RRC support for UE measurements (configuration, execution, reporting)</li>
|
||||
<li>Automatic Handover trigger based on RRC UE measurement reports</li>
|
||||
</ul>
|
||||
<li>Data collection components have been added in the 'src/stats' module.
|
||||
Data collection includes a Probe class that attaches to ns-3 trace
|
||||
sources to filter their output, and two Aggregator classes for
|
||||
marshaling probed data into text files or gnuplot plots. The ns-3
|
||||
tutorial has been extended to illustrate basic functionality. </li>
|
||||
<li>In 'src/wifi', several changes were made to enable partial 802.11n support:
|
||||
<ul>
|
||||
<li>A new helper (HtWifiMacHelper) was added to set up a high throughput (HT) MAC entity</li>
|
||||
<li>New attributes were added to help the user setup a high throughpt (HT) PHY entity. These attributes can be set using the YansWifiPhyHelper</li>
|
||||
<li>A new standard value has been added that enables the new 11n data rates.</li>
|
||||
<li>New 11n preambles has been added (Mixed format and greenfield). To be able to change Tx duration according to the preamble used, a new class TxVector has been added to carry the transmission parameters (mode, preamble, stbc,..). Several functions have been updated to allow the passage of TxVector instead of WifiMode in MacLow, WifiRemoteStationManager, WifiPhy, YansWifiPhy,.. </li>
|
||||
<li>A new information element has been added: HTCapabilities. This information element is added to the MAC frame header if the node is an HT node. This HTCapabilites information element is used to advertise the HT capabilites of the node to other nodes in the network</li>
|
||||
</ul>
|
||||
<li>InternetStackHelper has two new functions:<tt>SetIpv4ArpJitter (bool enable)</tt>
|
||||
and <tt>SetIpv6NsRsJitter (bool enable)</tt> to enable/disable
|
||||
the random jitter on the tranmission of IPv4 ARP Request and IPv6 NS/RS. </li>
|
||||
<li>Bounds on valid time inputs for time attributes can now be enabled.
|
||||
See <tt>attribute-test-suite.cc</tt> for an example.</li>
|
||||
<li>New generic hash function interface provided in the simulation core.
|
||||
Two hash functions are provided: murmur3 (default), and the venerable
|
||||
FNV1a. See the Hash Functions section in the ns-3 manual.</li>
|
||||
<li>New Mac16Address has been added. It can be used with IPv6 to make
|
||||
an Autoconfigured address.</li>
|
||||
<li>Mac64Address support has been extended. It can now be used with
|
||||
IPv6 to make an Autoconfigured address.</li>
|
||||
<li>IPv6 can now detect and use Path-MTU. See
|
||||
<tt>examples/ipv6/fragmentation-ipv6-two-MTU.cc</tt> for an example.</li>
|
||||
<li>Radvd application has a new Helper. See the updated
|
||||
<tt>examples/ipv6/radvd.cc</tt> for an example.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to existing API:</h2>
|
||||
<ul>
|
||||
<li> The Ipv6InterfaceContainer functions to set a node in forwarding state (i.e., a router)
|
||||
and to install a default router in a group of nodes have been extensively changed.
|
||||
The old function <tt>void Ipv6InterfaceContainer::SetRouter (uint32_t i, bool router)</tt>
|
||||
is now DEPRECATED.
|
||||
</li>
|
||||
<li> The documentation's IPv6 addresses (2001:db8::/32, RFC 3849) are now
|
||||
dropped by routers.
|
||||
</li>
|
||||
<li> The 'src/tools' module has been removed, and most files migrated to
|
||||
'src/stats'. For users of these programs (the statistics-processing
|
||||
in average.h, or the gnuplot support), the main change is likely to be
|
||||
replacing the inclusion of "tools-module.h" with "stats-module.h".
|
||||
Users of the event garbage collector, previously in tools, will now
|
||||
include it from the core module.
|
||||
</li>
|
||||
<li> The Ipv6 UnicastForwardCallback and MulticastForwardCallback
|
||||
have a new parameter, the NetDevice the packet has been received from.
|
||||
Existing Ipv6RoutingProtocols should update their RouteInput function
|
||||
accordingly, e.g., from <tt>ucb (rtentry, p, header);</tt> to <tt>ucb (idev, rtentry, p, header);</tt>
|
||||
</li>
|
||||
<li> The previous buildings module relied on a specific MobilityModel called
|
||||
BuildingsMobilityModel, which supported buildings but only allowed
|
||||
static positions. This mobility model has been removed. Now, the
|
||||
Buildings module instead relies on a new class called
|
||||
MobilityBuildingInfo which can be aggregated to any MobilityModel. This
|
||||
allows having moving nodes in presence of buildings with any of
|
||||
the existing MobilityModels.
|
||||
</li>
|
||||
<li>All functions in WifiRemoteStationManager named GetXxxMode have been changed to GetXxxTxVector </li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to build system:</h2>
|
||||
<ul>
|
||||
<li> Make references to bug id's in doxygen comments with
|
||||
<tt>\bugid{num}</tt>, where <tt>num</tt> is the bug id number. This
|
||||
form will generate a link to the bug in the bug database.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changed behavior:</h2>
|
||||
<ul>
|
||||
<li> Now it is possible to request printing command line arguments to the
|
||||
desired output stream using PrintHelp or operator <<
|
||||
<pre>
|
||||
CommandLine cmd;
|
||||
cmd.Parse (argc, argv);
|
||||
...
|
||||
|
||||
std::cerr << cmd;
|
||||
</pre>
|
||||
or
|
||||
<pre>
|
||||
cmd.PrintHelp (std::cerr);
|
||||
</pre>
|
||||
</li>
|
||||
<li>Command line boolean arguments specified with no integer value (e.g. <tt>"--boolArg"</tt>) will toggle the value from the default, instead of always setting the value to true.
|
||||
</li>
|
||||
<li>IPv4's ARP Request and IPv6's NS/RS are now transmitted with a random delay.
|
||||
The delay is, by default, a uniform random variable in time between 0 and 10ms.
|
||||
This is aimed at preventing reception errors due to collisions during wifi broadcasts when the sending behavior is synchronized (e.g. due to applications starting at the same time on several different nodes).
|
||||
This behaviour can be modified by using ArpL3Protocol's
|
||||
<tt>RequestJitter</tt> and Icmpv6L4Protocol's <tt>SolicitationJitter</tt>
|
||||
attributes or by using the new InternetStackHelper functions.
|
||||
</li>
|
||||
<li>AODV Hellos are disabled by default. The performance with Hellos enabled and disabled are almost identical. With Hellos enabled, AODV will suppress hellos from transmission, if any recent broadcast such as RREQ was transmitted. The attribute <tt>ns3::aodv::RoutingProtocol::EnableHello</tt> can be used to enable/disable Hellos.
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.16 to ns-3.17</h1>
|
||||
|
||||
<h2>New API:</h2>
|
||||
<ul>
|
||||
<li>New TCP Westwood and Westwood+ models
|
||||
<li>New FdNetDevice class providing a special NetDevice that is able to read
|
||||
and write traffic from a file descriptor. Three helpers are provided
|
||||
to associate the file descriptor with different underlying devices:
|
||||
<ul>
|
||||
<li> EmuFdNetDeviceHelper (to associate the |ns3| device with a physical
|
||||
device in the host machine). This helper is intended to
|
||||
eventually replace the EmuNetDevice in src/emu. </li>
|
||||
<li> TapFdNetDeviceHelper (to associate the ns-3 device with the file
|
||||
descriptor from a tap device in the host machine) </li>
|
||||
<li> PlanteLabFdNetDeviceHelper (to automate the creation of tap devices
|
||||
in PlanetLab nodes, enabling |ns3| simulations that can send and
|
||||
receive traffic though the Internet using PlanetLab resource.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>In Ipv4ClickRouting, the following APIs were added:
|
||||
<ul>
|
||||
<li>Ipv4ClickRouting::SetDefines(), accessible through ClickInternetStackHelper::SetDefines(), for the user to set Click defines from the ns-3 simulation file.</li>
|
||||
<li>SIMCLICK_GET_RANDOM_INT click-to-simulator command for ns-3 to drive Click's random number generation.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>LTE module
|
||||
<ul>
|
||||
<li> New user-visible LTE API
|
||||
<ul>
|
||||
<li>Two new methods have been added to LteHelper to enable the X2-based handover functionality: AddX2Interface, which setups the X2 interface between two eNBs, and HandoverRequest, which is a convenience method that schedules an explicit handover event to be executed at a given point in the simulation. </li>
|
||||
<li>the new LteHelper method EnablePhyTraces can now be used to enable the new PHY traces</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li> New internal LTE API
|
||||
<ul>
|
||||
<li>New LTE control message classes DlHarqFeedbackLteControlMessage,
|
||||
RachPreambleLteControlMessage, RarLteControlMessage, MibLteControlMessage</li>
|
||||
<li>New class UeManager
|
||||
<li>New LteRadioBearerInfo subclasses LteSignalingRadioBearerInfo,
|
||||
LteDataRadioBearerInfo</li>
|
||||
<li>New LteSinrChunkProcessor subclasses LteRsReceivedPowerChunkProcessor,
|
||||
LteInterferencePowerChunkProcessor</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>New DSR API
|
||||
<ul>
|
||||
<li>Added PassiveBuffer class to save maintenance packet entry for passive acknowledgment option</li>
|
||||
<li>Added FindSourceEntry function in RreqTable class to keep track of route request entry received from same source node</li>
|
||||
<li>Added NotifyDataReciept function in DsrRouting class to notify the data receipt of the next hop from link layer. This is used for the link layer acknowledgment.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>New Tag, PacketSocketTag, to carry the destination address of a packet and the packet type</li>
|
||||
<li>New Tag, DeviceNameTag, to carry the ns3 device name from where a packet is coming</li>
|
||||
<li>New Error Model, BurstError model, to determine which bursts of packets are errored corresponding to an underlying distribution, burst rate, and burst size</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changes to existing API:</h2>
|
||||
<ul>
|
||||
<li>ns3::Object and subclasses DoStart has been renamed to DoInitialize</li>
|
||||
<li>ns3::Object and subclasses Start has been renamed to Initialize</li>
|
||||
<li>EnergySource StartDeviceModels renamed to InitializeDeviceModels</li>
|
||||
<li>A typo was fixed in an LTE variable name. The variable ns3::AllocationRetentionPriority::preemprionVulnerability was changed to preemptionVulnerability.</li>
|
||||
<li>Changes in TestCase API
|
||||
<ul>
|
||||
<li>TestCase has new enumeration TestDuration containing QUICK, EXTENSIVE, TAKES_FOREVER</li>
|
||||
<li>TestCase constructor now requires TestDuration, old constructor marked deprecated</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li>Changes in LTE API
|
||||
<ul>
|
||||
<li> User-visible LTE API
|
||||
<ul>
|
||||
<li>The previous LteHelper method ActivateEpsBearer has been now replaced by two alternative methods: ActivateDataRadioBearer (to be used when the EPC model is not used) and ActivateDedicatedEpsBearer (to be used when the EPC model is used). In the case where the EPC model is used, the default EPS bearer is not automatically activated without the need for a specific method to be called.</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li> Internal LTE API
|
||||
<ul>
|
||||
<li>EpcHelper added methods AddUe, AddX2Interface. Method AddEnb now requires a cellId. Signature of ActivateEpsBearer changed to void ActivateEpsBearer (Ptr<NetDevice> ueLteDevice, uint64_t imsi, Ptr<EpcTft> tft, EpsBearer bearer)</li>
|
||||
<li>LteHelper added methods EnableDlPhyTraces, EnableUlPhyTraces, EnableDlTxPhyTraces, EnableUlTxPhyTraces, EnableDlRxPhyTraces, EnableUlRxPhyTraces</li>
|
||||
<li>LteHelper removed methods EnableDlRlcTraces, EnableUlRlcTraces, EnableDlPdcpTraces, EnableUlPdcpTraces</li>
|
||||
<li>RadioBearerStatsCalculator added methods (Set/Get)StartTime, (Set/Get)Epoch, RescheduleEndEpoch, EndEpoch</li>
|
||||
<li>RadioBearerStatsCalculator removed methods StartEpoch, CheckEpoch</li>
|
||||
<li>RadioBearerStatsCalculator methods UlTxPdu, DlRxPdu now require a cellId</li>
|
||||
<li>EpcEnbApplication constructor now requires Ipv4Addresses enbS1uAddress and sgwS1uAddress as well as cellId</li>
|
||||
<li>EpcEnbApplication added methods SetS1SapUser, GetS1SapProvider, SetS1apSapMme and GetS1apSapEnb</li>
|
||||
<li>EpcEnbApplication removed method ErabSetupRequest</li>
|
||||
<li>EpcSgwPgwApplication added methods SetS11SapMme, GetS11SapSgw, AddEnb, AddUe, SetUeAddress</li>
|
||||
<li>lte-common.h new structs PhyTransmissionStatParameters and PhyReceptionStatParameters used in TracedCallbacks</li>
|
||||
<li>LteControlMessage new message types DL_HARQ, RACH_PREAMBLE, RAR, MIB</li>
|
||||
<li>LteEnbCmacSapProvider new methods RemoveUe, GetRachConfig, AllocateNcRaPreamble, AllocateTemporaryCellRnti</li>
|
||||
<li>LteEnbPhy new methods GetLteEnbCphySapProvider, SetLteEnbCphySapUser, GetDlSpectrumPhy, GetUlSpectrumPhy, CreateSrsReport</li>
|
||||
<li>LteEnbPhy methods DoSendMacPdu, DoSetTransmissionMode, DoSetSrsConfigurationIndex, DoGetMacChTtiDelay, DoSendLteControlMessage, AddUePhy, DeleteUePhy made private</li>
|
||||
<li>LteEnbPhySapProvider removed methods SetBandwidth, SetTransmissionMode, SetSrsConfigurationIndex, SetCellId</li>
|
||||
<li>LteEnbPhySapUser added methods ReceiveRachPreamble, UlInfoListElementHarqFeeback, DlInfoListElementHarqFeeback</li>
|
||||
<li>LtePdcp added methods (Set/Get)Status</li>
|
||||
<li>LtePdcp DoTransmitRrcPdu renamed DoTransmitPdcpSdu</li>
|
||||
<li>LteUeRrc new enum State. New methods SetLteUeCphySapProvider, GetLteUeCphySapUser, SetLteUeRrcSapUser, GetLteUeRrcSapProvider, GetState, GetDlEarfcn, GetDlBandwidth, GetUlBandwidth, GetCellId, SetUseRlcSm . GetRnti made const.</li>
|
||||
<li>LteUeRrc removed methods ReleaseRadioBearer, GetLcIdVector, SetForwardUpCallback, DoRrcConfigurationUpdateInd</li>
|
||||
<li>LtePdcpSapProvider struct TransmitRrcPduParameters renamed TransmitPdcpSduParameters. Method TransmitRrcPdu renamed TransmitPdcpSdu </li>
|
||||
<li>LtePdcpSapUser struct ReceiveRrcPduParameters renamed ReceivePdcpSduParameters. Method ReceiveRrcPdu renamed TransmitPdcpSdu</li>
|
||||
<li>LtePdcpSpecificLtePdcpSapProvider method TransmitRrcPdu renamed TransmitPdcpSdu</li>
|
||||
<li>LtePdcpSpecificLtePdcpSapUser method ReceiveRrcPdu renamed ReceivePdcpSdu. Method ReceiveRrcPdu renamed ReceivePdcpSdu</li>
|
||||
<li>LtePhy removed methods DoSetBandwidth and DoSetEarfcn</li>
|
||||
<li>LtePhy added methods ReportInterference and ReportRsReceivedPower</li>
|
||||
<li>LteSpectrumPhy added methods SetHarqPhyModule, Reset, SetLtePhyDlHarqFeedbackCallback, SetLtePhyUlHarqFeedbackCallback, AddRsPowerChunkProcessor, AddInterferenceChunkProcessor</li>
|
||||
<li>LteUeCphySapProvider removed methods ConfigureRach, StartContentionBasedRandomAccessProcedure, StartNonContentionBasedRandomAccessProcedure</li>
|
||||
<li>LteUeMac added method AssignStreams</li>
|
||||
<li>LteUeNetDevice methods GetMac, GetRrc, GetImsi made const</li>
|
||||
<li>LteUeNetDevice new method GetNas</li>
|
||||
<li>LteUePhy new methods GetLteUeCphySapProvider, SetLteUeCphySapUser, GetDlSpectrumPhy, GetUlSpectrumPhy, ReportInterference, ReportRsReceivedPower, ReceiveLteDlHarqFeedback</li>
|
||||
<li>LteUePhy DoSendMacPdu, DoSendLteControlMessage, DoSetTransmissionMode, DoSetSrsConfigurationIndex made private</li>
|
||||
<li>LteUePhySapProvider removed methods SetBandwidth, SetTransmissionMode, SetSrsConfigurationIndex</li>
|
||||
<li>LteUePhySapProvider added method SendRachPreamble</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
<li>AnimationInterface method EnableIpv4RouteTracking returns reference to calling AnimationInterface object</li>
|
||||
<li>To make the API more uniform across the various
|
||||
PropagationLossModel classes, the Set/GetLambda methods of the
|
||||
FriisPropagationLossModel and TwoRayGroundPropagationLossModel
|
||||
classes have been changed to Set/GetFrequency, and now a Frequency
|
||||
attribute is exported which replaces the pre-existing Lambda
|
||||
attribute. Any previous user code setting a value for Lambda should
|
||||
be changed to set instead a value of Frequency = C / Lambda, with C
|
||||
= 299792458.0. </li>
|
||||
</ul>
|
||||
<h2>Changes to build system:</h2>
|
||||
<ul>
|
||||
<li>Waf shipped with ns-3 has been upgraded to version 1.7.10 and custom
|
||||
pkg-config generator has been replaced by Waf's builtin tool.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<h2>Changed behavior:</h2>
|
||||
<ul>
|
||||
<li>DSR link layer notification has changed. The model originally used
|
||||
"TxErrHeader" in Ptr<WifiMac> to indicate the transmission
|
||||
error of a specific packet in link layer; however, it was not working
|
||||
correctly. The model now uses a different path to implement
|
||||
the link layer notification mechanism; specifically, looking into the
|
||||
trace file to find packet receive events. If the model finds one
|
||||
receive event for the data packet, it is used as the indicator for
|
||||
successful data delivery.</li>
|
||||
</ul>
|
||||
|
||||
<hr>
|
||||
<h1>Changes from ns-3.15 to ns-3.16</h1>
|
||||
|
||||
@@ -58,7 +619,7 @@ us a note on ns-developers mailing list.</p>
|
||||
<li>(Set/Is)Ipv6RecvTclass - tells the socket to pass information about IPv6 TCLASS up the stack (by adding SocketIpv6TclassTag to the packet).</li>
|
||||
<li>(Set/Get)Ipv6HopLimit - sets Hop Limit field in the IPv6 headers.</li>
|
||||
<li>(Set/Is)Ipv6RecvHopLimit - tells the socket to pass information about IPv6 HOPLIMIT up the stack (by adding SocketIpv6HoplimitTag to the packet).</li>
|
||||
</ul>
|
||||
</ul>
|
||||
A user can call these functions to set/get the corresponding socket option. See examples/socket/socket-options-ipv4.cc and examples/socket/socket-options-ipv6.cc for examples.
|
||||
</ul>
|
||||
|
||||
@@ -912,16 +1473,16 @@ For example, before:
|
||||
<pre>
|
||||
void
|
||||
SimpleChannel::Send (Ptr<Packet> p, uint16_t protocol,
|
||||
Mac48Address to, Mac48Address from,
|
||||
Ptr<SimpleNetDevice> sender)
|
||||
Mac48Address to, Mac48Address from,
|
||||
Ptr<SimpleNetDevice> sender)
|
||||
{
|
||||
for (std::vector<Ptr<SimpleNetDevice> >::const_iterator i = m_devices.begin (); i != m_devices.end (); ++i)
|
||||
{
|
||||
Ptr<SimpleNetDevice> tmp = *i;
|
||||
if (tmp == sender)
|
||||
{
|
||||
continue;
|
||||
}
|
||||
{
|
||||
continue;
|
||||
}
|
||||
Simulator::ScheduleNow (&SimpleNetDevice::Receive, tmp, p->Copy (), protocol, to, from);
|
||||
}
|
||||
}
|
||||
@@ -930,16 +1491,16 @@ After:
|
||||
<pre>
|
||||
void
|
||||
SimpleChannel::Send (Ptr<Packet> p, uint16_t protocol,
|
||||
Mac48Address to, Mac48Address from,
|
||||
Ptr<SimpleNetDevice> sender)
|
||||
Mac48Address to, Mac48Address from,
|
||||
Ptr<SimpleNetDevice> sender)
|
||||
{
|
||||
for (std::vector<Ptr<SimpleNetDevice> >::const_iterator i = m_devices.begin (); i != m_devices.end (); ++i)
|
||||
{
|
||||
Ptr<SimpleNetDevice> tmp = *i;
|
||||
if (tmp == sender)
|
||||
{
|
||||
continue;
|
||||
}
|
||||
{
|
||||
continue;
|
||||
}
|
||||
Simulator::ScheduleWithContext (tmp->GetNode ()->GetId (), Seconds (0),
|
||||
&SimpleNetDevice::Receive, tmp, p->Copy (), protocol, to, from);
|
||||
}
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
# Makefile wrapper for waf
|
||||
|
||||
all:
|
||||
./waf
|
||||
|
||||
# free free to change this part to suit your requirements
|
||||
configure:
|
||||
./waf configure --enable-examples --enable-tests
|
||||
|
||||
build:
|
||||
./waf build
|
||||
|
||||
install:
|
||||
./waf install
|
||||
|
||||
clean:
|
||||
./waf clean
|
||||
|
||||
distclean:
|
||||
./waf distclean
|
||||
+565
-9
@@ -9,6 +9,562 @@ http://www.nsnam.org including tutorials: http://www.nsnam.org/tutorials.html
|
||||
Consult the file CHANGES.html for more detailed information about changed
|
||||
API and behavior across ns-3 releases.
|
||||
|
||||
Release 3.21
|
||||
============
|
||||
|
||||
Availability
|
||||
------------
|
||||
This release is not yet available.
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
- Fedora Core 20 (32/64 bit) with g++-4.8.2
|
||||
- Ubuntu 14.04 (32/64 bit) with g++-4.8.2
|
||||
- Ubuntu 12.04.4 (64 bit) with g++-4.6.3
|
||||
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
|
||||
- CentOS/RHEL 6.5 (64-bit) with g++-4.4.7
|
||||
- OS X Mavericks 10.9 with Xcode 5.1.1 and clang-503.0.40
|
||||
- FreeBSD 9.2-RELEASE (64 bit) with clang-3.3
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
|
||||
- The LTE module now supports the transport of the S1-U, X2-U and X2-C
|
||||
interfaces over emulated links via the new helper class EmuEpcHelper.
|
||||
- CommandLine can now provide a shorthand argument name for any
|
||||
Attribute.
|
||||
- Implemented support for Frequency Reuse algorithms in LTE module, as the
|
||||
outcome of GSoC 2014 project.
|
||||
The project also includes several sub-features, such as:
|
||||
- implementation of Downlink Power Control
|
||||
- implementation of Uplink Power Control
|
||||
- new DL-CQI generation approach, which increases throughput if FR algorithms
|
||||
are used
|
||||
- seven options of Frequency Reuse algorithms: LteFrNoOpAlgorithm,
|
||||
LteFrHardAlgorithm, LteFrStrictAlgorithm, LteFrSoftAlgorithm,
|
||||
LteFfrSoftAlgorithm, LteFfrEnhancedAlgorithm, LteFfrDistributedAlgorithm
|
||||
- updated RadioEnvironmentMapHelper. Now RadioEnvironmentMap can be generated
|
||||
for Data or Control channel and for specified RbId, what is helpful when
|
||||
using FR algorithms
|
||||
- Added a CoDel queue model. CoDel queues measure and control the queue
|
||||
traversal delay. The ns-3 implementation is a port of the Linux
|
||||
implementation.
|
||||
- Added support for TCP timestamp and window scale options, and added
|
||||
ability to trace the TCP slow start threshold value.
|
||||
- SimpleNetDevice and SimpleChannel (used for adding basic link effects
|
||||
for testing of higher-layer protocols) have been extended to support
|
||||
the option of broadcast or PointToPoint link semantics. The bandwidth
|
||||
and link delay can be constrained, and it uses an output queue.
|
||||
- SimpleNetDevice and SimpleChannel can be installed in a node through
|
||||
a new helper: SimpleNetDeviceHelper.
|
||||
- Implemented new PacketSocketServer and PacketSocketClient applications.
|
||||
The primary use is in tests, to avoid using the ones from the
|
||||
application module that also bring in a dependency on the internet module.
|
||||
|
||||
Bugs fixed
|
||||
----------
|
||||
|
||||
- Bug 1673 - Config::Set/Connect does not search for attributes in parent class
|
||||
- Bug 1762 - UE stuck in IDLE_CONNECTING because RRC CONN REQ is not transmitted
|
||||
- Bug 1811 - basic traffic generator for network module
|
||||
- Bug 1824 - L4 protocol sockets should support BindToNetDevice over IPv6
|
||||
- Bug 1831 - TcpSocket SlowStartThreshold is not a TraceSource
|
||||
- Bug 1851 - WifiRadioEnergyModel energy consumption values are taken from a 802.15.4 chip
|
||||
- Bug 1854 - std::out_of_range Problem
|
||||
- Bug 1858 - wireless examples not correctly recording packet reception
|
||||
- Bug 1860 - TCP needs the Window Scale option
|
||||
- Bug 1893 - issue in DoSchedUlTriggerReq with harq
|
||||
- Bug 1911 - AODV cannot work on nodes with more than one netdevice
|
||||
- Bug 1921 - Icmpv6L4Protocol::ForgeEchoRequest returns a malformed packet
|
||||
- Bug 1930 - Use of invalid reference in OLSR RemoveLinkTuple
|
||||
- Bug 1932 - NdiscCache entry is not failsafe on double neighbor probing.
|
||||
- Bug 1937 - FlowMonitor fails to track multiplexed packets
|
||||
- Bug 1942 - refactoring of lte-sinr-chunk-processor -> lte-chunk-processor
|
||||
- Bug 1943 - Waveform generator signal duration calc error
|
||||
- Bug 1951 - AODV does not update nexthop for 1-hop nodes
|
||||
- Bug 1955 - The IPv4 identification field should be unique per (source, destination, protocol) tuple
|
||||
- Bug 1960 - Wrong information on index range, about Node::GetDevice
|
||||
- Bug 1961 - planetlab-tap-creator "variable set but not used"
|
||||
- Bug 1963 - AODV can tag the same packet twice (and raise an assert)
|
||||
- Bug 1964 - Integer overflow on UniformRandomVariable::GetInteger()
|
||||
- Bug 1967 - LL Multicast is not compressed in the right way in IPHC
|
||||
- Bug 1981 - PyViz shell not compatible with ipython >= 0.11
|
||||
|
||||
Known issues
|
||||
------------
|
||||
- Bug 1770 - The mesh module will crash if used for g++ version >= 4.8.1
|
||||
in optimized mode, on a 32-bit Linux machine. Lowering the optimization
|
||||
level to -O1 in this case can be used as a workaround.
|
||||
|
||||
Release 3.20
|
||||
=============
|
||||
|
||||
Availability
|
||||
------------
|
||||
This release is available from:
|
||||
http://www.nsnam.org/release/ns-allinone-3.20.tar.bz2
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
- Fedora Core 20 (32/64 bit) with g++-4.8.2
|
||||
- Ubuntu 14.04 (32/64 bit) with g++-4.8.2
|
||||
- Ubuntu 12.04.4 (64 bit) with g++-4.6.3
|
||||
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
|
||||
- CentOS/RHEL 6.5 (64-bit) with g++-4.4.7
|
||||
- OS X Mavericks 10.9 with Xcode 5.1.1 and clang-503.0.40
|
||||
- FreeBSD 9.2-RELEASE (64 bit) with clang-3.3
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
|
||||
- A new LrWpan model, providing initial support for IEEE 802.15.4 networks
|
||||
- A new IPv6 routing protocol has been added: RIPng. This protocol is
|
||||
an Interior Gateway Protocol and it is available in the Internet module.
|
||||
- A new LTE MAC downlink scheduling algorithm named Channel and QoS Aware (CQA)
|
||||
Scheduler is provided by the new ``ns3::CqaFfMacScheduler`` object.
|
||||
- The Internet FlowMonitor can now track IPv6 packets.
|
||||
- FlowMonitor no longer tracks multicast/broadcast packets, reflecting
|
||||
its original design.
|
||||
- FlowMonitor "SerializeToXml" functions are now directly available
|
||||
from the helper.
|
||||
- The SixLowPan model can now use uncompressed IPv6 headers. An option to
|
||||
define the minimum compressed packet size has been added.
|
||||
- Simplify output of Times in a specific unit; see Time::As ()
|
||||
- Ipv6Extension::m_dropTrace has been removed. Ipv6L3Protocol::m_dropTrace
|
||||
is now fired when appropriate.
|
||||
- IPv4 identification field value is now dependent on the protocol field.
|
||||
- Fixes to support Python >= 3.3 in ns3 Python bindings
|
||||
- Enable selection of high precision int64x64_t implementation
|
||||
at configure time, for debugging purposes.
|
||||
|
||||
Bugs fixed
|
||||
----------
|
||||
- Bug 1276 - optimize NistErrorRateModel
|
||||
- Bug 1294 - New PeekU8 () and Read (Buffer::Iterator start, uint32_t size) methods in Buffer::Iterator
|
||||
- Bug 1443 - MinDistance replaced by MinLoss in FriisPropagationLossModel, to
|
||||
better handle conditions outside of the assumed far field region.
|
||||
- Bug 1653 - Extension of CommandLine interface: restored operator << (CommandLine)
|
||||
- Bug 1717 - Detect unsettable attributes
|
||||
- Bug 1730 - no model library documentation for spectrum module
|
||||
- Bug 1739 - The endpoint is not deallocated for UDP sockets
|
||||
- Bug 1786 - os << int64x64_t prints un-normalized fractional values
|
||||
- Bug 1787 - Runtime error when using AnimationInterface::EnablePacketMetadata() to fetch metadata of CSMA packet
|
||||
- Bug 1792 - Parameter logger constructor
|
||||
- Bug 1808 - FlowMon relies on IPv4's Identification field to trace packets
|
||||
- Bug 1817 - IPv4 Identification field should consider protocol as well.
|
||||
- Bug 1818 - FlowMonitor needs IPv6 support
|
||||
- Bug 1820 - models library doc: make should not rm -rf figures
|
||||
- Bug 1821 - Setting an interface to Down state will cause various asserts in IPv6
|
||||
- Bug 1829 - Multiple TCP socket entries
|
||||
- Bug 1837 - AODV crashes when using multiple interfaces
|
||||
- Bug 1838 - FlowMonitorHelper must not be copied.
|
||||
- Bug 1841 - FlowMonitor fails to install if IPv4 is not installed in the node
|
||||
- Bug 1842 - FlowMonitor SerializeToXml<Something> should be called by the helper
|
||||
- Bug 1843 - IPv6 extensions dropped packets do not fire L3 drop trace
|
||||
- Bug 1845 - FlowMonitor should discard any broadcast/multicast packet
|
||||
- Bug 1846 - IPv6 should send Destination Unreachable if no route is available
|
||||
- Bug 1850 - TCP NewReno loss behavior
|
||||
- Bug 1852 - cairo-wideint-private.h error cannot find definitions for fixed-width integral types
|
||||
- Bug 1853 - NS_LOG_FUNCTION broken on OSX 10.9
|
||||
- Bug 1855 - SixLowPanNetDevice is not correctly indexed
|
||||
- Bug 1857 - Detect location of installed boost libraries
|
||||
- Bug 1862 - NS_LOG="Time=*|prefix_time" causes stack overflow
|
||||
- Bug 1868 - Optimized builds are sensitive to -fstrict-overflow
|
||||
- Bug 1870 - Remove unnecessary AsInt functions
|
||||
- Bug 1872 - Inside RREQ processing, in case of IP duplication, packet dropped instead of being forwarded
|
||||
- Bug 1873 - Energy source checked to be aggregated to the node
|
||||
- Bug 1874 - Ipv4L3Protocol::ProcessFragment: addressCombination and idProto identifiers not properly computed
|
||||
- Bug 1876 - enable OLSR HNA table access
|
||||
- Bug 1877 - constructors missing for PropagationLossModels
|
||||
- Bug 1882 - int64x64 tests trigger valgrind bug
|
||||
- Bug 1883 - IPv6 don't consider the prefix and network when choosing output address
|
||||
- Bug 1885 - WifiSpectrumValue5MhzFactory::CreateRfFilter does not align with the used 5Mhz SpectrumModel
|
||||
- Bug 1887 - Point-to-point traces should contain PPP headers
|
||||
- Bug 1888 - COST231 propagation loss model: corrections
|
||||
- Bug 1889 - PointToPointNetDevice: In some cases MacTxDrop trace is not called
|
||||
- Bug 1890 - UdpClientTrace: MPEG frame size is squeezed into (insufficient) 16 bit integer
|
||||
- Bug 1891 - UdpSocketImpl::GetSockName doesn't return the IPv6 address
|
||||
- Bug 1894 - CqaFfMacScheduler needs an update
|
||||
- Bug 1895 - IP header Source Address changed while forwarding RREQ
|
||||
- Bug 1900 - Avoid floating point differences across platforms in test outputs
|
||||
- Bug 1903 - Namespace usage in olsr-state.cc/h
|
||||
- Bug 1907 - Add IsSupportedMcs method in YansWifiPhy
|
||||
- Bug 1912 - Avoid multiple Wifi MacTxMiddle instances
|
||||
- Bug 1913 - Avoid crash in Wifi BlockAckManager::GetNextPacket()
|
||||
- Bug 1915 - BRITE channel delay is rounded to an integer
|
||||
- Bug 1916 - RandomWalk2dMobilityMode default "Bounds" attribute is not a rectangle
|
||||
- Bug 1919 - Strip trailing semi-colons from mobility trace files
|
||||
- Bug 1920 - Remove DSR attributes so file can be re-loaded by config-store
|
||||
- Bug 1922 - WAVE GetSsid should not be fatal
|
||||
- Bug 1923 - Setting Active Probing to false in Wifi Sta has no effect
|
||||
- Bug 1924 - sensing radius and CCA
|
||||
|
||||
Known issues
|
||||
------------
|
||||
- Bug 1770 - The mesh module will crash if used for g++ version >= 4.8.1
|
||||
in optimized mode, on a 32-bit Linux machine. Lowering the optimization
|
||||
level to -O1 in this case can be used as a workaround.
|
||||
|
||||
Release 3.19
|
||||
=============
|
||||
|
||||
Availability
|
||||
------------
|
||||
This release is available from:
|
||||
http://www.nsnam.org/release/ns-allinone-3.19.tar.bz2
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
These platforms have been tested; others may work also:
|
||||
- Fedora Core 20 (32 bit) with g++-4.8.2
|
||||
- Fedora Core 19 (32/64 bit) with g++-4.8.1
|
||||
- Ubuntu 13.10 (64 bit) with g++-4.8.1
|
||||
- Ubuntu 12.04.3 (32/64 bit) with g++-4.6.3
|
||||
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
|
||||
- OS X Mavericks 10.9 with Xcode 5.0.1 and clang-500.2.79
|
||||
- OS X Mountain Lion 10.8.5 with Xcode 5 and g++-4.2.1
|
||||
- FreeBSD 9.2-RELEASE (64 bit) with clang-3.3
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
- Extension to UE measurements and improved handover algorithm models in LTE
|
||||
module, as the outcome of GSoC 2013 project. The project also includes several
|
||||
sub-features, such as:
|
||||
- implementation of System Information Block Type 1 (SIB1);
|
||||
- a new option for automatic UE attachment using Idle mode cell selection
|
||||
procedure;
|
||||
- improved configurability of UE measurements; and
|
||||
- two options of handover algorithms for enabling automatic handover trigger
|
||||
in LTE simulation: A2-A4-RSRQ and strongest cell (A3-RSRP).
|
||||
|
||||
- A new FixedRoomPositionAllocator has been added to the buildings
|
||||
module. It allows one to generate a random position uniformly
|
||||
distributed in the volume of a chosen room inside a chosen building.
|
||||
|
||||
- A new attribute ns3::LteRlcAm::TxOpportunityForRetxAlwaysBigEnough
|
||||
allows to overcome the lack for re-segmentation in the RLC AM
|
||||
implementation by assuming that the size of a TxOpportunity is
|
||||
always big enough for the RLC AM PDU to be retransmitted.
|
||||
|
||||
- After some profiling, the code of LteMiErrorModel has been optimized
|
||||
for speed, resulting in a significantly lower execution time of the
|
||||
LTE model when used with the error model enabled.
|
||||
|
||||
- A new WiFi extension for vehicular simulation support is available in
|
||||
the src/wave directory. The current code represents an interim capability
|
||||
to realize an IEEE 802.11p-compliant device, but without the WAVE
|
||||
extensions (which are planned for a later patch). The WaveNetDevice
|
||||
modelled herein enforces that a WAVE-compliant physical layer (at 5.9 GHz)
|
||||
is selected, and does not require any association between devices (similar
|
||||
to an adhoc WiFi MAC), but is otherwise similar (at this time) to a
|
||||
WifiNetDevice. WAVE capabililties of switching between control and
|
||||
service channels, or using multiple radios, are not yet modelled.
|
||||
|
||||
- A new IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) model
|
||||
is available. Using ns-3's naming convention, the acronym is expanded
|
||||
to SixLowPanNetDevice. The SixLowPanNetDevice is able to act as a
|
||||
shim between IPv6 and a NetDevice, compressing IPv6 headers according
|
||||
to RFCs 4944 and 6262. The SixLowPanNetDevice is meant to be used over
|
||||
IEEE 802.15.4 NetDevices, but it can be used on other NetDevices as
|
||||
well (see the manual for full details). This model precedes the
|
||||
general availability of an 802.15.4 model, so must be run in conjunction
|
||||
with a wired NetDevice model for now, or with experimental versions of
|
||||
802.15.4 models.
|
||||
|
||||
- It is now possible to use Ipv6PacketInfoTag from UDP applications in the
|
||||
same way as with Ipv4PacketInfoTag. See Doxygen for current limitations in
|
||||
using Ipv[4,6]PacketInfoTag to set IP properties.
|
||||
|
||||
- Ipv[4,6]Interfaces not respecting the minimum MTU requirements (68 octects
|
||||
for IPv4 and 1280 octects for IPv6) will be automatically set as Down.
|
||||
|
||||
- IPv6 addresses and routing tables are printed in a more conventional way,
|
||||
closely matching the Linux "route -A inet6" command.
|
||||
|
||||
- Additional time units (Year, Day, Hour, Minute) were added to the time
|
||||
value class that represents simulation time; the largest unit prior to
|
||||
this addition was Second.
|
||||
|
||||
- A new parallel scheduling algorithm based on null messages, a common
|
||||
parallel DES scheduling algorithm, has been added. The null message
|
||||
scheduler has better scaling properties when running on some scenarios
|
||||
with large numbers of nodes since it does not require a global
|
||||
communication.
|
||||
|
||||
Bugs fixed
|
||||
----------
|
||||
- Bug 1496 - Option to print log level in NS_LOG messages, and documentation.
|
||||
- Bug 1592 - Parsing bug in FlowMonitor example script
|
||||
- Bug 1756 - RLC AM Mode State Variable Bug
|
||||
- Bug 1763 - Message 3 should be sent using the UL GRANT in the RAR
|
||||
- Bug 1778 - Implement TapBridge::IsLinkUp() function
|
||||
- Bug 1777 - Implement the more direct way of "using" configuration of existing tap interface
|
||||
- Bug 1776 - Improve CRC performance for CsmaNetDevice in emulation modes
|
||||
- Bug 1788 - unused private field warning
|
||||
- Bug 1789 - missing test condition for sigma in buildings-shadowing-test
|
||||
- Bug 1796 - Ipv6PacketInfoTag is not filled by UdpSocketImpl::ForwardUp6
|
||||
- Bug 1798 - Changing the rate of onOffApplication might stop transmission
|
||||
- Bug 1802 - FlowMon header deserialization problem with IPv4 fragments
|
||||
- Bug 1803 - Lookup /NodeList/4/DeviceList/0/LteEnbRrc/UeMap/0 got no matches
|
||||
- Bug 1807 - Multiple bugs in Ipv4L3Protocol::LocalDeliver
|
||||
- Bug 1810 - IP packets can be sent on NetDevices not respecting the minimum MTU requirements
|
||||
- Bug 1814 - IPv6 Packet with length not multiple of 8 bytes are fragmented incorrectly.
|
||||
- Bug 1815 - Python bindings compilation with clang compiler toolchain
|
||||
- Bug 1816 - IPv4 fragmentation loses Packet tags
|
||||
- Bug 1877 - constructor missing for <something>PropagationLossModels
|
||||
|
||||
Release 3.18.2
|
||||
==============
|
||||
|
||||
ns-allinone-3.18.2 was released to include a bake configuration file update
|
||||
for Direct Code Execution. The ns-3 code in this release was unchanged
|
||||
from that of ns-3.18.1.
|
||||
|
||||
Release 3.18.1
|
||||
==============
|
||||
|
||||
This release is mainly to provide updated compiler support (clang/LLVM)
|
||||
and fix the Python API scanning facility. A few additional bug fixes
|
||||
and new features are described below.
|
||||
|
||||
Availability
|
||||
------------
|
||||
This release is available from:
|
||||
http://www.nsnam.org/release/ns-allinone-3.18.1.tar.bz2
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
These platforms have been tested; others may work also:
|
||||
- Fedora Core 19 (32/64 bit) with g++-4.8.1
|
||||
- Ubuntu 13.10 (64 bit) with g++-4.8.1
|
||||
- Ubuntu 12.04.3 (32/64 bit) with g++-4.6.3
|
||||
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
|
||||
- OS X Mavericks 10.9 with Xcode 5.0.1 and clang-500.2.79
|
||||
- OS X Mountain Lion 10.8.5 with Xcode 5 and g++-4.2.1
|
||||
- FreeBSD 9.2-RELEASE (64 bit) with clang-3.3
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
- It is now possible to randomize the time of the first beacon from an
|
||||
access point. Use an attribute "EnableBeaconJitter" to enable/disable
|
||||
this feature.
|
||||
- A new FixedRoomPositionAllocator helper class is available; it
|
||||
allows one to generate a random position uniformly distributed in the
|
||||
volume of a chosen room inside a chosen building.
|
||||
- Logging wildcards: allow "***" as synonym for "*=**" to turn on all logging.
|
||||
- The log component list ("NS_LOG=print-list") is now printed alphabetically.
|
||||
|
||||
Bugs fixed
|
||||
----------
|
||||
- Bug 1779 - NS_UNUSED_GLOBAL not working in attribute test class declaration
|
||||
- Bug 1766 - Fixes to wifi-hidden-terminal.cc example
|
||||
- Bug 1722 - Avoid transmitting beacons concurrently
|
||||
- Bug 1691 - RTS/CTS NAV reset prematurely
|
||||
- Bug 1622 - Avoid waf hanging during apiscan
|
||||
- Bug 1616 - WifiPhyStateHelper reports false CCA_BUSY times at State trace source
|
||||
- Bug 1552 - Storing log name inside LogComponent class (NS_LOG) as std::string
|
||||
- Bug 1011 - assert failed. file=../src/devices/wifi/dcf-manager.cc
|
||||
- bug 945 - remove deprecated IEEE 802.11p code from wifi module
|
||||
- Fix aliasing bug in optimized static builds
|
||||
- Fix memory leak due to circular reference in MPI module
|
||||
- Make wifi tests more robust to random variable perturbations
|
||||
- Fix Time class doxygen
|
||||
- Fix compilation with Clang 3.2 and newer versions, including Apple Xcode 5
|
||||
- Miscellaneous NetAnim fixes
|
||||
|
||||
Release 3.18
|
||||
=============
|
||||
|
||||
Availability
|
||||
------------
|
||||
This release is available from:
|
||||
http://www.nsnam.org/release/ns-allinone-3.18.tar.bz2
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
These platforms have been tested; others may work also:
|
||||
- Fedora Core 18 (32/64 bit) with g++-4.7.2
|
||||
- Fedora Core 17 (32/64 bit) with g++-4.7.0
|
||||
- Ubuntu 13.04 (32/64 bit) with g++-4.7.3
|
||||
- Ubuntu 12.04 (32/64 bit) with g++-4.6.3
|
||||
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
|
||||
- OS X Mountain Lion 10.8.3 with g++-4.2.1
|
||||
- FreeBSD 9.1-RELEASE (64 bit) with g++-4.2.1
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
- Time attributes can now be bounded. See attribute-test-suite.cc for an
|
||||
example.
|
||||
- Data collection components have been added to the stats module. These
|
||||
components can be used to generate time series data in files and plots.
|
||||
- IPv6 address class 2001:db8::/32 is now dropped by routers (RFC 3849).
|
||||
- New generic hash function interface. Two hash functions are provided:
|
||||
murmur3 (default), and the venerable FNV1a. See the Hash Functions
|
||||
section in the Manual.
|
||||
- New Mac16Address has been added, Mac64Address is now in-line with
|
||||
Mac48Address and all the three can be used in IPv6 autoconfigure.
|
||||
- Previously, the use of Building models was limited to the use of the
|
||||
companion BuildingsMobilityModel. Now, any MobilityModel can be
|
||||
used with Building models.
|
||||
- The latest LTE module code by the LENA project has been merged,
|
||||
including the following new features:
|
||||
- PHY support for UE measurements (RSRP and RSRQ)
|
||||
- RRC support for UE measurements (configuration, execution, reporting)
|
||||
- Automatic Handover trigger based on RRC UE measurement reports
|
||||
- IPv6 can now detect and use Path-MTU. See
|
||||
examples/ipv6/fragmentation-ipv6-two-MTU.cc for an example.
|
||||
- Radvd application have a new Helper. See the updated
|
||||
examples/ipv6/radvd.cc for an example.
|
||||
- 11n- It is now possible to create a high throughput (HT) node that used the new 11n data rates and preambles.
|
||||
- It is now possible to request printing command line arguments to the
|
||||
desired output stream using PrintHelp or operator <<
|
||||
|
||||
Bugs fixed
|
||||
----------
|
||||
- Bug 760 - IP address removal can be painful
|
||||
- Bug 1190 - Suppress hello if bcast was sent within the last hello interval
|
||||
- Bug 1296 - Enhancement in Ipv[4,6]RoutingHelper
|
||||
- Bug 1390 - ICMPv6 Redirect are handled correctly only for /64 networks
|
||||
- Bug 1522 - Hidden node scenario leads to ARP failure
|
||||
- Bug 1584 - Old Association Request Timeouts are not canceled
|
||||
- Bug 1629 - Make AODV Default to Disable Hello
|
||||
- Bug 1643 - NdiscCache creation and existence checks
|
||||
- Bug 1646 - ICMPv6 Redirect are sent from global address instead of link-local
|
||||
- Bug 1662 - m_type not set for Ipv6OptionRouterAlertHeader
|
||||
- Bug 1678 - C++11 compliance problem with std::pair"
|
||||
- Bug 1682 - ./waf crashes on FC10
|
||||
- Bug 1683 - IPv6 autoconfigured don't use *infinite* lifetimes
|
||||
- Bug 1669 - ns-3 should support binding two and three (possibly more) arguments
|
||||
- Bug 1675 - Throughput computation error in Wireless examples
|
||||
- Bug 1687 - wscript features report doesn't respect NOCOLOR
|
||||
- Bug 1688 - Routers should advertise themselves from the link-local address
|
||||
- Bug 1689 - IPv6 shouldn't add a default gateway without checking the Router lifetime
|
||||
- Bug 1690 - missing header files from wifi wscript
|
||||
- Bug 1697 - ICMPv6 Redirect trigger contains multiple bugs
|
||||
- Bug 1698 - mobility.SetPositionAllocator misses prefix "ns3::"
|
||||
- Bug 1700 - Ipv6RawSocket does not honor the bound address when sending packets
|
||||
- Bug 1701 - Ipv6StaticRouting: the source address should match the destination scope
|
||||
- Bug 1702 - Ipv6InterfaceContainer::SetRouter should not always add the router as the default router.
|
||||
- Bug 1703 - Nodes don't react to a DAD
|
||||
- Bug 1712 - The IP (v4 and v6) forwarding needs a test
|
||||
- Bug 1718 - Ipv4StaticRouting log component is misspelled
|
||||
- Bug 1720 - IPv6 Fragmentation cause crashes
|
||||
- Bug 1721 - Path MTU isn't handled properly
|
||||
- Bug 1723 - name clash in ipv4-header.h with <termios.h>
|
||||
- Bug 1727 - Ping6 should use a proper source address
|
||||
- Bug 1728 - Radvd application is missing an Helper
|
||||
- Bug 1731 - lte-phy-error-model passes unexpectedly
|
||||
- Bug 1738 - strict aliasing compiler bug
|
||||
- Bug 1742 - IPv6 HbH and Dst Extension Header size is not correctly calculated
|
||||
- Bug 1752 - RadvdInterface m_defaultLifeTime is set to milliseconds instead of seconds
|
||||
- Bug 1753 - Halting Issue with DistributedSimulatorImpl
|
||||
- Bug 1754 - Missing GIL lock in generated callback destructor
|
||||
|
||||
Known issues
|
||||
------------
|
||||
In general, known issues are tracked on the project tracker available
|
||||
at http://www.nsnam.org/bugzilla/
|
||||
|
||||
Release 3.17
|
||||
============
|
||||
|
||||
Availability
|
||||
------------
|
||||
This release is available from:
|
||||
http://www.nsnam.org/release/ns-allinone-3.17.tar.bz2
|
||||
|
||||
Supported platforms
|
||||
-------------------
|
||||
These platforms have been tested; others may work also:
|
||||
- Fedora Core 18 (32/64 bit) with g++-4.7.2
|
||||
- Fedora Core 17 (32/64 bit) with g++-4.7.0
|
||||
- Ubuntu 13.04 (32/64 bit) with g++-4.7.3
|
||||
- Ubuntu 12.10 (32/64 bit) with g++-4.6.3
|
||||
- Ubuntu 12.04 (32/64 bit) with g++-4.6.3
|
||||
- Ubuntu 10.04.4 LTS (64 bit) with g++-4.4.3
|
||||
- OS X Mountain Lion 10.8.3 with g++-4.2.1
|
||||
- FreeBSD 9.1-RELEASE (64 bit) with g++-4.2.1
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
- new TCP Westwood and Westwood+ models
|
||||
- new FdNetDevice model and associated helpers. The FdNetDevice is able
|
||||
to read and write from a file descriptor. Various helpers are provided
|
||||
to associate this descriptor with underlying devices or sockets on the
|
||||
host operating system, including a packet socket for emulation, and
|
||||
tap devices including a version specialized for use on PlanetLab.
|
||||
- ns-3-click: it's now possible to (i) have Click pull random numbers from
|
||||
ns-3 and (ii) have ns-3 set "defines" in Click via the simulation file
|
||||
(see src/click/examples/nsclick-defines.cc).
|
||||
- Waf shipped with ns-3 has been upgraded to version 1.7.10 and custom
|
||||
pkg-config generator has been replaced by Waf's builtin tool.
|
||||
- create-module.py script has been updated to work with waf 1.7 and support
|
||||
for creating modules with names containing dashes has been added.
|
||||
- the M5 release of the LTE module by the LENA project has been
|
||||
merged; please see src/lte/RELEASE_NOTES for more detailed info
|
||||
|
||||
Bugs fixed
|
||||
----------
|
||||
- bug 1256 - Unnecessary SND.NXT advance, missing ACK for Out of Order segments
|
||||
- bug 1318 - Ipv6L3Protocol::LocalDeliver can get stuck in an infinte loop
|
||||
- bug 1409 - Add an attribute "SystemId" to configure the ID for MPI
|
||||
- bug 1421 - Frequency dependent propagation loss models need uniform Frequency / Lambda attribute
|
||||
- bug 1434 - DSR throughput not comparable to other protocols for manet example
|
||||
- bug 1502 - Shutdown on tcp socket seems to misbehave
|
||||
- bug 1503 - BlockAckManager infine loop
|
||||
- bug 1517 - Waf clean/distclean doesn't remove the doc/html directory
|
||||
- bug 1540 - Waf not finding click libraries
|
||||
- bug 1549 - Test for NS_LOG
|
||||
- bug 1556 - Uses of htonl making OpenFlow's match field error
|
||||
- bug 1563 - Reduce valgrind test scope
|
||||
- bug 1564 - Packet meta data isn't shown in dumbbell-animation.xml
|
||||
- bug 1566 - WiFi SNR tag improvements
|
||||
- bug 1568 - Deserialized addresses are implicity marked as Mac48Address
|
||||
- bug 1569 - droptail_vs_red example doesn't run
|
||||
- bug 1570 - Valgrind errors in new test examples
|
||||
- bug 1574 - Node color overwritten, by mobility updates in netanim
|
||||
- bug 1575 - Invert the y-axis in netanim
|
||||
- bug 1576 - Frequency units HERTZ and MEGAHERTZ mix up
|
||||
- bug 1577 - Typo in ascii picture in example aodv script
|
||||
- bug 1579 - edca-txop-n fragmentation causes segfault
|
||||
- bug 1582 - IPv6 raw socket return value is not like Linux socket
|
||||
- bug 1585 - Length field of A-MSDU subframe header endianness
|
||||
- bug 1586 - Building documentation fails if make runs in parallel
|
||||
- bug 1588 - UdpEchoServer::HandleRead logs fail when using Ipv6
|
||||
- bug 1589 - Bake - support pre-2.7 version of python
|
||||
- bug 1590 - Bake - more autotools version support
|
||||
- bug 1595 - Function declarations without implementations cause problems with dsr module's python bindings
|
||||
- bug 1596 - Inet TopologyReader is skipping one link and duplicating another one
|
||||
- bug 1600 - Icmpv6OptionLinkLayerAddress can only carry 48 bit addresses correctly
|
||||
- bug 1601 - RttEstimator doesn't set the m_currentEstimatedRtt to m_initialEstimatedRtt on creation
|
||||
- bug 1602 - waf build can break due to file collisions in higher-level directory
|
||||
- bug 1603 - random-variable-stream-helper - this unavalable for static member functions
|
||||
- bug 1607 - OnOffApplication over TCP with IPv6 support
|
||||
- bug 1608 - DSR Network ACK is not handled correctly
|
||||
- bug 1609 - Route Request table is needed
|
||||
- bug 1612 - pyviz (visualizer) will not be installed
|
||||
- bug 1613 - Can't build ns-3-dev with g++ 4.7.2
|
||||
- bug 1615 - Adjusting OLSR HelloInterval Attribute results in no links
|
||||
- bug 1618 - bake.py not detecting install of libxml2-dev on ubuntu
|
||||
- bug 1623 - pybindgen rev809 is not able to build after Ubuntu 1210
|
||||
- bug 1625 - ns-3-dev fails to build on Debian wheezy amd64
|
||||
- bug 1626 - ipv6-only network can't use UDP or TCP
|
||||
- bug 1632 - Prepend bake build directory to the guessed locations
|
||||
that waf will look to find libraries
|
||||
- bug 1633 - Bake - should not report that it is downloading qt4 when it is already installed
|
||||
- bug 1635 - Small bug without Simulator::Destroy()
|
||||
- bug 1636 - Compilation error flagged as unmet dependency
|
||||
- bug 1637 - Bake calling apt-get for unpriviledged user
|
||||
- bug 1639 - bake.py support for linux mint
|
||||
- bug 1640 - bake needs to test for g++
|
||||
- bug 1641 - bake reports autotools dependency, but needs automake
|
||||
- bug 1661 - Variable ub1 defined but not used in ipv6-address.cc
|
||||
|
||||
Known issues
|
||||
------------
|
||||
In general, known issues are tracked on the project tracker available
|
||||
at http://www.nsnam.org/bugzilla/
|
||||
|
||||
Release 3.16
|
||||
============
|
||||
|
||||
@@ -761,7 +1317,7 @@ ns-3.9 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -918,7 +1474,7 @@ ns-3.8 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1062,7 +1618,7 @@ Unofficially supported platform
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1182,7 +1738,7 @@ ns-3.6 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1259,7 +1815,7 @@ ns-3.5 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1317,7 +1873,7 @@ ns-3.4 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1381,7 +1937,7 @@ ns-3.3 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1448,7 +2004,7 @@ ns-3.2 has been tested on the following platforms:
|
||||
|
||||
Not all ns-3 options are available on all platforms; consult the
|
||||
wiki for more information:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
New user-visible features
|
||||
-------------------------
|
||||
@@ -1476,7 +2032,7 @@ New user-visible features
|
||||
keep track of simulation data in persistent storage across multiple
|
||||
runs (database and ascii file backends are available).
|
||||
More information on the wiki:
|
||||
http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation
|
||||
http://www.nsnam.org/wiki/Statistical_Framework_for_Network_Simulation
|
||||
|
||||
API changes from ns-3.1
|
||||
-----------------------
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
from __future__ import print_function
|
||||
import warnings
|
||||
import sys
|
||||
import os
|
||||
@@ -6,6 +7,8 @@ from pybindgen import Module, FileCodeSink, param, retval, cppclass, typehandler
|
||||
from pybindgen.module import MultiSectionFactory
|
||||
import ns3modulegen_core_customizations
|
||||
|
||||
import logging
|
||||
|
||||
pybindgen.settings.wrapper_registry = pybindgen.settings.StdMapWrapperRegistry
|
||||
|
||||
import traceback
|
||||
@@ -55,6 +58,9 @@ class MyMultiSectionFactory(MultiSectionFactory):
|
||||
|
||||
|
||||
def main(argv):
|
||||
logging.basicConfig()
|
||||
logging.getLogger("pybindgen.typehandlers").setLevel(logging.DEBUG)
|
||||
|
||||
module_abs_src_path, target, extension_name, output_cc_file_name = argv[1:]
|
||||
module_name = os.path.basename(module_abs_src_path)
|
||||
out = MyMultiSectionFactory(output_cc_file_name)
|
||||
@@ -71,11 +77,11 @@ def main(argv):
|
||||
|
||||
try:
|
||||
from callbacks_list import callback_classes
|
||||
except ImportError, ex:
|
||||
print >> sys.stderr, "***************", repr(ex)
|
||||
except ImportError as ex:
|
||||
print("***************", repr(ex), file=sys.stderr)
|
||||
callback_classes = []
|
||||
else:
|
||||
print >> sys.stderr, ">>>>>>>>>>>>>>>>", repr(callback_classes)
|
||||
print(">>>>>>>>>>>>>>>>", repr(callback_classes), file=sys.stderr)
|
||||
|
||||
finally:
|
||||
sys.path.pop(0)
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
from __future__ import print_function
|
||||
import sys
|
||||
import re
|
||||
|
||||
from pybindgen.typehandlers import base as typehandlers
|
||||
@@ -5,6 +7,7 @@ from pybindgen import ReturnValue, Parameter
|
||||
from pybindgen.cppmethod import CustomCppMethodWrapper, CustomCppConstructorWrapper
|
||||
from pybindgen.typehandlers.codesink import MemoryCodeSink
|
||||
from pybindgen.typehandlers import ctypeparser
|
||||
from pybindgen.typehandlers.base import ForwardWrapperBase
|
||||
from pybindgen import cppclass
|
||||
import warnings
|
||||
|
||||
@@ -25,11 +28,13 @@ class SmartPointerTransformation(typehandlers.TypeTransformation):
|
||||
def __init__(self):
|
||||
super(SmartPointerTransformation, self).__init__()
|
||||
self.rx = re.compile(r'(ns3::|::ns3::|)Ptr<([^>]+)>\s*$')
|
||||
print("{0!r}".format(self), file=sys.stderr)
|
||||
|
||||
def _get_untransformed_type_traits(self, name):
|
||||
m = self.rx.match(name)
|
||||
is_const = False
|
||||
if m is None:
|
||||
print("{0!r} did not match".format(name), file=sys.stderr)
|
||||
return None, False
|
||||
else:
|
||||
name1 = m.group(2).strip()
|
||||
@@ -60,9 +65,9 @@ class SmartPointerTransformation(typehandlers.TypeTransformation):
|
||||
## fix the ctype, add ns3:: namespace
|
||||
orig_ctype, is_const = self._get_untransformed_type_traits(args[0])
|
||||
if is_const:
|
||||
correct_ctype = 'ns3::Ptr< %s const >' % orig_ctype[:-2]
|
||||
correct_ctype = 'ns3::Ptr< {0} const >'.format(orig_ctype[:-2])
|
||||
else:
|
||||
correct_ctype = 'ns3::Ptr< %s >' % orig_ctype[:-2]
|
||||
correct_ctype = 'ns3::Ptr< {0} >'.format(orig_ctype[:-2])
|
||||
args = tuple([correct_ctype] + list(args[1:]))
|
||||
|
||||
handler = type_handler(*args, **kwargs)
|
||||
@@ -83,58 +88,6 @@ typehandlers.param_type_matcher.register_transformation(transf)
|
||||
del transf
|
||||
|
||||
|
||||
class ArgvParam(Parameter):
|
||||
"""
|
||||
Converts a python list-of-strings argument to a pair of 'int argc,
|
||||
char *argv[]' arguments to pass into C.
|
||||
|
||||
One Python argument becomes two C function arguments -> it's a miracle!
|
||||
|
||||
Note: this parameter type handler is not registered by any name;
|
||||
must be used explicitly.
|
||||
"""
|
||||
|
||||
DIRECTIONS = [Parameter.DIRECTION_IN]
|
||||
CTYPES = []
|
||||
|
||||
def convert_c_to_python(self, wrapper):
|
||||
raise NotImplementedError
|
||||
|
||||
def convert_python_to_c(self, wrapper):
|
||||
py_name = wrapper.declarations.declare_variable('PyObject*', 'py_' + self.name)
|
||||
argc_var = wrapper.declarations.declare_variable('int', 'argc')
|
||||
name = wrapper.declarations.declare_variable('char**', self.name)
|
||||
idx = wrapper.declarations.declare_variable('Py_ssize_t', 'idx')
|
||||
wrapper.parse_params.add_parameter('O!', ['&PyList_Type', '&'+py_name], self.name)
|
||||
|
||||
#wrapper.before_call.write_error_check('!PyList_Check(%s)' % py_name) # XXX
|
||||
|
||||
wrapper.before_call.write_code("%s = (char **) malloc(sizeof(char*)*PyList_Size(%s));"
|
||||
% (name, py_name))
|
||||
wrapper.before_call.add_cleanup_code('free(%s);' % name)
|
||||
wrapper.before_call.write_code('''
|
||||
for (%(idx)s = 0; %(idx)s < PyList_Size(%(py_name)s); %(idx)s++)
|
||||
{
|
||||
''' % vars())
|
||||
wrapper.before_call.sink.indent()
|
||||
wrapper.before_call.write_code('''
|
||||
PyObject *item = PyList_GET_ITEM(%(py_name)s, %(idx)s);
|
||||
''' % vars())
|
||||
#wrapper.before_call.write_error_check('item == NULL')
|
||||
wrapper.before_call.write_error_check(
|
||||
'!PyString_Check(item)',
|
||||
failure_cleanup=('PyErr_SetString(PyExc_TypeError, '
|
||||
'"argument %s must be a list of strings");') % self.name)
|
||||
wrapper.before_call.write_code(
|
||||
'%s[%s] = PyString_AsString(item);' % (name, idx))
|
||||
wrapper.before_call.sink.unindent()
|
||||
wrapper.before_call.write_code('}')
|
||||
wrapper.before_call.write_code('%s = PyList_Size(%s);' % (argc_var, py_name))
|
||||
|
||||
wrapper.call_params.append(argc_var)
|
||||
wrapper.call_params.append(name)
|
||||
|
||||
|
||||
class CallbackImplProxyMethod(typehandlers.ReverseWrapperBase):
|
||||
"""
|
||||
Class that generates a proxy virtual method that calls a similarly named python method.
|
||||
@@ -177,8 +130,11 @@ public:
|
||||
}
|
||||
virtual ~%s()
|
||||
{
|
||||
PyGILState_STATE __py_gil_state;
|
||||
__py_gil_state = (PyEval_ThreadsInitialized() ? PyGILState_Ensure() : (PyGILState_STATE) 0);
|
||||
Py_DECREF(m_callback);
|
||||
m_callback = NULL;
|
||||
PyGILState_Release(__py_gil_state);
|
||||
}
|
||||
|
||||
virtual bool IsEqual(ns3::Ptr<const ns3::CallbackImplBase> other_base) const
|
||||
@@ -200,7 +156,7 @@ public:
|
||||
kwargs = {}
|
||||
try:
|
||||
return_type = ReturnValue.new(str(return_ctype), **kwargs)
|
||||
except (typehandlers.TypeLookupError, typehandlers.TypeConfigurationError), ex:
|
||||
except (typehandlers.TypeLookupError, typehandlers.TypeConfigurationError) as ex:
|
||||
warnings.warn("***** Unable to register callback; Return value '%s' error (used in %s): %r"
|
||||
% (callback_return, cls_name, ex),
|
||||
Warning)
|
||||
@@ -219,7 +175,7 @@ public:
|
||||
kwargs = {}
|
||||
try:
|
||||
arguments.append(Parameter.new(str(param_ctype), arg_name, **kwargs))
|
||||
except (typehandlers.TypeLookupError, typehandlers.TypeConfigurationError), ex:
|
||||
except (typehandlers.TypeLookupError, typehandlers.TypeConfigurationError) as ex:
|
||||
warnings.warn("***** Unable to register callback; parameter '%s %s' error (used in %s): %r"
|
||||
% (arg_type, arg_name, cls_name, ex),
|
||||
Warning)
|
||||
@@ -237,7 +193,7 @@ public:
|
||||
class PythonCallbackParameter(Parameter):
|
||||
"Class handlers"
|
||||
CTYPES = [cls_name]
|
||||
print >> sys.stderr, "***** registering callback handler: %r" % ctypeparser.normalize_type_string(cls_name)
|
||||
print("***** registering callback handler: %r" % ctypeparser.normalize_type_string(cls_name), file=sys.stderr)
|
||||
DIRECTIONS = [Parameter.DIRECTION_IN]
|
||||
PYTHON_CALLBACK_IMPL_NAME = class_name
|
||||
TEMPLATE_ARGS = template_parameters
|
||||
@@ -422,11 +378,24 @@ def add_std_ofstream(module):
|
||||
add_std_ios_openmode(module)
|
||||
|
||||
|
||||
def add_std_ios_openmode(module):
|
||||
import pybindgen.typehandlers.base
|
||||
for alias in "std::_Ios_Openmode", "std::ios::openmode":
|
||||
pybindgen.typehandlers.base.param_type_matcher.add_type_alias(alias, "int")
|
||||
class IosOpenmodeParam(Parameter):
|
||||
|
||||
DIRECTIONS = [Parameter.DIRECTION_IN]
|
||||
CTYPES = ['std::ios::openmode', 'std::_Ios_Openmode']
|
||||
|
||||
def convert_c_to_python(self, wrapper):
|
||||
assert isinstance(wrapper, ReverseWrapperBase)
|
||||
wrapper.build_params.add_parameter('i', [self.value])
|
||||
|
||||
def convert_python_to_c(self, wrapper):
|
||||
assert isinstance(wrapper, ForwardWrapperBase)
|
||||
name = wrapper.declarations.declare_variable("std::ios::openmode", self.name, self.default_value)
|
||||
wrapper.parse_params.add_parameter('i', ['&'+name], self.name, optional=bool(self.default_value))
|
||||
wrapper.call_params.append(name)
|
||||
|
||||
|
||||
|
||||
def add_std_ios_openmode(module):
|
||||
for flag in 'in', 'out', 'ate', 'app', 'trunc', 'binary':
|
||||
module.after_init.write_code('PyModule_AddIntConstant(m, (char *) "STD_IOS_%s", std::ios::%s);'
|
||||
% (flag.upper(), flag))
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
+49
-60
@@ -6,25 +6,17 @@ import subprocess
|
||||
import shutil
|
||||
import sys
|
||||
|
||||
import Task
|
||||
import Options
|
||||
import Configure
|
||||
import TaskGen
|
||||
import Logs
|
||||
import Build
|
||||
import Utils
|
||||
|
||||
from waflib import Task, Options, Configure, TaskGen, Logs, Build, Utils, Errors
|
||||
from waflib.Errors import WafError
|
||||
|
||||
# feature = TaskGen.feature
|
||||
# after = TaskGen.after
|
||||
|
||||
## https://launchpad.net/pybindgen/
|
||||
REQUIRED_PYBINDGEN_VERSION = (0, 15, 0, 809)
|
||||
REQUIRED_PYBINDGEN_VERSION = (0, 17, 0, 876)
|
||||
REQUIRED_PYGCCXML_VERSION = (0, 9, 5)
|
||||
|
||||
|
||||
from TaskGen import feature, after
|
||||
import Task
|
||||
|
||||
|
||||
RUN_ME=-3
|
||||
|
||||
def add_to_python_path(path):
|
||||
if os.environ.get('PYTHONPATH', ''):
|
||||
@@ -38,7 +30,7 @@ def set_pybindgen_pythonpath(env):
|
||||
|
||||
|
||||
def options(opt):
|
||||
opt.tool_options('python')
|
||||
opt.load('python')
|
||||
opt.add_option('--disable-python',
|
||||
help=("Don't build Python bindings."),
|
||||
action="store_true", default=False,
|
||||
@@ -55,6 +47,10 @@ def options(opt):
|
||||
opt.add_option('--with-python',
|
||||
help=('Path to the Python interpreter to use.'),
|
||||
default=None, dest='with_python', type="string")
|
||||
opt.add_option('--no32bit-scan',
|
||||
help=("Don't scan for the 32-bit variant of the bindings on 64-bit platforms."),
|
||||
action="store_true", default=False,
|
||||
dest='no32bit_scan')
|
||||
|
||||
|
||||
def configure(conf):
|
||||
@@ -76,7 +72,7 @@ def configure(conf):
|
||||
available_modules.sort()
|
||||
all_modules_enabled = (enabled_modules == available_modules)
|
||||
|
||||
conf.check_tool('misc', tooldir=['waf-tools'])
|
||||
conf.load('misc', tooldir=['waf-tools'])
|
||||
|
||||
if sys.platform == 'cygwin':
|
||||
conf.report_optional_feature("python", "Python Bindings", False,
|
||||
@@ -91,20 +87,20 @@ def configure(conf):
|
||||
conf.env.PYTHON = Options.options.with_python
|
||||
|
||||
try:
|
||||
conf.check_tool('python')
|
||||
except Configure.ConfigurationError, ex:
|
||||
conf.load('python')
|
||||
except Errors.ConfigurationError, ex:
|
||||
conf.report_optional_feature("python", "Python Bindings", False,
|
||||
"The python interpreter was not found")
|
||||
return
|
||||
try:
|
||||
conf.check_python_version((2,3))
|
||||
except Configure.ConfigurationError, ex:
|
||||
except Errors.ConfigurationError, ex:
|
||||
conf.report_optional_feature("python", "Python Bindings", False,
|
||||
"The python found version is too low (2.3 required)")
|
||||
return
|
||||
try:
|
||||
conf.check_python_headers()
|
||||
except Configure.ConfigurationError, ex:
|
||||
except Errors.ConfigurationError, ex:
|
||||
conf.report_optional_feature("python", "Python Bindings", False,
|
||||
"Python library or headers missing")
|
||||
return
|
||||
@@ -161,7 +157,7 @@ def configure(conf):
|
||||
|
||||
try:
|
||||
conf.check_python_module('pybindgen')
|
||||
except Configure.ConfigurationError:
|
||||
except Errors.ConfigurationError:
|
||||
Logs.warn("pybindgen missing => no python bindings")
|
||||
conf.report_optional_feature("python", "Python Bindings", False,
|
||||
"PyBindGen missing")
|
||||
@@ -169,7 +165,7 @@ def configure(conf):
|
||||
else:
|
||||
out = subprocess.Popen([conf.env['PYTHON'][0], "-c",
|
||||
"import pybindgen.version; "
|
||||
"print '.'.join([str(x) for x in pybindgen.version.__version__])"],
|
||||
"print('.'.join([str(x) for x in pybindgen.version.__version__]))"],
|
||||
stdout=subprocess.PIPE).communicate()[0]
|
||||
pybindgen_version_str = out.strip()
|
||||
pybindgen_version = tuple([int(x) for x in pybindgen_version_str.split('.')])
|
||||
@@ -197,9 +193,9 @@ int main ()
|
||||
|
||||
try:
|
||||
ret = conf.run_c_code(code=test_program,
|
||||
env=conf.env.copy(), compile_filename='test.cc',
|
||||
env=conf.env.derive(), compile_filename='test.cc',
|
||||
features='cxx cprogram', execute=False)
|
||||
except Configure.ConfigurationError:
|
||||
except Errors.ConfigurationError:
|
||||
ret = 1
|
||||
conf.msg('Checking for types %s and %s equivalence' % (t1, t2), (ret and 'no' or 'yes'))
|
||||
return not ret
|
||||
@@ -250,7 +246,7 @@ int main ()
|
||||
## Check for pygccxml
|
||||
try:
|
||||
conf.check_python_module('pygccxml')
|
||||
except Configure.ConfigurationError:
|
||||
except Errors.ConfigurationError:
|
||||
conf.report_optional_feature("pygccxml", "Python API Scanning Support", False,
|
||||
"Missing 'pygccxml' Python module")
|
||||
return
|
||||
@@ -318,15 +314,15 @@ def get_module_path(bld, module):
|
||||
raise ValueError("Module %r not found" % module)
|
||||
return ns3headers.path.abspath()
|
||||
|
||||
class apiscan_task(Task.TaskBase):
|
||||
class apiscan_task(Task.Task):
|
||||
"""Uses gccxml to scan the file 'everything.h' and extract API definitions.
|
||||
"""
|
||||
after = 'gen_ns3_module_header ns3header'
|
||||
before = 'cc cxx command'
|
||||
before = 'cxx command'
|
||||
color = "BLUE"
|
||||
def __init__(self, curdirnode, env, bld, target, cflags, module):
|
||||
self.bld = bld
|
||||
super(apiscan_task, self).__init__(generator=self)
|
||||
super(apiscan_task, self).__init__(generator=self, env=env)
|
||||
self.curdirnode = curdirnode
|
||||
self.env = env
|
||||
self.target = target
|
||||
@@ -336,7 +332,21 @@ class apiscan_task(Task.TaskBase):
|
||||
def display(self):
|
||||
return 'api-scan-%s\n' % (self.target,)
|
||||
|
||||
def uid(self):
|
||||
try:
|
||||
return self.uid_
|
||||
except AttributeError:
|
||||
m = Utils.md5()
|
||||
up = m.update
|
||||
up(self.__class__.__name__.encode())
|
||||
up(self.curdirnode.abspath().encode())
|
||||
up(self.target)
|
||||
self.uid_ = m.digest()
|
||||
return self.uid_
|
||||
|
||||
def run(self):
|
||||
self.inputs = [self.bld.bldnode.find_resource("ns3/{0}-module.h".format(self.module))]
|
||||
self.outputs = [self.bld.srcnode.find_resource("src/{}/bindings/modulegen__{}.py".format(self.module, self.target))]
|
||||
top_builddir = self.bld.bldnode.abspath()
|
||||
module_path = get_module_path(self.bld, self.module)
|
||||
headers_map = get_headers_map(self.bld)
|
||||
@@ -359,6 +369,12 @@ class apiscan_task(Task.TaskBase):
|
||||
retval = scan.wait()
|
||||
return retval
|
||||
|
||||
def runnable_status(self):
|
||||
# By default, Waf Task will skip running a task if the signature of
|
||||
# the build has not changed. We want this task to always run if
|
||||
# invoked by the user, particularly since --apiscan=all will require
|
||||
# invoking this task many times, once per module.
|
||||
return RUN_ME
|
||||
|
||||
def get_modules_and_headers(bld):
|
||||
"""
|
||||
@@ -389,33 +405,9 @@ def get_modules_and_headers(bld):
|
||||
|
||||
|
||||
|
||||
class python_scan_task_collector(Task.TaskBase):
|
||||
"""Tasks that waits for the python-scan-* tasks to complete and then signals WAF to exit
|
||||
"""
|
||||
after = 'apiscan'
|
||||
before = 'cc cxx'
|
||||
color = "BLUE"
|
||||
def __init__(self, curdirnode, env, bld):
|
||||
self.bld = bld
|
||||
super(python_scan_task_collector, self).__init__(generator=self)
|
||||
self.curdirnode = curdirnode
|
||||
self.env = env
|
||||
|
||||
def display(self):
|
||||
return 'python-scan-collector\n'
|
||||
|
||||
def run(self):
|
||||
# signal stop (we generated files into the source dir and WAF
|
||||
# can't cope with it, so we have to force the user to restart
|
||||
# WAF)
|
||||
self.bld.producer.stop = 1
|
||||
return 0
|
||||
|
||||
|
||||
|
||||
class gen_ns3_compat_pymod_task(Task.Task):
|
||||
"""Generates a 'ns3.py' compatibility module."""
|
||||
before = 'cc cxx'
|
||||
before = 'cxx'
|
||||
color = 'BLUE'
|
||||
|
||||
def run(self):
|
||||
@@ -437,8 +429,6 @@ def build(bld):
|
||||
return
|
||||
|
||||
env = bld.env
|
||||
curdir = bld.path.abspath()
|
||||
|
||||
set_pybindgen_pythonpath(env)
|
||||
|
||||
if Options.options.apiscan:
|
||||
@@ -450,7 +440,9 @@ def build(bld):
|
||||
else:
|
||||
import struct
|
||||
if struct.calcsize('I') == 4 and struct.calcsize('L') == 8 and struct.calcsize('P') == 8:
|
||||
scan_targets.extend([('gcc_ILP32', '-m32'), ('gcc_LP64', '-m64')])
|
||||
if not Options.options.no32bit_scan:
|
||||
scan_targets.append(('gcc_ILP32', '-m32'))
|
||||
scan_targets.append(('gcc_LP64', '-m64'))
|
||||
elif struct.calcsize('I') == 4 and struct.calcsize('L') == 4 and struct.calcsize('P') == 4:
|
||||
scan_targets.append(('gcc_ILP32', ''))
|
||||
else:
|
||||
@@ -477,7 +469,6 @@ def build(bld):
|
||||
group = bld.get_group(bld.current_group)
|
||||
for module in scan_modules:
|
||||
group.append(apiscan_task(bld.path, env, bld, target, cflags, module))
|
||||
group.append(python_scan_task_collector(bld.path, env, bld))
|
||||
return
|
||||
|
||||
|
||||
@@ -489,9 +480,7 @@ def build(bld):
|
||||
grp = bld.get_group(bld.current_group)
|
||||
grp.append(task)
|
||||
|
||||
bld.new_task_gen(features='copy',
|
||||
source="ns__init__.py",
|
||||
target='ns/__init__.py')
|
||||
bld(features='copy', source="ns__init__.py", target='ns/__init__.py')
|
||||
bld.install_as('${PYTHONARCHDIR}/ns/__init__.py', 'ns__init__.py')
|
||||
|
||||
|
||||
|
||||
+1
-1
@@ -3,7 +3,7 @@ build system (http://www.freehackers.org/~tnagy/waf.html)
|
||||
|
||||
Note: We've added a wiki page with more complete build instructions
|
||||
than the quick ones you find below:
|
||||
http://www.nsnam.org/wiki/index.php/Installation
|
||||
http://www.nsnam.org/wiki/Installation
|
||||
|
||||
=== Installing Waf ===
|
||||
|
||||
|
||||
+161
-45
@@ -1,4 +1,6 @@
|
||||
# Doxyfile 1.8.1.1
|
||||
# -*-sh-*-
|
||||
|
||||
# Doxyfile 1.8.3.1
|
||||
|
||||
# This file describes the settings to be used by the documentation system
|
||||
# doxygen (www.doxygen.org) for a project.
|
||||
@@ -126,7 +128,9 @@ FULL_PATH_NAMES = YES
|
||||
# only done if one of the specified strings matches the left-hand part of
|
||||
# the path. The tag can be used to show relative paths in the file list.
|
||||
# If left blank the directory from which doxygen is run is used as the
|
||||
# path to strip.
|
||||
# path to strip. Note that you specify absolute paths here, but also
|
||||
# relative paths, which will be relative from the directory where doxygen is
|
||||
# started.
|
||||
|
||||
STRIP_FROM_PATH =
|
||||
|
||||
@@ -151,7 +155,7 @@ SHORT_NAMES = NO
|
||||
# comments will behave just like regular Qt-style comments
|
||||
# (thus requiring an explicit @brief command for a brief description.)
|
||||
|
||||
JAVADOC_AUTOBRIEF = NO
|
||||
JAVADOC_AUTOBRIEF = YES
|
||||
|
||||
# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
|
||||
# interpret the first line (until the first dot) of a Qt-style
|
||||
@@ -159,7 +163,7 @@ JAVADOC_AUTOBRIEF = NO
|
||||
# will behave just like regular Qt-style comments (thus requiring
|
||||
# an explicit \brief command for a brief description.)
|
||||
|
||||
QT_AUTOBRIEF = NO
|
||||
QT_AUTOBRIEF = YES
|
||||
|
||||
# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
|
||||
# treat a multi-line C++ special comment block (i.e. a block of //! or ///
|
||||
@@ -193,9 +197,20 @@ TAB_SIZE = 4
|
||||
# will result in a user-defined paragraph with heading "Side Effects:".
|
||||
# You can put \n's in the value part of an alias to insert newlines.
|
||||
|
||||
ALIASES = \
|
||||
"intern=\internal \par \b Internal:" \
|
||||
"pname{1}=<span class=\"params\"><span class=\"paramname\">\1</span></span>"
|
||||
ALIASES =
|
||||
|
||||
# Link to bug tracker
|
||||
ALIASES += bugid{1}="<a href=\"http://www.nsnam.org/bugzilla/show_bug.cgi?id=\1\">Bug \1</a>"
|
||||
|
||||
# Set off \internal docs
|
||||
ALIASES += internal="\par \b Internal:"
|
||||
|
||||
# Typeset parameter name in docs as in the "Parameters:" list
|
||||
# Usage: /** \param [in/out] tag If found, \pname{tag} is ... */
|
||||
ALIASES += pname{1}="<span class=\"params\"><span class=\"paramname\">\1</span></span>"
|
||||
|
||||
# Link to RFC's
|
||||
ALIASES += RFC{1}="<a href=\"http://datatracker.ietf.org/doc/rfc\1/\">RFC \1</a>"
|
||||
|
||||
# This tag can be used to specify a number of word-keyword mappings (TCL only).
|
||||
# A mapping has the form "name=value". For example adding
|
||||
@@ -231,14 +246,15 @@ OPTIMIZE_FOR_FORTRAN = NO
|
||||
OPTIMIZE_OUTPUT_VHDL = NO
|
||||
|
||||
# Doxygen selects the parser to use depending on the extension of the files it
|
||||
# parses. With this tag you can assign which parser to use for a given extension.
|
||||
# Doxygen has a built-in mapping, but you can override or extend it using this
|
||||
# tag. The format is ext=language, where ext is a file extension, and language
|
||||
# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
|
||||
# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
|
||||
# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
|
||||
# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
|
||||
# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
|
||||
# parses. With this tag you can assign which parser to use for a given
|
||||
# extension. Doxygen has a built-in mapping, but you can override or extend it
|
||||
# using this tag. The format is ext=language, where ext is a file extension,
|
||||
# and language is one of the parsers supported by doxygen: IDL, Java,
|
||||
# Javascript, CSharp, C, C++, D, PHP, Objective-C, Python, Fortran, VHDL, C,
|
||||
# C++. For instance to make doxygen treat .inc files as Fortran files (default
|
||||
# is PHP), and .f files as C (default is Fortran), use: inc=Fortran f=C. Note
|
||||
# that for custom extensions you also need to set FILE_PATTERNS otherwise the
|
||||
# files are not read by doxygen.
|
||||
|
||||
EXTENSION_MAPPING =
|
||||
|
||||
@@ -251,6 +267,13 @@ EXTENSION_MAPPING =
|
||||
|
||||
MARKDOWN_SUPPORT = YES
|
||||
|
||||
# When enabled doxygen tries to link words that correspond to documented classes,
|
||||
# or namespaces to their corresponding documentation. Such a link can be
|
||||
# prevented in individual cases by by putting a % sign in front of the word or
|
||||
# globally by setting AUTOLINK_SUPPORT to NO.
|
||||
|
||||
AUTOLINK_SUPPORT = YES
|
||||
|
||||
# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
|
||||
# to include (a tag file for) the STL sources as input, then you should
|
||||
# set this tag to YES in order to let doxygen match functions declarations and
|
||||
@@ -271,10 +294,10 @@ CPP_CLI_SUPPORT = NO
|
||||
|
||||
SIP_SUPPORT = NO
|
||||
|
||||
# For Microsoft's IDL there are propget and propput attributes to indicate getter
|
||||
# and setter methods for a property. Setting this option to YES (the default)
|
||||
# will make doxygen replace the get and set methods by a property in the
|
||||
# documentation. This will only work if the methods are indeed getting or
|
||||
# For Microsoft's IDL there are propget and propput attributes to indicate
|
||||
# getter and setter methods for a property. Setting this option to YES (the
|
||||
# default) will make doxygen replace the get and set methods by a property in
|
||||
# the documentation. This will only work if the methods are indeed getting or
|
||||
# setting a simple type. If this is not the case, or you want to show the
|
||||
# methods anyway, you should set this option to NO.
|
||||
|
||||
@@ -285,7 +308,7 @@ IDL_PROPERTY_SUPPORT = YES
|
||||
# member in the group (if any) for the other members of the group. By default
|
||||
# all members of a group must be documented explicitly.
|
||||
|
||||
DISTRIBUTE_GROUP_DOC = NO
|
||||
DISTRIBUTE_GROUP_DOC = YES
|
||||
|
||||
# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
|
||||
# the same type (for instance a group of public functions) to be put as a
|
||||
@@ -335,7 +358,7 @@ TYPEDEF_HIDES_STRUCT = YES
|
||||
# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
|
||||
# corresponding to a cache size of 2^16 = 65536 symbols.
|
||||
|
||||
SYMBOL_CACHE_SIZE = 0
|
||||
SYMBOL_CACHE_SIZE = 1
|
||||
|
||||
# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be
|
||||
# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given
|
||||
@@ -364,7 +387,8 @@ EXTRACT_ALL = YES
|
||||
|
||||
EXTRACT_PRIVATE = YES
|
||||
|
||||
# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope will be included in the documentation.
|
||||
# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal
|
||||
# scope will be included in the documentation.
|
||||
|
||||
EXTRACT_PACKAGE = NO
|
||||
|
||||
@@ -535,7 +559,8 @@ GENERATE_BUGLIST = YES
|
||||
GENERATE_DEPRECATEDLIST= YES
|
||||
|
||||
# The ENABLED_SECTIONS tag can be used to enable conditional
|
||||
# documentation sections, marked by \if sectionname ... \endif.
|
||||
# documentation sections, marked by \if section-label ... \endif
|
||||
# and \cond section-label ... \endcond blocks.
|
||||
|
||||
ENABLED_SECTIONS =
|
||||
|
||||
@@ -593,7 +618,8 @@ LAYOUT_FILE =
|
||||
# requires the bibtex tool to be installed. See also
|
||||
# http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style
|
||||
# of the bibliography can be controlled using LATEX_BIB_STYLE. To use this
|
||||
# feature you need bibtex and perl available in the search path.
|
||||
# feature you need bibtex and perl available in the search path. Do not use
|
||||
# file names with spaces, bibtex cannot handle them.
|
||||
|
||||
CITE_BIB_FILES =
|
||||
|
||||
@@ -660,6 +686,7 @@ WARN_LOGFILE = doc/doxygen.log
|
||||
INPUT = doc/modules \
|
||||
doc/main.h \
|
||||
doc/introspected-doxygen.h \
|
||||
examples \
|
||||
utils \
|
||||
src
|
||||
|
||||
@@ -727,14 +754,18 @@ EXCLUDE_SYMBOLS =
|
||||
|
||||
EXAMPLE_PATH = src/aodv/examples \
|
||||
src/bridge/examples \
|
||||
src/brite/examples \
|
||||
src/buildings/examples \
|
||||
src/click/examples \
|
||||
src/config-store/examples \
|
||||
src/core/examples \
|
||||
src/csma/examples \
|
||||
src/csma-layout/examples \
|
||||
src/dsdv/examples \
|
||||
src/dsr/examples \
|
||||
src/emu/examples \
|
||||
src/energy/examples \
|
||||
src/fd-net-device/examples \
|
||||
src/flow-monitor/examples \
|
||||
src/internet/examples \
|
||||
src/lte/examples \
|
||||
@@ -749,8 +780,8 @@ EXAMPLE_PATH = src/aodv/examples \
|
||||
src/point-to-point/examples \
|
||||
src/propagation/examples \
|
||||
src/spectrum/examples \
|
||||
src/stats/examples \
|
||||
src/tap-bridge/examples \
|
||||
src/tools/examples \
|
||||
src/topology-read/examples \
|
||||
src/uan/examples \
|
||||
src/virtual-net-device/examples \
|
||||
@@ -777,7 +808,12 @@ EXAMPLE_RECURSIVE = NO
|
||||
# the \image command).
|
||||
|
||||
IMAGE_PATH = doc/ns3_html_theme/static \
|
||||
src/mesh/doc/
|
||||
src/lte/doc/source/figures \
|
||||
src/lte/test/reference \
|
||||
src/mesh/doc \
|
||||
src/netanim/doc/figures \
|
||||
src/stats/doc \
|
||||
src/visualizer/visualizer/resource
|
||||
|
||||
# The INPUT_FILTER tag can be used to specify a program that doxygen should
|
||||
# invoke to filter for each input file. Doxygen will invoke the filter program
|
||||
@@ -815,6 +851,13 @@ FILTER_SOURCE_FILES = NO
|
||||
|
||||
FILTER_SOURCE_PATTERNS =
|
||||
|
||||
# If the USE_MD_FILE_AS_MAINPAGE tag refers to the name of a markdown file that
|
||||
# is part of the input, its contents will be placed on the main page (index.html).
|
||||
# This can be useful if you have a project on for instance GitHub and want reuse
|
||||
# the introduction page also for the doxygen output.
|
||||
|
||||
USE_MDFILE_AS_MAINPAGE =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# configuration options related to source browsing
|
||||
#---------------------------------------------------------------------------
|
||||
@@ -936,12 +979,22 @@ HTML_FOOTER = doc/ns3_html_theme/ns3_doxy_footer.html
|
||||
|
||||
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
|
||||
# style sheet that is used by each HTML page. It can be used to
|
||||
# fine-tune the look of the HTML output. If the tag is left blank doxygen
|
||||
# will generate a default style sheet. Note that doxygen will try to copy
|
||||
# the style sheet file to the HTML output directory, so don't put your own
|
||||
# style sheet in the HTML output directory as well, or it will be erased!
|
||||
# fine-tune the look of the HTML output. If left blank doxygen will
|
||||
# generate a default style sheet. Note that it is recommended to use
|
||||
# HTML_EXTRA_STYLESHEET instead of this one, as it is more robust and this
|
||||
# tag will in the future become obsolete.
|
||||
|
||||
HTML_STYLESHEET = doc/ns3_html_theme/static/ns3_stylesheet.css
|
||||
HTML_STYLESHEET =
|
||||
|
||||
# The HTML_EXTRA_STYLESHEET tag can be used to specify an additional
|
||||
# user-defined cascading style sheet that is included after the standard
|
||||
# style sheets created by doxygen. Using this option one can overrule
|
||||
# certain style aspects. This is preferred over using HTML_STYLESHEET
|
||||
# since it does not replace the standard style sheet and is therefor more
|
||||
# robust against future updates. Doxygen will copy the style sheet file to
|
||||
# the output directory.
|
||||
|
||||
HTML_EXTRA_STYLESHEET = doc/ns3_html_theme/static/ns3_stylesheet.css
|
||||
|
||||
# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
|
||||
# other source files which should be copied to the HTML output directory. Note
|
||||
@@ -950,8 +1003,7 @@ HTML_STYLESHEET = doc/ns3_html_theme/static/ns3_stylesheet.css
|
||||
# files. In the HTML_STYLESHEET file, use the file name only. Also note that
|
||||
# the files will be copied as-is; there are no commands or markers available.
|
||||
|
||||
HTML_EXTRA_FILES = doc/ns3_html_theme/static/doxygen.css \
|
||||
doc/ns3_html_theme/static/bar-top.png \
|
||||
HTML_EXTRA_FILES = doc/ns3_html_theme/static/bar-top.png \
|
||||
doc/ns3_html_theme/static/drop-down-menu.js \
|
||||
doc/ns3_html_theme/static/favicon.ico \
|
||||
doc/ns3_html_theme/static/menu-bgr-400.png \
|
||||
@@ -1034,9 +1086,9 @@ DOCSET_FEEDNAME = "Doxygen generated docs"
|
||||
|
||||
DOCSET_BUNDLE_ID = org.nsnam.ns3
|
||||
|
||||
# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
|
||||
# the documentation publisher. This should be a reverse domain-name style
|
||||
# string, e.g. com.mycompany.MyDocSet.documentation.
|
||||
# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely
|
||||
# identify the documentation publisher. This should be a reverse domain-name
|
||||
# style string, e.g. com.mycompany.MyDocSet.documentation.
|
||||
|
||||
DOCSET_PUBLISHER_ID = org.nsnam.ns3
|
||||
|
||||
@@ -1221,6 +1273,13 @@ FORMULA_TRANSPARENT = YES
|
||||
|
||||
USE_MATHJAX = NO
|
||||
|
||||
# When MathJax is enabled you can set the default output format to be used for
|
||||
# thA MathJax output. Supported types are HTML-CSS, NativeMML (i.e. MathML) and
|
||||
# SVG. The default value is HTML-CSS, which is slower, but has the best
|
||||
# compatibility.
|
||||
|
||||
MATHJAX_FORMAT = HTML-CSS
|
||||
|
||||
# When MathJax is enabled you need to specify the location relative to the
|
||||
# HTML output directory using the MATHJAX_RELPATH option. The destination
|
||||
# directory should contain the MathJax.js script. For instance, if the mathjax
|
||||
@@ -1231,7 +1290,7 @@ USE_MATHJAX = NO
|
||||
# However, it is strongly recommended to install a local
|
||||
# copy of MathJax from http://www.mathjax.org before deployment.
|
||||
|
||||
MATHJAX_RELPATH = http://www.mathjax.org/mathjax
|
||||
MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
|
||||
|
||||
# The MATHJAX_EXTENSIONS tag can be used to specify one or MathJax extension
|
||||
# names that should be enabled during MathJax rendering.
|
||||
@@ -1249,15 +1308,55 @@ MATHJAX_EXTENSIONS =
|
||||
SEARCHENGINE = YES
|
||||
|
||||
# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
|
||||
# implemented using a PHP enabled web server instead of at the web client
|
||||
# using Javascript. Doxygen will generate the search PHP script and index
|
||||
# file to put on the web server. The advantage of the server
|
||||
# based approach is that it scales better to large projects and allows
|
||||
# full text search. The disadvantages are that it is more difficult to setup
|
||||
# and does not have live searching capabilities.
|
||||
# implemented using a web server instead of a web client using Javascript.
|
||||
# There are two flavours of web server based search depending on the
|
||||
# EXTERNAL_SEARCH setting. When disabled, doxygen will generate a PHP script for
|
||||
# searching and an index file used by the script. When EXTERNAL_SEARCH is
|
||||
# enabled the indexing and searching needs to be provided by external tools.
|
||||
# See the manual for details.
|
||||
|
||||
SERVER_BASED_SEARCH = NO
|
||||
|
||||
# When EXTERNAL_SEARCH is enabled doxygen will no longer generate the PHP
|
||||
# script for searching. Instead the search results are written to an XML file
|
||||
# which needs to be processed by an external indexer. Doxygen will invoke an
|
||||
# external search engine pointed to by the SEARCHENGINE_URL option to obtain
|
||||
# the search results. Doxygen ships with an example indexer (doxyindexer) and
|
||||
# search engine (doxysearch.cgi) which are based on the open source search engine
|
||||
# library Xapian. See the manual for configuration details.
|
||||
|
||||
EXTERNAL_SEARCH = NO
|
||||
|
||||
# The SEARCHENGINE_URL should point to a search engine hosted by a web server
|
||||
# which will returned the search results when EXTERNAL_SEARCH is enabled.
|
||||
# Doxygen ships with an example search engine (doxysearch) which is based on
|
||||
# the open source search engine library Xapian. See the manual for configuration
|
||||
# details.
|
||||
|
||||
SEARCHENGINE_URL =
|
||||
|
||||
# When SERVER_BASED_SEARCH and EXTERNAL_SEARCH are both enabled the unindexed
|
||||
# search data is written to a file for indexing by an external tool. With the
|
||||
# SEARCHDATA_FILE tag the name of this file can be specified.
|
||||
|
||||
SEARCHDATA_FILE = searchdata.xml
|
||||
|
||||
# When SERVER_BASED_SEARCH AND EXTERNAL_SEARCH are both enabled the
|
||||
# EXTERNAL_SEARCH_ID tag can be used as an identifier for the project. This is
|
||||
# useful in combination with EXTRA_SEARCH_MAPPINGS to search through multiple
|
||||
# projects and redirect the results back to the right project.
|
||||
|
||||
EXTERNAL_SEARCH_ID =
|
||||
|
||||
# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
|
||||
# projects other than the one defined by this configuration file, but that are
|
||||
# all added to the same external search index. Each project needs to have a
|
||||
# unique id set via EXTERNAL_SEARCH_ID. The search mapping then maps the id
|
||||
# of to a relative location where the documentation can be found.
|
||||
# The format is: EXTRA_SEARCH_MAPPINGS = id1=loc1 id2=loc2 ...
|
||||
|
||||
EXTRA_SEARCH_MAPPINGS =
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# configuration options related to the LaTeX output
|
||||
#---------------------------------------------------------------------------
|
||||
@@ -1543,6 +1642,9 @@ SEARCH_INCLUDES = YES
|
||||
|
||||
INCLUDE_PATH =
|
||||
|
||||
# Allow doxygen to find generated include files, such as ns3/core-config.h
|
||||
INCLUDE_PATH += build
|
||||
|
||||
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
|
||||
# patterns (like *.h and *.hpp) to filter out the header-files in the
|
||||
# directories. If left blank, the patterns specified with FILE_PATTERNS will
|
||||
@@ -1558,8 +1660,22 @@ INCLUDE_FILE_PATTERNS =
|
||||
# undefined via #undef or recursively expanded use the := operator
|
||||
# instead of the = operator.
|
||||
|
||||
PREDEFINED = NS3_ASSERT_ENABLE \
|
||||
NS3_LOG_ENABLE
|
||||
# ns-3:
|
||||
#
|
||||
# We predefine NS3_ASSERT_ENABLE and NS3_LOG_ENABLE so doxygen sees
|
||||
# the working definitions. (These are normally defined by waf
|
||||
# in ns3/core-config.h)
|
||||
#
|
||||
# Function like macros at file global scope typically need to be here,
|
||||
# since doxygen confuses invocations of these macros for function
|
||||
# definitions.
|
||||
|
||||
PREDEFINED = \
|
||||
NS3_ASSERT_ENABLE \
|
||||
NS3_LOG_ENABLE \
|
||||
NS_LOG_COMPONENT_DEFINE()=1 \
|
||||
NS_LOG_COMPONENT_DEFINE_MASK()=1 \
|
||||
NS_OBJECT_ENSURE_REGISTERED()=1 \
|
||||
|
||||
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
|
||||
# this tag can be used to specify a list of macro names that should be expanded.
|
||||
|
||||
+226
-32
@@ -1,59 +1,221 @@
|
||||
#!/bin/bash
|
||||
|
||||
# Process doxygen.warnings.log to generate sorted list of top offenders
|
||||
# Process doxygen log to generate sorted list of top offenders.
|
||||
#
|
||||
|
||||
# Flag to skip running doxygen
|
||||
skipdoxy=${1:-""}
|
||||
me=$(basename $0)
|
||||
DIR="$(dirname $0)"
|
||||
ROOT="$(hg root)"
|
||||
|
||||
DIR=`dirname $0`
|
||||
ROOT=`hg root`
|
||||
# Final resting place for the log file
|
||||
log=$DIR/doxygen.warnings.log
|
||||
# Known log files
|
||||
STANDARDLOGFILE=doxygen.log
|
||||
WARNINGSLOGFILE=doxygen.warnings.log
|
||||
# Default choice: generate it
|
||||
LOG="$DIR/$WARNINGSLOGFILE"
|
||||
|
||||
|
||||
# First, we have to modify doxygen.conf to generate all the warnings
|
||||
# (We also suppress dot graphs, so shorten the run time.)
|
||||
# Options ------------------------------
|
||||
#
|
||||
|
||||
if [ "$skipdoxy" == "" ]; then
|
||||
function usage
|
||||
{
|
||||
cat <<-EOF
|
||||
|
||||
Usage: $me [-eth] [-f <log-file> | -l | -s] [-m <module> | -F <regex>]
|
||||
|
||||
Run doxygen to generate all errors; report error counts
|
||||
by module and file.
|
||||
|
||||
The default behavior is to modify doxygen.conf temporarily to
|
||||
report all undocumented elements, and to reduce the run time.
|
||||
The output of this special run is kept in doc/$WARNINGSLOGFILE.
|
||||
|
||||
The -e and -t options exclude examples and test directories
|
||||
from the counts. The -m option only includes a specific module.
|
||||
The -F option only includes files (or warnings) matching the <regex>.
|
||||
The -m and -F options append the relevant warnings after the
|
||||
numerical report. These can be used in any combination.
|
||||
|
||||
-e Filter out warnings from */examples/*
|
||||
-t Filter out warnings from */test/*
|
||||
-m Only include files matching src/<module>
|
||||
-F Only include files matching the <regex>
|
||||
|
||||
The -f, -l, and -s options skip the doxygen run altogether.
|
||||
The first two use a specified or the standard log file;
|
||||
the -s option uses the warnings log from a prior run.
|
||||
Only the first of -f <log-file>, -s, or -l will have effect.
|
||||
|
||||
-f Skip doxygen run; use existing <log-file>.
|
||||
-s Skip doxygen run; use existing warnings log doc/$WARNINGSLOGFILE
|
||||
-l Skip doxygen run; use the normal doxygen log doc/$STANDARDLOGFILE
|
||||
|
||||
-h Print this usage message
|
||||
|
||||
EOF
|
||||
exit 1
|
||||
}
|
||||
|
||||
# Argument processing ------------------
|
||||
#
|
||||
|
||||
# -f argument
|
||||
usefilearg=0
|
||||
logfilearg=
|
||||
# -l
|
||||
usestandard=0
|
||||
# skip doxygen run; using existing log file
|
||||
SKIPDOXY=0
|
||||
|
||||
# Filtering flags
|
||||
filter_examples=0
|
||||
filter_test=0
|
||||
filter_module=""
|
||||
filter_regex=""
|
||||
|
||||
while getopts :etm:F:lF:sh option ; do
|
||||
|
||||
case $option in
|
||||
|
||||
(e) filter_examples=1 ;;
|
||||
|
||||
(t) filter_test=1 ;;
|
||||
|
||||
(m) filter_module="$OPTARG" ;;
|
||||
|
||||
(F) filter_regex="$OPTARG" ;;
|
||||
|
||||
(l) usestandard=1 ;;
|
||||
|
||||
(f) usefilearg=1
|
||||
logfilearg="$OPTARG"
|
||||
;;
|
||||
|
||||
(s) usefilearg=1
|
||||
logfilearg="$DIR/$WARNINGSLOGFILE"
|
||||
;;
|
||||
|
||||
(h) usage ;;
|
||||
(:) echo "$me: Missing argument to -$OPTARG" ; usage ;;
|
||||
(\?) echo "$me: Invalid option: -$OPTARG" ; usage ;;
|
||||
esac
|
||||
done
|
||||
|
||||
function checklogfile
|
||||
{
|
||||
if [ -e "$1" ] ; then
|
||||
SKIPDOXY=1
|
||||
LOG="$1"
|
||||
else
|
||||
echo "$me: log file $1 does not exist."
|
||||
exit 1
|
||||
fi
|
||||
}
|
||||
|
||||
# Which log file
|
||||
if [[ $usefilearg -eq 1 && "${logfilearg:-}" != "" ]] ; then
|
||||
checklogfile "$logfilearg"
|
||||
elif [ $usestandard -eq 1 ]; then
|
||||
checklogfile "$DIR/$STANDARDLOGFILE"
|
||||
fi
|
||||
|
||||
# Run doxygen -------------------------
|
||||
#
|
||||
|
||||
if [ $SKIPDOXY -eq 1 ]; then
|
||||
echo
|
||||
echo "Skipping doxygen run, using existing log file $LOG"
|
||||
else
|
||||
|
||||
# Run introspection, which may require a build
|
||||
(cd "$ROOT" && ./waf --run print-introspected-doxygen >doc/introspected-doxygen.h)
|
||||
|
||||
# Modify doxygen.conf to generate all the warnings
|
||||
# (We also suppress dot graphs, so shorten the run time.)
|
||||
|
||||
conf=$DIR/doxygen.conf
|
||||
|
||||
sed -i.bak -E '/^EXTRACT_ALL |^HAVE_DOT |^WARNINGS /s/YES/no/' $conf
|
||||
rm -f $conf.bak
|
||||
|
||||
echo
|
||||
echo -n "Rebuilding doxygen docs with full errors..."
|
||||
(cd $ROOT && ./waf --doxygen >/dev/null 2>&1)
|
||||
(cd "$ROOT" && ./waf --doxygen >/dev/null 2>&1)
|
||||
status=$?
|
||||
|
||||
hg revert $conf
|
||||
rm -f $conf
|
||||
mv -f $conf.bak $conf
|
||||
|
||||
if [ "$status" = "0" ]; then
|
||||
if [ $status -eq 0 ]; then
|
||||
echo "Done."
|
||||
else
|
||||
echo "FAILED."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
mv $DIR/doxygen.log $log
|
||||
cp -f "$DIR/$STANDARDLOGFILE" "$DIR/$WARNINGSLOGFILE"
|
||||
|
||||
else
|
||||
echo "Skipping doxygen run, using existing log file $log"
|
||||
fi
|
||||
|
||||
# Log filters --------------------------
|
||||
#
|
||||
|
||||
# Analyze the log
|
||||
# Filter regular expression for -m and -F
|
||||
filter_inRE=""
|
||||
if [ "$filter_module" != "" ] ; then
|
||||
filter_inRE="src/$filter_module"
|
||||
fi
|
||||
if [ "$filter_regex" != "" ] ; then
|
||||
filter_inRE="${filter_inRE:-}${filter_inRE:+\\|}$filter_regex"
|
||||
fi
|
||||
|
||||
# Filter regular expression for -e and -t
|
||||
filter_outRE=""
|
||||
if [ $filter_examples -eq 1 ]; then
|
||||
filter_outRE="/examples/"
|
||||
fi
|
||||
if [ $filter_test -eq 1 ]; then
|
||||
filter_outRE="${filter_outRE:-}${filter_outRE:+\\|}/test/"
|
||||
fi
|
||||
|
||||
if [ "${filter_inRE:-}" != "" ] ; then
|
||||
echo "Filtering in \"$filter_inRE\""
|
||||
fi
|
||||
if [ "${filter_outRE:-}" != "" ] ; then
|
||||
echo "Filtering out \"$filter_outRE\""
|
||||
fi
|
||||
echo
|
||||
|
||||
# Filter log file
|
||||
function filter_log
|
||||
{
|
||||
local flog;
|
||||
flog=$( cat "$LOG" | grep "^$ROOT" )
|
||||
|
||||
if [ "${filter_inRE:-}" != "" ] ; then
|
||||
flog=$( echo "$flog" | grep "$filter_inRE" )
|
||||
fi
|
||||
|
||||
if [ "${filter_outRE:-}" != "" ] ; then
|
||||
flog=$( echo "$flog" | grep -v "$filter_outRE" )
|
||||
fi
|
||||
|
||||
echo "$flog"
|
||||
}
|
||||
|
||||
|
||||
# Analyze the log ----------------------
|
||||
#
|
||||
|
||||
# List of module directories (e.g, "src/core/model")
|
||||
undocmods=$( \
|
||||
grep "^$ROOT" "$log" | \
|
||||
filter_log | \
|
||||
cut -d ':' -f 1 | \
|
||||
sed "s|$ROOT||g" | \
|
||||
cut -d '/' -f 2-4 | \
|
||||
sed "s|$ROOT/||g" | \
|
||||
cut -d '/' -f 1-3 | \
|
||||
sort | \
|
||||
uniq -c | \
|
||||
sort -nr \
|
||||
)
|
||||
|
||||
|
||||
# Number of directories
|
||||
modcount=$( \
|
||||
@@ -65,24 +227,24 @@ modcount=$( \
|
||||
# For a function with multiple undocumented parameters,
|
||||
# Doxygen prints the additional parameters on separate lines,
|
||||
# so they don't show up in the totals above.
|
||||
# Rather than work too hard to get the exact number,
|
||||
# Rather than work too hard to get the exact number for each file,
|
||||
# we just list the total here.
|
||||
addlparam=$( \
|
||||
grep -v "^$ROOT" $log | \
|
||||
grep -v "not generated, too many nodes" | \
|
||||
grep "^ parameter '" $log | \
|
||||
grep "^ parameter '" "$LOG" | \
|
||||
wc -l | \
|
||||
sed 's/^[ \t]*//;s/[ \t]*$//' \
|
||||
)
|
||||
|
||||
# Total number of warnings
|
||||
warncount=$(echo "$undocmods" | \
|
||||
awk '{total += $1}; END {print total}' )
|
||||
warncount=$( \
|
||||
echo "$undocmods" | \
|
||||
awk '{total += $1}; END {print total}' \
|
||||
)
|
||||
warncount=$((warncount + addlparam))
|
||||
|
||||
# List of files appearing in the log
|
||||
undocfiles=$( \
|
||||
grep "^$ROOT" "$log" | \
|
||||
undocfiles=$( \
|
||||
filter_log | \
|
||||
cut -d ':' -f 1 | \
|
||||
sed "s|$ROOT||g" | \
|
||||
cut -d '/' -f 2- | \
|
||||
@@ -91,6 +253,9 @@ undocfiles=$( \
|
||||
sort -k 2 \
|
||||
)
|
||||
|
||||
# Sorted by number, decreasing
|
||||
undocsort=$(echo "$undocfiles" | sort -k1nr,2 )
|
||||
|
||||
# Total number of files
|
||||
filecount=$( \
|
||||
echo "$undocfiles" | \
|
||||
@@ -98,7 +263,19 @@ filecount=$( \
|
||||
sed 's/^[ \t]*//;s/[ \t]*$//' \
|
||||
)
|
||||
|
||||
# Now we're ready to summarize the log
|
||||
# Filtered in warnings
|
||||
filterin=
|
||||
if [ "${filter_inRE:-}" != "" ] ; then
|
||||
filterin=$( \
|
||||
filter_log | \
|
||||
sed "s|$ROOT/||g" \
|
||||
)
|
||||
fi
|
||||
|
||||
|
||||
|
||||
# Summarize the log --------------------
|
||||
#
|
||||
|
||||
echo
|
||||
echo "Report of Doxygen warnings"
|
||||
@@ -117,7 +294,7 @@ printf "%6d total warnings\n" $warncount
|
||||
printf "%6d directories with warnings\n" $modcount
|
||||
echo
|
||||
echo
|
||||
echo "Warnings by file"
|
||||
echo "Warnings by file (alphabetical)"
|
||||
echo
|
||||
echo "Count File"
|
||||
echo "----- ----------------------------------"
|
||||
@@ -126,8 +303,25 @@ echo "----------------------------------------"
|
||||
printf "%6d files with warnings\n" $filecount
|
||||
echo
|
||||
echo
|
||||
echo "Warnings by file (numerical)"
|
||||
echo
|
||||
echo "Count File"
|
||||
echo "----- ----------------------------------"
|
||||
echo "$undocsort"
|
||||
echo "----------------------------------------"
|
||||
printf "%6d files with warnings\n" $filecount
|
||||
echo
|
||||
echo
|
||||
echo "Doxygen Warnings Summary"
|
||||
echo "----------------------------------------"
|
||||
printf "%6d directories\n" $modcount
|
||||
printf "%6d files\n" $filecount
|
||||
printf "%6d warnings\n" $warncount
|
||||
|
||||
if [ "$filterin" != "" ] ; then
|
||||
echo
|
||||
echo
|
||||
echo "Filtered Warnings"
|
||||
echo "========================================"
|
||||
echo "$filterin"
|
||||
fi
|
||||
|
||||
+25
-1
@@ -57,7 +57,6 @@
|
||||
* - stats
|
||||
* - tap-bridge
|
||||
* - test
|
||||
* - tools
|
||||
* - topology-read
|
||||
* - uan
|
||||
* - virtual-net-device
|
||||
@@ -72,3 +71,28 @@
|
||||
* ns3 namespace.
|
||||
*/
|
||||
|
||||
// Macros defined by the build system.
|
||||
//
|
||||
// These have to be visible for doxygen to document them,
|
||||
// so we put them here in a file only seen by doxygen, not the compiler.
|
||||
/**
|
||||
* \ingroup assert
|
||||
*
|
||||
* \def NS3_ASSERT_ENABLE
|
||||
*
|
||||
* Enable asserts at compile time.
|
||||
*
|
||||
* This is normally set by `./waf configure --build-profile=debug`.
|
||||
*/
|
||||
#define NS3_ASSERT_ENABLE
|
||||
|
||||
/**
|
||||
* \ingroup logging
|
||||
*
|
||||
* \def NS3_LOG_ENABLE
|
||||
*
|
||||
* Enable logging at compile time.
|
||||
*
|
||||
* This is normally set by `./waf configure --build-profile=debug`.
|
||||
*/
|
||||
#define NS3_LOG_ENABLE
|
||||
|
||||
+103
-32
@@ -2,38 +2,100 @@ EPSTOPDF = epstopdf
|
||||
DIA = dia
|
||||
CONVERT = convert
|
||||
|
||||
FIGURES = figures
|
||||
VPATH = $(FIGURES)
|
||||
SRC = ../../src
|
||||
# Temporary source directory, for build
|
||||
SOURCETEMP = source-temp
|
||||
FIGURES = $(SOURCETEMP)/figures
|
||||
#VPATH = $(FIGURES)
|
||||
|
||||
# list all manual .rst files that need to be copied to $SOURCETEMP
|
||||
SOURCES = \
|
||||
source/conf.py \
|
||||
source/_static \
|
||||
source/index.rst \
|
||||
source/replace.txt \
|
||||
source/attributes.rst \
|
||||
source/callbacks.rst \
|
||||
source/documentation.rst \
|
||||
source/enable-modules.rst \
|
||||
source/enable-tests.rst \
|
||||
source/events.rst \
|
||||
source/gnuplot.rst \
|
||||
source/hash-functions.rst \
|
||||
source/helpers.rst \
|
||||
source/how-to-write-tests.rst \
|
||||
source/logging.rst \
|
||||
source/new-models.rst \
|
||||
source/new-modules.rst \
|
||||
source/object-model.rst \
|
||||
source/object-names.rst \
|
||||
source/organization.rst \
|
||||
source/python.rst \
|
||||
source/random-variables.rst \
|
||||
source/realtime.rst \
|
||||
source/support.rst \
|
||||
source/test-background.rst \
|
||||
source/test-framework.rst \
|
||||
source/test-overview.rst \
|
||||
source/tests.rst \
|
||||
source/tracing.rst \
|
||||
source/troubleshoot.rst \
|
||||
${SRC}/stats/doc/data-collection.rst \
|
||||
${SRC}/stats/doc/data-collection-overview.rst \
|
||||
${SRC}/stats/doc/statistics.rst \
|
||||
${SRC}/stats/doc/data-collection-helpers.rst \
|
||||
${SRC}/stats/doc/probe.rst \
|
||||
${SRC}/stats/doc/collector.rst \
|
||||
${SRC}/stats/doc/aggregator.rst \
|
||||
${SRC}/stats/doc/adaptor.rst \
|
||||
${SRC}/stats/doc/scope-and-limitations.rst \
|
||||
|
||||
# list all manual figure files that need to be copied to
|
||||
# $SOURCETEMP/figures. For each figure to be included in all
|
||||
# documentation formats (html, latex...) the following formats are supported:
|
||||
# 1) a single .dia file (preferred option, because it can be edited)
|
||||
# 2) a single .eps file
|
||||
# 3) both a .pdf and .png file
|
||||
|
||||
SOURCEFIGS = \
|
||||
figures/software-organization.dia \
|
||||
figures/plot-2d.png \
|
||||
figures/plot-2d-with-error-bars.png \
|
||||
figures/plot-3d.png \
|
||||
${SRC}/stats/doc/Stat-framework-arch.png \
|
||||
${SRC}/stats/doc/Wifi-default.png \
|
||||
${SRC}/stats/doc/dcf-overview.dia \
|
||||
${SRC}/stats/doc/dcf-overview-with-aggregation.dia \
|
||||
${SRC}/stats/doc/gnuplot-example.png \
|
||||
${SRC}/stats/doc/file-example.png \
|
||||
${SRC}/stats/doc/seventh-packet-byte-count.png \
|
||||
${SRC}/stats/doc/gnuplot-helper-example.png \
|
||||
${SRC}/stats/doc/gnuplot-aggregator.png \
|
||||
|
||||
# specify figures from which .png and .pdf figures need to be
|
||||
# generated (all dia and eps figures)
|
||||
IMAGES_EPS = \
|
||||
$(FIGURES)/software-organization.eps \
|
||||
$(FIGURES)/dcf-overview.eps \
|
||||
$(FIGURES)/dcf-overview-with-aggregation.eps \
|
||||
|
||||
# rescale pdf figures as necessary
|
||||
$(FIGURES)/software-organization.pdf_width = 5in
|
||||
|
||||
# Do not delete/clean these png images upon make clean
|
||||
IMAGES_PNG_SAVED = \
|
||||
$(FIGURES)/plot-2d.png \
|
||||
$(FIGURES)/plot-2d-with-error-bars.png \
|
||||
$(FIGURES)/plot-3d.png \
|
||||
|
||||
IMAGES_PNG_CONVERTED = \
|
||||
${IMAGES_EPS:.eps=.png}
|
||||
|
||||
IMAGES_PNG = $(IMAGES_PNG_SAVED) $(IMAGES_PNG_CONVERTED)
|
||||
IMAGES_PNG = $(IMAGES_EPS:.eps=.png)
|
||||
|
||||
IMAGES_PDF = ${IMAGES_EPS:.eps=.pdf}
|
||||
|
||||
IMAGES = $(IMAGES_EPS) $(IMAGES_PNG) $(IMAGES_PDF)
|
||||
|
||||
IMAGES_TO_CLEAN = $(IMAGES_PNG_CONVERTED) $(IMAGES_PDF) $(IMAGES_EPS)
|
||||
RESCALE = ../../utils/rescale-pdf.sh
|
||||
|
||||
%.eps : %.dia; $(DIA) -t eps $< -e $@
|
||||
%.png : %.dia; $(DIA) -t png $< -e $@
|
||||
%.png : %.eps; $(CONVERT) $< $@
|
||||
%.pdf : %.eps;
|
||||
$(EPSTOPDF) $< -o=$@
|
||||
if test x$($@_width) != x; then ./rescale-pdf.sh $($@_width) $@ ; fi
|
||||
if test x$($@_width) != x; then $(RESCALE) $($@_width) $@ ; fi
|
||||
|
||||
|
||||
# You can set these variables from the command line.
|
||||
@@ -45,10 +107,12 @@ BUILDDIR = build
|
||||
# Internal variables.
|
||||
PAPEROPT_a4 = -D latex_paper_size=a4
|
||||
PAPEROPT_letter = -D latex_paper_size=letter
|
||||
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
|
||||
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) $(SOURCETEMP)
|
||||
|
||||
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest
|
||||
|
||||
.NOTPARALLEL:
|
||||
|
||||
help:
|
||||
@echo "Please use \`make <target>' where <target> is one of"
|
||||
@echo " html to make standalone HTML files"
|
||||
@@ -68,47 +132,54 @@ help:
|
||||
@echo " linkcheck to check all external links for integrity"
|
||||
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
|
||||
|
||||
copy-sources: $(SOURCES)
|
||||
@rm -rf $(SOURCETEMP)
|
||||
@mkdir -p $(SOURCETEMP)
|
||||
@mkdir -p $(FIGURES)
|
||||
@cp -r $(SOURCES) $(SOURCETEMP)
|
||||
@cp -r $(SOURCEFIGS) $(FIGURES)
|
||||
|
||||
clean:
|
||||
-rm -rf $(BUILDDIR)
|
||||
-rm -rf $(IMAGES_TO_CLEAN)
|
||||
-rm -rf $(SOURCETEMP)
|
||||
|
||||
frag: pickle
|
||||
@if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi
|
||||
pushd $(BUILDDIR)/frag && ../../pickle-to-xml.py ../pickle/index.fpickle > navigation.xml && popd
|
||||
cp -r $(BUILDDIR)/pickle/_images $(BUILDDIR)/frag
|
||||
|
||||
html: $(IMAGES)
|
||||
html: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
|
||||
@echo
|
||||
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
|
||||
|
||||
dirhtml: $(IMAGES)
|
||||
dirhtml: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
|
||||
@echo
|
||||
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
|
||||
|
||||
singlehtml: $(IMAGES)
|
||||
singlehtml: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
|
||||
@echo
|
||||
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
|
||||
|
||||
pickle: $(IMAGES)
|
||||
pickle: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
|
||||
@echo
|
||||
@echo "Build finished; now you can process the pickle files."
|
||||
|
||||
json: $(IMAGES)
|
||||
json: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
|
||||
@echo
|
||||
@echo "Build finished; now you can process the JSON files."
|
||||
|
||||
htmlhelp: $(IMAGES)
|
||||
htmlhelp: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
|
||||
@echo
|
||||
@echo "Build finished; now you can run HTML Help Workshop with the" \
|
||||
".hhp project file in $(BUILDDIR)/htmlhelp."
|
||||
|
||||
qthelp: $(IMAGES)
|
||||
qthelp: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
|
||||
@echo
|
||||
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
|
||||
@@ -117,7 +188,7 @@ qthelp: $(IMAGES)
|
||||
@echo "To view the help file:"
|
||||
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/ns-3.qhc"
|
||||
|
||||
devhelp: $(IMAGES)
|
||||
devhelp: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
|
||||
@echo
|
||||
@echo "Build finished."
|
||||
@@ -126,46 +197,46 @@ devhelp: $(IMAGES)
|
||||
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/ns-3"
|
||||
@echo "# devhelp"
|
||||
|
||||
epub: $(IMAGES)
|
||||
epub: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
|
||||
@echo
|
||||
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
|
||||
|
||||
latex: $(IMAGES)
|
||||
latex: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo
|
||||
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
|
||||
@echo "Run \`make' in that directory to run these through (pdf)latex" \
|
||||
"(use \`make latexpdf' here to do that automatically)."
|
||||
|
||||
latexpdf: $(IMAGES)
|
||||
latexpdf: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
|
||||
@echo "Running LaTeX files through pdflatex..."
|
||||
make -C $(BUILDDIR)/latex all-pdf
|
||||
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
|
||||
|
||||
text: $(IMAGES)
|
||||
text: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
|
||||
@echo
|
||||
@echo "Build finished. The text files are in $(BUILDDIR)/text."
|
||||
|
||||
man: $(IMAGES)
|
||||
man: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
|
||||
@echo
|
||||
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
|
||||
|
||||
changes: $(IMAGES)
|
||||
changes: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
|
||||
@echo
|
||||
@echo "The overview file is in $(BUILDDIR)/changes."
|
||||
|
||||
linkcheck: $(IMAGEs)
|
||||
linkcheck: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
|
||||
@echo
|
||||
@echo "Link check complete; look for any errors in the above output " \
|
||||
"or in $(BUILDDIR)/linkcheck/output.txt."
|
||||
|
||||
doctest: $(IMAGES)
|
||||
doctest: copy-sources $(IMAGES)
|
||||
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
|
||||
@echo "Testing of doctests in the sources finished, look at the " \
|
||||
"results in $(BUILDDIR)/doctest/output.txt."
|
||||
|
||||
@@ -1,14 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
TMPDIR=/tmp
|
||||
|
||||
TMPFILE=`mktemp`
|
||||
|
||||
echo "\documentclass{book}
|
||||
\usepackage{pdfpages}
|
||||
\begin{document}
|
||||
\includepdf[width=${1},fitpaper]{${2}}
|
||||
\end{document}" >${TMPFILE}.tex
|
||||
pdflatex -output-directory /tmp ${TMPFILE}.tex >/dev/null 2>/dev/null
|
||||
cp ${TMPFILE}.pdf ${2}
|
||||
rm -f ${TMPFILE}{,.{tex,aux,log,pdf}}
|
||||
+521
-288
File diff suppressed because it is too large
Load Diff
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Callbacks
|
||||
---------
|
||||
@@ -364,11 +365,11 @@ Now, we need to tie together this callback instance and the actual target functi
|
||||
callback-- this is important. We can pass in any such properly-typed function
|
||||
to this callback. Let's look at this more closely::
|
||||
|
||||
static double CbOne (double a, double b) {}
|
||||
^ ^ ^
|
||||
| ---| ------|
|
||||
| | |
|
||||
Callback<double, double, double> one;
|
||||
static double CbOne (double a, double b) {}
|
||||
^ ^ ^
|
||||
| | |
|
||||
| | |
|
||||
Callback<double, double, double> one;
|
||||
|
||||
You can only bind a function to a callback if they have the matching signature.
|
||||
The first template argument is the return type, and the additional template
|
||||
@@ -537,6 +538,30 @@ function call::
|
||||
|
||||
(*m_p.*m_pmi)(m_boundArg, arg);
|
||||
|
||||
It's possible to bind two or three arguments as well. Say we have a function with
|
||||
signature::
|
||||
|
||||
static void NotifyEvent (Ptr<A> a, Ptr<B> b, MyEventType e);
|
||||
|
||||
One can create bound callback binding first two arguments like::
|
||||
|
||||
MakeBoundCallback (&NotifyEvent, a1, b1);
|
||||
|
||||
assuming `a1` and `b1` are objects of type `A` and `B` respectively. Similarly for
|
||||
three arguments one would have function with a signature::
|
||||
|
||||
static void NotifyEvent (Ptr<A> a, Ptr<B> b, MyEventType e);
|
||||
|
||||
Binding three arguments in done with::
|
||||
|
||||
MakeBoundCallback (&NotifyEvent, a1, b1, c1);
|
||||
|
||||
again assuming `a1`, `b1` and `c1` are objects of type `A`, `B` and `C` respectively.
|
||||
|
||||
This kind of binding can be used for exchanging information between objects in
|
||||
simulation; specifically, bound callbacks can be used as traced callbacks, which will
|
||||
be described in the next section.
|
||||
|
||||
Traced Callbacks
|
||||
****************
|
||||
*Placeholder subsection*
|
||||
|
||||
@@ -197,7 +197,7 @@ latex_logo = '../../ns3_html_theme/static/ns-3.png'
|
||||
#latex_show_urls = False
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#latex_preamble = ''
|
||||
latex_preamble = '\usepackage{amssymb}'
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
@@ -0,0 +1,569 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Creating Documentation
|
||||
----------------------
|
||||
|
||||
|ns3| supplies two kinds of documentation: expository "user-guide"-style
|
||||
chapters, and source code API documentation.
|
||||
|
||||
The "user-guide" chapters are written by hand in reStructuredText_
|
||||
format (``.rst``), which is processed by the Python documentation
|
||||
system Sphinx_ to generate web pages and pdf files.
|
||||
The API documentation is generated from the source code itself,
|
||||
using Doxygen_, to generate cross-linked web pages.
|
||||
Both of these are important: the Sphinx chapters explain the *why*
|
||||
and overview of using a model; the API documentation explains the
|
||||
*how* details.
|
||||
|
||||
This chapter gives a quick overview of these
|
||||
tools, emphasizing preferred usage and customizations for |ns3|.
|
||||
|
||||
To build all the standard documentation:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf docs
|
||||
|
||||
For more specialized options, read on.
|
||||
|
||||
.. _reStructuredText: http://sphinx-doc.org/rest.html
|
||||
.. _sphinx: http://sphinx-doc.org/
|
||||
.. _doxygen: http://www.doxygen.org/
|
||||
|
||||
|
||||
Documenting with Sphinx
|
||||
***********************
|
||||
|
||||
We use Sphinx_ to generate expository chapters describing
|
||||
the design and usage of each module. Right now you are reading the
|
||||
:doc:`Documentation <documentation>` Chapter.
|
||||
The `Show Source <_sources/documentation.txt>`_ link in the sidebar
|
||||
will show you the reStructuredText source for this chapter.
|
||||
|
||||
Adding New Chapters
|
||||
===================
|
||||
|
||||
Adding a new chapter takes three steps (described in more detail below):
|
||||
|
||||
#. Choose `Where?`_ the documentation file(s) will live.
|
||||
#. `Link`_ from an existing page to the new documentation.
|
||||
#. Add the new file to the `Makefile`_.
|
||||
|
||||
Where?
|
||||
######
|
||||
|
||||
Documentation for a specific module, ``foo``, should normally go in
|
||||
``src/foo/doc/``. For example ``src/foo/doc/foo.rst`` would be the
|
||||
top-level document for the module. The ``src/create-module.py`` script
|
||||
will create this file for you.
|
||||
|
||||
Some models require several ``.rst`` files, and figures; these should
|
||||
all go in the ``src/foo/doc/`` directory. The docs are actually build
|
||||
by a Sphinx Makefile. For especially involved
|
||||
documentation, it may be helpful to have a local ``Makefile``
|
||||
in the ``src/foo/doc/`` directory to
|
||||
simplify building the documentation for this module
|
||||
(`Antenna`_ is an example). Setting this up
|
||||
is not particularly hard, but is beyond the scope of this chapter.
|
||||
|
||||
In some cases, documentation spans multiple models; the
|
||||
`Network`_ chapter is an example. In these cases
|
||||
adding the ``.rst`` files directly to ``doc/models/source/`` might
|
||||
be appropriate.
|
||||
|
||||
.. _antenna: http://www.nsnam.org/docs/models/html/antenna.html
|
||||
.. _network: http://www.nsnam.org/docs/models/html/network.html
|
||||
|
||||
Link
|
||||
####
|
||||
|
||||
Sphinx has to know *where* your new chapter should appear. In most
|
||||
cases, a new model chapter should appear the in `Models` book.
|
||||
To add your chapter there, edit ``doc/models/source/index.rst``
|
||||
|
||||
.. sourcecode:: rest
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
organization
|
||||
animation
|
||||
antenna
|
||||
aodv
|
||||
applications
|
||||
...
|
||||
|
||||
Add the name of your document (without the ``.rst`` extension) to
|
||||
this list. Please keep the Model chapters in alphabetical order,
|
||||
to ease visual scanning for specific chapters.
|
||||
|
||||
Makefile
|
||||
########
|
||||
|
||||
You also have to add your document to the appropriate ``Makefile``,
|
||||
so ``make`` knows to check it for updates. The Models book Makefile
|
||||
is ``doc/models/Makefile``, the Manual book Makefile is
|
||||
``doc/manual/Makefile``.
|
||||
|
||||
.. sourcecode:: make
|
||||
|
||||
# list all model library .rst files that need to be copied to $SOURCETEMP
|
||||
SOURCES = \
|
||||
source/conf.py \
|
||||
source/_static \
|
||||
source/index.rst \
|
||||
source/replace.txt \
|
||||
source/organization.rst \
|
||||
...
|
||||
$(SRC)/antenna/doc/source/antenna.rst \
|
||||
...
|
||||
|
||||
You add your ``.rst`` files to the ``SOURCES`` variable. To add figures,
|
||||
read the comments in the ``Makefile`` to see which variable should contain
|
||||
your image files. Again, please keep these in alphabetical order.
|
||||
|
||||
Building Sphinx Docs
|
||||
====================
|
||||
|
||||
Building the Sphinx documentation is pretty simple.
|
||||
To build all the Sphinx documentation:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf sphinx
|
||||
|
||||
To build just the Models documentation:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ make -C doc/models
|
||||
|
||||
To see the generated documentation point your browser at
|
||||
``doc/models/build/html``.
|
||||
|
||||
As you can see, Sphinx uses Make to guide the process.
|
||||
The default target builds all enabled output forms, which in
|
||||
|ns3| are the multi-page ``html``, single-page ``singlehtml``, and pdf
|
||||
(``latex``). To build just the multi-page html, you add the ``html`` target:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ make -C doc/models html
|
||||
|
||||
This can be helpful to reduce the build time (and the size of the
|
||||
build chatter) as you are writing your chapter.
|
||||
|
||||
Before committing your documentation to the repo, please check
|
||||
that it builds without errors or warnings. The build process
|
||||
generates lots of output (mostly normal chatter from LaTeX),
|
||||
which can make it difficult to see if there are any Sphinx
|
||||
warnings or errors. To find important warnings and errors
|
||||
build just the ``html`` version, then search the build log
|
||||
for ``warning`` or ``error``.
|
||||
|
||||
|
||||
|ns3| Specifics
|
||||
===============
|
||||
|
||||
The Sphinx documentation_ and tutorial_ are pretty good. We won't duplicate
|
||||
the basics here, instead focusing on preferred usage for |ns3|.
|
||||
|
||||
.. _documentation: http://sphinx-doc.org/contents.html
|
||||
.. _tutorial: http://sphinx-doc.org/tutorial.html
|
||||
|
||||
|
||||
* Start documents with these two lines:
|
||||
|
||||
.. sourcecode:: rest
|
||||
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
The first line enables some simple replacements. For example,
|
||||
typing ``|ns3|`` renders as |ns3|.
|
||||
The second sets the default source code highlighting language explicitly
|
||||
for the file, since the parser guess isn't always accurate.
|
||||
(It's also possible to set the language explicitly for a single code block,
|
||||
see below.)
|
||||
|
||||
* Sections:
|
||||
|
||||
Sphinx is pretty liberal about marking section headings. By convention,
|
||||
we prefer this hierarchy:
|
||||
|
||||
.. sourcecode:: rest
|
||||
|
||||
.. heading hierarchy:
|
||||
------------- Chapter
|
||||
************* Section (#.#)
|
||||
============= Subsection (#.#.#)
|
||||
############# Sub-subsection
|
||||
|
||||
* Syntax Highlighting:
|
||||
|
||||
To use the default syntax highlighter, simply start a sourcecode block:
|
||||
|
||||
+--------------------------------------+------------------------------------+
|
||||
| Sphinx Source | Rendered Output |
|
||||
+======================================+====================================+
|
||||
| .. sourcecode:: rest | |
|
||||
| | |
|
||||
| The ``Frobnitz`` is accessed by:: | The ``Frobnitz`` is accessed by:: |
|
||||
| | |
|
||||
| Foo::Frobnitz frob; | Foo::Frobnitz frob; |
|
||||
| frob.Set (...); | frob.Set (...); |
|
||||
+--------------------------------------+------------------------------------+
|
||||
|
||||
To use a specific syntax highlighter, for example, ``bash`` shell commands:
|
||||
|
||||
+--------------------------------------+------------------------------------+
|
||||
| Sphinx Source | Rendered Output |
|
||||
+======================================+====================================+
|
||||
| .. sourcecode:: rest | |
|
||||
| | |
|
||||
| .. sourcecode:: bash | .. sourcecode:: bash |
|
||||
| | |
|
||||
| $ ls | $ ls |
|
||||
+--------------------------------------+------------------------------------+
|
||||
|
||||
* Shorthand Notations:
|
||||
|
||||
These shorthands are defined:
|
||||
|
||||
+--------------------------------------+------------------------------------+
|
||||
| Sphinx Source | Rendered Output |
|
||||
+======================================+====================================+
|
||||
| .. sourcecode:: rest | |
|
||||
| | |
|
||||
| |ns3| | |ns3| |
|
||||
+--------------------------------------+------------------------------------+
|
||||
| .. sourcecode:: rest | |
|
||||
| | |
|
||||
| |ns2| | |ns2| |
|
||||
+--------------------------------------+------------------------------------+
|
||||
| .. sourcecode:: rest | |
|
||||
| | |
|
||||
| |check| | |check| |
|
||||
+--------------------------------------+------------------------------------+
|
||||
| .. sourcecode:: rest | |
|
||||
| | |
|
||||
| :rfc:`6282` | :rfc:`6282` |
|
||||
+--------------------------------------+------------------------------------+
|
||||
|
||||
|
||||
Documenting with Doxygen
|
||||
************************
|
||||
|
||||
We use Doxygen_ to generate browsable_ API documentation. Doxygen
|
||||
provides a number of useful features:
|
||||
|
||||
* Summary table of all class members.
|
||||
* Graphs of inheritance and collaboration for all classes.
|
||||
* Links to the source code imlementing each function.
|
||||
* Links to every place a member is used.
|
||||
* Links to every object used in implementing a function.
|
||||
* Grouping of related classes, such as all the classes related to
|
||||
a specific protocol.
|
||||
|
||||
In addition, we use the ``TypeId`` system to add to the documentation
|
||||
for every class
|
||||
|
||||
* The ``Config`` paths by which such objects can be reached.
|
||||
* Documentation for any ``Attributes``, including ``Attributes``
|
||||
defined in parent classes.
|
||||
* Documentation for any ``Trace`` sources defined by the class.
|
||||
|
||||
Doxygen operates by scaning the source code, looking for
|
||||
specially marked comments. It also creates a cross reference,
|
||||
indicating *where* each file, class, method, and variable is used.
|
||||
|
||||
.. _browsable: https://www.nsnam.org/docs/doxygen
|
||||
|
||||
|
||||
Preferred Style
|
||||
===============
|
||||
|
||||
The preferred style for Doxygen comments is the JavaDoc style::
|
||||
|
||||
/**
|
||||
* Brief description of this class or method.
|
||||
* Adjacent lines become a single paragraph.
|
||||
*
|
||||
* Longer description, with lots of details.
|
||||
*
|
||||
* Blank lines separate paragraphs.
|
||||
*
|
||||
* Explain what the class or method does, using what algorithm.
|
||||
* Explain the units of arguments and return values.
|
||||
*
|
||||
* \note Note any limitations or gotchas.
|
||||
*
|
||||
* (For functions with arguments or return valued:)
|
||||
* \param foo Brief noun phrase describing this argument.
|
||||
* \param bar Note Sentence case, and terminating period.
|
||||
* \return Brief noun phrase describing the value.
|
||||
*
|
||||
* \internal
|
||||
*
|
||||
* You can also discuss internal implementation details.
|
||||
* Understanding this material shouldn't be necessary to using
|
||||
* the class or method.
|
||||
*/
|
||||
class Example
|
||||
|
||||
In this style the Doxygen comment block begins with two \`*' characters:
|
||||
``/**``, and precedes the item being documented.
|
||||
|
||||
For items needing only a brief description, either of these short forms
|
||||
is appropriate::
|
||||
|
||||
/** Destructor implementation. */
|
||||
void DoDispose ();
|
||||
|
||||
int m_count; //!< Count of ...
|
||||
|
||||
Note the special form of the end of line comment, ``//!<``, indicating
|
||||
that it refers to the *preceding* item.
|
||||
|
||||
Some items to note:
|
||||
|
||||
* Use sentence case, including the initial capital.
|
||||
* Use punctuation, especially \`.'s at the end of sentences or phrases.
|
||||
* The ``\brief`` tag is not needed; the first sentence will be
|
||||
used as the brief description.
|
||||
|
||||
Every class, method, typedef, member variable, function argument
|
||||
and return value should be documented in all source code files
|
||||
which form the formal API and implementation for |ns3|, such as
|
||||
``src/<module>/model/*``, ``src/<module>/helper/*`` and
|
||||
``src/<module>/utils/*``. Documentation for items in ``src/<module>/test/*``
|
||||
and ``src/<module>/examples/*`` is preferred, but not required.
|
||||
|
||||
Useful Features
|
||||
===============
|
||||
|
||||
* Inherited members will automatically inherit docs from the parent,
|
||||
(but can be replaced by local documentation).
|
||||
|
||||
#. Document the base class.
|
||||
#. In the sub class mark inherited functions with an ordinary comment::
|
||||
|
||||
// Inherited methods
|
||||
virtual void FooBar (void);
|
||||
virtual int BarFoo (double baz);
|
||||
|
||||
Note that the signatures have to match exactly, so include the formal
|
||||
argument ``(void)``
|
||||
|
||||
This doesn't work for static functions; see ``GetTypeId``, below, for an
|
||||
example.
|
||||
|
||||
Building Doxygen Docs
|
||||
=====================
|
||||
|
||||
Building the Doxygen documentation is pretty simple:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf doxygen
|
||||
|
||||
This builds using the default configuration, which generates documentation
|
||||
sections for *all* items, even if they do not have explicit comment
|
||||
documentation blocks. This has the effect of suppressing warnings for
|
||||
undocumented items, but makes sure everything appears in the generated
|
||||
output.
|
||||
|
||||
When writing documentation, it's often more useful to see which items
|
||||
are generating warnings, typically about missing documentation.
|
||||
To see the full warnings list, use the ``doc/doxygen.warnings.report.sh``
|
||||
script:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ doc/doxygen.warnings.report.sh
|
||||
Waf: Entering directory `build'
|
||||
...
|
||||
Waf: Leaving directory `build'
|
||||
'build' finished successfully (3m24.094s)
|
||||
|
||||
Rebuilding doxygen docs with full errors...Done.
|
||||
|
||||
|
||||
Report of Doxygen warnings
|
||||
----------------------------------------
|
||||
|
||||
(All counts are lower bounds.)
|
||||
|
||||
Warnings by module/directory:
|
||||
|
||||
Count Directory
|
||||
----- ----------------------------------
|
||||
3844 src/lte/model
|
||||
1718 src/wimax/model
|
||||
1423 src/core/model
|
||||
....
|
||||
138 additional undocumented parameters.
|
||||
----------------------------------------
|
||||
15765 total warnings
|
||||
126 directories with warnings
|
||||
|
||||
|
||||
Warnings by file (alphabetical)
|
||||
|
||||
Count File
|
||||
----- ----------------------------------
|
||||
17 doc/introspected-doxygen.h
|
||||
15 examples/routing/manet-routing-compare.cc
|
||||
26 examples/stats/wifi-example-apps.h
|
||||
....
|
||||
----------------------------------------
|
||||
967 files with warnings
|
||||
|
||||
|
||||
Warnings by file (numerical)
|
||||
|
||||
Count File
|
||||
----- ----------------------------------
|
||||
374 src/lte/model/lte-asn1-header.h
|
||||
280 src/lte/model/lte-rrc-sap.h
|
||||
262 src/lte/model/lte-rrc-header.h
|
||||
....
|
||||
----------------------------------------
|
||||
967 files with warnings
|
||||
|
||||
|
||||
Doxygen Warnings Summary
|
||||
----------------------------------------
|
||||
126 directories
|
||||
967 files
|
||||
15765 warnings
|
||||
|
||||
The script modifies the configuration to show all warnings, and
|
||||
to shorten the run time. As you can see, at this writing we have
|
||||
*a lot* of undocumented items. The report summarizes warnings
|
||||
by module ``src/*/*``, and by file, in alphabetically and numerical
|
||||
order.
|
||||
|
||||
The script has a few options to pare things down and make this more
|
||||
manageable. For help, use the ``-h`` option. Having run it once
|
||||
to do the Doxygen build and generate the full warnings log,
|
||||
you can reprocess the log file with various "filters,"
|
||||
without having to do the full Doxygen build by,
|
||||
again using the ``-s`` option. You can exclude warnings
|
||||
from ``*/examples/*`` files (``-e`` option), and/or ``*/test/*`` files
|
||||
(``-t``).
|
||||
|
||||
Perhaps the most useful option when writing documentation comments
|
||||
is ``-m <module>``, which will limit the report to just files matching
|
||||
``src/<module>/*``, and follow the report with the actual warning lines.
|
||||
Combine with ``-et`` and you can focus on the warnings that are most
|
||||
urgent in a single module:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ doc/doxygen.warnings.report.sh -m mesh/helper
|
||||
...
|
||||
Doxygen Warnings Summary
|
||||
----------------------------------------
|
||||
1 directories
|
||||
3 files
|
||||
149 warnings
|
||||
|
||||
|
||||
Filtered Warnings
|
||||
========================================
|
||||
src/mesh/helper/dot11s/dot11s-installer.h:72: warning: Member m_root (variable) of class ns3::Dot11sStack is not documented.
|
||||
src/mesh/helper/dot11s/dot11s-installer.h:35: warning: return type of member ns3::Dot11sStack::GetTypeId is not documented
|
||||
src/mesh/helper/dot11s/dot11s-installer.h:56: warning: return type of member ns3::Dot11sStack::InstallStack is not documented
|
||||
src/mesh/helper/flame/flame-installer.h:40: warning: Member GetTypeId() (function) of class ns3::FlameStack is not documented.
|
||||
src/mesh/helper/flame/flame-installer.h:60: warning: return type of member ns3::FlameStack::InstallStack is not documented
|
||||
src/mesh/helper/mesh-helper.h:213: warning: Member m_nInterfaces (variable) of class ns3::MeshHelper is not documented.
|
||||
src/mesh/helper/mesh-helper.h:214: warning: Member m_spreadChannelPolicy (variable) of class ns3::MeshHelper is not documented.
|
||||
src/mesh/helper/mesh-helper.h:215: warning: Member m_stack (variable) of class ns3::MeshHelper is not documented.
|
||||
src/mesh/helper/mesh-helper.h:216: warning: Member m_stackFactory (variable) of class ns3::MeshHelper is not documented.
|
||||
src/mesh/helper/mesh-helper.h:209: warning: parameters of member ns3::MeshHelper::CreateInterface are not (all) documented
|
||||
src/mesh/helper/mesh-helper.h:119: warning: parameters of member ns3::MeshHelper::SetStandard are not (all) documented
|
||||
|
||||
|
||||
Now it's just a matter of understanding the code, and writing some
|
||||
docs!
|
||||
|
||||
|
||||
|
||||
|ns3| Specifics
|
||||
===============
|
||||
|
||||
As for Sphinx, the Doxygen docs_ and reference_ are pretty good.
|
||||
We won't duplicate the basics here, instead focusing on preferred
|
||||
usage for |ns3|.
|
||||
|
||||
.. _docs: http://www.stack.nl/~dimitri/doxygen/index.html
|
||||
.. _reference: http://www.stack.nl/~dimitri/doxygen/manual/commands.html
|
||||
|
||||
|
||||
* Use Doxygen ``Modules`` to group related items.
|
||||
|
||||
In the main header for a module, create a Doxgyen group::
|
||||
|
||||
/**
|
||||
* \defgroup foo Foo protocol.
|
||||
*/
|
||||
|
||||
Mark each associated class as belonging to the group::
|
||||
|
||||
/**
|
||||
* \ingroup foo
|
||||
*
|
||||
* Foo packet type.
|
||||
*/
|
||||
class Foo
|
||||
|
||||
* Copy the ``Attribute`` help strings from the ``GetTypeId`` method to use
|
||||
as the brief descriptions of associated members.
|
||||
|
||||
* ``\bugid{298}`` will create a link to bug 298 in our Bugzilla.
|
||||
|
||||
* ``\pname{foo}`` in a description will format ``foo``
|
||||
as a ``\param foo`` parameter, making it clear that you
|
||||
are referring to an actual argument.
|
||||
|
||||
* ``\RFC{301}`` will create a link to RFC 301.
|
||||
|
||||
* ``\internal`` should be used only to set off a discussion of implementation
|
||||
details, not to mark ``private`` functions (they are already marked,
|
||||
as ``private``!)
|
||||
|
||||
* Don't create classes with trivial names, such as ``class A``,
|
||||
even in test suites. These cause all instances of the class name
|
||||
literal \`A' to be rendered as links.
|
||||
|
||||
|
||||
As noted above, static functions don't inherit the documentation
|
||||
of the same functions in the parent class. |ns3| uses a few static
|
||||
functions ubiquitously; the suggested documentation block for these
|
||||
cases is:
|
||||
|
||||
* Default constructor/destructor::
|
||||
|
||||
MyClass (); //!< Default constructor
|
||||
~MyClass (); //!< Destructor
|
||||
|
||||
* Dummy destructor and DoDispose::
|
||||
|
||||
/** Dummy destructor, see DoDispose. */
|
||||
~MyClass ();
|
||||
|
||||
/** Destructor implementation */
|
||||
virtual void DoDispose ();
|
||||
|
||||
* GetTypeId::
|
||||
|
||||
/**
|
||||
* Register this type.
|
||||
* \return The object TypeId.
|
||||
*/
|
||||
static TypeId GetTypeId (void);
|
||||
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: bash
|
||||
|
||||
Enabling Subsets of |ns3| Modules
|
||||
---------------------------------
|
||||
@@ -10,11 +11,15 @@ This chapter discusses how to enable only the |ns3| modules that you are interst
|
||||
How to enable a subset of |ns3|'s modules
|
||||
*****************************************
|
||||
|
||||
If shared libraries are being built, then enabling a module will cause at least one library to be built: ::
|
||||
If shared libraries are being built, then enabling a module will cause at least one library to be built:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
libns3-modulename.so
|
||||
|
||||
If the module has a test library and test libraries are being built, then ::
|
||||
If the module has a test library and test libraries are being built, then
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
libns3-modulename-test.so
|
||||
|
||||
@@ -31,29 +36,37 @@ Enable modules using waf's --enable-modules option
|
||||
To enable only the core module with example and tests, for example,
|
||||
try these commands: ::
|
||||
|
||||
./waf clean
|
||||
./waf configure --enable-examples --enable-tests --enable-modules=core
|
||||
./waf build
|
||||
cd build/debug/
|
||||
ls
|
||||
$ ./waf clean
|
||||
$ ./waf configure --enable-examples --enable-tests --enable-modules=core
|
||||
$ ./waf build
|
||||
$ cd build/debug/
|
||||
$ ls
|
||||
|
||||
and the following libraries should be present: ::
|
||||
and the following libraries should be present:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
bindings libns3-core.so ns3 scratch utils
|
||||
examples libns3-core-test.so samples src
|
||||
|
||||
Note the ``./waf clean`` step is done here only to make it more obvious which module libraries were built. You don't have to do ``./waf clean`` in order to enable subsets of modules.
|
||||
|
||||
Running test.py will cause only those tests that depend on module core to be run: ::
|
||||
Running test.py will cause only those tests that depend on module core to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
24 of 24 tests passed (24 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
Repeat the above steps for the "network" module instead of the "core" module, and the following will be built, since network depends on core: ::
|
||||
Repeat the above steps for the "network" module instead of the "core" module, and the following will be built, since network depends on core:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
bindings libns3-core.so libns3-network.so ns3 scratch utils
|
||||
examples libns3-core-test.so libns3-network-test.so samples src
|
||||
|
||||
Running test.py will cause those tests that depend on only the core and network modules to be run: ::
|
||||
Running test.py will cause those tests that depend on only the core and network modules to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
31 of 31 tests passed (31 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
@@ -74,9 +87,11 @@ The maintained version of the .ns3rc file in the |ns3| source code repository re
|
||||
|
||||
Assuming that you are in the top level |ns3| directory, you can get a copy of the .ns3rc file that is in the ``utils`` directory as follows: ::
|
||||
|
||||
cp utils/.ns3rc .
|
||||
$ cp utils/.ns3rc .
|
||||
|
||||
The .ns3rc file should now be in your top level |ns3| directory, and it contains the following: ::
|
||||
The .ns3rc file should now be in your top level |ns3| directory, and it contains the following:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
#! /usr/bin/env python
|
||||
|
||||
@@ -92,7 +107,9 @@ The .ns3rc file should now be in your top level |ns3| directory, and it contains
|
||||
# Set this equal to true if you want tests to be run.
|
||||
tests_enabled = False
|
||||
|
||||
Use your favorite editor to modify the .ns3rc file to only enable the core module with examples and tests like this: ::
|
||||
Use your favorite editor to modify the .ns3rc file to only enable the core module with examples and tests like this:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
#! /usr/bin/env python
|
||||
|
||||
@@ -110,28 +127,36 @@ Use your favorite editor to modify the .ns3rc file to only enable the core modul
|
||||
|
||||
Only the core module will be enabled now if you try these commands: ::
|
||||
|
||||
./waf clean
|
||||
./waf configure
|
||||
./waf build
|
||||
cd build/debug/
|
||||
ls
|
||||
$ ./waf clean
|
||||
$ ./waf configure
|
||||
$ ./waf build
|
||||
$ cd build/debug/
|
||||
$ ls
|
||||
|
||||
and the following libraries should be present: ::
|
||||
and the following libraries should be present:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
bindings libns3-core.so ns3 scratch utils
|
||||
examples libns3-core-test.so samples src
|
||||
|
||||
Note the ``./waf clean`` step is done here only to make it more obvious which module libraries were built. You don't have to do ``./waf clean`` in order to enable subsets of modules.
|
||||
|
||||
Running test.py will cause only those tests that depend on module core to be run: ::
|
||||
Running test.py will cause only those tests that depend on module core to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
24 of 24 tests passed (24 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
Repeat the above steps for the "network" module instead of the "core" module, and the following will be built, since network depends on core: ::
|
||||
Repeat the above steps for the "network" module instead of the "core" module, and the following will be built, since network depends on core:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
bindings libns3-core.so libns3-network.so ns3 scratch utils
|
||||
examples libns3-core-test.so libns3-network-test.so samples src
|
||||
|
||||
Running test.py will cause those tests that depend on only the core and network modules to be run: ::
|
||||
Running test.py will cause those tests that depend on only the core and network modules to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
31 of 31 tests passed (31 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: bash
|
||||
|
||||
|
||||
Enabling/disabling |ns3| Tests and Examples
|
||||
-------------------------------------------
|
||||
@@ -26,18 +28,22 @@ By default, examples and tests are not built in |ns3|.
|
||||
From the ns-3-allinone directory, you can build |ns3| without any
|
||||
examples or tests simply by doing: ::
|
||||
|
||||
./build.py
|
||||
$ ./build.py
|
||||
|
||||
Running test.py in the top level |ns3| directory now will cause no examples or tests to be run: ::
|
||||
Running test.py in the top level |ns3| directory now will cause no examples or tests to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
0 of 0 tests passed (0 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
If you would like build |ns3| with examples and tests, then do the following from the ns-3-allinone directory: ::
|
||||
|
||||
./build.py --enable-examples --enable-tests
|
||||
$ ./build.py --enable-examples --enable-tests
|
||||
|
||||
Running test.py in the top level |ns3| directory will cause all of the examples and tests to be run: ::
|
||||
Running test.py in the top level |ns3| directory will cause all of the examples and tests to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
170 of 170 tests passed (170 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
Enable/disable examples and tests using waf
|
||||
@@ -50,20 +56,24 @@ By default, examples and tests are not built in |ns3|.
|
||||
From the top level |ns3| directory, you can build |ns3| without any
|
||||
examples or tests simply by doing: ::
|
||||
|
||||
./waf configure
|
||||
./waf build
|
||||
$ ./waf configure
|
||||
$ ./waf build
|
||||
|
||||
Running test.py now will cause no examples or tests to be run: ::
|
||||
Running test.py now will cause no examples or tests to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
0 of 0 tests passed (0 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
If you would like build |ns3| with examples and tests, then do the following from the top level |ns3| directory: ::
|
||||
|
||||
./waf configure --enable-examples --enable-tests
|
||||
./waf build
|
||||
$ ./waf configure --enable-examples --enable-tests
|
||||
$ ./waf build
|
||||
|
||||
Running test.py will cause all of the examples and tests to be run: ::
|
||||
Running test.py will cause all of the examples and tests to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
170 of 170 tests passed (170 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
Enable/disable examples and tests using the |ns3| configuration file
|
||||
@@ -84,9 +94,11 @@ The maintained version of the .ns3rc file in the |ns3| source code repository re
|
||||
|
||||
Assuming that you are in the top level |ns3| directory, you can get a copy of the .ns3rc file that is in the ``utils`` directory as follows: ::
|
||||
|
||||
cp utils/.ns3rc .
|
||||
$ cp utils/.ns3rc .
|
||||
|
||||
The .ns3rc file should now be in your top level |ns3| directory, and it contains the following: ::
|
||||
The .ns3rc file should now be in your top level |ns3| directory, and it contains the following:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
#! /usr/bin/env python
|
||||
|
||||
@@ -105,16 +117,20 @@ The .ns3rc file should now be in your top level |ns3| directory, and it contains
|
||||
From the top level |ns3| directory, you can build |ns3| without any
|
||||
examples or tests simply by doing: ::
|
||||
|
||||
./waf configure
|
||||
./waf build
|
||||
$ ./waf configure
|
||||
$ ./waf build
|
||||
|
||||
Running test.py now will cause no examples or tests to be run: ::
|
||||
Running test.py now will cause no examples or tests to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
0 of 0 tests passed (0 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
If you would like build |ns3| with examples and tests, use your
|
||||
favorite editor to change the values in the .ns3rc file for
|
||||
examples_enabled and tests_enabled file to be True: ::
|
||||
examples_enabled and tests_enabled file to be True:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
#! /usr/bin/env python
|
||||
|
||||
@@ -133,9 +149,11 @@ examples_enabled and tests_enabled file to be True: ::
|
||||
From the top level |ns3| directory, you can build |ns3| with examples
|
||||
and tests simply by doing: ::
|
||||
|
||||
./waf configure
|
||||
./waf build
|
||||
$ ./waf configure
|
||||
$ ./waf build
|
||||
|
||||
Running test.py will cause all of the examples and tests to be run: ::
|
||||
Running test.py will cause all of the examples and tests to be run:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
170 of 170 tests passed (170 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
@@ -1,4 +1,6 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
|
||||
.. heading hierarchy:
|
||||
------------- Chapter
|
||||
@@ -42,7 +44,7 @@ Simulator
|
||||
The Simulator class is the public entry point to access event scheduling
|
||||
facilities. Once a couple of events have been scheduled to start the
|
||||
simulation, the user can start to execute them by entering the simulator
|
||||
main loop (call Simulator::Run). Once the main loop starts running, it
|
||||
main loop (call ``Simulator::Run``). Once the main loop starts running, it
|
||||
will sequentially execute all scheduled events in order from oldest to
|
||||
most recent until there are either no more events left in the event
|
||||
queue or Simulator::Stop has been called.
|
||||
@@ -70,7 +72,7 @@ might write this:
|
||||
|
||||
Which will output:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
handler called with argument arg0=10 and arg1=5
|
||||
|
||||
@@ -153,11 +155,11 @@ In some very rare cases, developers might need to modify or understand
|
||||
how the context (node id) of the first event is set to that of its
|
||||
associated node. This is accomplished by the NodeList class: whenever a
|
||||
new node is created, the NodeList class uses ScheduleWithContext to
|
||||
schedule a 'start' event for this node. The 'start' event thus executes
|
||||
schedule a 'initialize' event for this node. The 'initialize' event thus executes
|
||||
with a context set to that of the node id and can use the normal variety
|
||||
of Schedule methods. It invokes the Node::Start method which propagates
|
||||
the 'start' event by calling the DoStart method for each object
|
||||
associated with the node. The DoStart method overridden in some of these
|
||||
of Schedule methods. It invokes the Node::Initialize method which propagates
|
||||
the 'initialize' event by calling the DoInitialize method for each object
|
||||
associated with the node. The DoInitialize method overridden in some of these
|
||||
objects (most notably in the Application base class) will schedule some
|
||||
events (most notably Application::StartApplication) which will in turn
|
||||
scheduling traffic generation events which will in turn schedule
|
||||
@@ -165,8 +167,8 @@ network-level events.
|
||||
|
||||
Notes:
|
||||
|
||||
* Users need to be careful to propagate DoStart methods across objects
|
||||
by calling Start explicitely on their member objects
|
||||
* Users need to be careful to propagate DoInitialize methods across objects
|
||||
by calling Initialize explicitely on their member objects
|
||||
* The context id associated with each ScheduleWithContext method has
|
||||
other uses beyond logging: it is used by an experimental branch of ns-3
|
||||
to perform parallel simulation on multicore systems using
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
.. include:: replace.txt
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
Making Plots using the Gnuplot Class
|
||||
------------------------------------
|
||||
|
||||
@@ -25,39 +26,51 @@ See the code from the example plots that are discussed below for details on step
|
||||
An Example Program that Uses the Gnuplot Class
|
||||
**********************************************
|
||||
|
||||
An example program that uses |ns3|'s Gnuplot class can be found here: ::
|
||||
An example program that uses |ns3|'s Gnuplot class can be found here:
|
||||
|
||||
src/tools/examples/gnuplot-example.cc
|
||||
.. sourcecode:: bash
|
||||
|
||||
In order to run this example, do the following: ::
|
||||
src/stats/examples/gnuplot-example.cc
|
||||
|
||||
./waf shell
|
||||
cd build/debug/src/tools/examples
|
||||
./gnuplot-example
|
||||
In order to run this example, do the following:
|
||||
|
||||
This should produce the following gnuplot control files in the directory where the example is located: ::
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf shell
|
||||
$ cd build/debug/src/stats/examples
|
||||
$ ./gnuplot-example
|
||||
|
||||
This should produce the following gnuplot control files in the directory where the example is located:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
plot-2d.plt
|
||||
plot-2d-with-error-bars.plt
|
||||
plot-3d.plt
|
||||
|
||||
In order to process these gnuplot control files, do the following: ::
|
||||
In order to process these gnuplot control files, do the following:
|
||||
|
||||
gnuplot plot-2d.plt
|
||||
gnuplot plot-2d-with-error-bars.plt
|
||||
gnuplot plot-3d.plt
|
||||
.. sourcecode:: bash
|
||||
|
||||
This should produce the following graphics files in the directory where the example is located: ::
|
||||
$ gnuplot plot-2d.plt
|
||||
$ gnuplot plot-2d-with-error-bars.plt
|
||||
$ gnuplot plot-3d.plt
|
||||
|
||||
This should produce the following graphics files in the directory where the example is located:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
plot-2d.png
|
||||
plot-2d-with-error-bars.png
|
||||
plot-3d.png
|
||||
|
||||
You can view these graphics files in your favorite graphics viewer. If you have gimp installed on your machine, for example, you can do this: ::
|
||||
You can view these graphics files in your favorite graphics viewer. If you have gimp installed on your machine, for example, you can do this:
|
||||
|
||||
gimp plot-2d.png
|
||||
gimp plot-2d-with-error-bars.png
|
||||
gimp plot-3d.png
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ gimp plot-2d.png
|
||||
$ gimp plot-2d-with-error-bars.png
|
||||
$ gimp plot-3d.png
|
||||
|
||||
An Example 2-Dimensional Plot
|
||||
*****************************
|
||||
|
||||
@@ -0,0 +1,118 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Hash Functions
|
||||
----------------
|
||||
|
||||
|ns3| provides a generic interface to general purpose hash functions.
|
||||
In the simplest usage, the hash function returns the 32-bit or 64-bit
|
||||
hash of a data buffer or string. The default underlying hash function
|
||||
is murmur3_, chosen because it has good hash function properties and
|
||||
offers a 64-bit version. The venerable FNV1a_ hash is also available.
|
||||
|
||||
There is a straight-forward mechanism to
|
||||
add (or provide at run time) alternative hash function implementations.
|
||||
|
||||
.. _murmur3: http://code.google.com/p/smhasher/wiki/MurmurHash3
|
||||
.. _FNV1a: http://isthe.com/chongo/tech/comp/fnv/
|
||||
|
||||
Basic Usage
|
||||
***********
|
||||
|
||||
The simplest way to get a hash value of a data buffer or string is just::
|
||||
|
||||
#include "ns3/hash.h"
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
char * buffer = ...
|
||||
size_t buffer_size = ...
|
||||
|
||||
uint32_t buffer_hash = Hash32 ( buffer, buffer_size);
|
||||
|
||||
std::string s;
|
||||
uint32_t string_hash = Hash32 (s);
|
||||
|
||||
Equivalent functions are defined for 64-bit hash values.
|
||||
|
||||
Incremental Hashing
|
||||
*******************
|
||||
|
||||
In some situations it's useful to compute the hash of multiple buffers,
|
||||
as if they had been joined together. (For example, you might want
|
||||
the hash of a packet stream, but not want to assemble a single buffer
|
||||
with the combined contents of all the packets.)
|
||||
|
||||
This is almost as straight-forward as the first example::
|
||||
|
||||
#include "ns3/hash.h"
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
char * buffer;
|
||||
size_t buffer_size;
|
||||
|
||||
Hasher hasher; // Use default hash function
|
||||
|
||||
for (<every buffer>)
|
||||
{
|
||||
buffer = get_next_buffer ();
|
||||
hasher (buffer, buffer_size);
|
||||
}
|
||||
uint32_t combined_hash = hasher.GetHash32 ();
|
||||
|
||||
By default ``Hasher`` preserves internal state to enable incremental
|
||||
hashing. If you want to reuse a ``Hasher`` object (for example
|
||||
because it's configured with a non-default hash function), but don't
|
||||
want to add to the previously computed hash, you need to ``clear()``
|
||||
first::
|
||||
|
||||
hasher.clear ().GetHash32 (buffer, buffer_size);
|
||||
|
||||
This reinitializes the internal state before hashing the buffer.
|
||||
|
||||
|
||||
Using an Alternative Hash Function
|
||||
**********************************
|
||||
|
||||
The default hash function is murmur3_. FNV1a_ is also available. To specify
|
||||
the hash function explicitly, use this contructor::
|
||||
|
||||
Hasher hasher = Hasher ( Create<Hash::Function::Fnv1a> () );
|
||||
|
||||
|
||||
Adding New Hash Function Implementations
|
||||
****************************************
|
||||
|
||||
To add the hash function ``foo``, follow the ``hash-murmur3.h``/``.cc`` pattern:
|
||||
|
||||
* Create a class declaration (``.h``) and definition (``.cc``) inheriting
|
||||
from ``Hash::Implementation``.
|
||||
* ``include`` the declaration in ``hash.h`` (at the point where
|
||||
``hash-murmur3.h`` is included.
|
||||
* In your own code, instantiate a ``Hasher`` object via the constructor
|
||||
``Hasher (Ptr<Hash::Function::Foo> ())``
|
||||
|
||||
|
||||
If your hash function is a single function, e.g. ``hashf``, you don't
|
||||
even need to create a new class derived from HashImplementation::
|
||||
|
||||
Hasher hasher =
|
||||
Hasher ( Create<Hash::Function::Hash32> (&hashf) );
|
||||
|
||||
For this to compile, your ``hashf`` has to match one of the function pointer
|
||||
signatures::
|
||||
|
||||
typedef uint32_t (*Hash32Function_ptr) (const char *, const size_t);
|
||||
typedef uint64_t (*Hash64Function_ptr) (const char *, const size_t);
|
||||
|
||||
|
||||
Sources for Hash Functions
|
||||
**************************
|
||||
|
||||
Sources for other hash function implementations include:
|
||||
|
||||
* Peter Kankowski: http://www.strchr.com
|
||||
* Arash Partow: http://www.partow.net/programming/hashfunctions/index.html
|
||||
* SMHasher: http://code.google.com/p/smhasher/
|
||||
* Sanmayce: http://www.sanmayce.com/Fastest_Hash/index.html
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Helpers
|
||||
-------
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
How to write tests
|
||||
------------------
|
||||
@@ -46,7 +47,7 @@ more descriptive test case name.
|
||||
You also need to add a block into your wscript to get this test to
|
||||
compile:
|
||||
|
||||
::
|
||||
.. sourcecode:: python
|
||||
|
||||
module_test.source = [
|
||||
'test/router-test-suite.cc',
|
||||
@@ -64,13 +65,13 @@ is called "router" such as here:
|
||||
|
||||
Try this command:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./test.py -s router
|
||||
$ ./test.py -s router
|
||||
|
||||
Output such as below should be produced:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
PASS: TestSuite router
|
||||
1 of 1 tests passed (1 passed, 0 skipped, 0 failed, 0 crashed, 0 valgrind errors)
|
||||
|
||||
@@ -8,7 +8,7 @@ available in five forms:
|
||||
|
||||
* `ns-3 Doxygen <http://www.nsnam.org/doxygen/index.html>`_: Documentation of the public APIs of the simulator
|
||||
* Tutorial, Manual *(this document)*, and Model Library for the `latest release <http://www.nsnam.org/documentation/latest/>`_ and `development tree <http://www.nsnam.org/ns-3-dev/documentation/>`_
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/index.php/Main_Page>`_
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/Main_Page>`_
|
||||
|
||||
This document is written in `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ for `Sphinx <http://sphinx.pocoo.org/>`_ and is maintained in the
|
||||
``doc/manual`` directory of ns-3's source code.
|
||||
@@ -18,6 +18,7 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
|
||||
|
||||
organization
|
||||
random-variables
|
||||
hash-functions
|
||||
events
|
||||
callbacks
|
||||
object-model
|
||||
@@ -25,6 +26,8 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
|
||||
object-names
|
||||
logging
|
||||
tracing
|
||||
data-collection
|
||||
statistics
|
||||
realtime
|
||||
helpers
|
||||
gnuplot
|
||||
|
||||
@@ -1,7 +1,429 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
.. heading hierarchy:
|
||||
------------- Chapter
|
||||
************* Section (#.#)
|
||||
============= Subsection (#.#.#)
|
||||
############# Paragraph (no number)
|
||||
|
||||
Logging
|
||||
-------
|
||||
|
||||
*This chapter not yet written. For now, the ns-3 tutorial contains logging
|
||||
information.*
|
||||
The |ns3| logging facility can be used to monitor or debug the progress
|
||||
of simulation programs. Logging output can be enabled by program statements
|
||||
in your ``main()`` program or by the use of the ``NS_LOG`` environment variable.
|
||||
|
||||
Logging statements are not compiled into optimized builds of |ns3|. To use
|
||||
logging, one must build the (default) debug build of |ns3|.
|
||||
|
||||
The project makes no guarantee about whether logging output will remain
|
||||
the same over time. Users are cautioned against building simulation output
|
||||
frameworks on top of logging code, as the output and the way the output
|
||||
is enabled may change over time.
|
||||
|
||||
Overview
|
||||
********
|
||||
|
||||
|ns3| logging statements are typically used to log various program
|
||||
execution events, such as the occurrence of simulation events or the
|
||||
use of a particular function.
|
||||
|
||||
For example, this code snippet is from ``Ipv4L3Protocol::IsDestinationAddress()``::
|
||||
|
||||
if (address == iaddr.GetBroadcast ())
|
||||
{
|
||||
NS_LOG_LOGIC ("For me (interface broadcast address)");
|
||||
return true;
|
||||
}
|
||||
|
||||
If logging has been enabled for the ``Ipv4L3Protocol`` component at a severity
|
||||
of ``LOGIC`` or above (see below about log severity), the statement
|
||||
will be printed out; otherwise, it will be suppressed.
|
||||
|
||||
Enabling Output
|
||||
===============
|
||||
|
||||
There are two ways that users typically control log output. The
|
||||
first is by setting the ``NS_LOG`` environment variable; e.g.:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="*" ./waf --run first
|
||||
|
||||
will run the ``first`` tutorial program with all logging output. (The
|
||||
specifics of the ``NS_LOG`` format will be discussed below.)
|
||||
|
||||
This can be made more granular by selecting individual components:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="Ipv4L3Protocol" ./waf --run first
|
||||
|
||||
The output can be further tailored with prefix options.
|
||||
|
||||
The second way to enable logging is to use explicit statements in your
|
||||
program, such as in the ``first`` tutorial program::
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
LogComponentEnable ("UdpEchoClientApplication", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("UdpEchoServerApplication", LOG_LEVEL_INFO);
|
||||
...
|
||||
|
||||
(The meaning of ``LOG_LEVEL_INFO``, and other possible values,
|
||||
will be discussed below.)
|
||||
|
||||
``NS_LOG`` Syntax
|
||||
=================
|
||||
|
||||
The ``NS_LOG`` environment variable contains a list of log components
|
||||
and options. Log components are separated by \`:' characters:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="<log-component>:<log-component>..."
|
||||
|
||||
Options for each log component are given as flags after
|
||||
each log component:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="<log-component>=<option>|<option>...:<log-component>..."
|
||||
|
||||
Options control the severity and level for that component,
|
||||
and whether optional information should be included, such as the
|
||||
simulation time, simulation node, function name, and the symbolic severity.
|
||||
|
||||
Log Components
|
||||
==============
|
||||
|
||||
Generally a log component refers to a single source code ``.cc`` file,
|
||||
and encompasses the entire file.
|
||||
|
||||
Some helpers have special methods to enable the logging of all components
|
||||
in a module, spanning different compilation units, but logically grouped
|
||||
together, such as the |ns3| wifi code::
|
||||
|
||||
WifiHelper wifiHelper;
|
||||
wifiHelper.EnableLogComponents ();
|
||||
|
||||
The ``NS_LOG`` log component wildcard \`*' will enable all components.
|
||||
|
||||
To see what log components are defined, any of these will work:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="print-list" ./waf --run ...
|
||||
|
||||
$ NS_LOG="foo" # a token not matching any log-component
|
||||
|
||||
The first form will print the name and enabled flags for all log components
|
||||
which are linked in; try it with ``scratch-simulator``.
|
||||
The second form prints all registered log components,
|
||||
then exit with an error.
|
||||
|
||||
|
||||
Severity and Level Options
|
||||
==========================
|
||||
|
||||
Individual messages belong to a single "severity class," set by the macro
|
||||
creating the message. In the example above,
|
||||
``NS_LOG_LOGIC(..)`` creates the message in the ``LOG_LOGIC`` severity class.
|
||||
|
||||
The following severity classes are defined as ``enum`` constants:
|
||||
|
||||
================ =====================================
|
||||
Severity Class Meaning
|
||||
================ =====================================
|
||||
``LOG_NONE`` The default, no logging
|
||||
``LOG_ERROR`` Serious error messages only
|
||||
``LOG_WARN`` Warning messages
|
||||
``LOG_DEBUG`` For use in debugging
|
||||
``LOG_INFO`` Informational
|
||||
``LOG_FUNCTION`` Function tracing
|
||||
``LOG_LOGIC`` Control flow tracing within functions
|
||||
================ =====================================
|
||||
|
||||
Typically one wants to see messages at a given severity class *and higher*.
|
||||
This is done by defining inclusive logging "levels":
|
||||
|
||||
====================== ===========================================
|
||||
Level Meaning
|
||||
====================== ===========================================
|
||||
``LOG_LEVEL_ERROR`` Only ``LOG_ERROR`` severity class messages.
|
||||
``LOG_LEVEL_WARN`` ``LOG_WARN`` and above.
|
||||
``LOG_LEVEL_DEBUG`` ``LOG_DEBUG`` and above.
|
||||
``LOG_LEVEL_INFO`` ``LOG_INFO`` and above.
|
||||
``LOG_LEVEL_FUNCTION`` ``LOG_FUNCTION`` and above.
|
||||
``LOG_LEVEL_LOGIC`` ``LOG_LOGIC`` and above.
|
||||
``LOG_LEVEL_ALL`` All severity classes.
|
||||
``LOG_ALL`` Synonym for ``LOG_LEVEL_ALL``
|
||||
====================== ===========================================
|
||||
|
||||
The severity class and level options can be given in the ``NS_LOG``
|
||||
environment variable by these tokens:
|
||||
|
||||
============ =================
|
||||
Class Level
|
||||
============ =================
|
||||
``error`` ``level_error``
|
||||
``warn`` ``level_warn``
|
||||
``debug`` ``level_debug``
|
||||
``info`` ``level_info``
|
||||
``function`` ``level_function``
|
||||
``logic`` ``level_logic``
|
||||
.. | ``level_all``
|
||||
| ``all``
|
||||
| ``*``
|
||||
============ =================
|
||||
|
||||
Using a severity class token enables log messages at that severity only.
|
||||
For example, ``NS_LOG="*=warn"`` won't output messages with severity ``error``.
|
||||
``NS_LOG="*=level_debug"`` will output messages at severity levels
|
||||
``debug`` and above.
|
||||
|
||||
Severity classes and levels can be combined with the \`|' operator:
|
||||
``NS_LOG="*=level_warn|logic"`` will output messages at severity levels
|
||||
``error``, ``warn`` and ``logic``.
|
||||
|
||||
The ``NS_LOG`` severity level wildcard \`*' and ``all``
|
||||
are synonyms for ``level_all``.
|
||||
|
||||
For log components merely mentioned in ``NS_LOG``
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="<log-component>:..."
|
||||
|
||||
the default severity is ``LOG_LEVEL_ALL``.
|
||||
|
||||
|
||||
Prefix Options
|
||||
==============
|
||||
|
||||
A number of prefixes can help identify
|
||||
where and when a message originated, and at what severity.
|
||||
|
||||
The available prefix options (as ``enum`` constants) are
|
||||
|
||||
====================== ===========================================
|
||||
Prefix Symbol Meaning
|
||||
====================== ===========================================
|
||||
``LOG_PREFIX_FUNC`` Prefix the name of the calling function.
|
||||
``LOG_PREFIX_TIME`` Prefix the simulation time.
|
||||
``LOG_PREFIX_NODE`` Prefix the node id.
|
||||
``LOG_PREFIX_LEVEL`` Prefix the severity level.
|
||||
``LOG_PREFIX_ALL`` Enable all prefixes.
|
||||
====================== ===========================================
|
||||
|
||||
The prefix options are described briefly below.
|
||||
|
||||
The options can be given in the ``NS_LOG``
|
||||
environment variable by these tokens:
|
||||
|
||||
================ =========
|
||||
Token Alternate
|
||||
================ =========
|
||||
``prefix_func`` ``func``
|
||||
``prefix_time`` ``time``
|
||||
``prefix_node`` ``node``
|
||||
``prefix_level`` ``level``
|
||||
``prefix_all`` | ``all``
|
||||
| ``*``
|
||||
================ =========
|
||||
|
||||
For log components merely mentioned in ``NS_LOG``
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="<log-component>:..."
|
||||
|
||||
the default prefix options are ``LOG_PREFIX_ALL``.
|
||||
|
||||
Severity Prefix
|
||||
###############
|
||||
|
||||
The severity class of a message can be included with the options
|
||||
``prefix_level`` or ``level``. For example, this value of ``NS_LOG``
|
||||
enables logging for all log components (\`*') and all severity
|
||||
classes (``=all``), and prefixes the message with the severity
|
||||
class (``|prefix_level``).
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="*=all|prefix_level" ./waf --run scratch-simulator
|
||||
Scratch Simulator
|
||||
[ERROR] error message
|
||||
[WARN] warn message
|
||||
[DEBUG] debug message
|
||||
[INFO] info message
|
||||
[FUNCT] function message
|
||||
[LOGIC] logic message
|
||||
|
||||
Time Prefix
|
||||
###########
|
||||
|
||||
The simulation time can be included with the options
|
||||
``prefix_time`` or ``time``. This prints the simulation time in seconds.
|
||||
|
||||
Node Prefix
|
||||
###########
|
||||
|
||||
The simulation node id can be included with the options
|
||||
``prefix_node`` or ``node``.
|
||||
|
||||
Function Prefix
|
||||
###############
|
||||
|
||||
The name of the calling function can be included with the options
|
||||
``prefix_func`` or ``func``.
|
||||
|
||||
|
||||
``NS_LOG`` Wildcards
|
||||
####################
|
||||
|
||||
The log component wildcard \`*' will enable all components. To
|
||||
enable all components at a specific severity level
|
||||
use ``*=<severity>``.
|
||||
|
||||
The severity level option wildcard \`*' is a synonym for ``all``.
|
||||
This must occur before any \`|' characters separating options.
|
||||
To enable all severity classes, use ``<log-component>=*``,
|
||||
or ``<log-component>=*|<options>``.
|
||||
|
||||
The option wildcard \`*' or token ``all`` enables all prefix options,
|
||||
but must occur *after* a \`|' character. To enable a specific
|
||||
severity class or level, and all prefixes, use
|
||||
``<log-component>=<severity>|*``.
|
||||
|
||||
The combined option wildcard ``**`` enables all severities and all prefixes;
|
||||
for example, ``<log-component>=**``.
|
||||
|
||||
The uber-wildcard ``***`` enables all severities and all prefixes
|
||||
for all log components. These are all equivalent:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_LOG="***" ... $ NS_LOG="*=all|*" ... $ NS_LOG="*=*|all" ...
|
||||
$ NS_LOG="*=**" ... $ NS_LOG="*=level_all|*" ... $ NS_LOG="*=*|prefix_all" ...
|
||||
$ NS_LOG="*=*|*" ...
|
||||
|
||||
Be advised: even the trivial ``scratch-simulator`` produces over
|
||||
46K lines of output with ``NS_LOG="***"``!
|
||||
|
||||
|
||||
How to add logging to your code
|
||||
*******************************
|
||||
|
||||
Adding logging to your code is very simple:
|
||||
|
||||
1. Invoke the ``NS_LOG_COMPONENT_DEFINE (...);`` macro
|
||||
outside of ``namespace ns3``.
|
||||
|
||||
Create a unique string identifier (usually based on the name of the file
|
||||
and/or class defined within the file) and register it with a macro call
|
||||
such as follows:
|
||||
|
||||
::
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("Ipv4L3Protocol");
|
||||
|
||||
namespace ns3 {
|
||||
...
|
||||
|
||||
This registers ``Ipv4L3Protocol`` as a log component.
|
||||
|
||||
(The macro was carefully written to permit inclusion either within or
|
||||
outside of namespace ``ns3``, and usage will vary across the codebase, but
|
||||
the original intent was to register this *outside* of namespace ``ns3``
|
||||
at file global scope.)
|
||||
|
||||
2. Add logging statements (macro calls) to your functions and function bodies.
|
||||
|
||||
Logging Macros
|
||||
==============
|
||||
|
||||
The logging macros and associated severity levels are
|
||||
|
||||
================ ==========================
|
||||
Severity Class Macro
|
||||
================ ==========================
|
||||
``LOG_NONE`` (none needed)
|
||||
``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 (...);``
|
||||
``LOG_LOGIC`` ``NS_LOG_LOGIC (...);``
|
||||
================ ==========================
|
||||
|
||||
The macros function as output streamers, so anything you can send to
|
||||
``std::cout``, joined by ``<<`` operators, is allowed::
|
||||
|
||||
void MyClass::Check (int value, char * item)
|
||||
{
|
||||
NS_LOG_FUNCTION (this << arg << item);
|
||||
if (arg > 10)
|
||||
{
|
||||
NS_LOG_ERROR ("encountered bad value " << value <<
|
||||
" while checking " << name << "!");
|
||||
}
|
||||
...
|
||||
}
|
||||
|
||||
Note that ``NS_LOG_FUNCTION`` automatically inserts a \`\ :literal:`,\ `'
|
||||
(comma-space) separator between each of its arguments.
|
||||
This simplifies logging of function arguments;
|
||||
just concatenate them with ``<<`` as in the example above.
|
||||
|
||||
Unconditional Logging
|
||||
=====================
|
||||
|
||||
As a convenience, the ``NS_LOG_UNCOND (...);`` macro will always log its
|
||||
arguments, even if the associated log-component is not enabled at any
|
||||
severity. This macro does not use any of the prefix options. Note that
|
||||
logging is only enabled in debug builds; this macro won't produce
|
||||
output in optimized builds.
|
||||
|
||||
|
||||
Guidelines
|
||||
==========
|
||||
|
||||
* Start every class method with ``NS_LOG_FUNCTION (this << args...);``
|
||||
This enables easy function call tracing.
|
||||
|
||||
* Except: don't log operators or explicit copy constructors,
|
||||
since these will cause infinite recursion and stack overflow.
|
||||
|
||||
* For methods without arguments use the same form:
|
||||
``NS_LOG_FUNCTION (this);``
|
||||
|
||||
* For static functions:
|
||||
|
||||
* With arguments use ``NS_LOG_FUNCTION (...);`` as normal.
|
||||
* Without arguments use ``NS_LOG_FUNCTION_NOARGS ();``
|
||||
|
||||
* Use ``NS_LOG_ERROR`` for serious error conditions that probably
|
||||
invalidate the simulation execution.
|
||||
|
||||
* Use ``NS_LOG_WARN`` for unusual conditions that may be correctable.
|
||||
Please give some hints as to the nature of the problem and how
|
||||
it might be corrected.
|
||||
|
||||
* ``NS_LOG_DEBUG`` is usually used in an *ad hoc* way to understand
|
||||
the execution of a model.
|
||||
|
||||
* Use ``NS_LOG_INFO`` for additional information about the execution,
|
||||
such as the size of a data structure when adding/removing from it.
|
||||
|
||||
* Use ``NS_LOG_LOGIC`` to trace important logic branches within a function.
|
||||
|
||||
* Test that your logging changes do not break the code.
|
||||
Run some example programs with all log components turned on (e.g.
|
||||
``NS_LOG="***"``).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,7 +1,8 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Creating a new ns-3 model
|
||||
-------------------------
|
||||
Creating a new |ns3| model
|
||||
--------------------------
|
||||
|
||||
This chapter walks through the design process of an |ns3| model. In many
|
||||
research cases, users will not be satisfied to merely adapt existing models, but
|
||||
@@ -10,7 +11,16 @@ example of adding an ErrorModel to a simple |ns3| link as a motivating example
|
||||
of how one might approach this problem and proceed through a design and
|
||||
implementation.
|
||||
|
||||
Design-approach
|
||||
.. note:: Documentation
|
||||
|
||||
Here we focus on the process of creating new models
|
||||
and new modules, and some of the design choices involved.
|
||||
For the sake of clarity, we defer discussion of the
|
||||
*mechanics* of documenting models and source code to the
|
||||
:doc:`Documentation <documentation>` chapter.
|
||||
|
||||
|
||||
Design Approach
|
||||
***************
|
||||
|
||||
Consider how you want it to work; what should it do. Think about these things:
|
||||
@@ -25,13 +35,13 @@ Consider how you want it to work; what should it do. Think about these things:
|
||||
should I avoid any dependence on IPv4 if I want it to also be used by IPv6?
|
||||
Should I avoid any dependency on IP at all?
|
||||
|
||||
Do not be hesitant to contact the ns-3-users or ns-developers list if you have
|
||||
Do not be hesitant to contact the `ns-3-users` or `ns-developers` list if you have
|
||||
questions. In particular, it is important to think about the public API of your
|
||||
new model and ask for feedback. It also helps to let others know of your work in
|
||||
case you are interested in collaborators.
|
||||
|
||||
Example: ErrorModel
|
||||
+++++++++++++++++++
|
||||
Example: `ErrorModel`
|
||||
+++++++++++++++++++++
|
||||
|
||||
An error model exists in |ns2|. It allows packets to be passed to a stateful
|
||||
object that determines, based on a random variable, whether the packet is
|
||||
@@ -43,7 +53,7 @@ return value of this function is a boolean that tells the caller whether any
|
||||
corruption occurred. Note that depending on the error model, the packet data
|
||||
buffer may or may not be corrupted. Let's call this function "IsCorrupt()".
|
||||
|
||||
So far, in our design, we have:::
|
||||
So far, in our design, we have::
|
||||
|
||||
class ErrorModel
|
||||
{
|
||||
@@ -94,7 +104,7 @@ a user to force errors on otherwise successful packet transmissions, at the
|
||||
NetDevice level.
|
||||
|
||||
After some thinking and looking at existing |ns2| code, here is a sample API of
|
||||
a base class and first subclass that could be posted for initial review:::
|
||||
a base class and first subclass that could be posted for initial review::
|
||||
|
||||
class ErrorModel
|
||||
{
|
||||
@@ -157,16 +167,16 @@ your model since if you follow the error model verbatim, the code you produce
|
||||
will collide with the existing error model. The below is just an outline of how
|
||||
ErrorModel was built that you can adapt to other models.
|
||||
|
||||
Review the ns-3 coding style document
|
||||
+++++++++++++++++++++++++++++++++++++
|
||||
Review the |ns3| Coding Style Document
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
At this point, you may want to pause and read the |ns3| coding style document,
|
||||
especially if you are considering to contribute your code back to the project.
|
||||
The coding style document is linked off the main project page: `ns-3 coding
|
||||
style <http://www.nsnam.org/developers/contributing-code/coding-style/>`_.
|
||||
|
||||
Decide where in the source tree the model will reside in
|
||||
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
Decide Where in the Source Tree the Model Should Reside
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
All of the |ns3| model source code is in the directory ``src/``. You will need
|
||||
to choose which subdirectory it resides in. If it is new model code of some
|
||||
@@ -177,8 +187,8 @@ In the case of the error model, it is very related to the packet class, so it
|
||||
makes sense to implement this in the ``src/network/`` module where |ns3|
|
||||
packets are implemented.
|
||||
|
||||
waf and wscript
|
||||
+++++++++++++++
|
||||
`waf` and `wscript`
|
||||
+++++++++++++++++++
|
||||
|
||||
|ns3| uses the `Waf <http://www.freehackers.org/~tnagy/waf.html>`_ build system.
|
||||
You will want to integrate your new |ns3| uses the Waf build system. You will
|
||||
@@ -192,7 +202,7 @@ rest of the source files, and the .h file to the list of the header files.
|
||||
Now, pop up to the top level directory and type "./test.py". You
|
||||
shouldn't have broken anything by this operation.
|
||||
|
||||
include guards
|
||||
Include Guards
|
||||
++++++++++++++
|
||||
|
||||
Next, let's add some `include guards
|
||||
@@ -203,8 +213,8 @@ Next, let's add some `include guards
|
||||
...
|
||||
#endif
|
||||
|
||||
namespace ns3
|
||||
+++++++++++++
|
||||
`namespace ns3`
|
||||
+++++++++++++++
|
||||
|
||||
|ns3| uses the |ns3| `namespace
|
||||
<http://en.wikipedia.org/wiki/Namespace_(computer_science)#Use_in_common_languages>`_
|
||||
@@ -216,7 +226,7 @@ an |ns3| namespace block in both the cc and h file.::
|
||||
}
|
||||
|
||||
At this point, we have some skeletal files in which we can start defining
|
||||
our new classes. The header file looks like this:::
|
||||
our new classes. The header file looks like this::
|
||||
|
||||
#ifndef ERROR_MODEL_H
|
||||
#define ERROR_MODEL_H
|
||||
@@ -226,7 +236,7 @@ our new classes. The header file looks like this:::
|
||||
} // namespace ns3
|
||||
#endif
|
||||
|
||||
while the ``error-model.cc`` file simply looks like this:::
|
||||
while the ``error-model.cc`` file simply looks like this::
|
||||
|
||||
#include "error-model.h"
|
||||
|
||||
@@ -243,8 +253,8 @@ Initial Implementation
|
||||
At this point, we're still working on some scaffolding, but we can begin to
|
||||
define our classes, with the functionality to be added later.
|
||||
|
||||
use of class Object?
|
||||
++++++++++++++++++++
|
||||
Inherit from the `Object` Class?
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
This is an important design step; whether to use class :cpp:class:`Object` as a
|
||||
base class for your new classes.
|
||||
@@ -267,7 +277,7 @@ In our case, we want to make use of the attribute system, and we will be passing
|
||||
instances of this object across the |ns3| public API, so class
|
||||
:cpp:class:`Object` is appropriate for us.
|
||||
|
||||
initial classes
|
||||
Initial Classes
|
||||
+++++++++++++++
|
||||
|
||||
One way to proceed is to start by defining the bare minimum functions and see if
|
||||
@@ -373,28 +383,28 @@ every class that defines a new GetTypeId method, and it does the actual
|
||||
registration of the class into the system. The :ref:`Object-model` chapter
|
||||
discusses this in more detail.
|
||||
|
||||
how to include files from elsewhere
|
||||
+++++++++++++++++++++++++++++++++++
|
||||
Including External Files
|
||||
++++++++++++++++++++++++
|
||||
|
||||
log component
|
||||
+++++++++++++
|
||||
Logging Support
|
||||
+++++++++++++++
|
||||
|
||||
*Here, write a bit about adding |ns3| logging macros. Note that
|
||||
LOG_COMPONENT_DEFINE is done outside the namespace ns3*
|
||||
|
||||
constructor, empty function prototypes
|
||||
Constructor, Empty Function Prototypes
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
key variables (default values, attributes)
|
||||
Key Variables (Default Values, Attributes)
|
||||
++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
test program 1
|
||||
Test Program 1
|
||||
++++++++++++++
|
||||
|
||||
Object Framework
|
||||
++++++++++++++++
|
||||
|
||||
Adding-a-sample-script
|
||||
Adding a Sample Script
|
||||
**********************
|
||||
|
||||
At this point, one may want to try to take the basic scaffolding defined above
|
||||
@@ -403,12 +413,12 @@ model when plumbing into the system and may also reveal whether any design or
|
||||
API modifications need to be made. Once this is done, we will return to building
|
||||
out the functionality of the ErrorModels themselves.
|
||||
|
||||
Add basic support in the class
|
||||
Add Basic Support in the Class
|
||||
++++++++++++++++++++++++++++++
|
||||
|
||||
::
|
||||
|
||||
point-to-point-net-device.h
|
||||
/* point-to-point-net-device.h */
|
||||
class ErrorModel;
|
||||
|
||||
/**
|
||||
@@ -434,7 +444,7 @@ Add Accessor
|
||||
MakePointerAccessor (&PointToPointNetDevice::m_receiveErrorModel),
|
||||
MakePointerChecker<ErrorModel> ())
|
||||
|
||||
Plumb into the system
|
||||
Plumb Into the System
|
||||
+++++++++++++++++++++
|
||||
|
||||
::
|
||||
@@ -468,12 +478,12 @@ Plumb into the system
|
||||
}
|
||||
}
|
||||
|
||||
Create null functional script
|
||||
Create Null Functional Script
|
||||
+++++++++++++++++++++++++++++
|
||||
|
||||
::
|
||||
|
||||
simple-error-model.cc
|
||||
/* simple-error-model.cc */
|
||||
|
||||
// Error model
|
||||
// We want to add an error model to node 3's NetDevice
|
||||
@@ -498,8 +508,8 @@ the receive path of the PointToPointNetDevice. It prints out the string
|
||||
"Corrupt!" for each packet received at node n3. Next, we return to the error
|
||||
model to add in a subclass that performs more interesting error modeling.
|
||||
|
||||
Add subclass
|
||||
************
|
||||
Add a Subclass
|
||||
**************
|
||||
|
||||
The trivial base class ErrorModel does not do anything interesting, but it
|
||||
provides a useful base class interface (Corrupt () and Reset ()), forwarded to
|
||||
@@ -522,7 +532,7 @@ Here are a few simple requirements we will consider:
|
||||
of granularity.
|
||||
* Ability to enable/disable (default is enabled)
|
||||
|
||||
How to subclass
|
||||
How to Subclass
|
||||
+++++++++++++++
|
||||
|
||||
We declare BasicErrorModel to be a subclass of ErrorModel as follows,::
|
||||
@@ -540,7 +550,7 @@ We declare BasicErrorModel to be a subclass of ErrorModel as follows,::
|
||||
}
|
||||
|
||||
and configure the subclass GetTypeId function by setting a unique TypeId string
|
||||
and setting the Parent to ErrorModel:::
|
||||
and setting the Parent to ErrorModel::
|
||||
|
||||
TypeId RateErrorModel::GetTypeId (void)
|
||||
{
|
||||
@@ -549,12 +559,12 @@ and setting the Parent to ErrorModel:::
|
||||
.AddConstructor<RateErrorModel> ()
|
||||
...
|
||||
|
||||
Build-core-functions-and-unit-tests
|
||||
Build Core Functions and Unit Tests
|
||||
***********************************
|
||||
|
||||
assert macros
|
||||
Assert Macros
|
||||
+++++++++++++
|
||||
|
||||
Writing unit tests
|
||||
Writing Unit Tests
|
||||
++++++++++++++++++
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Adding a New Module to |ns3|
|
||||
----------------------------
|
||||
@@ -20,7 +21,9 @@ example, the spectrum module can be found here: ::
|
||||
src/spectrum
|
||||
|
||||
A prototypical module has the following directory structure and
|
||||
required files: ::
|
||||
required files:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/
|
||||
module-name/
|
||||
@@ -39,29 +42,39 @@ Not all directories will be present in each module.
|
||||
Step 2 - Create your new module based on the template module
|
||||
************************************************************
|
||||
|
||||
A python program is provided in the source directory that will create a skeleton for a new module ::
|
||||
A python program is provided in the source directory that will create a skeleton for a new module
|
||||
|
||||
src/create-module.py
|
||||
.. sourcecode:: bash
|
||||
|
||||
For the purposes of this discussion we will assume that your new module is called "new-module". From the ``src`` directory, do the following to create the new module: ::
|
||||
$ src/create-module.py
|
||||
|
||||
./create-module.py new-module
|
||||
For the purposes of this discussion we will assume that your new module is called "new-module". From the ``src`` directory, do the following to create the new module:
|
||||
|
||||
Next, cd into ``new-module``; you will find this directory layout: ::
|
||||
.. sourcecode:: bash
|
||||
|
||||
examples helper model test wscript
|
||||
$ ./create-module.py new-module
|
||||
|
||||
Next, cd into ``new-module``; you will find this directory layout:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
$ examples helper model test wscript
|
||||
|
||||
We next walk through how to customize this module. All |ns3| modules
|
||||
depend on the 'core' module and usually on other modules. This
|
||||
dependency is specified in the wscript file.
|
||||
Let's assume that 'new-module' depends on the internet,
|
||||
mobility, and aodv modules. Then the call to the function that will
|
||||
create this module should look like this before editing: ::
|
||||
create this module should look like this before editing:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
def build(bld):
|
||||
module = bld.create_ns3_module('new-module', ['core'])
|
||||
|
||||
and after editing: ::
|
||||
and after editing:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
def build(bld):
|
||||
module = bld.create_ns3_module('new-module', ['internet', 'mobility', 'aodv'])
|
||||
@@ -82,18 +95,24 @@ Step 3 - Adding to your module's source files
|
||||
*********************************************
|
||||
|
||||
If your new module has model and/or helper source files, then they
|
||||
must be specified in your ::
|
||||
must be specified in your
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/new-module/wscript
|
||||
|
||||
file by modifying it with your text editor.
|
||||
|
||||
As an example, the source files for the spectrum module are specified
|
||||
in ::
|
||||
in
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/spectrum/wscript
|
||||
|
||||
with the following list of source files: ::
|
||||
with the following list of source files:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
module.source = [
|
||||
'model/spectrum-model.cc',
|
||||
@@ -112,22 +131,28 @@ Step 4 - Specify your module's header files
|
||||
*******************************************
|
||||
|
||||
If your new module has model and/or helper header files, then they
|
||||
must be specified in your ::
|
||||
must be specified in your
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/new-module/wscript
|
||||
|
||||
file by modifying it with your text editor.
|
||||
|
||||
As an example, the header files for the spectrum module are specified
|
||||
in ::
|
||||
in
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/spectrum/wscript
|
||||
|
||||
with the following function call, module name, and list of header
|
||||
files. Note that the argument for the function new_task_gen() tells
|
||||
waf to install this module's headers with the other |ns3| headers: ::
|
||||
waf to install this module's headers with the other |ns3| headers:
|
||||
|
||||
headers = bld.new_task_gen(features=['ns3header'])
|
||||
.. sourcecode:: python
|
||||
|
||||
headers = bld(features='ns3header')
|
||||
|
||||
headers.module = 'spectrum'
|
||||
|
||||
@@ -147,17 +172,23 @@ waf to install this module's headers with the other |ns3| headers: ::
|
||||
Step 5 - Specify your module's tests
|
||||
************************************
|
||||
|
||||
If your new module has tests, then they must be specified in your ::
|
||||
If your new module has tests, then they must be specified in your
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/new-module/wscript
|
||||
|
||||
file by modifying it with your text editor.
|
||||
|
||||
As an example, the tests for the spectrum module are specified in ::
|
||||
As an example, the tests for the spectrum module are specified in
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/spectrum/wscript
|
||||
|
||||
with the following function call and list of test suites: ::
|
||||
with the following function call and list of test suites:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
module_test = bld.create_ns3_module_test_library('spectrum')
|
||||
|
||||
@@ -170,20 +201,26 @@ with the following function call and list of test suites: ::
|
||||
Step 6 - Specify your module's examples
|
||||
***************************************
|
||||
|
||||
If your new module has examples, then they must be specified in your ::
|
||||
If your new module has examples, then they must be specified in your
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/new-module/examples/wscript
|
||||
|
||||
file by modifying it with your text editor.
|
||||
|
||||
As an example, the examples for the core module are specified in ::
|
||||
As an example, the examples for the core module are specified in
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/core/examples/wscript
|
||||
|
||||
The core module's C++ examples are specified using the following
|
||||
function calls and source file names. Note that the second argument
|
||||
for the function ``create_ns3_program()`` is the list of modules that the
|
||||
program being created depends on: ::
|
||||
program being created depends on:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
obj = bld.create_ns3_program('main-callback', ['core'])
|
||||
obj.source = 'main-callback.cc'
|
||||
@@ -194,7 +231,9 @@ program being created depends on: ::
|
||||
The core module's Python examples are specified using the following
|
||||
function call. Note that the second argument for the function
|
||||
register_ns3_script() is the list of modules that the Python example
|
||||
depends on: ::
|
||||
depends on:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
bld.register_ns3_script('sample-simulator.py', ['core'])
|
||||
|
||||
@@ -207,11 +246,15 @@ are suitable for regression tests. A file called ``examples-to-run.py``
|
||||
that exists in each module's test directory can control the invocation
|
||||
of the examples when the test framework runs.
|
||||
|
||||
As an example, the examples that are run by ``test.py`` for the core module are specified in ::
|
||||
As an example, the examples that are run by ``test.py`` for the core module are specified in
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/core/test/examples-to-run.py
|
||||
|
||||
using the following two lists of C++ and Python examples: ::
|
||||
using the following two lists of C++ and Python examples:
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
# A list of C++ examples to run in order to ensure that they remain
|
||||
# buildable and runnable over time. Each tuple in the list contains
|
||||
@@ -238,7 +281,9 @@ using the following two lists of C++ and Python examples: ::
|
||||
("sample-simulator.py", "True"),
|
||||
]
|
||||
|
||||
Each tuple in the C++ list of examples to run contains ::
|
||||
Each tuple in the C++ list of examples to run contains
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
(example_name, do_run, do_valgrind_run)
|
||||
|
||||
@@ -249,11 +294,15 @@ is needed because NSC causes illegal instruction crashes with
|
||||
some tests when they are run under valgrind.
|
||||
|
||||
Note that the two conditions are Python statements that
|
||||
can depend on waf configuration variables. For example, ::
|
||||
can depend on waf configuration variables. For example,
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
("tcp-nsc-lfn", "NSC_ENABLED == True", "NSC_ENABLED == False"),
|
||||
|
||||
Each tuple in the Python list of examples to run contains ::
|
||||
Each tuple in the Python list of examples to run contains
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
(example_name, do_run)
|
||||
|
||||
@@ -261,12 +310,16 @@ where example_name is the Python script to be run and
|
||||
do_run is a condition under which to run the example.
|
||||
|
||||
Note that the condition is a Python statement that can
|
||||
depend on waf configuration variables. For example, ::
|
||||
depend on waf configuration variables. For example,
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
("realtime-udp-echo.py", "ENABLE_REAL_TIME == False"),
|
||||
|
||||
If your new module has examples, then you must specify which of them
|
||||
should be run in your ::
|
||||
should be run in your
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
src/new-module/test/examples-to-run.py
|
||||
|
||||
@@ -276,10 +329,30 @@ test.py.
|
||||
Step 8 - Build and test your new module
|
||||
***************************************
|
||||
|
||||
You can now build and test your module as normal: ::
|
||||
You can now build and test your module as normal. You must reconfigure
|
||||
the project as a first step or else your new module will not be included
|
||||
in the build.
|
||||
|
||||
./waf configure --enable-examples --enable-tests
|
||||
./waf build
|
||||
./test.py
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf configure --enable-examples --enable-tests
|
||||
$ ./waf build
|
||||
$ ./test.py
|
||||
|
||||
and look for your new module's test suite (and example programs, if enabled) in the test output.
|
||||
|
||||
Step 9 - Python bindings
|
||||
************************
|
||||
|
||||
Adding Python bindings to your module is optional, and the step is
|
||||
commented out by default in the ``create-module.py`` script.
|
||||
|
||||
.. sourcecode:: python
|
||||
|
||||
# bld.ns3_python_bindings()
|
||||
|
||||
If you want to include Python bindings (needed only if you want
|
||||
to write Python ns-3 programs instead of C++ ns-3 programs), you
|
||||
should uncomment the above and install the Python API scanning
|
||||
system (covered elsewhere in this manual) and scan your module to
|
||||
generate new bindings.
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
.. _Object-model:
|
||||
|
||||
@@ -26,7 +27,7 @@ Object-oriented behavior
|
||||
C++ objects, in general, provide common object-oriented capabilities
|
||||
(abstraction, encapsulation, inheritance, and polymorphism) that are part
|
||||
of classic object-oriented design. |ns3| objects make use of these
|
||||
properties; for instance:::
|
||||
properties; for instance::
|
||||
|
||||
class Address
|
||||
{
|
||||
@@ -129,7 +130,7 @@ holds true for |ns3| also, but some objects in the system have some additional
|
||||
frameworks available. Specifically, reference counted objects are usually
|
||||
allocated using a templated Create or CreateObject method, as follows.
|
||||
|
||||
For objects deriving from class :cpp:class:`Object`:::
|
||||
For objects deriving from class :cpp:class:`Object`::
|
||||
|
||||
Ptr<WifiNetDevice> device = CreateObject<WifiNetDevice> ();
|
||||
|
||||
@@ -138,7 +139,7 @@ Please do not create such objects using ``operator new``; create them using
|
||||
|
||||
For objects deriving from class :cpp:class:`SimpleRefCount`, or other objects
|
||||
that support usage of the smart pointer class, a templated helper function is
|
||||
available and recommended to be used:::
|
||||
available and recommended to be used::
|
||||
|
||||
Ptr<B> b = Create<B> ();
|
||||
|
||||
@@ -175,7 +176,7 @@ problems. This design is based on elements of the `Component Object Model
|
||||
binary-level compatibility of replaceable components is not supported and we
|
||||
have tried to simplify the syntax and impact on model developers.
|
||||
|
||||
Exmaples
|
||||
Examples
|
||||
********
|
||||
|
||||
Aggregation example
|
||||
@@ -217,7 +218,7 @@ Consider a node pointer ``m_node`` that points to a Node object that has an
|
||||
implementation of IPv4 previously aggregated to it. The client code wishes to
|
||||
configure a default route. To do so, it must access an object within the node
|
||||
that has an interface to the IP forwarding configuration. It performs the
|
||||
following:::
|
||||
following::
|
||||
|
||||
Ptr<Ipv4> ipv4 = m_node->GetObject<Ipv4> ();
|
||||
|
||||
@@ -280,7 +281,7 @@ to the subclass API?"
|
||||
|
||||
The answer to this is that in many situations, both techniques will work.
|
||||
|ns3| provides a templated function for making the syntax of Object
|
||||
dynamic casting much more user friendly:::
|
||||
dynamic casting much more user friendly::
|
||||
|
||||
template <typename T1, typename T2>
|
||||
Ptr<T1>
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
.. _Object-names:
|
||||
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
|
||||
Organization
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: python
|
||||
|
||||
Using Python to Run |ns3|
|
||||
-------------------------
|
||||
@@ -74,30 +75,30 @@ Running Python Scripts
|
||||
|
||||
waf contains some options that automatically update the python path to find the ns3 module. To run example programs, there are two ways to use waf to take care of this. One is to run a waf shell; e.g.:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --shell
|
||||
python examples/mixed-wireless.py
|
||||
$ ./waf --shell
|
||||
$ python examples/wireless/mixed-wireless.py
|
||||
|
||||
and the other is to use the --pyrun option to waf:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --pyrun examples/mixed-wireless.py
|
||||
$ ./waf --pyrun examples/wireless/mixed-wireless.py
|
||||
|
||||
To run a python script under the C debugger:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --shell
|
||||
gdb --args python examples/mixed-wireless.py
|
||||
$ ./waf --shell
|
||||
$ gdb --args python examples/wireless/mixed-wireless.py
|
||||
|
||||
To run your own Python script that calls |ns3| and that has this path, ``/path/to/your/example/my-script.py``, do the following:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --shell
|
||||
python /path/to/your/example/my-script.py
|
||||
$ ./waf --shell
|
||||
$ python /path/to/your/example/my-script.py
|
||||
|
||||
Caveats
|
||||
*******
|
||||
@@ -118,9 +119,9 @@ Most of the missing APIs can be wrapped, given enough time, patience, and expert
|
||||
Conversion Constructors
|
||||
+++++++++++++++++++++++
|
||||
|
||||
Conversion constructors (http://publib.boulder.ibm.com/infocenter/compbgpl/v9v111/topic/com.ibm.xlcpp9.bg.doc/language_ref/cplr384.htm) are not fully supported yet by PyBindGen, and they always act as explicit constructors when translating an API into Python. For example, in C++ you can do this:
|
||||
`Conversion constructors <http://publib.boulder.ibm.com/infocenter/compbgpl/v9v111/topic/com.ibm.xlcpp9.bg.doc/language_ref/cplr384.htm>`_ are not fully supported yet by PyBindGen, and they always act as explicit constructors when translating an API into Python. For example, in C++ you can do this:
|
||||
|
||||
::
|
||||
.. sourcecode:: cpp
|
||||
|
||||
Ipv4AddressHelper ipAddrs;
|
||||
ipAddrs.SetBase ("192.168.0.0", "255.255.255.0");
|
||||
@@ -188,9 +189,9 @@ will probably have to be that we disable python bindings in CygWin.
|
||||
If you really care about Python bindings on Windows, try building with mingw and native
|
||||
python instead. Or else, to build without python bindings, disable python bindings in the configuration stage:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf configure --disable-python
|
||||
$ ./waf configure --disable-python
|
||||
|
||||
Working with Python Bindings
|
||||
****************************
|
||||
@@ -211,9 +212,9 @@ The process by which Python bindings are handled is the following:
|
||||
|
||||
If something goes wrong with compiling Python bindings and you just want to ignore them and move on with C++, you can disable Python with:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --disable-python
|
||||
$ ./waf --disable-python
|
||||
|
||||
Instructions for Handling New Files or Changed API's
|
||||
****************************************************
|
||||
@@ -230,9 +231,9 @@ Scanning the Monolithic Python Bindings
|
||||
|
||||
To scan the monolithic Python bindings do the following:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --python-scan
|
||||
$ ./waf --python-scan
|
||||
|
||||
Organization of the Monolithic Python Bindings
|
||||
++++++++++++++++++++++++++++++++++++++++++++++
|
||||
@@ -269,15 +270,15 @@ Scanning the Modular Python Bindings
|
||||
|
||||
To scan the modular Python bindings for the core module, for example, do the following:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --apiscan=core
|
||||
$ ./waf --apiscan=core
|
||||
|
||||
To scan the modular Python bindings for all of the modules, do the following:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --apiscan=all
|
||||
$ ./waf --apiscan=all
|
||||
|
||||
Creating a New Module
|
||||
+++++++++++++++++++++
|
||||
@@ -311,5 +312,4 @@ The ``src/<module>/bindings`` directory may contain the following files, some of
|
||||
More Information for Developers
|
||||
*******************************
|
||||
|
||||
If you are a developer and need more information on |ns3|'s Python bindings, please see the Python Bindings wiki page at
|
||||
`<http://www.nsnam.org/wiki/index.php/NS-3_Python_Bindings>`_.
|
||||
If you are a developer and need more information on |ns3|'s Python bindings, please see the `Python Bindings wiki page <http://www.nsnam.org/wiki/NS-3_Python_Bindings>`_.
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Random Variables
|
||||
----------------
|
||||
@@ -125,7 +126,7 @@ run number behavior. This seeding and substream state setting must be called
|
||||
before any random variables are created; e.g::
|
||||
|
||||
RngSeedManager::SetSeed (3); // Changes seed from default of 1 to 3
|
||||
RngSeedManager::SetRun (7); // Changes run number from default of 1 to 7
|
||||
RngSeedManager::SetRun (7); // Changes run number from default of 1 to 7
|
||||
// Now, create random variables
|
||||
Ptr<UniformRandomVariable> x = CreateObject<UniformRandomVariable> ();
|
||||
Ptr<ExponentialRandomVariable> y = CreateObject<ExponentialRandomVarlable> ();
|
||||
@@ -143,18 +144,24 @@ independent replications using the substreams.
|
||||
|
||||
For ease of use, it is not necessary to control the seed and run number from
|
||||
within the program; the user can set the ``NS_GLOBAL_VALUE`` environment
|
||||
variable as follows::
|
||||
variable as follows:
|
||||
|
||||
NS_GLOBAL_VALUE="RngRun=3" ./waf --run program-name
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ NS_GLOBAL_VALUE="RngRun=3" ./waf --run program-name
|
||||
|
||||
Another way to control this is by passing a command-line argument; since this is
|
||||
an |ns3| GlobalValue instance, it is equivalently done such as follows::
|
||||
an |ns3| GlobalValue instance, it is equivalently done such as follows:
|
||||
|
||||
./waf --command-template="%s --RngRun=3" --run program-name
|
||||
.. sourcecode:: bash
|
||||
|
||||
or, if you are running programs directly outside of waf::
|
||||
$ ./waf --command-template="%s --RngRun=3" --run program-name
|
||||
|
||||
./build/optimized/scratch/program-name --RngRun=3
|
||||
or, if you are running programs directly outside of waf:
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./build/optimized/scratch/program-name --RngRun=3
|
||||
|
||||
The above command-line variants make it easy to run lots of different
|
||||
runs from a shell script by just passing a different RngRun index.
|
||||
@@ -177,7 +184,9 @@ Base class public API
|
||||
*********************
|
||||
|
||||
Below are excerpted a few public methods of class :cpp:class:`RandomVariableStream`
|
||||
that access the next value in the substream.::
|
||||
that access the next value in the substream.
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* \brief Returns a random double from the underlying distribution
|
||||
@@ -226,7 +235,7 @@ handled by smart pointers.
|
||||
|
||||
RandomVariableStream instances can also be used in |ns3| attributes, which means
|
||||
that values can be set for them through the |ns3| attribute system.
|
||||
An example is in the propagation models for WifiNetDevice:::
|
||||
An example is in the propagation models for WifiNetDevice::
|
||||
|
||||
TypeId
|
||||
RandomPropagationDelayModel::GetTypeId (void)
|
||||
@@ -278,20 +287,20 @@ of the base class RandomVariableStream.
|
||||
|
||||
By partitioning the existing sequence of streams from before:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
<-------------------------------------------------------------------------->
|
||||
stream 0 stream (2^64 - 1)
|
||||
stream 0 stream (2^64 - 1)
|
||||
|
||||
into two equal-sized sets:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
<--------------------------------------------------------------------------->
|
||||
^ ^^ ^
|
||||
| || |
|
||||
stream 0 stream (2^63 - 1) stream 2^63 stream (2^64 - 1)
|
||||
<- automatically assigned -----><-------- assigned by user----------->
|
||||
<-------------------------------------------------------------------------->
|
||||
^ ^^ ^
|
||||
| || |
|
||||
stream 0 stream (2^63 - 1) stream 2^63 stream (2^64 - 1)
|
||||
<- automatically assigned -----------><- assigned by user ----------------->
|
||||
|
||||
The first 2^63 streams continue to be automatically assigned, while
|
||||
the last 2^63 are given stream indices starting with zero up to
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
RealTime
|
||||
--------
|
||||
@@ -61,9 +62,11 @@ perspective. Users just need to set the attribute
|
||||
StringValue ("ns3::RealtimeSimulatorImpl"));
|
||||
|
||||
There is a script in ``examples/realtime/realtime-udp-echo.cc`` that
|
||||
has an example of how to configure the realtime behavior. Try: ::
|
||||
has an example of how to configure the realtime behavior. Try:
|
||||
|
||||
./waf --run realtime-udp-echo
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf --run realtime-udp-echo
|
||||
|
||||
Whether the simulator will work in a best effort or hard limit policy fashion is
|
||||
governed by the attributes explained in the previous section.
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. |ns3| replace:: *ns-3*
|
||||
|
||||
.. |ns2| replace:: *ns-2*
|
||||
|
||||
.. |check| replace:: :math:`\checkmark`
|
||||
|
||||
@@ -5,6 +5,7 @@ Support
|
||||
|
||||
new-models
|
||||
new-modules
|
||||
documentation
|
||||
enable-modules
|
||||
enable-tests
|
||||
troubleshoot
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: bash
|
||||
|
||||
Testing framework
|
||||
-----------------
|
||||
@@ -27,7 +28,9 @@ properly on all of its supported systems.
|
||||
Users (and developers) typically will not interact with the buildbot system other
|
||||
than to read its messages regarding test results. If a failure is detected in
|
||||
one of the automated build and test jobs, the buildbot will send an email to the
|
||||
*ns-developers* mailing list. This email will look something like::
|
||||
*ns-developers* mailing list. This email will look something like
|
||||
|
||||
.. sourcecode: text
|
||||
|
||||
The Buildbot has detected a new failure of osx-ppc-g++-4.2 on NsNam.
|
||||
Full details are available at:
|
||||
@@ -69,20 +72,20 @@ have been built by doing the following
|
||||
|
||||
::
|
||||
|
||||
./waf configure --enable-examples --enable-tests
|
||||
./waf
|
||||
$ ./waf configure --enable-examples --enable-tests
|
||||
$ ./waf
|
||||
|
||||
By default, ``test.py`` will run all available tests and report status
|
||||
back in a very concise form. Running the command
|
||||
|
||||
::
|
||||
|
||||
./test.py
|
||||
$ ./test.py
|
||||
|
||||
will result in a number of ``PASS``, ``FAIL``, ``CRASH`` or ``SKIP``
|
||||
indications followed by the kind of test that was run and its display name.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
@@ -103,7 +106,7 @@ in determining if changes they have made have caused any regressions.
|
||||
There are a number of options available to control the behavior of ``test.py``.
|
||||
if you run ``test.py --help`` you should see a command summary like:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
Usage: test.py [options]
|
||||
|
||||
@@ -145,7 +148,7 @@ nightly builds using
|
||||
|
||||
::
|
||||
|
||||
./test.py --html=nightly.html
|
||||
$ ./test.py --html=nightly.html
|
||||
|
||||
In this case, an HTML file named ''nightly.html'' would be created with a pretty
|
||||
summary of the testing done. A ''human readable'' format is available for users
|
||||
@@ -153,7 +156,7 @@ interested in the details.
|
||||
|
||||
::
|
||||
|
||||
./test.py --text=results.txt
|
||||
$ ./test.py --text=results.txt
|
||||
|
||||
In the example above, the test suite checking the |ns3| wireless
|
||||
device propagation loss models failed. By default no further information is
|
||||
@@ -164,17 +167,17 @@ to be specified. Running the command
|
||||
|
||||
::
|
||||
|
||||
./test.py --suite=ns3-wifi-propagation-loss-models
|
||||
$ ./test.py --suite=ns3-wifi-propagation-loss-models
|
||||
|
||||
or equivalently
|
||||
|
||||
::
|
||||
|
||||
./test.py -s ns3-wifi-propagation-loss-models
|
||||
$ ./test.py -s ns3-wifi-propagation-loss-models
|
||||
|
||||
results in that single test suite being run.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
FAIL: TestSuite ns3-wifi-propagation-loss-models
|
||||
|
||||
@@ -182,13 +185,14 @@ To find detailed information regarding the failure, one must specify the kind
|
||||
of output desired. For example, most people will probably be interested in
|
||||
a text file::
|
||||
|
||||
./test.py --suite=ns3-wifi-propagation-loss-models --text=results.txt
|
||||
$ ./test.py --suite=ns3-wifi-propagation-loss-models --text=results.txt
|
||||
|
||||
This will result in that single test suite being run with the test status written to
|
||||
the file ''results.txt''.
|
||||
|
||||
You should find something similar to the following in that file::
|
||||
You should find something similar to the following in that file
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
FAIL: Test Suite ''ns3-wifi-propagation-loss-models'' (real 0.02 user 0.01 system 0.00)
|
||||
PASS: Test Case "Check ... Friis ... model ..." (real 0.01 user 0.00 system 0.00)
|
||||
@@ -222,21 +226,23 @@ changes to a repository. In this case, ``test.py`` can be told to constrain
|
||||
the types of tests being run to a particular class of tests. The following
|
||||
command will result in only the unit tests being run::
|
||||
|
||||
./test.py --constrain=unit
|
||||
$ ./test.py --constrain=unit
|
||||
|
||||
Similarly, the following command will result in only the example smoke tests
|
||||
being run::
|
||||
|
||||
./test.py --constrain=unit
|
||||
$ ./test.py --constrain=unit
|
||||
|
||||
To see a quick list of the legal kinds of constraints, you can ask for them
|
||||
to be listed. The following command
|
||||
|
||||
::
|
||||
|
||||
./test.py --kinds
|
||||
$ ./test.py --kinds
|
||||
|
||||
will result in the following list being displayed::
|
||||
will result in the following list being displayed:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
@@ -256,9 +262,11 @@ to be listed. The following command,
|
||||
|
||||
::
|
||||
|
||||
./test.py --list
|
||||
$ ./test.py --list
|
||||
|
||||
will result in a list of the test suite being displayed, similar to::
|
||||
will result in a list of the test suite being displayed, similar to
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
@@ -291,11 +299,11 @@ for C++ examples do not have extensions. Entering
|
||||
|
||||
::
|
||||
|
||||
./test.py --example=udp-echo
|
||||
$ ./test.py --example=udp-echo
|
||||
|
||||
results in that single example being run.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
PASS: Example examples/udp/udp-echo
|
||||
|
||||
@@ -304,7 +312,7 @@ You can specify the directory where ns-3 was built using the
|
||||
|
||||
::
|
||||
|
||||
./test.py --buildpath=/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build/debug --example=wifi-simple-adhoc
|
||||
$ ./test.py --buildpath=/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build/debug --example=wifi-simple-adhoc
|
||||
|
||||
One can run a single Python example program using the ``--pyexample``
|
||||
option. Note that the relative path for the example must be included
|
||||
@@ -312,11 +320,11 @@ and that Python examples do need their extensions. Entering
|
||||
|
||||
::
|
||||
|
||||
./test.py --pyexample=examples/tutorial/first.py
|
||||
$ ./test.py --pyexample=examples/tutorial/first.py
|
||||
|
||||
results in that single example being run.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
PASS: Example examples/tutorial/first.py
|
||||
|
||||
@@ -344,9 +352,11 @@ option.
|
||||
|
||||
::
|
||||
|
||||
./test.py --list --nowaf
|
||||
$ ./test.py --list --nowaf
|
||||
|
||||
will result in a list of the currently built test suites being displayed, similar to::
|
||||
will result in a list of the currently built test suites being displayed, similar to:
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
ns3-wifi-propagation-loss-models
|
||||
ns3-tcp-cwnd
|
||||
@@ -366,7 +376,7 @@ leaks. This can be selected by using the ``--grind`` option.
|
||||
|
||||
::
|
||||
|
||||
./test.py --grind
|
||||
$ ./test.py --grind
|
||||
|
||||
As it runs, ``test.py`` and the programs that it runs indirectly, generate large
|
||||
numbers of temporary files. Usually, the content of these files is not interesting,
|
||||
@@ -378,7 +388,7 @@ Universal Time (also known as Greenwich Mean Time).
|
||||
|
||||
::
|
||||
|
||||
./test.py --retain
|
||||
$ ./test.py --retain
|
||||
|
||||
Finally, ``test.py`` provides a ``--verbose`` option which will print
|
||||
large amounts of information about its progress. It is not expected that this
|
||||
@@ -386,13 +396,13 @@ will be terribly useful unless there is an error. In this case, you can get
|
||||
access to the standard output and standard error reported by running test suites
|
||||
and examples. Select verbose in the following way::
|
||||
|
||||
./test.py --verbose
|
||||
$ ./test.py --verbose
|
||||
|
||||
All of these options can be mixed and matched. For example, to run all of the
|
||||
ns-3 core test suites under valgrind, in verbose mode, while generating an HTML
|
||||
output file, one would do::
|
||||
|
||||
./test.py --verbose --grind --constrain=core --html=results.html
|
||||
$ ./test.py --verbose --grind --constrain=core --html=results.html
|
||||
|
||||
TestTaxonomy
|
||||
************
|
||||
@@ -480,7 +490,7 @@ stage, and also (optionally) examples if examples are to be checked:
|
||||
|
||||
::
|
||||
|
||||
./waf --configure --enable-examples --enable-tests
|
||||
$ ./waf --configure --enable-examples --enable-tests
|
||||
|
||||
Then, build ns-3, and after it is built, just run ``test.py``. ``test.py -h``
|
||||
will show a number of configuration options that modify the behavior
|
||||
@@ -501,9 +511,11 @@ The main reason why ``test.py`` is not suitable for debugging is that it is not
|
||||
In order to execute the test-runner, you run it like any other ns-3 executable
|
||||
-- using ``waf``. To get a list of available options, you can type::
|
||||
|
||||
./waf --run "test-runner --help"
|
||||
$ ./waf --run "test-runner --help"
|
||||
|
||||
You should see something like the following::
|
||||
You should see something like the following
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-test/ns-3-dev/build'
|
||||
@@ -537,10 +549,10 @@ option something like,
|
||||
|
||||
::
|
||||
|
||||
./waf shell
|
||||
cd build/debug/utils
|
||||
gdb test-runner
|
||||
run --suite=global-value --assert
|
||||
$ ./waf shell
|
||||
$ cd build/debug/utils
|
||||
$ gdb test-runner
|
||||
$ run --suite=global-value --assert
|
||||
|
||||
If an error is then found in the global-value test suite, a segfault would be
|
||||
generated and the (source level) debugger would stop at the ``NS_TEST_ASSERT_MSG``
|
||||
@@ -556,7 +568,7 @@ option for you. To run one of the tests directly from the test-runner
|
||||
using ``waf``, you will need to specify the test suite to run along with
|
||||
the base directory. So you could use the shell and do::
|
||||
|
||||
./waf --run "test-runner --basedir=`pwd` --suite=pcap-file-object"
|
||||
$ ./waf --run "test-runner --basedir=`pwd` --suite=pcap-file-object"
|
||||
|
||||
Note the ''backward'' quotation marks on the ``pwd`` command.
|
||||
|
||||
@@ -601,7 +613,7 @@ output, run ``test.py`` with the "retain" option:
|
||||
|
||||
::
|
||||
|
||||
./test.py -r
|
||||
$ ./test.py -r
|
||||
|
||||
and test output can be found in the ``testpy-output/`` directory.
|
||||
|
||||
@@ -619,11 +631,11 @@ Try,
|
||||
|
||||
::
|
||||
|
||||
./waf --run "test-runner --basedir=`pwd` --suite=pcap-file-object --out=myfile.xml"
|
||||
$ ./waf --run "test-runner --basedir=`pwd` --suite=pcap-file-object --out=myfile.xml"
|
||||
|
||||
If you look at the file ``myfile.xml`` you should see something like,
|
||||
|
||||
::
|
||||
.. sourcecode:: xml
|
||||
|
||||
<TestSuite>
|
||||
<SuiteName>pcap-file-object</SuiteName>
|
||||
@@ -669,7 +681,9 @@ section.
|
||||
Debugging test suite failures
|
||||
+++++++++++++++++++++++++++++
|
||||
|
||||
To debug test crashes, such as::
|
||||
To debug test crashes, such as
|
||||
|
||||
.. sourcecode:: text
|
||||
|
||||
CRASH: TestSuite ns3-wifi-interference
|
||||
|
||||
@@ -677,7 +691,7 @@ You can access the underlying test-runner program via gdb as follows, and
|
||||
then pass the "--basedir=`pwd`" argument to run (you can also pass other
|
||||
arguments as needed, but basedir is the minimum needed)::
|
||||
|
||||
./waf --command-template="gdb %s" --run "test-runner"
|
||||
$ ./waf --command-template="gdb %s" --run "test-runner"
|
||||
Waf: Entering directory `/home/tomh/hg/sep09/ns-3-allinone/ns-3-dev-678/build'
|
||||
Waf: Leaving directory `/home/tomh/hg/sep09/ns-3-allinone/ns-3-dev-678/build'
|
||||
'build' finished successfully (0.380s)
|
||||
@@ -699,7 +713,7 @@ such as::
|
||||
|
||||
VALGR: TestSuite devices-mesh-dot11s-regression
|
||||
|
||||
./waf --command-template="valgrind %s --basedir=`pwd` --suite=devices-mesh-dot11s-regression" --run test-runner
|
||||
$ ./waf --command-template="valgrind %s --basedir=`pwd` --suite=devices-mesh-dot11s-regression" --run test-runner
|
||||
|
||||
Class TestRunner
|
||||
****************
|
||||
@@ -736,7 +750,7 @@ and perform these two duties.
|
||||
The following code will define a new class that can be run by ``test.py``
|
||||
as a ''unit'' test with the display name, ``my-test-suite-name``.
|
||||
|
||||
::
|
||||
.. sourcecode:: cpp
|
||||
|
||||
class MySuite : public TestSuite
|
||||
{
|
||||
@@ -766,7 +780,7 @@ In order to create a new test case in the system, all one has to do is to inheri
|
||||
from the ``TestCase`` base class, override the constructor to give the test
|
||||
case a name and override the ``DoRun`` method to run the test.
|
||||
|
||||
::
|
||||
.. sourcecode:: cpp
|
||||
|
||||
class MyTestCase : public TestCase
|
||||
{
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
Tracing
|
||||
-------
|
||||
@@ -243,7 +244,7 @@ provided.
|
||||
The first thing to do is to read the path backward. The last segment of the path
|
||||
must be an ``Attribute`` of an ``Object``. In fact, if you had a pointer to the
|
||||
``Object`` that has the "CongestionWindow" ``Attribute`` handy (call it
|
||||
``theObject``), you could write this just like the previous example:::
|
||||
``theObject``), you could write this just like the previous example::
|
||||
|
||||
void CwndTracer (uint32_t oldval, uint32_t newval) {}
|
||||
|
||||
@@ -269,7 +270,7 @@ aggregation model. The next path segment begins with the "$" character which
|
||||
indicates a ``GetObject`` call should be made looking for the type that follows.
|
||||
When a node is initialized by an ``InternetStackHelper`` a number of interfaces
|
||||
are aggregated to the node. One of these is the TCP level four protocol. The
|
||||
runtime type of this protocol object is "ns3::TcpL4Protocol". When the
|
||||
runtime type of this protocol object is ``ns3::TcpL4Protocol''. When the
|
||||
``GetObject`` is executed, it returns a pointer to the object of this type.
|
||||
|
||||
The ``TcpL4Protocol`` class defines an Attribute called "SocketList" which is a
|
||||
@@ -313,7 +314,7 @@ different trace events and writing them to files. In previous sections,
|
||||
primarily "Building Topologies," we have seen several varieties of the trace
|
||||
helper methods designed for use inside other (device) helpers.
|
||||
|
||||
Perhaps you will recall seeing some of these variations:::
|
||||
Perhaps you will recall seeing some of these variations::
|
||||
|
||||
pointToPoint.EnablePcapAll ("second");
|
||||
pointToPoint.EnablePcap ("second", p2pNodes.Get (0)->GetId (), 0);
|
||||
@@ -342,14 +343,15 @@ stack helpers. Naturally, the trace files should follow a
|
||||
The trace helpers therefore fall naturally into a two-dimensional taxonomy.
|
||||
There are subtleties that prevent all four classes from behaving identically,
|
||||
but we do strive to make them all work as similarly as possible; and whenever
|
||||
possible there are analogs for all methods in all classes.::
|
||||
possible there are analogs for all methods in all classes.
|
||||
|
||||
| pcap | ascii |
|
||||
-----------------+------+-------|
|
||||
Device Helper | | |
|
||||
-----------------+------+-------|
|
||||
Protocol Helper | | |
|
||||
-----------------+------+-------|
|
||||
+-----------------+---------+---------+
|
||||
| | pcap | ascii |
|
||||
+=================+=========+=========+
|
||||
| Device Helper | |check| | |check| |
|
||||
+-----------------+---------+---------+
|
||||
| Protocol Helper | |check| | |check| |
|
||||
+-----------------+---------+---------+
|
||||
|
||||
We use an approach called a ``mixin`` to add tracing functionality to our helper
|
||||
classes. A ``mixin`` is a class that provides functionality to that is
|
||||
@@ -393,11 +395,16 @@ Pcap Tracing Device Helper Methods
|
||||
|
||||
::
|
||||
|
||||
void EnablePcap (std::string prefix, Ptr<NetDevice> nd, bool promiscuous = false, bool explicitFilename = false);
|
||||
void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilename = false);
|
||||
void EnablePcap (std::string prefix, NetDeviceContainer d, bool promiscuous = false);
|
||||
void EnablePcap (std::string prefix, NodeContainer n, bool promiscuous = false);
|
||||
void EnablePcap (std::string prefix, uint32_t nodeid, uint32_t deviceid, bool promiscuous = false);
|
||||
void EnablePcap (std::string prefix, Ptr<NetDevice> nd,
|
||||
bool promiscuous = false, bool explicitFilename = false);
|
||||
void EnablePcap (std::string prefix, std::string ndName,
|
||||
bool promiscuous = false, bool explicitFilename = false);
|
||||
void EnablePcap (std::string prefix, NetDeviceContainer d,
|
||||
bool promiscuous = false);
|
||||
void EnablePcap (std::string prefix, NodeContainer n,
|
||||
bool promiscuous = false);
|
||||
void EnablePcap (std::string prefix, uint32_t nodeid, uint32_t deviceid,
|
||||
bool promiscuous = false);
|
||||
void EnablePcapAll (std::string prefix, bool promiscuous = false);
|
||||
|
||||
In each of the methods shown above, there is a default parameter called
|
||||
@@ -502,7 +509,7 @@ enable pcap tracing on a single device.
|
||||
|
||||
For example, in order to arrange for a device helper to create a single
|
||||
promiscuous pcap capture file of a specific name (``my-pcap-file.pcap``) on a
|
||||
given device, one could:::
|
||||
given device, one could::
|
||||
|
||||
Ptr<NetDevice> nd;
|
||||
...
|
||||
@@ -593,7 +600,7 @@ suffix ".tr" instead of ".pcap".
|
||||
|
||||
If you want to enable ascii tracing on more than one net device and have all
|
||||
traces sent to a single file, you can do that as well by using an object to
|
||||
refer to a single file:::
|
||||
refer to a single file::
|
||||
|
||||
Ptr<NetDevice> nd1;
|
||||
Ptr<NetDevice> nd2;
|
||||
@@ -625,7 +632,7 @@ belong to exactly one ``Node``. For example,::
|
||||
This would result in two files named ``prefix-client-eth0.tr`` and
|
||||
``prefix-server-eth0.tr`` with traces for each device in the respective trace
|
||||
file. Since all of the EnableAscii functions are overloaded to take a stream
|
||||
wrapper, you can use that form as well:::
|
||||
wrapper, you can use that form as well::
|
||||
|
||||
Names::Add ("client" ...);
|
||||
Names::Add ("client/eth0" ...);
|
||||
@@ -653,7 +660,7 @@ since the found net device must belong to exactly one ``Node``. For example,::
|
||||
|
||||
This would result in a number of ascii trace files being created, each of which
|
||||
follows the <prefix>-<node id>-<device id>.tr convention. Combining all of the
|
||||
traces into a single file is accomplished similarly to the examples above:::
|
||||
traces into a single file is accomplished similarly to the examples above::
|
||||
|
||||
NetDeviceContainer d = ...;
|
||||
...
|
||||
@@ -761,7 +768,7 @@ and ``NetDevice``- centric versions of the device versions. Instead of
|
||||
``Node`` and ``NetDevice`` pair constraints, we use protocol and interface
|
||||
constraints.
|
||||
|
||||
Note that just like in the device version, there are six methods:::
|
||||
Note that just like in the device version, there are six methods::
|
||||
|
||||
void EnablePcapIpv4 (std::string prefix, Ptr<Ipv4> ipv4, uint32_t interface);
|
||||
void EnablePcapIpv4 (std::string prefix, std::string ipv4Name, uint32_t interface);
|
||||
@@ -941,7 +948,7 @@ suffix ".tr" instead of ".pcap".
|
||||
If you want to enable ascii tracing on more than one interface and have all
|
||||
traces sent to a single file, you can do that as well by using an object to
|
||||
refer to a single file. We have already something similar to this in the "cwnd"
|
||||
example above:::
|
||||
example above::
|
||||
|
||||
Ptr<Ipv4> protocol1 = node1->GetObject<Ipv4> ();
|
||||
Ptr<Ipv4> protocol2 = node2->GetObject<Ipv4> ();
|
||||
@@ -971,7 +978,7 @@ between protocol instances and nodes, For example,::
|
||||
This would result in two files named "prefix-nnode1Ipv4-i1.tr" and
|
||||
"prefix-nnode2Ipv4-i1.tr" with traces for each interface in the respective
|
||||
trace file. Since all of the EnableAscii functions are overloaded to take a
|
||||
stream wrapper, you can use that form as well:::
|
||||
stream wrapper, you can use that form as well::
|
||||
|
||||
Names::Add ("node1Ipv4" ...);
|
||||
Names::Add ("node2Ipv4" ...);
|
||||
@@ -1004,7 +1011,7 @@ one-to-one correspondence between each protocol and its node. For example,::
|
||||
|
||||
This would result in a number of ascii trace files being created, each of which
|
||||
follows the <prefix>-n<node id>-i<interface>.tr convention. Combining all of the
|
||||
traces into a single file is accomplished similarly to the examples above:::
|
||||
traces into a single file is accomplished similarly to the examples above::
|
||||
|
||||
NodeContainer nodes;
|
||||
...
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: bash
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
@@ -7,7 +8,7 @@ This chapter posts some information about possibly common errors in building
|
||||
or running |ns3| programs.
|
||||
|
||||
Please note that the wiki
|
||||
(`<http://www.nsnam.org/wiki/index.php/Troubleshooting>`_) may have contributed
|
||||
(`<http://www.nsnam.org/wiki/Troubleshooting>`_) may have contributed
|
||||
items.
|
||||
|
||||
Build errors
|
||||
@@ -20,20 +21,22 @@ Sometimes, errors can occur with a program after a successful build. These are
|
||||
run-time errors, and can commonly occur when memory is corrupted or pointer
|
||||
values are unexpectedly null.
|
||||
|
||||
Here is an example of what might occur:::
|
||||
Here is an example of what might occur::
|
||||
|
||||
ns-old:~/ns-3-nsc$ ./waf --run tcp-point-to-point
|
||||
Entering directory `/home/tomh/ns-3-nsc/build'
|
||||
$ ./waf --run tcp-point-to-point
|
||||
Entering directory '/home/tomh/ns-3-nsc/build'
|
||||
Compilation finished successfully
|
||||
Command ['/home/tomh/ns-3-nsc/build/debug/examples/tcp-point-to-point'] exited with code -11
|
||||
|
||||
The error message says that the program terminated unsuccessfully, but it is
|
||||
not clear from this information what might be wrong. To examine more
|
||||
closely, try running it under the `gdb debugger
|
||||
<http://sources.redhat.com/gdb/>`_:::
|
||||
<http://sources.redhat.com/gdb/>`_:
|
||||
|
||||
ns-old:~/ns-3-nsc$ ./waf --run tcp-point-to-point --command-template="gdb %s"
|
||||
Entering directory `/home/tomh/ns-3-nsc/build'
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ ./waf --run tcp-point-to-point --command-template="gdb %s"
|
||||
Entering directory '/home/tomh/ns-3-nsc/build'
|
||||
Compilation finished successfully
|
||||
GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
|
||||
Copyright 2004 Free Software Foundation, Inc.
|
||||
@@ -66,7 +69,9 @@ argument to the command template "gdb %s".
|
||||
This tells us that there was an attempt to dereference a null pointer
|
||||
socketFactory.
|
||||
|
||||
Let's look around line 136 of tcp-point-to-point, as gdb suggests:::
|
||||
Let's look around line 136 of tcp-point-to-point, as gdb suggests:
|
||||
|
||||
.. sourcecode:: cpp
|
||||
|
||||
Ptr<SocketFactory> socketFactory = n2->GetObject<SocketFactory> (Tcp::iid);
|
||||
Ptr<Socket> localSocket = socketFactory->CreateSocket ();
|
||||
@@ -77,6 +82,6 @@ may be null.
|
||||
|
||||
Sometimes you may need to use the `valgrind memory checker
|
||||
<http://valgrind.org>`_ for more subtle errors. Again, you invoke the use of
|
||||
valgrind similarly:::
|
||||
valgrind similarly::
|
||||
|
||||
ns-old:~/ns-3-nsc$ ./waf --run tcp-point-to-point --command-template="valgrind %s"
|
||||
$ ./waf --run tcp-point-to-point --command-template="valgrind %s"
|
||||
|
||||
+170
-40
@@ -34,9 +34,10 @@ SOURCES = \
|
||||
$(SRC)/csma/doc/csma.rst \
|
||||
$(SRC)/dsdv/doc/dsdv.rst \
|
||||
$(SRC)/dsr/doc/dsr.rst \
|
||||
$(SRC)/emu/doc/emu.rst \
|
||||
$(SRC)/mpi/doc/distributed.rst \
|
||||
$(SRC)/energy/doc/energy.rst \
|
||||
$(SRC)/emu/doc/emu.rst \
|
||||
$(SRC)/fd-net-device/doc/fd-net-device.rst \
|
||||
$(SRC)/tap-bridge/doc/tap.rst \
|
||||
$(SRC)/mesh/doc/mesh.rst \
|
||||
$(SRC)/lte/doc/source/lte.rst \
|
||||
@@ -48,6 +49,7 @@ SOURCES = \
|
||||
$(SRC)/propagation/doc/propagation.rst \
|
||||
$(SRC)/network/doc/network-overview.rst \
|
||||
$(SRC)/network/doc/packets.rst \
|
||||
$(SRC)/network/doc/error-model.rst \
|
||||
$(SRC)/network/doc/sockets-api.rst \
|
||||
$(SRC)/network/doc/simple.rst \
|
||||
$(SRC)/network/doc/queue.rst \
|
||||
@@ -56,6 +58,7 @@ SOURCES = \
|
||||
$(SRC)/internet/doc/ipv6.rst \
|
||||
$(SRC)/internet/doc/routing-overview.rst \
|
||||
$(SRC)/internet/doc/tcp.rst \
|
||||
$(SRC)/internet/doc/codel.rst \
|
||||
$(SRC)/mobility/doc/mobility.rst \
|
||||
$(SRC)/olsr/doc/olsr.rst \
|
||||
$(SRC)/openflow/doc/openflow-switch.rst \
|
||||
@@ -64,9 +67,20 @@ SOURCES = \
|
||||
$(SRC)/wimax/doc/wimax.rst \
|
||||
$(SRC)/uan/doc/uan.rst \
|
||||
$(SRC)/topology-read/doc/topology.rst \
|
||||
$(SRC)/stats/doc/statistics.rst \
|
||||
$(SRC)/spectrum/doc/spectrum.rst \
|
||||
$(SRC)/stats/doc/adaptor.rst \
|
||||
$(SRC)/stats/doc/aggregator.rst \
|
||||
$(SRC)/stats/doc/collector.rst \
|
||||
$(SRC)/stats/doc/data-collection-helpers.rst \
|
||||
$(SRC)/stats/doc/data-collection-overview.rst \
|
||||
$(SRC)/stats/doc/data-collection.rst \
|
||||
$(SRC)/stats/doc/probe.rst \
|
||||
$(SRC)/stats/doc/scope-and-limitations.rst \
|
||||
$(SRC)/netanim/doc/animation.rst \
|
||||
$(SRC)/flow-monitor/doc/flow-monitor.rst \
|
||||
$(SRC)/wave/doc/wave.rst \
|
||||
$(SRC)/sixlowpan/doc/sixlowpan.rst \
|
||||
$(SRC)/lr-wpan/doc/lr-wpan.rst \
|
||||
|
||||
# list all model library figure files that need to be copied to
|
||||
# $SOURCETEMP/figures. For each figure to be included in all
|
||||
@@ -89,19 +103,35 @@ SOURCEFIGS = \
|
||||
$(SRC)/wifi/doc/WifiArchitecture.dia \
|
||||
$(SRC)/wifi/doc/snir.dia \
|
||||
$(SRC)/wimax/doc/WimaxArchitecture.dia \
|
||||
$(SRC)/lte/doc/source/figures/epc-ctrl-arch.dia \
|
||||
$(SRC)/lte/doc/source/figures/epc-data-flow-dl.dia \
|
||||
$(SRC)/lte/doc/source/figures/epc-data-flow-ul.dia \
|
||||
$(SRC)/lte/doc/source/figures/epc-profiling-scenario.dia \
|
||||
$(SRC)/lte/doc/source/figures/epc-topology.dia \
|
||||
$(SRC)/lte/doc/source/figures/epc-topology-x2-enhanced.dia \
|
||||
$(SRC)/lte/doc/source/figures/eutran-profiling-scenario.dia \
|
||||
$(SRC)/lte/doc/source/figures/ff-example.dia \
|
||||
$(SRC)/lte/doc/source/figures/ff-mac-saps.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-arch-data-rrc-pdcp-rlc.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-enb-architecture.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-arch-enb-data.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-arch-enb-ctrl.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-arch-ue-data.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-arch-ue-ctrl.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-enb-phy.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-ue-phy.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-epc-x2-handover-seq-diagram.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-epc-e2e-data-protocol-stack.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-interference-test-scenario.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-ue-architecture.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-subframe-structure.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-epc-x2-interface.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-harq-architecture.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-harq-processes-scheme.dia \
|
||||
$(SRC)/lte/doc/source/figures/ue-meas-consumer.dia \
|
||||
$(SRC)/lte/doc/source/figures/ue-meas-piecewise-motion.dia \
|
||||
$(SRC)/lte/doc/source/figures/ue-meas-piecewise-a1.dia \
|
||||
$(SRC)/lte/doc/source/figures/ue-meas-piecewise-a1-hys.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-cell-selection-timeline.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-cell-selection-scenario.dia \
|
||||
$(SRC)/lte/doc/source/figures/lte-handover-target-scenario.dia \
|
||||
$(SRC)/lte/doc/source/figures/lena-dual-stripe.eps \
|
||||
$(SRC)/lte/doc/source/figures/lte-mcs-index.eps \
|
||||
$(SRC)/lte/doc/source/figures/lenaThrTestCase1.eps \
|
||||
@@ -118,12 +148,60 @@ SOURCEFIGS = \
|
||||
$(SRC)/lte/doc/source/figures/lte-rlc-data-retx-dl.eps \
|
||||
$(SRC)/lte/doc/source/figures/lte-rlc-data-txon-ul.eps \
|
||||
$(SRC)/lte/doc/source/figures/lte-rlc-data-retx-ul.eps \
|
||||
$(SRC)/lte/doc/source/figures/fading_pedestrian.png \
|
||||
$(SRC)/lte/doc/source/figures/fading_vehicular.png \
|
||||
$(SRC)/lte/doc/source/figures/fading_urban_3kmph.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-epc-x2-entity-saps.eps \
|
||||
$(SRC)/lte/doc/source/figures/lte-strongest-cell-handover-algorithm.eps \
|
||||
$(SRC)/lte/doc/source/figures/lte-phy-interference.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-phy-interference.png \
|
||||
$(SRC)/lte/doc/source/figures/helpers.pdf \
|
||||
$(SRC)/lte/doc/source/figures/helpers.png \
|
||||
$(SRC)/lte/doc/source/figures/mac-random-access-contention.pdf \
|
||||
$(SRC)/lte/doc/source/figures/mac-random-access-contention.png \
|
||||
$(SRC)/lte/doc/source/figures/mac-random-access-noncontention.pdf \
|
||||
$(SRC)/lte/doc/source/figures/mac-random-access-noncontention.png \
|
||||
$(SRC)/lte/doc/source/figures/rrc-connection-establishment.pdf \
|
||||
$(SRC)/lte/doc/source/figures/rrc-connection-establishment.png \
|
||||
$(SRC)/lte/doc/source/figures/rrc-connection-reconfiguration.pdf \
|
||||
$(SRC)/lte/doc/source/figures/rrc-connection-reconfiguration.png \
|
||||
$(SRC)/lte/doc/source/figures/rrc-connection-reconfiguration-handover.pdf \
|
||||
$(SRC)/lte/doc/source/figures/rrc-connection-reconfiguration-handover.png \
|
||||
$(SRC)/lte/doc/source/figures/nas-attach.pdf \
|
||||
$(SRC)/lte/doc/source/figures/nas-attach.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-enb-rrc-states.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-enb-rrc-states.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-ue-rrc-states.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-ue-rrc-states.png \
|
||||
$(SRC)/lte/doc/source/figures/fading_pedestrian.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fading_pedestrian.png \
|
||||
$(SRC)/lte/doc/source/figures/fading_vehicular.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fading_vehicular.png \
|
||||
$(SRC)/lte/doc/source/figures/fading_urban_3kmph.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fading_urban_3kmph.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-enhanced-fractional-frequency-reuse-scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-enhanced-fractional-frequency-reuse-scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fr-full-frequency-reuse-scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-full-frequency-reuse-scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fr-hard-frequency-reuse-scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-hard-frequency-reuse-scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fr-soft-fractional-frequency-reuse-scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-soft-fractional-frequency-reuse-scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fr-soft-frequency-reuse-scheme-v1.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-soft-frequency-reuse-scheme-v1.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fr-soft-frequency-reuse-scheme-v2.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-soft-frequency-reuse-scheme-v2.pdf \
|
||||
$(SRC)/lte/doc/source/figures/fr-strict-frequency-reuse-scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/fr-strict-frequency-reuse-scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/ffr-distributed-scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/ffr-distributed-scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-soft-1-rem.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-soft-1-rem.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-ffr-soft-2-spectrum-trace.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-ffr-soft-2-spectrum-trace.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-hard-1-rem.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-hard-1-rem.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-hard-2-rem.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-hard-2-rem.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-hard-3-rem.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-fr-hard-3-rem.pdf \
|
||||
$(SRC)/lte/doc/source/figures/MCS_1_4.pdf \
|
||||
$(SRC)/lte/doc/source/figures/MCS_1_4.png \
|
||||
$(SRC)/lte/doc/source/figures/MCS_5_8.pdf \
|
||||
@@ -146,50 +224,60 @@ SOURCEFIGS = \
|
||||
$(SRC)/lte/doc/source/figures/MCS_12_test.pdf \
|
||||
$(SRC)/lte/doc/source/figures/MCS_16_test.png \
|
||||
$(SRC)/lte/doc/source/figures/MCS_16_test.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-phy-interference.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-phy-interference.pdf \
|
||||
$(SRC)/lte/doc/source/figures/helpers.png \
|
||||
$(SRC)/lte/doc/source/figures/helpers.pdf \
|
||||
$(SRC)/lte/doc/source/figures/miesm_scheme.pdf \
|
||||
$(SRC)/lte/doc/source/figures/miesm_scheme.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-phy-interference.seqdiag \
|
||||
$(SRC)/lte/doc/source/figures/helpers.seqdiag \
|
||||
$(SRC)/lte/doc/source/figures/lte-dl-power-control.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-dl-power-control.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-ffr-scheduling.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-ffr-scheduling.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-handover-campaign-rem.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-handover-campaign-rem.png \
|
||||
$(SRC)/lte/doc/source/figures/lte-legacy-handover-algorithm.pdf \
|
||||
$(SRC)/lte/doc/source/figures/lte-legacy-handover-algorithm.png \
|
||||
$(SRC)/uan/doc/auvmobility-classes.dia \
|
||||
$(SRC)/stats/doc/Stat-framework-arch.png \
|
||||
$(SRC)/stats/doc/Wifi-default.png \
|
||||
$(SRC)/netanim/doc/figures/Dumbbell.png \
|
||||
$(SRC)/netanim/doc/figures/Dumbbell.pdf \
|
||||
$(SRC)/stats/doc/dcf-overview.dia \
|
||||
$(SRC)/stats/doc/dcf-overview-with-aggregation.dia \
|
||||
$(SRC)/stats/doc/file-example.png \
|
||||
$(SRC)/stats/doc/gnuplot-aggregator.png \
|
||||
$(SRC)/stats/doc/gnuplot-example.png \
|
||||
$(SRC)/stats/doc/gnuplot-helper-example.png \
|
||||
$(SRC)/stats/doc/seventh-packet-byte-count.png \
|
||||
$(SRC)/netanim/doc/figures/PacketStatistics.png \
|
||||
$(SRC)/netanim/doc/figures/PacketStatistics.pdf \
|
||||
$(SRC)/netanim/doc/figures/FastForward.png \
|
||||
$(SRC)/netanim/doc/figures/FastForward.pdf \
|
||||
$(SRC)/netanim/doc/figures/Wireless.png \
|
||||
$(SRC)/netanim/doc/figures/Wireless.pdf \
|
||||
$(SRC)/netanim/doc/figures/Precision.png \
|
||||
$(SRC)/netanim/doc/figures/Precision.pdf \
|
||||
$(SRC)/netanim/doc/figures/Persist.png \
|
||||
$(SRC)/netanim/doc/figures/Persist.pdf \
|
||||
$(SRC)/netanim/doc/figures/SimTime.png \
|
||||
$(SRC)/netanim/doc/figures/SimTime.pdf \
|
||||
$(SRC)/netanim/doc/figures/NetAnim_3_105.png \
|
||||
$(SRC)/netanim/doc/figures/NetAnim_3_105.pdf \
|
||||
$(SRC)/netanim/doc/figures/Trajectory.png \
|
||||
$(SRC)/netanim/doc/figures/Trajectory.pdf \
|
||||
$(SRC)/netanim/doc/figures/UpdateRateInterval.png \
|
||||
$(SRC)/netanim/doc/figures/UpdateRateInterval.pdf \
|
||||
$(SRC)/netanim/doc/figures/WithoutPrecision.png \
|
||||
$(SRC)/netanim/doc/figures/WithoutPrecision.pdf \
|
||||
$(SRC)/netanim/doc/figures/WithPrecision.png \
|
||||
$(SRC)/netanim/doc/figures/WithPrecision.pdf \
|
||||
$(SRC)/netanim/doc/figures/NodeCountersChart.png \
|
||||
$(SRC)/netanim/doc/figures/NodeCountersChart.pdf \
|
||||
$(SRC)/netanim/doc/figures/NodeCountersTable.png \
|
||||
$(SRC)/netanim/doc/figures/NodeCountersTable.pdf \
|
||||
$(SRC)/netanim/doc/figures/RoutingTables.png \
|
||||
$(SRC)/netanim/doc/figures/RoutingTables.pdf \
|
||||
$(SRC)/netanim/doc/figures/PacketTimeline.png \
|
||||
$(SRC)/netanim/doc/figures/PacketTimeline.pdf \
|
||||
$(SRC)/spectrum/doc/spectrum-channel-phy-interface.png \
|
||||
$(SRC)/spectrum/doc/spectrum-channel-phy-interface.pdf \
|
||||
$(SRC)/spectrum/doc/spectrum-analyzer-example.eps \
|
||||
$(SRC)/lr-wpan/doc/lr-wpan-arch.dia \
|
||||
$(SRC)/lr-wpan/doc/lr-wpan-data-example.dia \
|
||||
$(SRC)/lr-wpan/doc/lr-wpan-primitives.dia \
|
||||
$(SRC)/lr-wpan/doc/802-15-4-ber.eps \
|
||||
$(SRC)/lr-wpan/doc/802-15-4-per-sens.eps \
|
||||
$(SRC)/lr-wpan/doc/802-15-4-psr-distance.eps
|
||||
|
||||
# specify figures from which .png and .pdf figures need to be
|
||||
# generated (all dia and eps figures)
|
||||
IMAGES_EPS = \
|
||||
$(FIGURES)/testbed.eps \
|
||||
$(FIGURES)/emulated-channel.eps \
|
||||
$(FIGURES)/antenna-coordinate-system.eps \
|
||||
$(FIGURES)/packet.eps \
|
||||
$(FIGURES)/node.eps \
|
||||
$(FIGURES)/buffer.eps \
|
||||
$(FIGURES)/sockets-overview.eps \
|
||||
$(FIGURES)/antenna-coordinate-system.eps \
|
||||
$(FIGURES)/internet-node-send.eps \
|
||||
$(FIGURES)/internet-node-recv.eps \
|
||||
$(FIGURES)/routing.eps \
|
||||
@@ -197,19 +285,36 @@ IMAGES_EPS = \
|
||||
$(FIGURES)/WifiArchitecture.eps \
|
||||
$(FIGURES)/snir.eps \
|
||||
$(FIGURES)/WimaxArchitecture.eps \
|
||||
$(FIGURES)/dcf-overview.eps \
|
||||
$(FIGURES)/dcf-overview-with-aggregation.eps \
|
||||
$(FIGURES)/epc-ctrl-arch.eps \
|
||||
$(FIGURES)/epc-data-flow-dl.eps \
|
||||
$(FIGURES)/epc-data-flow-ul.eps \
|
||||
$(FIGURES)/epc-profiling-scenario.eps \
|
||||
$(FIGURES)/epc-topology.eps \
|
||||
$(FIGURES)/epc-topology-x2-enhanced.eps \
|
||||
$(FIGURES)/eutran-profiling-scenario.eps \
|
||||
$(FIGURES)/ff-example.eps \
|
||||
$(FIGURES)/ff-mac-saps.eps \
|
||||
$(FIGURES)/lte-arch-data-rrc-pdcp-rlc.eps \
|
||||
$(FIGURES)/lte-enb-architecture.eps \
|
||||
$(FIGURES)/lte-arch-enb-data.eps \
|
||||
$(FIGURES)/lte-arch-enb-ctrl.eps \
|
||||
$(FIGURES)/lte-arch-ue-data.eps \
|
||||
$(FIGURES)/lte-arch-ue-ctrl.eps \
|
||||
$(FIGURES)/lte-enb-phy.eps \
|
||||
$(FIGURES)/lte-ue-phy.eps \
|
||||
$(FIGURES)/lte-epc-e2e-data-protocol-stack.eps \
|
||||
$(FIGURES)/lte-interference-test-scenario.eps \
|
||||
$(FIGURES)/lte-ue-architecture.eps \
|
||||
$(FIGURES)/lte-subframe-structure.eps \
|
||||
$(FIGURES)/lte-epc-x2-interface.eps \
|
||||
$(FIGURES)/lte-harq-architecture.eps \
|
||||
$(FIGURES)/lte-harq-processes-scheme.eps \
|
||||
$(FIGURES)/ue-meas-consumer.eps \
|
||||
$(FIGURES)/ue-meas-piecewise-motion.eps \
|
||||
$(FIGURES)/ue-meas-piecewise-a1.eps \
|
||||
$(FIGURES)/ue-meas-piecewise-a1-hys.eps \
|
||||
$(FIGURES)/lte-cell-selection-timeline.eps \
|
||||
$(FIGURES)/lte-cell-selection-scenario.eps \
|
||||
$(FIGURES)/lte-handover-target-scenario.eps \
|
||||
$(FIGURES)/lena-dual-stripe.eps \
|
||||
$(FIGURES)/lte-mcs-index.eps \
|
||||
$(FIGURES)/lenaThrTestCase1.eps \
|
||||
@@ -226,7 +331,17 @@ IMAGES_EPS = \
|
||||
$(FIGURES)/lte-rlc-data-retx-dl.eps \
|
||||
$(FIGURES)/lte-rlc-data-txon-ul.eps \
|
||||
$(FIGURES)/lte-rlc-data-retx-ul.eps \
|
||||
$(FIGURES)/lte-epc-x2-handover-seq-diagram.eps \
|
||||
$(FIGURES)/lte-epc-x2-entity-saps.eps \
|
||||
$(FIGURES)/lte-strongest-cell-handover-algorithm.eps \
|
||||
$(FIGURES)/auvmobility-classes.eps \
|
||||
$(FIGURES)/spectrum-analyzer-example.eps \
|
||||
$(FIGURES)/lr-wpan-primitives.eps \
|
||||
$(FIGURES)/lr-wpan-data-example.eps \
|
||||
$(FIGURES)/lr-wpan-arch.eps \
|
||||
$(FIGURES)/802-15-4-ber.eps \
|
||||
$(FIGURES)/802-15-4-per-sens.eps \
|
||||
$(FIGURES)/802-15-4-psr-distance.eps
|
||||
|
||||
# rescale pdf figures as necessary
|
||||
$(FIGURES)/testbed.pdf_width = 5in
|
||||
@@ -242,30 +357,44 @@ $(FIGURES)/routing.pdf_width = 6in
|
||||
$(FIGURES)/routing-specialization.pdf_width = 5in
|
||||
$(FIGURES)/snir.pdf_width = 3in
|
||||
$(FIGURES)/lte-interference-test-scenario.pdf_width = 3in
|
||||
$(FIGURES)/epc-ctrl-arch.pdf_width = 8cm
|
||||
$(FIGURES)/epc-topology.pdf_width = 4in
|
||||
$(FIGURES)/epc-topology-x2-enhanced.pdf_width = 14cm
|
||||
$(FIGURES)/lte-arch-data-rrc-pdcp-rlc.pdf_width = 3in
|
||||
$(FIGURES)/lte-epc-e2e-data-protocol-stack.pdf_width = 15cm
|
||||
$(FIGURES)/ff-mac-saps.pdf_width = 5in
|
||||
$(FIGURES)/ff-example.pdf_width = 5in
|
||||
$(FIGURES)/lte-arch-enb-data.pdf_width = 6cm
|
||||
$(FIGURES)/lte-arch-enb-ctrl.pdf_width = 10cm
|
||||
$(FIGURES)/lte-arch-ue-data.pdf_width = 6cm
|
||||
$(FIGURES)/lte-arch-ue-ctrl.pdf_width = 10cm
|
||||
$(FIGURES)/lte-rlc-implementation-model.pdf_width = 20in
|
||||
$(FIGURES)/lte-rlc-data-txon-dl.pdf_width = 10cm
|
||||
$(FIGURES)/lte-rlc-data-txon-ul.pdf_width = 10cm
|
||||
$(FIGURES)/lte-rlc-data-retx-ul.pdf_width = 10cm
|
||||
$(FIGURES)/lte-phy-interference.pdf_width = 12cm
|
||||
$(FIGURES)/lte-subframe-structure.pdf_width = 2in
|
||||
$(FIGURES)/mac-random-access-contention.pdf_width = 10cm
|
||||
$(FIGURES)/mac-random-access-noncontention.pdf_width = 15cm
|
||||
$(FIGURES)/helpers.pdf_width = 8cm
|
||||
$(FIGURES)/auvmobility-classes.pdf_width = 10cm
|
||||
$(FIGURES)/spectrum-analyzer-example.pdf_width = 15cm
|
||||
$(FIGURES)/lr-wpan-primitives.pdf_width = 3in
|
||||
$(FIGURES)/lr-wpan-arch.pdf_width = 2in
|
||||
|
||||
IMAGES_PNG = ${IMAGES_EPS:.eps=.png}
|
||||
IMAGES_PDF = ${IMAGES_EPS:.eps=.pdf}
|
||||
|
||||
IMAGES = $(IMAGES_EPS) $(IMAGES_PNG) $(IMAGES_PDF)
|
||||
|
||||
RESCALE = ../../utils/rescale-pdf.sh
|
||||
|
||||
%.eps : %.dia; $(DIA) -t eps $< -e $@
|
||||
%.png : %.dia; $(DIA) -t png $< -e $@
|
||||
%.png : %.eps; $(CONVERT) $< $@
|
||||
%.pdf : %.eps
|
||||
$(EPSTOPDF) $< -o=$@
|
||||
if test x$($@_width) != x; then ./rescale-pdf.sh $($@_width) $@ ; fi
|
||||
@if test x$($@_width) != x; then $(RESCALE) $($@_width) $@ ; fi
|
||||
|
||||
# You can set these variables from the command line.
|
||||
SPHINXOPTS =
|
||||
@@ -280,6 +409,8 @@ ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) $(S
|
||||
|
||||
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest
|
||||
|
||||
.NOTPARALLEL:
|
||||
|
||||
help:
|
||||
@echo "Please use \`make <target>' where <target> is one of"
|
||||
@echo " html to make standalone HTML files"
|
||||
@@ -300,11 +431,10 @@ help:
|
||||
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
|
||||
|
||||
copy-sources: $(SOURCES)
|
||||
@rm -rf $(SOURCETEMP)
|
||||
@mkdir -p $(SOURCETEMP)
|
||||
@mkdir -p $(FIGURES)
|
||||
@cp -r $(SOURCES) $(SOURCETEMP)
|
||||
@cp -r $(SOURCEFIGS) $(FIGURES)
|
||||
@cp -r -p $(SOURCES) $(SOURCETEMP)
|
||||
@cp -r -p $(SOURCEFIGS) $(FIGURES)
|
||||
|
||||
clean:
|
||||
-rm -rf $(BUILDDIR)/*
|
||||
|
||||
Binary file not shown.
@@ -1,14 +0,0 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
TMPDIR=/tmp
|
||||
|
||||
TMPFILE=`mktemp`
|
||||
|
||||
echo "\documentclass{book}
|
||||
\usepackage{pdfpages}
|
||||
\begin{document}
|
||||
\includepdf[width=${1},fitpaper]{${2}}
|
||||
\end{document}" >${TMPFILE}.tex
|
||||
pdflatex -output-directory /tmp ${TMPFILE}.tex >/dev/null 2>/dev/null
|
||||
cp ${TMPFILE}.pdf ${2}
|
||||
rm -f ${TMPFILE}{,.{tex,aux,log,pdf}}
|
||||
@@ -5,17 +5,28 @@ Emulation Overview
|
||||
|
||||
|ns3| has been designed for integration into testbed and virtual machine
|
||||
environments. We have addressed this need by providing two kinds of net devices.
|
||||
The first kind, which we call an ``Emu`` ``NetDevice`` allows |ns3| simulations
|
||||
The first kind of device is a file descriptor net device (``FdNetDevice``),
|
||||
which is a generic device type that can read and write from a file descriptor.
|
||||
By associating this file descriptor with different things on the host
|
||||
system, different capabilities can be provided. For instance, the
|
||||
FdNetDevice can be associated with an underlying packet socket to provide
|
||||
emulation capabilities. This allows |ns3| simulations
|
||||
to send data on a "real" network. The second kind, called a ``Tap``
|
||||
``NetDevice`` allows a "real" host to participate in an |ns3| simulation as if
|
||||
it were one of the simulated nodes. An |ns3| simulation may be constructed with
|
||||
any combination of simulated, ``Emu``, or ``Tap`` devices.
|
||||
any combination of simulated or emulated devices.
|
||||
|
||||
**Note:** Prior to ns-3.17, the emulation capability was provided by a
|
||||
special device called an ``Emu`` NetDevice; the ``Emu`` NetDevice has
|
||||
been superseded by the ``FdNetDevice``, and will be deprecated and removed
|
||||
in future revisions of |ns3|.
|
||||
|
||||
One of the use-cases we want to support is that of a testbed. A concrete example
|
||||
of an environment of this kind is the ORBIT testbed. ORBIT is a laboratory
|
||||
emulator/field trial network arranged as a two dimensional grid of 400 802.11
|
||||
radio nodes. We integrate with ORBIT by using their "imaging" process to load
|
||||
and run |ns3| simulations on the ORBIT array. We use our ``Emu`` ``NetDevice``
|
||||
and run |ns3| simulations on the ORBIT array. We can use our
|
||||
``EmuFdNetDevice``
|
||||
to drive the hardware in the testbed and we can accumulate results either using
|
||||
the |ns3| tracing and logging functions, or the native ORBIT data gathering
|
||||
techniques. See `<http://www.orbit-lab.org/>`_ for details on the ORBIT
|
||||
@@ -73,4 +84,5 @@ simulated |ns3| networks.
|
||||
.. toctree::
|
||||
|
||||
emu
|
||||
fd-net-device
|
||||
tap
|
||||
|
||||
@@ -8,13 +8,13 @@ available in five forms:
|
||||
|
||||
* `ns-3 Doxygen <http://www.nsnam.org/doxygen/index.html>`_: Documentation of the public APIs of the simulator
|
||||
* Tutorial, Manual, and Model Library *(this document)* for the `latest release <http://www.nsnam.org/documentation/latest/>`_ and `development tree <http://www.nsnam.org/ns-3-dev/documentation/>`_
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/index.php/Main_Page>`_
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki>`_
|
||||
|
||||
This document is written in `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ for `Sphinx <http://sphinx.pocoo.org/>`_ and is maintained in the
|
||||
``doc/models`` directory of ns-3's source code.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:maxdepth: 1
|
||||
|
||||
organization
|
||||
animation
|
||||
@@ -26,12 +26,14 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
|
||||
buildings
|
||||
click
|
||||
csma
|
||||
data-collection
|
||||
dsdv
|
||||
dsr
|
||||
emulation-overview
|
||||
energy
|
||||
flow-monitor
|
||||
internet-models
|
||||
lr-wpan
|
||||
lte
|
||||
mesh
|
||||
distributed
|
||||
@@ -41,8 +43,10 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
|
||||
openflow-switch
|
||||
point-to-point
|
||||
propagation
|
||||
statistics
|
||||
spectrum
|
||||
sixlowpan
|
||||
topology
|
||||
uan
|
||||
wave
|
||||
wifi
|
||||
wimax
|
||||
|
||||
@@ -8,3 +8,4 @@ Internet Models
|
||||
ipv6
|
||||
routing-overview
|
||||
tcp
|
||||
codel
|
||||
|
||||
@@ -4,6 +4,7 @@ Network Module
|
||||
.. toctree::
|
||||
|
||||
packets
|
||||
error-model
|
||||
network-overview
|
||||
sockets-api
|
||||
simple
|
||||
|
||||
@@ -34,7 +34,13 @@ Finally, additional documentation about various aspects of |ns3| may
|
||||
exist on the `project wiki <http://www.nsnam.org/wiki>`_.
|
||||
|
||||
A sample outline of how to write model library documentation can be
|
||||
found in :mod:`src/template/doc`.
|
||||
found by executing the ``create-module.py`` program and looking at the
|
||||
template created in the file ``new-module/doc/new-module.rst``.
|
||||
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ cd src
|
||||
$ ./create-module.py new-module
|
||||
|
||||
The remainder of this document is organized alphabetically by module name.
|
||||
|
||||
|
||||
+25
-16
@@ -1,33 +1,42 @@
|
||||
/**
|
||||
* @anchor modules_anchor
|
||||
*
|
||||
* @defgroup constructs C++ Constructs Used by All Modules
|
||||
* \brief These are C++ constructs defined by the modules.
|
||||
*
|
||||
* @defgroup constants Constants
|
||||
* @brief Constants you can change
|
||||
*
|
||||
* @defgroup utils Utils
|
||||
* @brief The utils directory is for various programs and scripts related
|
||||
* to code coverage, test suites, style checking, and benchmarking.
|
||||
*
|
||||
*/
|
||||
/**
|
||||
* @defgroup core Core
|
||||
* \brief The "core" module contains:
|
||||
* - a time management class to hold a time and convert between various time units: ns3::Time
|
||||
* - a scheduler base class used to implement new simulation event schedulers:
|
||||
* - a time management class to hold a time and convert between various
|
||||
* time units: ns3::Time
|
||||
* - a scheduler base class used to implement new simulation event
|
||||
* schedulers:
|
||||
* ns3::Scheduler and ns3::SchedulerFactory
|
||||
* - a simulator class used to create, schedule and cancel events: ns3::Simulator
|
||||
* - a simulator class used to create, schedule and cancel events:
|
||||
* ns3::Simulator
|
||||
* - a Functor class: ns3::Callback
|
||||
* - an os-independent interface to get access to the elapsed wall clock time: ns3::SystemWallClockMs
|
||||
* - a class to register regression tests with the test manager: ns3::Test and ns3::TestManager
|
||||
* - debugging facilities: \ref logging, \ref assert
|
||||
* - an os-independent interface to get access to the elapsed wall clock
|
||||
* time: ns3::SystemWallClockMs
|
||||
* - a class to register regression tests with the test manager: ns3::Test
|
||||
* and ns3::TestManager
|
||||
* - debugging facilities: \ref debugging
|
||||
* - \ref randomvariable
|
||||
* - a base class for objects which need to support per-instance "attributes" and
|
||||
* trace sources: ns3::ObjectBase
|
||||
* - a base class for objects which need to support per-instance
|
||||
* "attributes" and trace sources: ns3::ObjectBase
|
||||
* - a base class for objects which need to support reference counting
|
||||
* and dynamic object aggregation: ns3::Object
|
||||
* - a smart-pointer class ns3::Ptr designed to work together with ns3::Object
|
||||
* - a configuration class used to set and control all attributes and trace sources
|
||||
* in a simulation: ns3::Config.
|
||||
*
|
||||
* - a smart-pointer class ns3::Ptr designed to work together with
|
||||
* ns3::Object
|
||||
* - a configuration class used to set and control all attributes and
|
||||
* trace sources in a simulation: ns3::Config.
|
||||
*/
|
||||
/**
|
||||
* @ingroup core
|
||||
* @defgroup debugging Debugging tools
|
||||
*
|
||||
* @brief Assertions, breakpoints, logging, and abnormal program termination
|
||||
*/
|
||||
|
||||
@@ -21,7 +21,7 @@
|
||||
# to force us into the public case.)
|
||||
#
|
||||
# The approach to identify cases 1 & 2 is to test:
|
||||
# a. We're on nsnam.org (actually, nsnam.ece.gatech.edu), and
|
||||
# a. We're on nsnam.org (actually, nsnam-www.coe-hosted.gatech.edu), and
|
||||
# b. We're in the tmp build directory, /tmp/daily-nsnam/
|
||||
# (This is the directory used by the update-* scripts
|
||||
# run by cron jobs.)
|
||||
@@ -71,6 +71,7 @@ EOF
|
||||
|
||||
# script arguments
|
||||
say
|
||||
say using doxygen: $(which doxygen) $(doxygen --version)
|
||||
public=0
|
||||
nsnam=0
|
||||
daily=0
|
||||
@@ -91,9 +92,9 @@ while getopts :pndth option ; do
|
||||
esac
|
||||
done
|
||||
|
||||
# Hostname, fully qualified, e.g. nsnam.ece.gatech.edu
|
||||
# Hostname, fully qualified, e.g. nsnam-www.coe-hosted.gatech.edu
|
||||
HOST=`hostname`
|
||||
NSNAM="nsnam.ece.gatech.edu"
|
||||
NSNAM="nsnam-www.coe-hosted.gatech.edu"
|
||||
|
||||
# Build directory
|
||||
DAILY="^/tmp/daily-nsnam/"
|
||||
@@ -201,8 +202,9 @@ fi
|
||||
# by Sphinx when rebuilding
|
||||
cd doc 2>&1 >/dev/null
|
||||
for d in {manual,models,tutorial{,-pt-br}}/build/{single,}html/_static/ ; do
|
||||
# expect the copy to fail if the destination dir
|
||||
# hasn't been created by a prior doc build
|
||||
if [ ! -d $d ]; then
|
||||
mkdir -p $d
|
||||
fi
|
||||
cp ns3_html_theme/static/ns3_version.js $d
|
||||
done
|
||||
cd - 2>&1 >/dev/null
|
||||
@@ -211,4 +213,4 @@ cd - 2>&1 >/dev/null
|
||||
say
|
||||
say "outf = $outf:"
|
||||
cat -n $outf
|
||||
say Done.
|
||||
say Done.
|
||||
|
||||
@@ -1,3 +1,7 @@
|
||||
<!-- ns-3 doxygen header, based on
|
||||
HTML header for doxygen 1.8.3.1
|
||||
Verified compatible with 1.8.6
|
||||
-->
|
||||
<!-- start footer part -->
|
||||
<!--BEGIN GENERATE_TREEVIEW-->
|
||||
<div id="nav-path" class="navpath"><!-- id is needed for treeview function! -->
|
||||
|
||||
@@ -1,18 +1,23 @@
|
||||
<!-- ns-3 doxygen header, based on
|
||||
HTML header for doxygen 1.8.3.1
|
||||
Verified compatible with 1.8.6
|
||||
-->
|
||||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"></meta>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=9"></meta>
|
||||
<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
|
||||
<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
|
||||
<link href="$relpath$tabs.css" rel="stylesheet" type="text/css"></link>
|
||||
<script type="text/javascript" src="$relpath$jquery.js"></script>
|
||||
<script type="text/javascript" src="$relpath$dynsections.js"></script>
|
||||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
|
||||
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
|
||||
<meta name="generator" content="Doxygen $doxygenversion"/>
|
||||
<!--BEGIN PROJECT_NAME--><title>$projectname: $title</title><!--END PROJECT_NAME-->
|
||||
<!--BEGIN !PROJECT_NAME--><title>$title</title><!--END !PROJECT_NAME-->
|
||||
<link href="$relpath^tabs.css" rel="stylesheet" type="text/css"/>
|
||||
<script type="text/javascript" src="$relpath^jquery.js"></script>
|
||||
<script type="text/javascript" src="$relpath^dynsections.js"></script>
|
||||
$treeview
|
||||
$search
|
||||
$mathjax
|
||||
<link href="$relpath$doxygen.css" rel="stylesheet" type="text/css"></link>
|
||||
<link href="$relpath$ns3_stylesheet.css" rel="stylesheet" type="text/css"></link>
|
||||
<link href="$relpath^$stylesheet" rel="stylesheet" type="text/css" />
|
||||
$extrastylesheet
|
||||
<link href="$relpath$favicon.ico" rel="shortcut icon" type="image/ico"></link>
|
||||
<script type="text/javascript" src="$relpath$drop-down-menu.js"></script>
|
||||
<script type="text/javascript" src="$relpath$ns3_version.js"></script>
|
||||
@@ -99,7 +104,7 @@ $mathjax
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
<script type="text/javascript">ns3_write_links()</script>
|
||||
<script type="text/javascript">ns3_write_links();</script>
|
||||
</div>
|
||||
<!--END TITLEAREA-->
|
||||
<!-- end header part -->
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -25,6 +25,11 @@ div.body h6 {
|
||||
background-image: url('nav_f.png');
|
||||
}
|
||||
|
||||
/* Sphinx figure captions */
|
||||
p.caption {
|
||||
font-weight: bold;
|
||||
}
|
||||
|
||||
/* Doxygen side bar */
|
||||
#nav-tree {
|
||||
font-size: 12px;
|
||||
@@ -185,7 +190,7 @@ div.sphinxsidebar a {
|
||||
|
||||
#ns3-menu .menu div {
|
||||
background: #94A901;
|
||||
background-size: 100%; 100%
|
||||
background-size: 100%;
|
||||
color:#ffffff;
|
||||
position: absolute;
|
||||
visibility: hidden;
|
||||
|
||||
+11
-6
@@ -31,7 +31,7 @@ and/or the buildbots have been testing
|
||||
-- ./waf --pyrun src/flow-monitor/examples/wifi-olsr-flowmon.py --vis
|
||||
- ensure that tests pass (./test.py -g) and make sure that the buildbots
|
||||
are reporting blue based on the tip of the repository
|
||||
- revise and check in AUTHORS, RELEASE_NOTES, and CHANGES>html
|
||||
- revise and check in AUTHORS, RELEASE_NOTES, and CHANGES.html
|
||||
- required versions for related libraries (nsc, netanim, pybindgen)
|
||||
are correct
|
||||
- confirm that Doxygen builds cleanly (./waf doxygen),
|
||||
@@ -102,7 +102,7 @@ do not plan to further touch ns-3-dev, tag ns-3-dev
|
||||
- change the string 3-dev in the VERSION file to the real version
|
||||
(e.g. 3.14) This must agree with the version name you chose in the clone.
|
||||
- change the version and release string for the documentation in
|
||||
doc/manual/source, doc/tutorial/source, doc/tutorial-pt/source,
|
||||
doc/manual/source, doc/tutorial/source, doc/tutorial-pt-br/source,
|
||||
and doc/models/source conf.py files
|
||||
This should hopefully be updated in the future to simply pull from the
|
||||
VERSION file.
|
||||
@@ -140,12 +140,13 @@ preparing the documentation
|
||||
|
||||
1. If final release, build release documentation
|
||||
- sudo bash; su nsnam; cd /home/nsnam/bin
|
||||
./update-doxygen-release ns-3.x
|
||||
./update-manual-release ns-3.x
|
||||
./update-tutorial-release ns-3.x
|
||||
./update-docs -r http://code.nsnam.org/ns-3.x -R
|
||||
|
||||
2. Check if these new files are available on the website
|
||||
|
||||
3. In ns-3-dev, edit the tutorial "Getting Started" page to
|
||||
update the release version numbers.
|
||||
|
||||
preparing the Wordpress-based main website
|
||||
------------------------------------------
|
||||
|
||||
@@ -157,6 +158,7 @@ http://www.nsnam.org/ns-3.x
|
||||
- Documentation
|
||||
|
||||
2. Repoint http://www.nsnam.org/releases/latest to the new page
|
||||
Repoint http://www.nsnam.org/documentation/latest to the new page
|
||||
Repoint /var/www/html/doxygen-release to the new release doxygen.
|
||||
|
||||
3. Update the Older Releases page to create an entry for the previous
|
||||
@@ -166,7 +168,10 @@ Documentation)
|
||||
4. The main page http://www.nsnam.org should point to
|
||||
ns-3.x in the "Download" and "Documentation" boxes
|
||||
|
||||
5. Create a blog entry to announce release
|
||||
5. The releases page http://www.nsnam.org must be updated (including
|
||||
source tarball link)
|
||||
|
||||
6. Create a blog entry to announce release
|
||||
|
||||
ns-3 wiki edits
|
||||
---------------
|
||||
|
||||
@@ -25,6 +25,8 @@ IMAGES = $(IMAGES_EPS) $(IMAGES_PNG) $(IMAGES_PDF)
|
||||
|
||||
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest
|
||||
|
||||
.NOTPARALLEL:
|
||||
|
||||
%.eps : %.dia; $(DIA) -t eps $< -e $@
|
||||
%.png : %.dia; $(DIA) -t png $< -e $@
|
||||
%.pdf : %.eps; $(EPSTOPDF) $< -o=$@
|
||||
|
||||
@@ -30,9 +30,9 @@ Baixando o ns-3
|
||||
present on your system before proceeding. |ns3| provides a wiki
|
||||
for your reading pleasure that includes pages with many useful hints and tips.
|
||||
One such page is the "Installation" page,
|
||||
http://www.nsnam.org/wiki/index.php/Installation.
|
||||
http://www.nsnam.org/wiki/Installation.
|
||||
|
||||
O |ns3|, como um todo, é bastante complexo e possui várias dependências. Isto também é verdade para as ferramentas que fornecem suporte ao |ns3| (exemplos, `"GNU toolchain"`, Mercurial e um editor para a programação), desta forma é necessário assegurar que várias bibliotecas estejam presentes no sistema. O |ns3| fornece um Wiki com várias dicas sobre o sistema. Uma das páginas do Wiki é a página de instalação (`"Installation"`) que está disponível em: http://www.nsnam.org/wiki/index.php/Installation.
|
||||
O |ns3|, como um todo, é bastante complexo e possui várias dependências. Isto também é verdade para as ferramentas que fornecem suporte ao |ns3| (exemplos, `"GNU toolchain"`, Mercurial e um editor para a programação), desta forma é necessário assegurar que várias bibliotecas estejam presentes no sistema. O |ns3| fornece um Wiki com várias dicas sobre o sistema. Uma das páginas do Wiki é a página de instalação (`"Installation"`) que está disponível em: http://www.nsnam.org/wiki/Installation.
|
||||
|
||||
..
|
||||
The "Prerequisites" section of this wiki page explains which packages are
|
||||
@@ -740,7 +740,7 @@ Agora, ao executar o programa ``hello-simulator`` devemos ter a seguinte a sa
|
||||
..
|
||||
If you want to run programs under another tool such as gdb or valgrind,
|
||||
see this `wiki entry
|
||||
<http://www.nsnam.org/wiki/index.php/User_FAQ#How_to_run_NS-3_programs_under_another_tool>`_.
|
||||
<http://www.nsnam.org/wiki/User_FAQ#How_to_run_NS-3_programs_under_another_tool>`_.
|
||||
|
||||
Se o leitor for executar seus programas sob outras ferramentas, tais como Gdb ou Valgrind, é recomendável que leia a seguinte `entrada no Wiki <http://www.nsnam.org/wiki/index.php/User_FAQ#How_to_run_NS-3_programs_under_another_tool>`_.
|
||||
Se o leitor for executar seus programas sob outras ferramentas, tais como Gdb ou Valgrind, é recomendável que leia a seguinte `entrada no Wiki <http://www.nsnam.org/wiki/User_FAQ#How_to_run_NS-3_programs_under_another_tool>`_.
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ Este
|
||||
|
||||
* Tutorial *(este documento)*, manual, modelos de bibliotecas para a `última release <http://www.nsnam.org/documentation/latest/>`_ e `árvore de desenvolvimento <http://www.nsnam.org/ns-3-dev/documentation/>`_;
|
||||
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/index.php/Main_Page>`_.
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/Main_Page>`_.
|
||||
|
||||
..
|
||||
This document is written in `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ for `Sphinx <http://sphinx.pocoo.org/>`_ and is maintained in the
|
||||
|
||||
@@ -132,15 +132,15 @@ O |ns3|
|
||||
|
||||
* Licença de código aberto compatível com GNU GPLv2;
|
||||
|
||||
* `Wiki <http://www.nsnam.org/wiki/index.php>`_;
|
||||
* `Wiki <http://www.nsnam.org/wiki>`_;
|
||||
|
||||
..
|
||||
* `Contributed Code
|
||||
<http://www.nsnam.org/wiki/index.php/Contributed_Code>`_ page, similar to ns-2's popular Contributed Code
|
||||
<http://www.nsnam.org/wiki/Contributed_Code>`_ page, similar to ns-2's popular Contributed Code
|
||||
`page
|
||||
<http://nsnam.isi.edu/nsnam/index.php/Contributed_Code>`_
|
||||
|
||||
* Página para `contribuição com o código <http://www.nsnam.org/wiki/index.php/Contributed_Code>`_, similar a página de contribuição do `ns-2 <http://nsnam.isi.edu/nsnam/index.php/Contributed_Code>`_;
|
||||
* Página para `contribuição com o código <http://www.nsnam.org/wiki/Contributed_Code>`_, similar a página de contribuição do `ns-2 <http://nsnam.isi.edu/nsnam/index.php/Contributed_Code>`_;
|
||||
|
||||
..
|
||||
* Open `bug tracker
|
||||
|
||||
@@ -25,6 +25,8 @@ IMAGES = $(IMAGES_EPS) $(IMAGES_PNG) $(IMAGES_PDF)
|
||||
|
||||
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest
|
||||
|
||||
.NOTPARALLEL:
|
||||
|
||||
%.eps : %.dia; $(DIA) -t eps $< -e $@
|
||||
%.png : %.dia; $(DIA) -t png $< -e $@
|
||||
%.pdf : %.eps; $(EPSTOPDF) $< -o=$@
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
Building Topologies
|
||||
-------------------
|
||||
@@ -337,10 +337,10 @@ the scratch directory and use waf to build just as you did with
|
||||
the ``first.cc`` example. If you are in the top-level directory of the
|
||||
repository you just type,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
cp examples/tutorial/second.cc scratch/mysecond.cc
|
||||
./waf
|
||||
$ cp examples/tutorial/second.cc scratch/mysecond.cc
|
||||
$ ./waf
|
||||
|
||||
Warning: We use the file ``second.cc`` as one of our regression tests to
|
||||
verify that it works exactly as we think it should in order to make your
|
||||
@@ -353,15 +353,15 @@ If you are following the tutorial religiously (you are, aren't you) you will
|
||||
still have the NS_LOG variable set, so go ahead and clear that variable and
|
||||
run the program.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export NS_LOG=
|
||||
./waf --run scratch/mysecond
|
||||
$ export NS_LOG=
|
||||
$ ./waf --run scratch/mysecond
|
||||
|
||||
Since we have set up the UDP echo applications to log just as we did in
|
||||
``first.cc``, you will see similar output when you run the script.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
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'
|
||||
@@ -381,7 +381,7 @@ the server.
|
||||
If you now go and look in the top level directory, you will find three trace
|
||||
files:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
second-0-0.pcap second-1-0.pcap second-2-0.pcap
|
||||
|
||||
@@ -403,13 +403,13 @@ promiscuous-mode trace.
|
||||
Now, let's follow the echo packet through the internetwork. First, do a
|
||||
tcpdump of the trace file for the leftmost point-to-point node --- node zero.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r second-0-0.pcap
|
||||
$ tcpdump -nn -tt -r second-0-0.pcap
|
||||
|
||||
You should see the contents of the pcap file displayed:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-0-0.pcap, link-type PPP (PPP)
|
||||
2.000000 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
@@ -422,14 +422,14 @@ device associated with IP address 10.1.1.1 headed for IP address
|
||||
point-to-point link and be received by the point-to-point net device on node
|
||||
one. Let's take a look:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r second-1-0.pcap
|
||||
$ tcpdump -nn -tt -r second-1-0.pcap
|
||||
|
||||
You should now see the pcap trace output of the other side of the point-to-point
|
||||
link:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-1-0.pcap, link-type PPP (PPP)
|
||||
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
@@ -444,13 +444,13 @@ pop out on that device headed for its ultimate destination.
|
||||
Remember that we selected node 2 as the promiscuous sniffer node for the CSMA
|
||||
network so let's then look at second-2-0.pcap and see if its there.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r second-2-0.pcap
|
||||
$ tcpdump -nn -tt -r second-2-0.pcap
|
||||
|
||||
You should now see the promiscuous dump of node two, device zero:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-2-0.pcap, link-type EN10MB (Ethernet)
|
||||
2.003696 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
|
||||
@@ -471,7 +471,7 @@ exchange, but is sniffing the network and reporting all of the traffic it sees.
|
||||
|
||||
This exchange is seen in the following lines,
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
2.003696 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
|
||||
2.003707 arp reply 10.1.2.4 is-at 00:00:00:00:00:06
|
||||
@@ -479,7 +479,7 @@ This exchange is seen in the following lines,
|
||||
Then node one, device one goes ahead and sends the echo packet to the UDP echo
|
||||
server at IP address 10.1.2.4.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
2.003801 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
|
||||
@@ -490,40 +490,41 @@ routing and it has figured all of this out for us. But, the echo server node
|
||||
doesn't know the MAC address of the first CSMA node, so it has to ARP for it
|
||||
just like the first CSMA node had to do.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
2.003811 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4
|
||||
2.003822 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
|
||||
|
||||
The server then sends the echo back to the forwarding node.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
2.003915 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
|
||||
|
||||
Looking back at the rightmost node of the point-to-point link,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r second-1-0.pcap
|
||||
$ tcpdump -nn -tt -r second-1-0.pcap
|
||||
|
||||
You can now see the echoed packet coming back onto the point-to-point link as
|
||||
the last line of the trace dump.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-1-0.pcap, link-type PPP (PPP)
|
||||
2.003686 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
2.003915 IP 10.1.2.4.9 > 10.1.1.1.49153: UDP, length 1024
|
||||
|
||||
Lastly, you can look back at the node that originated the echo
|
||||
::
|
||||
|
||||
tcpdump -nn -tt -r second-0-0.pcap
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ tcpdump -nn -tt -r second-0-0.pcap
|
||||
|
||||
and see that the echoed packet arrives back at the source at 2.007602 seconds,
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-0-0.pcap, link-type PPP (PPP)
|
||||
2.000000 IP 10.1.1.1.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
@@ -535,13 +536,13 @@ the same way as when we looked at changing the number of packets echoed in the
|
||||
``first.cc`` example. Try running the program with the number of "extra"
|
||||
devices set to four:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/mysecond --nCsma=4"
|
||||
$ ./waf --run "scratch/mysecond --nCsma=4"
|
||||
|
||||
You should now see,
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
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'
|
||||
@@ -602,20 +603,20 @@ determining node numbers much easier in complex topologies.
|
||||
Let's clear the old trace files out of the top-level directory to avoid confusion
|
||||
about what is going on,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
rm *.pcap
|
||||
rm *.tr
|
||||
$ rm *.pcap
|
||||
$ rm *.tr
|
||||
|
||||
If you build the new script and run the simulation setting ``nCsma`` to 100,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/mysecond --nCsma=100"
|
||||
$ ./waf --run "scratch/mysecond --nCsma=100"
|
||||
|
||||
you will see the following output:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
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'
|
||||
@@ -628,7 +629,7 @@ Note that the echo server is now located at 10.1.2.101 which corresponds to
|
||||
having 100 "extra" CSMA nodes with the echo server on the last one. If you
|
||||
list the pcap files in the top level directory you will see,
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
second-0-0.pcap second-100-0.pcap second-101-0.pcap
|
||||
|
||||
@@ -643,15 +644,15 @@ To illustrate the difference between promiscuous and non-promiscuous traces, we
|
||||
also requested a non-promiscuous trace for the next-to-last node. Go ahead and
|
||||
take a look at the ``tcpdump`` for ``second-100-0.pcap``.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r second-100-0.pcap
|
||||
$ tcpdump -nn -tt -r second-100-0.pcap
|
||||
|
||||
You can now see that node 100 is really a bystander in the echo exchange. The
|
||||
only packets that it receives are the ARP requests which are broadcast to the
|
||||
entire CSMA network.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-100-0.pcap, link-type EN10MB (Ethernet)
|
||||
2.003696 arp who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
|
||||
@@ -659,13 +660,13 @@ entire CSMA network.
|
||||
|
||||
Now take a look at the ``tcpdump`` for ``second-101-0.pcap``.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r second-101-0.pcap
|
||||
$ tcpdump -nn -tt -r second-101-0.pcap
|
||||
|
||||
You can now see that node 101 is really the participant in the echo exchange.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file second-101-0.pcap, link-type EN10MB (Ethernet)
|
||||
2.003696 arp who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
|
||||
@@ -1180,16 +1181,16 @@ script into the scratch directory and use Waf to build just as you did with
|
||||
the ``second.cc`` example. If you are in the top-level directory of the
|
||||
repository you would type,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
cp examples/third.cc scratch/mythird.cc
|
||||
./waf
|
||||
./waf --run scratch/mythird
|
||||
$ cp examples/third.cc scratch/mythird.cc
|
||||
$ ./waf
|
||||
$ ./waf --run scratch/mythird
|
||||
|
||||
Again, since we have set up the UDP echo applications just as we did in the
|
||||
``second.cc`` script, you will see similar output.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
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'
|
||||
@@ -1209,7 +1210,7 @@ that it has received its echo back from the server.
|
||||
If you now go and look in the top level directory, you will find four trace
|
||||
files from this simulation, two from node zero and two from node one:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap
|
||||
|
||||
@@ -1224,13 +1225,13 @@ the code?
|
||||
Since the echo client is on the Wifi network, let's start there. Let's take
|
||||
a look at the promiscuous (monitor mode) trace we captured on that network.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r third-0-1.pcap
|
||||
$ tcpdump -nn -tt -r third-0-1.pcap
|
||||
|
||||
You should see some wifi-looking contents you haven't seen here before:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file third-0-1.pcap, link-type IEEE802_11 (802.11)
|
||||
0.000025 Beacon (ns-3-ssid) [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
|
||||
@@ -1258,13 +1259,13 @@ trace dump.
|
||||
|
||||
Now, look at the pcap file of the right side of the point-to-point link,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r third-0-0.pcap
|
||||
$ tcpdump -nn -tt -r third-0-0.pcap
|
||||
|
||||
Again, you should see some familiar looking contents:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file third-0-0.pcap, link-type PPP (PPP)
|
||||
2.002160 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
@@ -1275,13 +1276,13 @@ again across the point-to-point link.
|
||||
|
||||
Now, look at the pcap file of the right side of the point-to-point link,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r third-1-0.pcap
|
||||
$ tcpdump -nn -tt -r third-1-0.pcap
|
||||
|
||||
Again, you should see some familiar looking contents:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file third-1-0.pcap, link-type PPP (PPP)
|
||||
2.005846 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
|
||||
@@ -1294,13 +1295,13 @@ as you might expect.
|
||||
The echo server is on the CSMA network, let's look at the promiscuous trace
|
||||
there:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r third-1-1.pcap
|
||||
$ tcpdump -nn -tt -r third-1-1.pcap
|
||||
|
||||
You should see some familiar looking contents:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
reading from file third-1-1.pcap, link-type EN10MB (Ethernet)
|
||||
2.005846 ARP, Request who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1, length 50
|
||||
@@ -1326,7 +1327,8 @@ connect the two. We will use the mobility model predefined course change
|
||||
trace source to originate the trace events. We will need to write a trace
|
||||
sink to connect to that source that will display some pretty information for
|
||||
us. Despite its reputation as being difficult, it's really quite simple.
|
||||
Just before the main program of the ``scratch/mythird.cc`` script, add the
|
||||
Just before the main program of the ``scratch/mythird.cc`` script (i.e.,
|
||||
just after the ``NS_LOG_COMPONENT_DEFINE`` statement), add the
|
||||
following function:
|
||||
|
||||
::
|
||||
@@ -1381,7 +1383,7 @@ trace sink, which will in turn print out the new position.
|
||||
If you now run the simulation, you will see the course changes displayed as
|
||||
they happen.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
Build finished successfully (00:00:01)
|
||||
/NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
|
||||
.. highlight:: cpp
|
||||
|
||||
Conceptual Overview
|
||||
-------------------
|
||||
@@ -153,7 +153,7 @@ of |ns3| in a directory called ``repos`` under your home
|
||||
directory. Change into that release directory, and you should find a
|
||||
directory structure something like the following:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
AUTHORS examples scratch utils waf.bat*
|
||||
bindings LICENSE src utils.py waf-tools
|
||||
@@ -250,16 +250,16 @@ load all of the public header files.
|
||||
Since you are, of course, following this tutorial religiously, you will
|
||||
already have done a
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf -d debug --enable-examples --enable-tests configure
|
||||
$ ./waf -d debug --enable-examples --enable-tests configure
|
||||
|
||||
in order to configure the project to perform debug builds that include
|
||||
examples and tests. You will also have done a
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf
|
||||
$ ./waf
|
||||
|
||||
to build the project. So now if you look in the directory
|
||||
``../../build/debug/ns3`` you will find the four module include files shown
|
||||
@@ -340,6 +340,21 @@ Just as in any C++ program, you need to define a main function that will be
|
||||
the first function run. There is nothing at all special here. Your
|
||||
|ns3| script is just a C++ program.
|
||||
|
||||
The next line sets the time resolution to one nanosecond, which happens
|
||||
to be the default value:
|
||||
|
||||
::
|
||||
|
||||
Time::SetResolution (Time::NS);
|
||||
|
||||
The resolution is the smallest time value that can be represented (as well as
|
||||
the smallest representable difference between two time values).
|
||||
You can change the resolution exactly once. The mechanism enabling this
|
||||
flexibility is somewhat memory hungry, so once the resolution has been
|
||||
set explicitly we release the memory, preventing further updates. (If
|
||||
you don't set the resolution explicitly, it will default to one nanosecond,
|
||||
and the memory will be released when the simulation starts.)
|
||||
|
||||
The next two lines of the script are used to enable two logging components that
|
||||
are built into the Echo Client and Echo Server applications:
|
||||
|
||||
@@ -728,6 +743,69 @@ took care of the hard part for you. The remaining lines of our first
|
||||
return 0;
|
||||
}
|
||||
|
||||
When the simulator will stop?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|ns3| is a Discrete Event (DE) simulator. In such a simulator, each event is
|
||||
associated with its execution time, and the simulation proceeds by executing
|
||||
events in the temporal order of simulation time. Events may cause future
|
||||
events to be scheduled (for example, a timer may reschedule itself to
|
||||
expire at the next interval).
|
||||
|
||||
The initial events are usually triggered by each object, e.g., IPv6 will
|
||||
schedule Router Advertisements, Neighbor Solicitations, etc.,
|
||||
an Application schedule the first packet sending event, etc.
|
||||
|
||||
When an event is processed, it may generate zero, one or more events.
|
||||
As a simulation executes, events are consumed, but more events may (or may
|
||||
not) be generated.
|
||||
The simulation will stop automatically when no further events are in the
|
||||
event queue, or when a special Stop event is found. The Stop event is
|
||||
created through the
|
||||
``Simulator::Stop (stopTime);`` function.
|
||||
|
||||
There is a typical case where ``Simulator::Stop`` is absolutely necessary
|
||||
to stop the simulation: when there is a self-sustaining event.
|
||||
Self-sustaining (or recurring) events are events that always reschedule
|
||||
themselves. As a consequence, they always keep the event queue non-empty.
|
||||
|
||||
There are many protocols and modules containing recurring events, e.g.:
|
||||
|
||||
* FlowMonitor - periodic check for lost packets
|
||||
* RIPng - periodic broadcast of routing tables update
|
||||
* etc.
|
||||
|
||||
In these cases, ``Simulator::Stop`` is necessary to gracefully stop the
|
||||
simulation. In addition, when |ns3| is in emulation mode, the
|
||||
``RealtimeSimulator`` is used to keep the simulation clock aligned with
|
||||
the machine clock, and ``Simulator::Stop`` is necessary to stop the
|
||||
process.
|
||||
|
||||
Many of the simulation programs in the tutorial do not explicitly call
|
||||
``Simulator::Stop``, since the event queue will automatically run out
|
||||
of events. However, these programs will also accept a call to
|
||||
``Simulator::Stop``. For example, the following additional statement
|
||||
in the first example program will schedule an explicit stop at 11 seconds:
|
||||
|
||||
::
|
||||
|
||||
+ Simulator::Stop (Seconds (11.0));
|
||||
Simulator::Run ();
|
||||
Simulator::Destroy ();
|
||||
return 0;
|
||||
}
|
||||
|
||||
The above wil not actually change the behavior of this program, since
|
||||
this particular simulation naturally ends after 10 seconds. But if you
|
||||
were to change the stop time in the above statement from 11 seconds to 1
|
||||
second, you would notice that the simulation stops before any output is
|
||||
printed to the screen (since the output occurs around time 2 seconds of
|
||||
simulation time).
|
||||
|
||||
It is important to call ``Simulator::Stop`` *before* calling
|
||||
``Simulator::Run``; otherwise, ``Simulator::Run`` may never return control
|
||||
to the main program to execute the stop!
|
||||
|
||||
Building Your Script
|
||||
++++++++++++++++++++
|
||||
We have made it trivial to build your simple scripts. All you have to do is
|
||||
@@ -735,21 +813,21 @@ to drop your script into the scratch directory and it will automatically be
|
||||
built if you run Waf. Let's try it. Copy ``examples/tutorial/first.cc`` into
|
||||
the ``scratch`` directory after changing back into the top level directory.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
cd ../..
|
||||
cp examples/tutorial/first.cc scratch/myfirst.cc
|
||||
$ cd ../..
|
||||
$ cp examples/tutorial/first.cc scratch/myfirst.cc
|
||||
|
||||
Now build your first example script using waf:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf
|
||||
$ ./waf
|
||||
|
||||
You should see messages reporting that your ``myfirst`` example was built
|
||||
successfully.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
|
||||
[614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
|
||||
@@ -760,13 +838,13 @@ successfully.
|
||||
You can now run the example (note that if you build your program in the scratch
|
||||
directory you must run it out of the scratch directory):
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run scratch/myfirst
|
||||
$ ./waf --run scratch/myfirst
|
||||
|
||||
You should see some output:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -794,14 +872,14 @@ summary page for our |ns3| development tree.
|
||||
|
||||
At the top of the page, you will see a number of links,
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
summary | shortlog | changelog | graph | tags | files
|
||||
|
||||
Go ahead and select the ``files`` link. This is what the top-level of
|
||||
most of our *repositories* will look:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
drwxr-xr-x [up]
|
||||
drwxr-xr-x bindings python files
|
||||
|
||||
@@ -197,7 +197,7 @@ latex_logo = '../../ns3_html_theme/static/ns-3.png'
|
||||
#latex_show_urls = False
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
#latex_preamble = ''
|
||||
latex_preamble = '\usepackage{amssymb}'
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
#latex_appendices = []
|
||||
|
||||
@@ -0,0 +1,446 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
.. role:: raw-role(raw)
|
||||
:format: html latex
|
||||
|
||||
Data Collection
|
||||
---------------
|
||||
|
||||
Our final tutorial chapter introduces some components that were added
|
||||
to |ns3| in version 3.18, and that are still under development. This
|
||||
tutorial section is also a work-in-progress.
|
||||
|
||||
Motivation
|
||||
**********
|
||||
|
||||
One of the main points of running simulations is to generate output data,
|
||||
either for research purposes or simply to learn about the system.
|
||||
In the previous chapter, we introduced the tracing subsystem and
|
||||
the example ``sixth.cc``. from which PCAP or ASCII trace files are
|
||||
generated. These traces are valuable for data analysis using a
|
||||
variety of external tools, and for many users, such output data is
|
||||
a preferred means of gathering data (for analysis by external tools).
|
||||
|
||||
However, there are also use cases for more than trace file generation,
|
||||
including the following:
|
||||
|
||||
* generation of data that does not map well to PCAP or ASCII traces, such
|
||||
as non-packet data (e.g. protocol state machine transitions),
|
||||
* large simulations for which the disk I/O requirements for generating
|
||||
trace files is prohibitive or cumbersome, and
|
||||
* the need for *online* data reduction or computation, during the course
|
||||
of the simulation. A good example of this is to define a termination
|
||||
condition for the simulation, to tell it when to stop when it has
|
||||
received enough data to form a narrow-enough confidence interval around
|
||||
the estimate of some parameter.
|
||||
|
||||
The |ns3| data collection framework is designed to provide these
|
||||
additional capabilities beyond trace-based output. We recommend
|
||||
that the reader interested in this topic consult the |ns3| Manual
|
||||
for a more detailed treatment of this framework; here, we summarize
|
||||
with an example program some of the developing capabilities.
|
||||
|
||||
Example Code
|
||||
************
|
||||
|
||||
The tutorial example ``examples/tutorial/seventh.cc`` resembles the
|
||||
``sixth.cc`` example we previously reviewed, except for a few changes.
|
||||
First, it has been enabled for IPv6 support with a command-line option:
|
||||
|
||||
::
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("useIpv6", "Use Ipv6", useV6);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
If the user specifies ``useIpv6``, option, the program will be run
|
||||
using IPv6 instead of IPv4. The ``help`` option, available on all |ns3|
|
||||
programs that support the CommandLine object as shown above, can
|
||||
be invoked as follows (please note the use of double quotes):
|
||||
|
||||
::
|
||||
|
||||
./waf --run "seventh --help"
|
||||
|
||||
which produces:
|
||||
|
||||
::
|
||||
|
||||
ns3-dev-seventh-debug [Program Arguments] [General Arguments]
|
||||
|
||||
Program Arguments:
|
||||
--useIpv6: Use Ipv6 [false]
|
||||
|
||||
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.
|
||||
|
||||
This default (use of IPv4, since useIpv6 is false) can be changed by
|
||||
toggling the boolean value as follows:
|
||||
|
||||
::
|
||||
|
||||
./waf --run "seventh --useIpv6=1"
|
||||
|
||||
and have a look at the pcap generated, such as with ``tcpdump``:
|
||||
|
||||
::
|
||||
|
||||
tcpdump -r seventh.pcap -nn -tt
|
||||
|
||||
This has been a short digression into IPv6 support and the command line,
|
||||
which was also introduced earlier in this tutorial. For a dedicated
|
||||
example of command line usage, please see
|
||||
``src/core/examples/command-line-example.cc``.
|
||||
|
||||
Now back to data collection. In the ``examples/tutorial/`` directory,
|
||||
type the following command: ``diff -u sixth.cc seventh.cc``, and examine
|
||||
some of the new lines of this diff:
|
||||
|
||||
::
|
||||
|
||||
+ std::string probeName;
|
||||
+ std::string probeTrace;
|
||||
+ if (useV6 == false)
|
||||
+ {
|
||||
...
|
||||
+ probeName = "ns3::Ipv4PacketProbe";
|
||||
+ probeTrace = "/NodeList/*/$ns3::Ipv4L3Protocol/Tx";
|
||||
+ }
|
||||
+ else
|
||||
+ {
|
||||
...
|
||||
+ probeName = "ns3::Ipv6PacketProbe";
|
||||
+ probeTrace = "/NodeList/*/$ns3::Ipv6L3Protocol/Tx";
|
||||
+ }
|
||||
...
|
||||
+ // Use GnuplotHelper to plot the packet byte count over time
|
||||
+ GnuplotHelper plotHelper;
|
||||
+
|
||||
+ // Configure the plot. The first argument is the file name prefix
|
||||
+ // for the output files generated. The second, third, and fourth
|
||||
+ // arguments are, respectively, the plot title, x-axis, and y-axis labels
|
||||
+ plotHelper.ConfigurePlot ("seventh-packet-byte-count",
|
||||
+ "Packet Byte Count vs. Time",
|
||||
+ "Time (Seconds)",
|
||||
+ "Packet Byte Count");
|
||||
+
|
||||
+ // Specify the probe type, probe path (in configuration namespace), and
|
||||
+ // probe output trace source ("OutputBytes") to plot. The fourth argument
|
||||
+ // specifies the name of the data series label on the plot. The last
|
||||
+ // argument formats the plot by specifying where the key should be placed.
|
||||
+ plotHelper.PlotProbe (probeName,
|
||||
+ probeTrace,
|
||||
+ "OutputBytes",
|
||||
+ "Packet Byte Count",
|
||||
+ GnuplotAggregator::KEY_BELOW);
|
||||
+
|
||||
+ // Use FileHelper to write out the packet byte count over time
|
||||
+ FileHelper fileHelper;
|
||||
+
|
||||
+ // Configure the file to be written, and the formatting of output data.
|
||||
+ fileHelper.ConfigureFile ("seventh-packet-byte-count",
|
||||
+ FileAggregator::FORMATTED);
|
||||
+
|
||||
+ // Set the labels for this formatted output file.
|
||||
+ fileHelper.Set2dFormat ("Time (Seconds) = %.3e\tPacket Byte Count = %.0f");
|
||||
+
|
||||
+ // Specify the probe type, probe path (in configuration namespace), and
|
||||
+ // probe output trace source ("OutputBytes") to write.
|
||||
+ fileHelper.WriteProbe (probeName,
|
||||
+ probeTrace,
|
||||
+ "OutputBytes");
|
||||
+
|
||||
Simulator::Stop (Seconds (20));
|
||||
Simulator::Run ();
|
||||
Simulator::Destroy ();
|
||||
|
||||
|
||||
The careful reader will have noticed, when testing the IPv6 command
|
||||
line attribute, that ``seventh.cc`` had created a number of new output files:
|
||||
|
||||
::
|
||||
|
||||
seventh-packet-byte-count-0.txt
|
||||
seventh-packet-byte-count-1.txt
|
||||
seventh-packet-byte-count.dat
|
||||
seventh-packet-byte-count.plt
|
||||
seventh-packet-byte-count.png
|
||||
seventh-packet-byte-count.sh
|
||||
|
||||
These were created by the additional statements introduced above; in
|
||||
particular, by a GnuplotHelper and a FileHelper. This data was produced
|
||||
by hooking the data collection components to |ns3| trace sources, and
|
||||
marshaling the data into a formatted ``gnuplot`` and into a formatted
|
||||
text file. In the next sections, we'll review each of these.
|
||||
|
||||
GnuplotHelper
|
||||
*************
|
||||
|
||||
The GnuplotHelper is an |ns3| helper object aimed at the production of
|
||||
``gnuplot`` plots with as few statements as possible, for common cases.
|
||||
It hooks |ns3| trace sources with data types supported by the
|
||||
data collection system. Not all |ns3| trace sources data types are
|
||||
supported, but many of the common trace types are, including TracedValues
|
||||
with plain old data (POD) types.
|
||||
|
||||
Let's look at the output produced by this helper:
|
||||
|
||||
::
|
||||
|
||||
seventh-packet-byte-count.dat
|
||||
seventh-packet-byte-count.plt
|
||||
seventh-packet-byte-count.sh
|
||||
|
||||
The first is a gnuplot data file with a series of space-delimited
|
||||
timestamps and packet byte counts. We'll cover how this particular
|
||||
data output was configured below, but let's continue with the output
|
||||
files. The file ``seventh-packet-byte-count.plt`` is a gnuplot plot file,
|
||||
that can be opened from within gnuplot. Readers who understand gnuplot
|
||||
syntax can see that this will produce a formatted output PNG file named
|
||||
``seventh-packet-byte-count.png``. Finally, a small shell script
|
||||
``seventh-packet-byte-count.sh`` runs this plot file through gnuplot
|
||||
to produce the desired PNG (which can be viewed in an image editor); that
|
||||
is, the command:
|
||||
|
||||
::
|
||||
|
||||
sh seventh-packet-byte-count.sh
|
||||
|
||||
will yield ``seventh-packet-byte-count.png``. Why wasn't this PNG
|
||||
produced in the first place? The answer is that by providing the
|
||||
plt file, the user can hand-configure the result if desired, before
|
||||
producing the PNG.
|
||||
|
||||
The PNG image title states that this plot is a plot of
|
||||
"Packet Byte Count vs. Time", and that it is plotting the probed data
|
||||
corresponding to the trace source path:
|
||||
|
||||
::
|
||||
|
||||
/NodeList/*/$ns3::Ipv6L3Protocol/Tx
|
||||
|
||||
Note the wild-card in the trace path. In summary, what this plot is
|
||||
capturing is the plot of packet bytes observed at the transmit trace
|
||||
source of the Ipv6L3Protocol object; largely 596-byte TCP segments
|
||||
in one direction, and 60-byte TCP acks in the other (two node
|
||||
trace sources were matched by this trace source).
|
||||
|
||||
How was this configured? A few statements need to be provided. First,
|
||||
the GnuplotHelper object must be declared and configured:
|
||||
|
||||
::
|
||||
|
||||
+ // Use GnuplotHelper to plot the packet byte count over time
|
||||
+ GnuplotHelper plotHelper;
|
||||
+
|
||||
+ // Configure the plot. The first argument is the file name prefix
|
||||
+ // for the output files generated. The second, third, and fourth
|
||||
+ // arguments are, respectively, the plot title, x-axis, and y-axis labels
|
||||
+ plotHelper.ConfigurePlot ("seventh-packet-byte-count",
|
||||
+ "Packet Byte Count vs. Time",
|
||||
+ "Time (Seconds)",
|
||||
+ "Packet Byte Count");
|
||||
|
||||
|
||||
To this point, an empty plot has been configured. The filename prefix
|
||||
is the first argument, the plot title is the second, the x-axis label
|
||||
the third, and the y-axis label the fourth argument.
|
||||
|
||||
The next step is to configure the data, and here is where the trace
|
||||
source is hooked. First, note above in the program we declared a few
|
||||
variables for later use:
|
||||
|
||||
::
|
||||
|
||||
+ std::string probeName;
|
||||
+ std::string probeTrace;
|
||||
+ probeName = "ns3::Ipv6PacketProbe";
|
||||
+ probeTrace = "/NodeList/*/$ns3::Ipv6L3Protocol/Tx";
|
||||
|
||||
We use them here:
|
||||
|
||||
::
|
||||
|
||||
+ // Specify the probe type, probe path (in configuration namespace), and
|
||||
+ // probe output trace source ("OutputBytes") to plot. The fourth argument
|
||||
+ // specifies the name of the data series label on the plot. The last
|
||||
+ // argument formats the plot by specifying where the key should be placed.
|
||||
+ plotHelper.PlotProbe (probeName,
|
||||
+ probeTrace,
|
||||
+ "OutputBytes",
|
||||
+ "Packet Byte Count",
|
||||
+ GnuplotAggregator::KEY_BELOW);
|
||||
|
||||
The first two arguments are the name of the probe type and the probe trace.
|
||||
These two are probably the hardest to determine when you try to use
|
||||
this framework to plot other traces. The probe trace here is the ``Tx``
|
||||
trace source of class ``Ipv6L3Protocol``. When we examine this class
|
||||
implementation (``src/internet/model/ipv6-l3-protocol.cc``) we can
|
||||
observe:
|
||||
|
||||
::
|
||||
|
||||
.AddTraceSource ("Tx", "Send IPv6 packet to outgoing interface.",
|
||||
MakeTraceSourceAccessor (&Ipv6L3Protocol::m_txTrace))
|
||||
|
||||
This says that ``Tx`` is a name for variable ``m_txTrace``, which has
|
||||
a declaration of:
|
||||
|
||||
::
|
||||
|
||||
/**
|
||||
* \brief Callback to trace TX (transmission) packets.
|
||||
*/
|
||||
TracedCallback<Ptr<const Packet>, Ptr<Ipv6>, uint32_t> m_txTrace;
|
||||
|
||||
It turns out that this specific trace source signature is supported
|
||||
by a Probe class (what we need here) of class Ipv6PacketProbe.
|
||||
See the files ``src/internet/model/ipv6-packet-probe.{h,cc}``.
|
||||
|
||||
So, in the PlotProbe statement above, we see that the statement is
|
||||
hooking the trace source (identified by path string) with a matching
|
||||
|ns3| Probe type of ``Ipv6PacketProbe``. If we did not support
|
||||
this probe type (matching trace source signature), we could have not
|
||||
used this statement (although some more complicated lower-level statements
|
||||
could have been used, as described in the manual).
|
||||
|
||||
The Ipv6PacketProbe exports, itself, some trace sources that extract
|
||||
the data out of the probed Packet object:
|
||||
|
||||
::
|
||||
|
||||
TypeId
|
||||
Ipv6PacketProbe::GetTypeId ()
|
||||
{
|
||||
static TypeId tid = TypeId ("ns3::Ipv6PacketProbe")
|
||||
.SetParent<Probe> ()
|
||||
.AddConstructor<Ipv6PacketProbe> ()
|
||||
.AddTraceSource ( "Output",
|
||||
"The packet plus its IPv6 object and interface that serve as the output for this probe",
|
||||
MakeTraceSourceAccessor (&Ipv6PacketProbe::m_output))
|
||||
.AddTraceSource ( "OutputBytes",
|
||||
"The number of bytes in the packet",
|
||||
MakeTraceSourceAccessor (&Ipv6PacketProbe::m_outputBytes))
|
||||
;
|
||||
return tid;
|
||||
}
|
||||
|
||||
|
||||
The third argument of our PlotProbe statement specifies that we are
|
||||
interested in the number of bytes in this packet; specifically, the
|
||||
"OutputBytes" trace source of Ipv6PacketProbe.
|
||||
Finally, the last two arguments of the statement provide the plot
|
||||
legend for this data series ("Packet Byte Count"), and an optional
|
||||
gnuplot formatting statement (GnuplotAggregator::KEY_BELOW) that we want
|
||||
the plot key to be inserted below the plot. Other options include
|
||||
NO_KEY, KEY_INSIDE, and KEY_ABOVE.
|
||||
|
||||
|
||||
Supported Trace Types
|
||||
*********************
|
||||
|
||||
The following traced values are supported with Probes as of this writing:
|
||||
|
||||
+------------------+-------------------+------------------------------------+
|
||||
| TracedValue type | Probe type | File |
|
||||
+==================+=========+=========+====================================+
|
||||
| double | DoubleProbe | stats/model/double-probe.h |
|
||||
+------------------+-------------------+------------------------------------+
|
||||
| uint8_t | Uinteger8Probe | stats/model/uinteger-8-probe.h |
|
||||
+------------------+-------------------+------------------------------------+
|
||||
| uint16_t | Uinteger16Probe | stats/model/uinteger-16-probe.h |
|
||||
+------------------+-------------------+------------------------------------+
|
||||
| uint32_t | Uinteger32Probe | stats/model/uinteger-32-probe.h |
|
||||
+------------------+-------------------+------------------------------------+
|
||||
| bool | BooleanProbe | stats/model/uinteger-16-probe.h |
|
||||
+------------------+-------------------+------------------------------------+
|
||||
|
||||
The following TraceSource types are supported by Probes as of this writing:
|
||||
|
||||
+------------------------------------------+------------------------+---------------+----------------------------------------------------+
|
||||
| TracedSource type | Probe type | Probe outputs | File |
|
||||
+==========================================+========================+===============+====================================================+
|
||||
| Ptr<const Packet> | PacketProbe | OutputBytes | network/utils/packet-probe.h |
|
||||
+------------------------------------------+------------------------+---------------+----------------------------------------------------+
|
||||
| Ptr<const Packet>, Ptr<Ipv4>, uint32_t | Ipv4PacketProbe | OutputBytes | internet/model/ipv4-packet-probe.h |
|
||||
+------------------------------------------+------------------------+---------------+----------------------------------------------------+
|
||||
| Ptr<const Packet>, Ptr<Ipv6>, uint32_t | Ipv6PacketProbe | OutputBytes | internet/model/ipv6-packet-probe.h |
|
||||
+------------------------------------------+------------------------+---------------+----------------------------------------------------+
|
||||
| Ptr<const Packet>, Ptr<Ipv6>, uint32_t | Ipv6PacketProbe | OutputBytes | internet/model/ipv6-packet-probe.h |
|
||||
+------------------------------------------+------------------------+---------------+----------------------------------------------------+
|
||||
| Ptr<const Packet>, const Address& | ApplicationPacketProbe | OutputBytes | applications/model/application-packet-probe.h |
|
||||
+------------------------------------------+------------------------+---------------+----------------------------------------------------+
|
||||
|
||||
As can be seen, only a few trace sources are supported, and they are all
|
||||
oriented towards outputting the Packet size (in bytes). However,
|
||||
most of the fundamental data types available as TracedValues can be
|
||||
supported with these helpers.
|
||||
|
||||
FileHelper
|
||||
**********
|
||||
|
||||
The FileHelper class is just a variation of the previous GnuplotHelper
|
||||
example. The example program provides formatted output of the
|
||||
same timestamped data, such as follows:
|
||||
|
||||
::
|
||||
|
||||
Time (Seconds) = 9.312e+00 Packet Byte Count = 596
|
||||
Time (Seconds) = 9.312e+00 Packet Byte Count = 564
|
||||
|
||||
Two files are provided, one for node "0" and one for node "1" as can
|
||||
be seen in the filenames. Let's look at the code piece-by-piece:
|
||||
|
||||
::
|
||||
|
||||
+ // Use FileHelper to write out the packet byte count over time
|
||||
+ FileHelper fileHelper;
|
||||
+
|
||||
+ // Configure the file to be written, and the formatting of output data.
|
||||
+ fileHelper.ConfigureFile ("seventh-packet-byte-count",
|
||||
+ FileAggregator::FORMATTED);
|
||||
|
||||
The file helper file prefix is the first argument, and a format specifier
|
||||
is next.
|
||||
Some other options for formatting include SPACE_SEPARATED, COMMA_SEPARATED,
|
||||
and TAB_SEPARATED. Users are able to change the formatting (if
|
||||
FORMATTED is specified) with a format string such as follows:
|
||||
|
||||
::
|
||||
|
||||
+
|
||||
+ // Set the labels for this formatted output file.
|
||||
+ fileHelper.Set2dFormat ("Time (Seconds) = %.3e\tPacket Byte Count = %.0f");
|
||||
|
||||
Finally, the probe of interest must be hooked. Again, the probeName and
|
||||
probeTrace variables in this example are used, and the probe's output
|
||||
trace source "OutputBytes" is hooked:
|
||||
|
||||
::
|
||||
|
||||
+
|
||||
+ // Specify the probe type, probe path (in configuration namespace), and
|
||||
+ // probe output trace source ("OutputBytes") to write.
|
||||
+ fileHelper.WriteProbe (probeName,
|
||||
+ probeTrace,
|
||||
+ "OutputBytes");
|
||||
+
|
||||
|
||||
The wildcard fields in this trace source specifier match two trace sources.
|
||||
Unlike the GnuplotHelper example, in which two data series were overlaid
|
||||
on the same plot, here, two separate files are written to disk.
|
||||
|
||||
Summary
|
||||
*******
|
||||
|
||||
Data collection support is new as of ns-3.18, and basic support for
|
||||
providing time series output has been added. The basic pattern described
|
||||
above may be replicated within the scope of support of the existing
|
||||
probes and trace sources. More capabilities including statistics
|
||||
processing will be added in future releases.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -8,7 +8,7 @@ available in five forms:
|
||||
|
||||
* `ns-3 Doxygen <http://www.nsnam.org/doxygen/index.html>`_: Documentation of the public APIs of the simulator
|
||||
* Tutorial *(this document)*, Manual, and Model Library for the `latest release <http://www.nsnam.org/documentation/latest/>`_ and `development tree <http://www.nsnam.org/ns-3-dev/documentation/>`_
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/index.php/Main_Page>`_
|
||||
* `ns-3 wiki <http://www.nsnam.org/wiki/Main_Page>`_
|
||||
|
||||
This document is written in `reStructuredText <http://docutils.sourceforge.net/rst.html>`_ for `Sphinx <http://sphinx.pocoo.org/>`_ and is maintained in the
|
||||
``doc/tutorial`` directory of ns-3's source code.
|
||||
@@ -23,4 +23,5 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
|
||||
tweaking
|
||||
building-topologies
|
||||
tracing
|
||||
data-collection
|
||||
conclusion
|
||||
|
||||
@@ -22,21 +22,55 @@ into the workings of the system.
|
||||
|
||||
A few key points are worth noting at the onset:
|
||||
|
||||
* Ns-3 is not an extension of `ns-2
|
||||
* |ns3| is open-source, and the project strives to maintain an
|
||||
open environment for researchers to contribute and share their software.
|
||||
* |ns3| is not a backwards-compatible extension of `ns-2
|
||||
<http://www.isi.edu/nsnam/ns>`_;
|
||||
it is a new simulator. The two simulators are both written in C++ but
|
||||
|ns3| is a new simulator that does not support the |ns2| APIs. Some
|
||||
models from |ns2| have already been ported from |ns2| to |ns3|. The
|
||||
project will continue to maintain |ns2| while |ns3| is being built,
|
||||
and will study transition and integration mechanisms.
|
||||
* |ns3| is open-source, and the project strives to maintain an
|
||||
open environment for researchers to contribute and share their software.
|
||||
|
||||
About |ns3|
|
||||
***********
|
||||
|
||||
|ns3| has been developed to provide an open, extensible network simulation
|
||||
platform, for networking research and education. In brief, |ns3| provides
|
||||
models of how packet data networks work and perform, and provides a
|
||||
simulation engine for users to conduct simulation experiments. Some of the
|
||||
reasons to use |ns3| include to perform studies that are more difficult
|
||||
or not possible to perform with real systems, to study system behavior in
|
||||
a highly controllled, reproducible environment, and to learn about how
|
||||
networks work. Users will note that the available model set in |ns3|
|
||||
focuses on modeling how Internet protocols and networks work, but
|
||||
|ns3| is not limited to Internet systems; several users are using
|
||||
|ns3| to model non-Internet-based systems.
|
||||
|
||||
Many simulation tools exist for network simulation studies. Below are
|
||||
a few distinguishing features of |ns3| in contrast to other tools.
|
||||
|
||||
* |ns3| is designed as a set of libraries that can be combined together
|
||||
and also with other external software libraries. While some simulation
|
||||
platforms provide users with a single, integrated graphical user
|
||||
interface environment in which all tasks are carried out, |ns3| is
|
||||
more modular in this regard. Several external animators and
|
||||
data analysis and visualization tools can be used with |ns3|. However,
|
||||
users should expect to work at the command line and with C++ and/or
|
||||
Python software development tools.
|
||||
* |ns3| is primarily used on Linux systems, although support exists
|
||||
for FreeBSD, Cygwin (for Windows), and native Windows Visual Studio
|
||||
support is in the process of being developed.
|
||||
* |ns3| is not an officially supported software product of any company.
|
||||
Support for |ns3| is done on a best-effort basis on the
|
||||
ns-3-users mailing list.
|
||||
|
||||
|
||||
For |ns2| Users
|
||||
***************
|
||||
|
||||
For those familiar with |ns2|, the most visible outward change when moving to
|
||||
For those familiar with |ns2| (a popular tool that preceded |ns3|),
|
||||
the most visible outward change when moving to
|
||||
|ns3| is the choice of scripting language. Programs in |ns2| are
|
||||
scripted in OTcl and results of simulations can be visualized using the
|
||||
Network Animator nam. It is not possible to run a simulation
|
||||
@@ -57,17 +91,38 @@ We will try to highlight differences between |ns2| and |ns3|
|
||||
as we proceed in this tutorial.
|
||||
|
||||
A question that we often hear is "Should I still use |ns2| or move to
|
||||
|ns3|?" The answer is that it depends. |ns3| does not have
|
||||
all of the models that |ns2| currently has, but on the other hand, |ns3|
|
||||
does have new capabilities (such as handling multiple interfaces on nodes
|
||||
correctly, use of IP addressing and more alignment with Internet
|
||||
protocols and designs, more detailed 802.11 models, etc.). |ns2|
|
||||
models can sometimes be ported to |ns3| (a porting guide is under
|
||||
development). The support available on the user mailing list, and the
|
||||
developer and maintainer activity, is higher for |ns3|. A good guideline
|
||||
would be to look at both simulators, and in particular the models available
|
||||
for your research, but when in doubt or when starting new simulation
|
||||
projects, choose the tool that is under more active development (|ns3|).
|
||||
|ns3|?" In this author's opinion, unless the user is somehow vested
|
||||
in |ns2| (either based on existing personal comfort with and knowledge
|
||||
of |ns2|, or based on a specific simulation model that is only available
|
||||
in |ns2|), a user will be more productive with |ns3| for the following
|
||||
reasons:
|
||||
|
||||
* |ns3| is actively maintained with an active, responsive users mailing
|
||||
list, while |ns2| is only lightly maintained and has not seen
|
||||
significant development in its main code tree for over a decade.
|
||||
* |ns3| provides features not available in |ns2|, such as a implementation
|
||||
code execution environment (allowing users to run real implementation
|
||||
code in the simulator)
|
||||
* |ns3| provides a lower base level of abstraction compared with |ns2|,
|
||||
allowing it to align better with how real systems are put together.
|
||||
Some limitations found in |ns2| (such as supporting multiple types of
|
||||
interfaces on nodes correctly) have been remedied in |ns3|.
|
||||
|
||||
|ns2| has a more diverse set of contributed modules than does |ns3|, owing to
|
||||
its long history. However, |ns3| has more detailed models in several
|
||||
popular areas of research (including sophisticated LTE and WiFi models),
|
||||
and its support of implementation code admits a very wide spectrum
|
||||
of high-fidelity models. Users may be surprised to learn that the
|
||||
whole Linux networking stack can be encapsulated in an |ns3| node,
|
||||
using the Direct Code Execution (DCE) framework. |ns2|
|
||||
models can sometimes be ported to |ns3|, particularly if they have been
|
||||
implemented in C++.
|
||||
|
||||
If in doubt, a good guideline would be to look at both simulators (as
|
||||
well as other simulators), and in particular the models available
|
||||
for your research, but keep in mind that your experience may be better
|
||||
in using the tool that is being actively developed and
|
||||
maintained (|ns3|).
|
||||
|
||||
Contributing
|
||||
************
|
||||
@@ -80,9 +135,9 @@ contribute to |ns3| like they have for |ns2|:
|
||||
|
||||
* Open source licensing based on GNU GPLv2 compatibility
|
||||
* `wiki
|
||||
<http://www.nsnam.org/wiki/index.php>`_
|
||||
<http://www.nsnam.org/wiki>`_
|
||||
* `Contributed Code
|
||||
<http://www.nsnam.org/wiki/index.php/Contributed_Code>`_ page, similar to |ns2|'s popular Contributed Code
|
||||
<http://www.nsnam.org/wiki/Contributed_Code>`_ page, similar to |ns2|'s popular Contributed Code
|
||||
`page
|
||||
<http://nsnam.isi.edu/nsnam/index.php/Contributed_Code>`_
|
||||
* Open `bug tracker
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
.. |ns3| replace:: *ns-3*
|
||||
|
||||
.. |ns2| replace:: *ns-2*
|
||||
|
||||
.. |check| replace:: :math:`\checkmark`
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
.. include:: replace.txt
|
||||
|
||||
.. highlight:: cpp
|
||||
.. role:: raw-role(raw)
|
||||
:format: html latex
|
||||
|
||||
Tracing
|
||||
-------
|
||||
@@ -15,12 +17,13 @@ somehow developing an output mechanism that conveys exactly (and perhaps only)
|
||||
the information wanted.
|
||||
|
||||
Using pre-defined bulk output mechanisms has the advantage of not requiring any
|
||||
changes to |ns3|, but it does require programming. Often, pcap or NS_LOG
|
||||
changes to |ns3|, but it may require writing scripts to parse and filter
|
||||
for data of interest. Often, pcap or NS_LOG
|
||||
output messages are gathered during simulation runs and separately run through
|
||||
scripts that use grep, sed or awk to parse the messages and reduce and transform
|
||||
the data to a manageable form. Programs must be written to do the
|
||||
transformation, so this does not come for free. Of course, if the information
|
||||
of interest in does not exist in any of the pre-defined output mechanisms,
|
||||
of interest does not exist in any of the pre-defined output mechanisms,
|
||||
this approach fails.
|
||||
|
||||
If you need to add some tidbit of information to the pre-defined bulk mechanisms,
|
||||
@@ -256,11 +259,11 @@ trace source invokes its ``operator()`` providing zero or more parameters.
|
||||
The ``operator()`` eventually wanders down into the system and does something
|
||||
remarkably like the indirect call you just saw. It provides zero or more
|
||||
parameters (the call to "pfi" above passed one parameter to the target function
|
||||
``MyFunction``.
|
||||
``MyFunction``).
|
||||
|
||||
The important difference that the tracing system adds is that for each trace
|
||||
source there is an internal list of Callbacks. Instead of just making one
|
||||
indirect call, a trace source may invoke any number of Callbacks. When a trace
|
||||
indirect call, a trace source may invoke multiple. When a trace
|
||||
sink expresses interest in notifications from a trace source, it basically just
|
||||
arranges to add its own function to the callback list.
|
||||
|
||||
@@ -309,7 +312,8 @@ illustrates how simple this all really is.
|
||||
|
||||
The file, ``traced-value.h`` brings in the required declarations for tracing
|
||||
of data that obeys value semantics. In general, value semantics just means that
|
||||
you can pass the object around, not an address. In order to use value semantics
|
||||
you can pass the object itself around, rather than passing the address of the
|
||||
object. In order to use value semantics
|
||||
at all you have to have an object with an associated copy constructor and
|
||||
assignment operator available. We extend the requirements to talk about the set
|
||||
of operators that are pre-defined for plain-old-data (POD) types. Operator=,
|
||||
@@ -426,21 +430,20 @@ called with the parameters provided by the source.
|
||||
|
||||
If you now build and run this example,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run fourth
|
||||
$ ./waf --run fourth
|
||||
|
||||
you will see the output from the ``IntTrace`` function execute as soon as the
|
||||
trace source is hit:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
Traced 0 to 1234
|
||||
|
||||
When we executed the code, ``myObject->m_myInt = 1234;``, the trace source
|
||||
fired and automatically provided the before and after values to the trace sink.
|
||||
The function ``IntTrace`` then printed this to the standard output. No
|
||||
problem.
|
||||
The function ``IntTrace`` then printed this to the standard output.
|
||||
|
||||
Using the Config Subsystem to Connect to Trace Sources
|
||||
++++++++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
@@ -449,7 +452,7 @@ The ``TraceConnectWithoutContext`` call shown above in the simple example is
|
||||
actually very rarely used in the system. More typically, the ``Config``
|
||||
subsystem is used to allow selecting a trace source in the system using what is
|
||||
called a *config path*. We saw an example of this in the previous section
|
||||
where we hooked the "CourseChange" event when we were playing with
|
||||
where we hooked the "CourseChange" event when we were experimenting with
|
||||
``third.cc``.
|
||||
|
||||
Recall that we defined a trace sink to print course change information from the
|
||||
@@ -679,9 +682,9 @@ The easiest way to do this is to grep around in the |ns3| codebase for someone
|
||||
who has already figured it out, You should always try to copy someone else's
|
||||
working code before you start to write your own. Try something like:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
find . -name '*.cc' | xargs grep CourseChange | grep Connect
|
||||
$ find . -name '*.cc' | xargs grep CourseChange | grep Connect
|
||||
|
||||
and you may find your answer along with working code. For example, in this
|
||||
case, ``./ns-3-dev/examples/wireless/mixed-wireless.cc`` has something
|
||||
@@ -732,7 +735,7 @@ connect.
|
||||
You are looking at the same information for the RandomWalk2dMobilityModel; and
|
||||
the information you want is now right there in front of you in the Doxygen:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
This object is accessible through the following paths with Config::Set and Config::Connect:
|
||||
|
||||
@@ -756,7 +759,7 @@ going to be looking for is found in the base class as we have seen.
|
||||
|
||||
Look further down in the ``GetTypeId`` doxygen. You will find,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
No TraceSources defined for this type.
|
||||
TraceSources defined in parent class ns3::MobilityModel:
|
||||
@@ -788,9 +791,9 @@ The easiest way to do this is to grep around in the |ns3| codebase for someone
|
||||
who has already figured it out, You should always try to copy someone else's
|
||||
working code. Try something like:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
find . -name '*.cc' | xargs grep CourseChange | grep Connect
|
||||
$ find . -name '*.cc' | xargs grep CourseChange | grep Connect
|
||||
|
||||
and you may find your answer along with working code. For example, in this
|
||||
case, ``./ns-3-dev/examples/wireless/mixed-wireless.cc`` has something
|
||||
@@ -812,7 +815,7 @@ there is a callback function there which you can use. Sure enough, there is:
|
||||
...
|
||||
}
|
||||
|
||||
Take my Word for It
|
||||
Take My Word for It
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If there are no examples to work from, this can be, well, challenging to
|
||||
@@ -899,9 +902,9 @@ We are probably going to be interested in some kind of declaration in the
|
||||
we know this declaration is going to have to be in some kind of header file,
|
||||
so just grep for it using:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
find . -name '*.h' | xargs grep TracedCallback
|
||||
$ find . -name '*.h' | xargs grep TracedCallback
|
||||
|
||||
You'll see 124 lines fly by (I piped this through wc to see how bad it was).
|
||||
Although that may seem like it, that's not really a lot. Just pipe the output
|
||||
@@ -943,7 +946,7 @@ in your favorite editor to see what is happening.
|
||||
|
||||
You will see a comment at the top of the file that should be comforting:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
An ns3::TracedCallback has almost exactly the same API as a normal ns3::Callback but
|
||||
instead of forwarding calls to a single function (as an ns3::Callback normally does),
|
||||
@@ -1019,7 +1022,7 @@ If you look down through the file, you will see a lot of probably almost
|
||||
incomprehensible template code. You will eventually come to some Doxygen for
|
||||
the Callback template class, though. Fortunately, there is some English:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
|
||||
This class template implements the Functor Design Pattern.
|
||||
It is used to declare the type of a Callback:
|
||||
@@ -1179,7 +1182,7 @@ trace sources" to see what we have to work with. Recall that this is found
|
||||
in the |ns3| Doxygen in the "C++ Constructs Used by All Modules" Module section. If you scroll
|
||||
through the list, you will eventually find:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
ns3::TcpNewReno
|
||||
CongestionWindow: The TCP connection's congestion window
|
||||
@@ -1189,9 +1192,9 @@ file ``src/internet/model/tcp-socket-base.cc`` while congestion control
|
||||
variants are in files such as ``src/internet/model/tcp-newreno.cc``.
|
||||
If you don't know this a priori, you can use the recursive grep trick:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
find . -name '*.cc' | xargs grep -i tcp
|
||||
$ find . -name '*.cc' | xargs grep -i tcp
|
||||
|
||||
You will find page after page of instances of tcp pointing you to that file.
|
||||
|
||||
@@ -1247,9 +1250,9 @@ modify, rather than starting from scratch. So the first order of business now
|
||||
is to find some code that already hooks the "CongestionWindow" trace source
|
||||
and see if we can modify it. As usual, grep is your friend:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
find . -name '*.cc' | xargs grep CongestionWindow
|
||||
$ find . -name '*.cc' | xargs grep CongestionWindow
|
||||
|
||||
This will point out a couple of promising candidates:
|
||||
``examples/tcp/tcp-large-transfer.cc`` and
|
||||
@@ -1507,57 +1510,57 @@ you will find,
|
||||
|
||||
::
|
||||
|
||||
Simulator::ScheduleWithContext (index, TimeStep (0), &Node::Start, node);
|
||||
Simulator::ScheduleWithContext (index, TimeStep (0), &Node::Initialize, node);
|
||||
|
||||
This tells you that whenever a ``Node`` is created in a simulation, as
|
||||
a side-effect, a call to that node's ``Start`` method is scheduled for
|
||||
a side-effect, a call to that node's ``Initialize`` method is scheduled for
|
||||
you that happens at time zero. Don't read too much into that name, yet.
|
||||
It doesn't mean that the node is going to start doing anything, it can be
|
||||
interpreted as an informational call into the ``Node`` telling it that
|
||||
the simulation has started, not a call for action telling the ``Node``
|
||||
to start doing something.
|
||||
|
||||
So, ``NodeList::Add`` indirectly schedules a call to ``Node::Start``
|
||||
So, ``NodeList::Add`` indirectly schedules a call to ``Node::Initialize``
|
||||
at time zero to advise a new node that the simulation has started. If you
|
||||
look in ``src/network/model/node.h`` you will, however, not find a method called
|
||||
``Node::Start``. It turns out that the ``Start`` method is inherited
|
||||
``Node::Initialize``. It turns out that the ``Initialize`` method is inherited
|
||||
from class ``Object``. All objects in the system can be notified when
|
||||
the simulation starts, and objects of class ``Node`` are just one kind
|
||||
of those objects.
|
||||
|
||||
Take a look at ``src/core/model/object.cc`` next and search for ``Object::Start``.
|
||||
Take a look at ``src/core/model/object.cc`` next and search for ``Object::Initialize``.
|
||||
This code is not as straightforward as you might have expected since
|
||||
|ns3| ``Objects`` support aggregation. The code in
|
||||
``Object::Start`` then loops through all of the objects that have been
|
||||
aggregated together and calls their ``DoStart`` method. This is another
|
||||
``Object::Initialize`` then loops through all of the objects that have been
|
||||
aggregated together and calls their ``DoInitialize`` method. This is another
|
||||
idiom that is very common in |ns3|. There is a public API method,
|
||||
that stays constant across implementations, that calls a private implementation
|
||||
method that is inherited and implemented by subclasses. The names are typically
|
||||
something like ``MethodName`` for the public API and ``DoMethodName`` for
|
||||
the private API.
|
||||
|
||||
This tells us that we should look for a ``Node::DoStart`` method in
|
||||
This tells us that we should look for a ``Node::DoInitialize`` method in
|
||||
``src/network/model/node.cc`` for the method that will continue our trail. If you
|
||||
locate the code, you will find a method that loops through all of the devices
|
||||
in the node and then all of the applications in the node calling
|
||||
``device->Start`` and ``application->Start`` respectively.
|
||||
``device->Initialize`` and ``application->Initialize`` respectively.
|
||||
|
||||
You may already know that classes ``Device`` and ``Application`` both
|
||||
inherit from class ``Object`` and so the next step will be to look at
|
||||
what happens when ``Application::DoStart`` is called. Take a look at
|
||||
what happens when ``Application::DoInitialize`` is called. Take a look at
|
||||
``src/network/model/application.cc`` and you will find:
|
||||
|
||||
::
|
||||
|
||||
void
|
||||
Application::DoStart (void)
|
||||
Application::DoInitialize (void)
|
||||
{
|
||||
m_startEvent = Simulator::Schedule (m_startTime, &Application::StartApplication, this);
|
||||
if (m_stopTime != TimeStep (0))
|
||||
{
|
||||
m_stopEvent = Simulator::Schedule (m_stopTime, &Application::StopApplication, this);
|
||||
}
|
||||
Object::DoStart ();
|
||||
Object::DoInitialize ();
|
||||
}
|
||||
|
||||
Here, we finally come to the end of the trail. If you have kept it all straight,
|
||||
@@ -1567,16 +1570,16 @@ and ``StopApplication`` methods and provide mechanisms for starting and
|
||||
stopping the flow of data out of your new ``Application``. When a ``Node``
|
||||
is created in the simulation, it is added to a global ``NodeList``. The act
|
||||
of adding a node to this ``NodeList`` causes a simulator event to be scheduled
|
||||
for time zero which calls the ``Node::Start`` method of the newly added
|
||||
for time zero which calls the ``Node::Initialize`` method of the newly added
|
||||
``Node`` to be called when the simulation starts. Since a ``Node`` inherits
|
||||
from ``Object``, this calls the ``Object::Start`` method on the ``Node``
|
||||
which, in turn, calls the ``DoStart`` methods on all of the ``Objects``
|
||||
from ``Object``, this calls the ``Object::Initialize`` method on the ``Node``
|
||||
which, in turn, calls the ``DoInitialize`` methods on all of the ``Objects``
|
||||
aggregated to the ``Node`` (think mobility models). Since the ``Node``
|
||||
``Object`` has overridden ``DoStart``, that method is called when the
|
||||
simulation starts. The ``Node::DoStart`` method calls the ``Start`` methods
|
||||
``Object`` has overridden ``DoInitialize``, that method is called when the
|
||||
simulation starts. The ``Node::DoInitialize`` method calls the ``Initialize`` methods
|
||||
of all of the ``Applications`` on the node. Since ``Applications`` are
|
||||
also ``Objects``, this causes ``Application::DoStart`` to be called. When
|
||||
``Application::DoStart`` is called, it schedules events for the
|
||||
also ``Objects``, this causes ``Application::DoInitialize`` to be called. When
|
||||
``Application::DoInitialize`` is called, it schedules events for the
|
||||
``StartApplication`` and ``StopApplication`` calls on the ``Application``.
|
||||
These calls are designed to start and stop the flow of data from the
|
||||
``Application``
|
||||
@@ -1954,10 +1957,10 @@ Since we have provided the file ``fifth.cc`` for you, if you have built
|
||||
your distribution (in debug mode since it uses NS_LOG -- recall that optimized
|
||||
builds optimize out NS_LOGs) it will be waiting for you to run.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run fifth
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build
|
||||
$ ./waf --run fifth
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
|
||||
Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-dev/ns-3-dev/build'
|
||||
'build' finished successfully (0.684s)
|
||||
1.20919 1072
|
||||
@@ -1976,9 +1979,9 @@ information along with those RxDrop messages. We will remedy that soon, but I'm
|
||||
sure you can't wait to see the results of all of this work. Let's redirect that
|
||||
output to a file called ``cwnd.dat``:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run fifth > cwnd.dat 2>&1
|
||||
$ ./waf --run fifth > cwnd.dat 2>&1
|
||||
|
||||
Now edit up "cwnd.dat" in your favorite editor and remove the waf build status
|
||||
and drop lines, leaving only the traced data (you could also comment out the
|
||||
@@ -1988,8 +1991,9 @@ script to get rid of the drop prints just as easily.
|
||||
You can now run gnuplot (if you have it installed) and tell it to generate some
|
||||
pretty pictures:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
$ gnuplot
|
||||
gnuplot> set terminal png size 640,480
|
||||
gnuplot> set output "cwnd.png"
|
||||
gnuplot> plot "cwnd.dat" using 1:2 title 'Congestion Window' with linespoints
|
||||
@@ -2140,7 +2144,7 @@ is going to contain packets prefixed with point to point headers. This is true
|
||||
since the packets are coming from our point-to-point device driver. Other
|
||||
common data link types are DLT_EN10MB (10 MB Ethernet) appropriate for csma
|
||||
devices and DLT_IEEE802_11 (IEEE 802.11) appropriate for wifi devices. These
|
||||
are defined in ``src/network/helper/trace-helper.h"`` if you are interested in seeing
|
||||
are defined in ``src/network/helper/trace-helper.h`` if you are interested in seeing
|
||||
the list. The entries in the list match those in ``bpf.h`` but we duplicate
|
||||
them to avoid a pcap source dependence.
|
||||
|
||||
@@ -2187,21 +2191,21 @@ mean that "something" is an |ns3| Object on which you can hang |ns3|
|
||||
|
||||
Now, back to the example. If you now build and run this example,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run sixth
|
||||
$ ./waf --run sixth
|
||||
|
||||
you will see the same messages appear as when you ran "fifth", but two new
|
||||
files will appear in the top-level directory of your |ns3| distribution.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
sixth.cwnd sixth.pcap
|
||||
|
||||
Since "sixth.cwnd" is an ASCII text file, you can view it with ``cat``
|
||||
or your favorite file viewer.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
1.20919 536 1072
|
||||
1.21511 1072 1608
|
||||
@@ -2215,7 +2219,7 @@ There are no extraneous prints in the file, no parsing or editing is required.
|
||||
|
||||
Since "sixth.pcap" is a pcap file, you can fiew it with ``tcpdump``.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
reading from file ../../sixth.pcap, link-type PPP (PPP)
|
||||
1.251507 IP 10.1.1.1.49153 > 10.1.1.2.8080: . 17689:18225(536) ack 1 win 65535
|
||||
@@ -2305,14 +2309,13 @@ There are subtleties that prevent all four classes from behaving identically,
|
||||
but we do strive to make them all work as similarly as possible; and whenever
|
||||
possible there are analogs for all methods in all classes.
|
||||
|
||||
::
|
||||
|
||||
| pcap | ascii |
|
||||
-----------------+------+-------|
|
||||
Device Helper | | |
|
||||
-----------------+------+-------|
|
||||
Protocol Helper | | |
|
||||
-----------------+------+-------|
|
||||
+-----------------+---------+---------+
|
||||
| | pcap | ascii |
|
||||
+=================+=========+=========+
|
||||
| Device Helper | |check| | |check| |
|
||||
+-----------------+---------+---------+
|
||||
| Protocol Helper | |check| | |check| |
|
||||
+-----------------+---------+---------+
|
||||
|
||||
We use an approach called a ``mixin`` to add tracing functionality to our
|
||||
helper classes. A ``mixin`` is a class that provides functionality to that
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
.. include:: replace.txt
|
||||
.. highlight:: cpp
|
||||
|
||||
|
||||
Tweaking
|
||||
@@ -80,16 +81,16 @@ Let's use the NS_LOG environment variable to turn on some more logging, but
|
||||
first, just to get our bearings, go ahead and run the last script just as you
|
||||
did previously,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run scratch/myfirst
|
||||
$ ./waf --run scratch/myfirst
|
||||
|
||||
You should see the now familiar output of the first |ns3| example
|
||||
program
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build'
|
||||
$ 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
|
||||
@@ -121,13 +122,13 @@ all lower levels. In this case, we have enabled ``NS_LOG_INFO``,
|
||||
increase the logging level and get more information without changing the
|
||||
script and recompiling by setting the NS_LOG environment variable like this:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export NS_LOG=UdpEchoClientApplication=level_all
|
||||
$ export NS_LOG=UdpEchoClientApplication=level_all
|
||||
|
||||
This sets the shell environment variable ``NS_LOG`` to the string,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
UdpEchoClientApplication=level_all
|
||||
|
||||
@@ -137,9 +138,9 @@ we are going to turn on all of the debugging levels for the application. If
|
||||
you run the script with NS_LOG set this way, the |ns3| logging
|
||||
system will pick up the change and you should see the following output:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build
|
||||
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()
|
||||
@@ -183,9 +184,9 @@ wonder where the string "``Received 1024 bytes from 10.1.1.2``" comes
|
||||
from. You can resolve this by OR'ing the ``prefix_func`` level into the
|
||||
``NS_LOG`` environment variable. Try doing the following,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'
|
||||
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'
|
||||
|
||||
Note that the quotes are required since the vertical bar we use to indicate an
|
||||
OR operation is also a Unix pipe connector.
|
||||
@@ -194,7 +195,7 @@ Now, if you run the script you will see that the logging system makes sure
|
||||
that every message from the given log component is prefixed with the component
|
||||
name.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -219,9 +220,9 @@ remaining message must be coming from the UDP echo server application. We
|
||||
can enable that component by entering a colon separated list of components in
|
||||
the NS_LOG environment variable.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:
|
||||
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func:
|
||||
UdpEchoServerApplication=level_all|prefix_func'
|
||||
|
||||
Warning: You will need to remove the newline after the ``:`` in the
|
||||
@@ -231,7 +232,7 @@ Now, if you run the script you will see all of the log messages from both the
|
||||
echo client and server applications. You may see that this can be very useful
|
||||
in debugging problems.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -258,15 +259,15 @@ in debugging problems.
|
||||
It is also sometimes useful to be able to see the simulation time at which a
|
||||
log message is generated. You can do this by ORing in the prefix_time bit.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func|prefix_time:
|
||||
$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func|prefix_time:
|
||||
UdpEchoServerApplication=level_all|prefix_func|prefix_time'
|
||||
|
||||
Again, you will have to remove the newline above. If you run the script now,
|
||||
you should see the following output:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -314,9 +315,9 @@ are not seeing as well. You can very easily follow the entire process by
|
||||
turning on all of the logging components in the system. Try setting the
|
||||
``NS_LOG`` variable to the following,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export 'NS_LOG=*=level_all|prefix_func|prefix_time'
|
||||
$ export 'NS_LOG=*=level_all|prefix_func|prefix_time'
|
||||
|
||||
The asterisk above is the logging component wildcard. This will turn on all
|
||||
of the logging in all of the components used in the simulation. I won't
|
||||
@@ -324,9 +325,9 @@ reproduce the output here (as of this writing it produces 1265 lines of output
|
||||
for the single packet echo) but you can redirect this information into a file
|
||||
and look through it with your favorite editor if you like,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run scratch/myfirst > log.out 2>&1
|
||||
$ ./waf --run scratch/myfirst > log.out 2>&1
|
||||
|
||||
I personally use this extremely verbose version of logging when I am presented
|
||||
with a problem and I have no idea where things are going wrong. I can follow the
|
||||
@@ -374,16 +375,16 @@ right before the lines,
|
||||
Now build the script using waf and clear the ``NS_LOG`` variable to turn
|
||||
off the torrent of logging we previously enabled:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf
|
||||
export NS_LOG=
|
||||
$ ./waf
|
||||
$ export NS_LOG=
|
||||
|
||||
Now, if you run the script,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run scratch/myfirst
|
||||
$ ./waf --run scratch/myfirst
|
||||
|
||||
you will ``not`` see your new message since its associated logging
|
||||
component (``FirstScriptExample``) has not been enabled. In order to see your
|
||||
@@ -391,14 +392,14 @@ message you will have to enable the ``FirstScriptExample`` logging component
|
||||
with a level greater than or equal to ``NS_LOG_INFO``. If you just want to
|
||||
see this particular level of logging, you can enable it by,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export NS_LOG=FirstScriptExample=info
|
||||
$ export NS_LOG=FirstScriptExample=info
|
||||
|
||||
If you now run the script you will see your new "Creating Topology" log
|
||||
message,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -441,16 +442,16 @@ ahead and add that two lines of code to the ``scratch/myfirst.cc`` script at
|
||||
the start of ``main``. Go ahead and build the script and run it, but ask
|
||||
the script for help in the following way,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst --PrintHelp"
|
||||
$ ./waf --run "scratch/myfirst --PrintHelp"
|
||||
|
||||
This will ask Waf to run the ``scratch/myfirst`` script and pass the command
|
||||
line argument ``--PrintHelp`` to the script. The quotes are required to
|
||||
sort out which program gets which argument. The command line parser will
|
||||
now see the ``--PrintHelp`` argument and respond with,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -481,14 +482,14 @@ listing says that we should provide a ``TypeId``. This corresponds to the
|
||||
class name of the class to which the ``Attributes`` belong. In this case it
|
||||
will be ``ns3::PointToPointNetDevice``. Let's go ahead and type in,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"
|
||||
$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointNetDevice"
|
||||
|
||||
The system will print out all of the ``Attributes`` of this kind of net device.
|
||||
Among the ``Attributes`` you will see listed is,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
--ns3::PointToPointNetDevice::DataRate=[32768bps]:
|
||||
The default data rate for point to point links
|
||||
@@ -521,13 +522,13 @@ Go ahead and build the new script with Waf (``./waf``) and let's go back
|
||||
and enable some logging from the UDP echo server application and turn on the
|
||||
time prefix.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'
|
||||
$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'
|
||||
|
||||
If you run the script, you should now see the following output,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -545,7 +546,7 @@ If you run the script, you should now see the following output,
|
||||
Recall that the last time we looked at the simulation time at which the packet
|
||||
was received by the echo server, it was at 2.00369 seconds.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
|
||||
|
||||
@@ -557,9 +558,9 @@ If we were to provide a new ``DataRate`` using the command line, we could
|
||||
speed our simulation up again. We do this in the following way, according to
|
||||
the formula implied by the help item:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"
|
||||
$ ./waf --run "scratch/myfirst --ns3::PointToPointNetDevice::DataRate=5Mbps"
|
||||
|
||||
This will set the default value of the ``DataRate`` ``Attribute`` back to
|
||||
five megabits per second. Are you surprised by the result? It turns out that
|
||||
@@ -568,30 +569,30 @@ the speed-of-light delay of the channel as well. We can ask the command line
|
||||
system to print out the ``Attributes`` of the channel just like we did for
|
||||
the net device:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"
|
||||
$ ./waf --run "scratch/myfirst --PrintAttributes=ns3::PointToPointChannel"
|
||||
|
||||
We discover the ``Delay`` ``Attribute`` of the channel is set in the following
|
||||
way:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
--ns3::PointToPointChannel::Delay=[0ns]:
|
||||
Transmission delay through the channel
|
||||
|
||||
We can then set both of these default values through the command line system,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst
|
||||
$ ./waf --run "scratch/myfirst
|
||||
--ns3::PointToPointNetDevice::DataRate=5Mbps
|
||||
--ns3::PointToPointChannel::Delay=2ms"
|
||||
|
||||
in which case we recover the timing we had when we explicitly set the
|
||||
``DataRate`` and ``Delay`` in the script:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -620,9 +621,9 @@ you should be able to control the number of packets echoed from the command
|
||||
line. Since we're nice folks, we'll tell you that your command line should
|
||||
end up looking something like,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst
|
||||
$ ./waf --run "scratch/myfirst
|
||||
--ns3::PointToPointNetDevice::DataRate=5Mbps
|
||||
--ns3::PointToPointChannel::Delay=2ms
|
||||
--ns3::UdpEchoClient::MaxPackets=2"
|
||||
@@ -666,11 +667,11 @@ should see your new ``User Argument`` listed in the help display.
|
||||
|
||||
Try,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst --PrintHelp"
|
||||
$ ./waf --run "scratch/myfirst --PrintHelp"
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -687,13 +688,13 @@ Try,
|
||||
If you want to specify the number of packets to echo, you can now do so by
|
||||
setting the ``--nPackets`` argument in the command line,
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run "scratch/myfirst --nPackets=2"
|
||||
$ ./waf --run "scratch/myfirst --nPackets=2"
|
||||
|
||||
You should now see
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
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'
|
||||
@@ -821,9 +822,9 @@ the popular trace points that log "+", "-", "d", and "r" events.
|
||||
|
||||
You can now build the script and run it from the command line:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run scratch/myfirst
|
||||
$ ./waf --run scratch/myfirst
|
||||
|
||||
Just as you have seen many times before, you will see some messages from Waf and then
|
||||
"'build' finished successfully" with some number of messages from
|
||||
@@ -856,31 +857,32 @@ space after it). This character will have the following meaning:
|
||||
* ``r``: A packet was received by the net device.
|
||||
|
||||
Let's take a more detailed view of the first line in the trace file. I'll
|
||||
break it down into sections (indented for clarity) with a two digit reference
|
||||
break it down into sections (indented for clarity) with a reference
|
||||
number on the left side:
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
:linenos:
|
||||
|
||||
00 +
|
||||
01 2
|
||||
02 /NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
|
||||
03 ns3::PppHeader (
|
||||
04 Point-to-Point Protocol: IP (0x0021))
|
||||
05 ns3::Ipv4Header (
|
||||
06 tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
|
||||
07 length: 1052 10.1.1.1 > 10.1.1.2)
|
||||
08 ns3::UdpHeader (
|
||||
09 length: 1032 49153 > 9)
|
||||
10 Payload (size=1024)
|
||||
+
|
||||
2
|
||||
/NodeList/0/DeviceList/0/$ns3::PointToPointNetDevice/TxQueue/Enqueue
|
||||
ns3::PppHeader (
|
||||
Point-to-Point Protocol: IP (0x0021))
|
||||
ns3::Ipv4Header (
|
||||
tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
|
||||
length: 1052 10.1.1.1 > 10.1.1.2)
|
||||
ns3::UdpHeader (
|
||||
length: 1032 49153 > 9)
|
||||
Payload (size=1024)
|
||||
|
||||
The first line of this expanded trace event (reference number 00) is the
|
||||
The first section of this expanded trace event (reference number 0) is the
|
||||
operation. We have a ``+`` character, so this corresponds to an
|
||||
*enqueue* operation on the transmit queue. The second line (reference 01)
|
||||
*enqueue* operation on the transmit queue. The second section (reference 1)
|
||||
is the simulation time expressed in seconds. You may recall that we asked the
|
||||
``UdpEchoClientApplication`` to start sending packets at two seconds. Here
|
||||
we see confirmation that this is, indeed, happening.
|
||||
|
||||
The next line of the example trace (reference 02) tell us which trace source
|
||||
The next section of the example trace (reference 2) tell us which trace source
|
||||
originated this event (expressed in the tracing namespace). You can think
|
||||
of the tracing namespace somewhat like you would a filesystem namespace. The
|
||||
root of the namespace is the ``NodeList``. This corresponds to a container
|
||||
@@ -899,11 +901,11 @@ Recall that the operation ``+`` found at reference 00 meant that an enqueue
|
||||
operation happened on the transmit queue of the device. This is reflected in
|
||||
the final segments of the "trace path" which are ``TxQueue/Enqueue``.
|
||||
|
||||
The remaining lines in the trace should be fairly intuitive. References 03-04
|
||||
The remaining sections in the trace should be fairly intuitive. References 3-4
|
||||
indicate that the packet is encapsulated in the point-to-point protocol.
|
||||
References 05-07 show that the packet has an IP version four header and has
|
||||
References 5-7 show that the packet has an IP version four header and has
|
||||
originated from IP address 10.1.1.1 and is destined for 10.1.1.2. References
|
||||
08-09 show that this packet has a UDP header and, finally, reference 10 shows
|
||||
8-9 show that this packet has a UDP header and, finally, reference 10 shows
|
||||
that the payload is the expected 1024 bytes.
|
||||
|
||||
The next line in the trace file shows the same packet being dequeued from the
|
||||
@@ -912,17 +914,18 @@ transmit queue on the same node.
|
||||
The Third line in the trace file shows the packet being received by the net
|
||||
device on the node with the echo server. I have reproduced that event below.
|
||||
|
||||
::
|
||||
.. sourcecode:: text
|
||||
:linenos:
|
||||
|
||||
00 r
|
||||
01 2.25732
|
||||
02 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
|
||||
03 ns3::Ipv4Header (
|
||||
04 tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
|
||||
05 length: 1052 10.1.1.1 > 10.1.1.2)
|
||||
06 ns3::UdpHeader (
|
||||
07 length: 1032 49153 > 9)
|
||||
08 Payload (size=1024)
|
||||
r
|
||||
2.25732
|
||||
/NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
|
||||
ns3::Ipv4Header (
|
||||
tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
|
||||
length: 1052 10.1.1.1 > 10.1.1.2)
|
||||
ns3::UdpHeader (
|
||||
length: 1032 49153 > 9)
|
||||
Payload (size=1024)
|
||||
|
||||
Notice that the trace operation is now ``r`` and the simulation time has
|
||||
increased to 2.25732 seconds. If you have been following the tutorial steps
|
||||
@@ -968,9 +971,9 @@ node 1-device 0, respectively.
|
||||
Once you have added the line of code to enable pcap tracing, you can run the
|
||||
script in the usual way:
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
./waf --run scratch/myfirst
|
||||
$ ./waf --run scratch/myfirst
|
||||
|
||||
If you look at the top level directory of your distribution, you should now
|
||||
see three log files: ``myfirst.tr`` is the ASCII trace file we have
|
||||
@@ -982,9 +985,9 @@ Reading output with tcpdump
|
||||
The easiest thing to do at this point will be to use ``tcpdump`` to look
|
||||
at the ``pcap`` files.
|
||||
|
||||
::
|
||||
.. sourcecode:: bash
|
||||
|
||||
tcpdump -nn -tt -r myfirst-0-0.pcap
|
||||
$ 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
|
||||
|
||||
@@ -35,7 +35,7 @@ NS_LOG_COMPONENT_DEFINE ("EnergyExample");
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
std::string
|
||||
static inline std::string
|
||||
PrintReceivedPacket (Address& from)
|
||||
{
|
||||
InetSocketAddress iaddr = InetSocketAddress::ConvertFrom (from);
|
||||
|
||||
@@ -0,0 +1,337 @@
|
||||
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
|
||||
/*
|
||||
* Copyright (c) 2014 Wireless Communications and Networking Group (WCNG),
|
||||
* University of Rochester, Rochester, NY, USA.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation;
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
*
|
||||
* Author: Cristiano Tapparello <cristiano.tapparello@rochester.edu>
|
||||
*/
|
||||
|
||||
/**
|
||||
*
|
||||
* This example extends the energy model example by connecting a basic energy
|
||||
* harvester to the nodes.
|
||||
*
|
||||
* The example considers a simple communication link between a source and a
|
||||
* destination node, where the source node sends a packet to the destination
|
||||
* every 1 second. Each node is powered by a BasiEnergySource, which is recharged
|
||||
* by a BasicEnergyHarvester, and the WiFi radio consumes energy for the transmission/
|
||||
* reception of the packets.
|
||||
*
|
||||
* For the receiver node, the example prints the energy consumption of the WiFi radio,
|
||||
* the power harvested by the energy harvester and the residual energy in the
|
||||
* energy source.
|
||||
*
|
||||
* The nodes initial energy is set to 1.0 J, the transmission and reception entail a
|
||||
* current consumption of 0.0174 A and 0.0197 A, respectively (default values in
|
||||
* WifiRadioEnergyModel). The energy harvester provides an amount of power that varies
|
||||
* according to a random variable uniformly distributed in [0 0.1] W, and is updated
|
||||
* every 1 s. The energy source voltage is 3 V (default value in BasicEnergySource) and
|
||||
* the residual energy level is updated every 1 second (default value).
|
||||
*
|
||||
* The simulation start at time 0 and it is hard stopped at time 10 seconds. Given the
|
||||
* packet size and the distance between the nodes, each transmission lasts 0.0023s.
|
||||
* As a result, the destination node receives 10 messages.
|
||||
*
|
||||
*/
|
||||
|
||||
#include "ns3/core-module.h"
|
||||
#include "ns3/network-module.h"
|
||||
#include "ns3/mobility-module.h"
|
||||
#include "ns3/config-store-module.h"
|
||||
#include "ns3/wifi-module.h"
|
||||
#include "ns3/energy-module.h"
|
||||
#include "ns3/internet-module.h"
|
||||
|
||||
#include <iostream>
|
||||
#include <fstream>
|
||||
#include <vector>
|
||||
#include <string>
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("EnergyWithHarvestingExample");
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
static inline std::string
|
||||
PrintReceivedPacket (Address& from)
|
||||
{
|
||||
InetSocketAddress iaddr = InetSocketAddress::ConvertFrom (from);
|
||||
|
||||
std::ostringstream oss;
|
||||
oss << "--\nReceived one packet! Socket: " << iaddr.GetIpv4 ()
|
||||
<< " port: " << iaddr.GetPort ()
|
||||
<< " at time = " << Simulator::Now ().GetSeconds ()
|
||||
<< "\n--";
|
||||
|
||||
return oss.str ();
|
||||
}
|
||||
|
||||
/**
|
||||
* \param socket Pointer to socket.
|
||||
*
|
||||
* Packet receiving sink.
|
||||
*/
|
||||
void
|
||||
ReceivePacket (Ptr<Socket> socket)
|
||||
{
|
||||
Ptr<Packet> packet;
|
||||
Address from;
|
||||
while ((packet = socket->RecvFrom (from)))
|
||||
{
|
||||
if (packet->GetSize () > 0)
|
||||
{
|
||||
NS_LOG_UNCOND (PrintReceivedPacket (from));
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* \param socket Pointer to socket.
|
||||
* \param pktSize Packet size.
|
||||
* \param n Pointer to node.
|
||||
* \param pktCount Number of packets to generate.
|
||||
* \param pktInterval Packet sending interval.
|
||||
*
|
||||
* Traffic generator.
|
||||
*/
|
||||
static void
|
||||
GenerateTraffic (Ptr<Socket> socket, uint32_t pktSize, Ptr<Node> n,
|
||||
uint32_t pktCount, Time pktInterval)
|
||||
{
|
||||
if (pktCount > 0)
|
||||
{
|
||||
socket->Send (Create<Packet> (pktSize));
|
||||
Simulator::Schedule (pktInterval, &GenerateTraffic, socket, pktSize, n,
|
||||
pktCount - 1, pktInterval);
|
||||
}
|
||||
else
|
||||
{
|
||||
socket->Close ();
|
||||
}
|
||||
}
|
||||
|
||||
/// Trace function for remaining energy at node.
|
||||
void
|
||||
RemainingEnergy (double oldValue, double remainingEnergy)
|
||||
{
|
||||
std::cout << Simulator::Now ().GetSeconds ()
|
||||
<< "s Current remaining energy = " << remainingEnergy << "J" << std::endl;
|
||||
}
|
||||
|
||||
/// Trace function for total energy consumption at node.
|
||||
void
|
||||
TotalEnergy (double oldValue, double totalEnergy)
|
||||
{
|
||||
std::cout << Simulator::Now ().GetSeconds ()
|
||||
<< "s Total energy consumed by radio = " << totalEnergy << "J" << std::endl;
|
||||
}
|
||||
|
||||
/// Trace function for the power harvested by the energy harvester.
|
||||
void
|
||||
HarvestedPower (double oldValue, double harvestedPower)
|
||||
{
|
||||
std::cout << Simulator::Now ().GetSeconds ()
|
||||
<< "s Current harvested power = " << harvestedPower << " W" << std::endl;
|
||||
}
|
||||
|
||||
/// Trace function for the total energy harvested by the node.
|
||||
void
|
||||
TotalEnergyHarvested (double oldValue, double TotalEnergyHarvested)
|
||||
{
|
||||
std::cout << Simulator::Now ().GetSeconds ()
|
||||
<< "s Total energy harvested by harvester = "
|
||||
<< TotalEnergyHarvested << " J" << std::endl;
|
||||
}
|
||||
|
||||
|
||||
int
|
||||
main (int argc, char *argv[])
|
||||
{
|
||||
/*
|
||||
LogComponentEnable ("EnergySource", LOG_LEVEL_DEBUG);
|
||||
LogComponentEnable ("BasicEnergySource", LOG_LEVEL_DEBUG);
|
||||
LogComponentEnable ("DeviceEnergyModel", LOG_LEVEL_DEBUG);
|
||||
LogComponentEnable ("WifiRadioEnergyModel", LOG_LEVEL_DEBUG);
|
||||
LogComponentEnable ("EnergyHarvester", LOG_LEVEL_DEBUG);
|
||||
LogComponentEnable ("BasicEnergyHarvester", LOG_LEVEL_DEBUG);
|
||||
*/
|
||||
|
||||
std::string phyMode ("DsssRate1Mbps");
|
||||
double Prss = -80; // dBm
|
||||
uint32_t PpacketSize = 200; // bytes
|
||||
bool verbose = false;
|
||||
|
||||
// simulation parameters
|
||||
uint32_t numPackets = 10000; // number of packets to send
|
||||
double interval = 1; // seconds
|
||||
double startTime = 0.0; // seconds
|
||||
double distanceToRx = 100.0; // meters
|
||||
/*
|
||||
* This is a magic number used to set the transmit power, based on other
|
||||
* configuration.
|
||||
*/
|
||||
double offset = 81;
|
||||
|
||||
// Energy Harvester variables
|
||||
double harvestingUpdateInterval = 1; // seconds
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("phyMode", "Wifi Phy mode", phyMode);
|
||||
cmd.AddValue ("Prss", "Intended primary RSS (dBm)", Prss);
|
||||
cmd.AddValue ("PpacketSize", "size of application packet sent", PpacketSize);
|
||||
cmd.AddValue ("numPackets", "Total number of packets to send", numPackets);
|
||||
cmd.AddValue ("startTime", "Simulation start time", startTime);
|
||||
cmd.AddValue ("distanceToRx", "X-Axis distance between nodes", distanceToRx);
|
||||
cmd.AddValue ("verbose", "Turn on all device log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
// Convert to time object
|
||||
Time interPacketInterval = Seconds (interval);
|
||||
|
||||
// disable fragmentation for frames below 2200 bytes
|
||||
Config::SetDefault ("ns3::WifiRemoteStationManager::FragmentationThreshold",
|
||||
StringValue ("2200"));
|
||||
// turn off RTS/CTS for frames below 2200 bytes
|
||||
Config::SetDefault ("ns3::WifiRemoteStationManager::RtsCtsThreshold",
|
||||
StringValue ("2200"));
|
||||
// Fix non-unicast data rate to be the same as that of unicast
|
||||
Config::SetDefault ("ns3::WifiRemoteStationManager::NonUnicastMode",
|
||||
StringValue (phyMode));
|
||||
|
||||
NodeContainer c;
|
||||
c.Create (2); // create 2 nodes
|
||||
NodeContainer networkNodes;
|
||||
networkNodes.Add (c.Get (0));
|
||||
networkNodes.Add (c.Get (1));
|
||||
|
||||
// The below set of helpers will help us to put together the wifi NICs we want
|
||||
WifiHelper wifi;
|
||||
if (verbose)
|
||||
{
|
||||
wifi.EnableLogComponents ();
|
||||
}
|
||||
wifi.SetStandard (WIFI_PHY_STANDARD_80211b);
|
||||
|
||||
/** Wifi PHY **/
|
||||
/***************************************************************************/
|
||||
YansWifiPhyHelper wifiPhy = YansWifiPhyHelper::Default ();
|
||||
wifiPhy.Set ("RxGain", DoubleValue (-10));
|
||||
wifiPhy.Set ("TxGain", DoubleValue (offset + Prss));
|
||||
wifiPhy.Set ("CcaMode1Threshold", DoubleValue (0.0));
|
||||
/***************************************************************************/
|
||||
|
||||
/** wifi channel **/
|
||||
YansWifiChannelHelper wifiChannel;
|
||||
wifiChannel.SetPropagationDelay ("ns3::ConstantSpeedPropagationDelayModel");
|
||||
wifiChannel.AddPropagationLoss ("ns3::FriisPropagationLossModel");
|
||||
// create wifi channel
|
||||
Ptr<YansWifiChannel> wifiChannelPtr = wifiChannel.Create ();
|
||||
wifiPhy.SetChannel (wifiChannelPtr);
|
||||
|
||||
/** MAC layer **/
|
||||
// Add a non-QoS upper MAC, and disable rate control
|
||||
NqosWifiMacHelper wifiMac = NqosWifiMacHelper::Default ();
|
||||
wifi.SetRemoteStationManager ("ns3::ConstantRateWifiManager", "DataMode",
|
||||
StringValue (phyMode), "ControlMode",
|
||||
StringValue (phyMode));
|
||||
// Set it to ad-hoc mode
|
||||
wifiMac.SetType ("ns3::AdhocWifiMac");
|
||||
|
||||
/** install PHY + MAC **/
|
||||
NetDeviceContainer devices = wifi.Install (wifiPhy, wifiMac, networkNodes);
|
||||
|
||||
/** mobility **/
|
||||
MobilityHelper mobility;
|
||||
Ptr<ListPositionAllocator> positionAlloc = CreateObject<ListPositionAllocator> ();
|
||||
positionAlloc->Add (Vector (0.0, 0.0, 0.0));
|
||||
positionAlloc->Add (Vector (2 * distanceToRx, 0.0, 0.0));
|
||||
mobility.SetPositionAllocator (positionAlloc);
|
||||
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
|
||||
mobility.Install (c);
|
||||
|
||||
/** Energy Model **/
|
||||
/***************************************************************************/
|
||||
/* energy source */
|
||||
BasicEnergySourceHelper basicSourceHelper;
|
||||
// configure energy source
|
||||
basicSourceHelper.Set ("BasicEnergySourceInitialEnergyJ", DoubleValue (1.0));
|
||||
// install source
|
||||
EnergySourceContainer sources = basicSourceHelper.Install (c);
|
||||
/* device energy model */
|
||||
WifiRadioEnergyModelHelper radioEnergyHelper;
|
||||
// configure radio energy model
|
||||
radioEnergyHelper.Set ("TxCurrentA", DoubleValue (0.0174));
|
||||
radioEnergyHelper.Set ("RxCurrentA", DoubleValue (0.0197));
|
||||
// install device model
|
||||
DeviceEnergyModelContainer deviceModels = radioEnergyHelper.Install (devices, sources);
|
||||
|
||||
/* energy harvester */
|
||||
BasicEnergyHarvesterHelper basicHarvesterHelper;
|
||||
// configure energy harvester
|
||||
basicHarvesterHelper.Set ("PeriodicHarvestedPowerUpdateInterval", TimeValue (Seconds (harvestingUpdateInterval)));
|
||||
basicHarvesterHelper.Set ("HarvestablePower", StringValue ("ns3::UniformRandomVariable[Min=0.0|Max=0.1]"));
|
||||
// install harvester on all energy sources
|
||||
EnergyHarvesterContainer harvesters = basicHarvesterHelper.Install (sources);
|
||||
/***************************************************************************/
|
||||
|
||||
/** Internet stack **/
|
||||
InternetStackHelper internet;
|
||||
internet.Install (networkNodes);
|
||||
|
||||
Ipv4AddressHelper ipv4;
|
||||
NS_LOG_INFO ("Assign IP Addresses.");
|
||||
ipv4.SetBase ("10.1.1.0", "255.255.255.0");
|
||||
Ipv4InterfaceContainer i = ipv4.Assign (devices);
|
||||
|
||||
TypeId tid = TypeId::LookupByName ("ns3::UdpSocketFactory");
|
||||
Ptr<Socket> recvSink = Socket::CreateSocket (networkNodes.Get (1), tid); // node 1, Destination
|
||||
InetSocketAddress local = InetSocketAddress (Ipv4Address::GetAny (), 80);
|
||||
recvSink->Bind (local);
|
||||
recvSink->SetRecvCallback (MakeCallback (&ReceivePacket));
|
||||
|
||||
Ptr<Socket> source = Socket::CreateSocket (networkNodes.Get (0), tid); // node 0, Source
|
||||
InetSocketAddress remote = InetSocketAddress (Ipv4Address::GetBroadcast (), 80);
|
||||
source->SetAllowBroadcast (true);
|
||||
source->Connect (remote);
|
||||
|
||||
/** connect trace sources **/
|
||||
/***************************************************************************/
|
||||
// all traces are connected to node 1 (Destination)
|
||||
// energy source
|
||||
Ptr<BasicEnergySource> basicSourcePtr = DynamicCast<BasicEnergySource> (sources.Get (1));
|
||||
basicSourcePtr->TraceConnectWithoutContext ("RemainingEnergy", MakeCallback (&RemainingEnergy));
|
||||
// device energy model
|
||||
Ptr<DeviceEnergyModel> basicRadioModelPtr =
|
||||
basicSourcePtr->FindDeviceEnergyModels ("ns3::WifiRadioEnergyModel").Get (0);
|
||||
NS_ASSERT (basicRadioModelPtr != 0);
|
||||
basicRadioModelPtr->TraceConnectWithoutContext ("TotalEnergyConsumption", MakeCallback (&TotalEnergy));
|
||||
// energy harvester
|
||||
Ptr<BasicEnergyHarvester> basicHarvesterPtr = DynamicCast<BasicEnergyHarvester> (harvesters.Get (1));
|
||||
basicHarvesterPtr->TraceConnectWithoutContext ("HarvestedPower", MakeCallback (&HarvestedPower));
|
||||
basicHarvesterPtr->TraceConnectWithoutContext ("TotalEnergyHarvested", MakeCallback (&TotalEnergyHarvested));
|
||||
/***************************************************************************/
|
||||
|
||||
|
||||
/** simulation setup **/
|
||||
// start traffic
|
||||
Simulator::Schedule (Seconds (startTime), &GenerateTraffic, source, PpacketSize,
|
||||
networkNodes.Get (0), numPackets, interPacketInterval);
|
||||
|
||||
Simulator::Stop (Seconds (10.0));
|
||||
Simulator::Run ();
|
||||
Simulator::Destroy ();
|
||||
|
||||
return 0;
|
||||
}
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
@@ -3,3 +3,5 @@
|
||||
def build(bld):
|
||||
obj = bld.create_ns3_program('energy-model-example', ['core', 'mobility', 'wifi', 'energy', 'internet'])
|
||||
obj.source = 'energy-model-example.cc'
|
||||
obj = bld.create_ns3_program('energy-model-with-harvesting-example', ['core', 'mobility', 'wifi', 'energy', 'internet'])
|
||||
obj.source = 'energy-model-with-harvesting-example.cc'
|
||||
@@ -57,16 +57,21 @@ main (int argc, char *argv[])
|
||||
|
||||
|
||||
// Set a few attributes
|
||||
Config::SetDefault ("ns3::RateErrorModel::ErrorRate", DoubleValue (0.01));
|
||||
Config::SetDefault ("ns3::RateErrorModel::ErrorRate", DoubleValue (0.001));
|
||||
Config::SetDefault ("ns3::RateErrorModel::ErrorUnit", StringValue ("ERROR_UNIT_PACKET"));
|
||||
|
||||
Config::SetDefault ("ns3::BurstErrorModel::ErrorRate", DoubleValue (0.01));
|
||||
Config::SetDefault ("ns3::BurstErrorModel::BurstSize", StringValue ("ns3::UniformRandomVariable[Min=1|Max=3]"));
|
||||
|
||||
Config::SetDefault ("ns3::OnOffApplication::PacketSize", UintegerValue (210));
|
||||
Config::SetDefault ("ns3::OnOffApplication::DataRate", DataRateValue (DataRate ("448kb/s")));
|
||||
|
||||
std::string errorModelType = "ns3::RateErrorModel";
|
||||
|
||||
// Allow the user to override any of the defaults and the above
|
||||
// Bind()s at run-time, via command-line arguments
|
||||
CommandLine cmd;
|
||||
cmd.AddValue("errorModelType", "TypeId of the error model to use", errorModelType);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
// Here, we will explicitly create four nodes. In more sophisticated
|
||||
@@ -146,9 +151,11 @@ main (int argc, char *argv[])
|
||||
// Error model
|
||||
//
|
||||
// Create an ErrorModel based on the implementation (constructor)
|
||||
// specified by the default classId
|
||||
Ptr<RateErrorModel> em = CreateObject<RateErrorModel> ();
|
||||
em->SetAttribute ("ErrorRate", DoubleValue (0.001));
|
||||
// specified by the default TypeId
|
||||
|
||||
ObjectFactory factory;
|
||||
factory.SetTypeId (errorModelType);
|
||||
Ptr<ErrorModel> em = factory.Create<ErrorModel> ();
|
||||
d3d2.Get (0)->SetAttribute ("ReceiveErrorModel", PointerValue (em));
|
||||
|
||||
// Now, let's use the ListErrorModel and explicitly force a loss
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
@@ -0,0 +1,124 @@
|
||||
/* -*- Mode: C++; c-file-style: "gnu"; indent-tabs-mode:nil; -*- */
|
||||
/*
|
||||
* Copyright (c) 2008-2009 Strasbourg University
|
||||
* Copyright (c) 2013 Universita' di Firenze
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation;
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
*
|
||||
* Author: David Gross <gdavid.devel@gmail.com>
|
||||
* Sebastien Vincent <vincent@clarinet.u-strasbg.fr>
|
||||
* Modified by Tommaso Pecorella <tommaso.pecorella@unifi.it>
|
||||
*/
|
||||
|
||||
// Network topology
|
||||
// //
|
||||
// // Src n0 r n1 Dst
|
||||
// // | _ |
|
||||
// // MTU ====|_|==== MTU
|
||||
// // 5000 router 1500
|
||||
// //
|
||||
// // - Tracing of queues and packet receptions to file "fragmentation-ipv6-two-mtu.tr"
|
||||
|
||||
#include <fstream>
|
||||
#include "ns3/core-module.h"
|
||||
#include "ns3/internet-module.h"
|
||||
#include "ns3/csma-module.h"
|
||||
#include "ns3/applications-module.h"
|
||||
#include "ns3/ipv6-static-routing-helper.h"
|
||||
|
||||
#include "ns3/ipv6-routing-table-entry.h"
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("FragmentationIpv6TwoMtuExample");
|
||||
|
||||
int main (int argc, char** argv)
|
||||
{
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> n0 = CreateObject<Node> ();
|
||||
Ptr<Node> r = CreateObject<Node> ();
|
||||
Ptr<Node> n1 = CreateObject<Node> ();
|
||||
|
||||
NodeContainer net1 (n0, r);
|
||||
NodeContainer net2 (r, n1);
|
||||
NodeContainer all (n0, r, n1);
|
||||
|
||||
NS_LOG_INFO ("Create IPv6 Internet Stack");
|
||||
InternetStackHelper internetv6;
|
||||
internetv6.Install (all);
|
||||
|
||||
NS_LOG_INFO ("Create channels.");
|
||||
CsmaHelper csma;
|
||||
csma.SetChannelAttribute ("DataRate", DataRateValue (5000000));
|
||||
csma.SetChannelAttribute ("Delay", TimeValue (MilliSeconds (2)));
|
||||
NetDeviceContainer d2 = csma.Install (net2);
|
||||
csma.SetDeviceAttribute ("Mtu", UintegerValue (5000));
|
||||
NetDeviceContainer d1 = csma.Install (net1);
|
||||
|
||||
NS_LOG_INFO ("Create networks and assign IPv6 Addresses.");
|
||||
Ipv6AddressHelper ipv6;
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i1 = ipv6.Assign (d1);
|
||||
i1.SetForwarding (1, true);
|
||||
i1.SetDefaultRouteInAllNodes (1);
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i2 = ipv6.Assign (d2);
|
||||
i2.SetForwarding (0, true);
|
||||
i2.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper> (&std::cout);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (0), n0, routingStream);
|
||||
|
||||
/* Create a Ping6 application to send ICMPv6 echo request from n0 to n1 via r */
|
||||
uint32_t packetSize = 4096;
|
||||
uint32_t maxPacketCount = 5;
|
||||
Time interPacketInterval = Seconds (1.0);
|
||||
Ping6Helper ping6;
|
||||
|
||||
ping6.SetLocal (i1.GetAddress (0, 1));
|
||||
ping6.SetRemote (i2.GetAddress (1, 1));
|
||||
|
||||
ping6.SetAttribute ("MaxPackets", UintegerValue (maxPacketCount));
|
||||
ping6.SetAttribute ("Interval", TimeValue (interPacketInterval));
|
||||
ping6.SetAttribute ("PacketSize", UintegerValue (packetSize));
|
||||
ApplicationContainer apps = ping6.Install (net1.Get (0));
|
||||
apps.Start (Seconds (2.0));
|
||||
apps.Stop (Seconds (20.0));
|
||||
|
||||
AsciiTraceHelper ascii;
|
||||
csma.EnableAsciiAll (ascii.CreateFileStream ("fragmentation-ipv6-two-mtu.tr"));
|
||||
csma.EnablePcapAll (std::string ("fragmentation-ipv6-two-mtu"), true);
|
||||
|
||||
NS_LOG_INFO ("Run Simulation.");
|
||||
Simulator::Run ();
|
||||
Simulator::Destroy ();
|
||||
NS_LOG_INFO ("Done.");
|
||||
}
|
||||
|
||||
@@ -41,69 +41,23 @@ using namespace ns3;
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("FragmentationIpv6Example");
|
||||
|
||||
/**
|
||||
* \class StackHelper
|
||||
* \brief Helper to set or get some IPv6 information about nodes.
|
||||
*/
|
||||
class StackHelper
|
||||
{
|
||||
public:
|
||||
/**
|
||||
* \brief Add an address to a IPv6 node.
|
||||
* \param n node
|
||||
* \param interface interface index
|
||||
* \param address IPv6 address to add
|
||||
*/
|
||||
inline void AddAddress (Ptr<Node>& n, uint32_t interface, Ipv6Address address)
|
||||
{
|
||||
Ptr<Ipv6> ipv6 = n->GetObject<Ipv6> ();
|
||||
ipv6->AddAddress (interface, address);
|
||||
}
|
||||
|
||||
/**
|
||||
* \brief Print the routing table.
|
||||
* \param n the node
|
||||
*/
|
||||
inline void PrintRoutingTable (Ptr<Node>& n)
|
||||
{
|
||||
Ptr<Ipv6StaticRouting> routing = 0;
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<Ipv6> ipv6 = n->GetObject<Ipv6> ();
|
||||
uint32_t nbRoutes = 0;
|
||||
Ipv6RoutingTableEntry route;
|
||||
|
||||
routing = routingHelper.GetStaticRouting (ipv6);
|
||||
|
||||
std::cout << "Routing table of " << n << " : " << std::endl;
|
||||
std::cout << "Destination\t\t\t\t" << "Gateway\t\t\t\t\t" << "Interface\t" << "Prefix to use" << std::endl;
|
||||
|
||||
nbRoutes = routing->GetNRoutes ();
|
||||
for (uint32_t i = 0; i < nbRoutes; i++)
|
||||
{
|
||||
route = routing->GetRoute (i);
|
||||
std::cout << route.GetDest () << "\t"
|
||||
<< route.GetGateway () << "\t"
|
||||
<< route.GetInterface () << "\t"
|
||||
<< route.GetPrefixToUse () << "\t"
|
||||
<< std::endl;
|
||||
}
|
||||
}
|
||||
};
|
||||
|
||||
int main (int argc, char** argv)
|
||||
{
|
||||
#if 0
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
#endif
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
StackHelper stackHelper;
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> n0 = CreateObject<Node> ();
|
||||
@@ -129,12 +83,16 @@ int main (int argc, char** argv)
|
||||
Ipv6AddressHelper ipv6;
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i1 = ipv6.Assign (d1);
|
||||
i1.SetRouter (1, true);
|
||||
i1.SetForwarding (1, true);
|
||||
i1.SetDefaultRouteInAllNodes (1);
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i2 = ipv6.Assign (d2);
|
||||
i2.SetRouter (0, true);
|
||||
i2.SetForwarding (0, true);
|
||||
i2.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
stackHelper.PrintRoutingTable (n0);
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper> (&std::cout);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (0), n0, routingStream);
|
||||
|
||||
/* Create a Ping6 application to send ICMPv6 echo request from n0 to n1 via r */
|
||||
uint32_t packetSize = 4096;
|
||||
|
||||
@@ -53,75 +53,25 @@ using namespace ns3;
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("Icmpv6RedirectExample");
|
||||
|
||||
/**
|
||||
* \class StackHelper
|
||||
* \brief Helper to set or get some IPv6 information about nodes.
|
||||
*/
|
||||
class StackHelper
|
||||
{
|
||||
public:
|
||||
/**
|
||||
* \brief Print the routing table.
|
||||
* \param n the node
|
||||
*/
|
||||
inline void PrintRoutingTable (Ptr<Node>& n)
|
||||
{
|
||||
Ptr<Ipv6StaticRouting> routing = 0;
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<Ipv6> ipv6 = n->GetObject<Ipv6> ();
|
||||
uint32_t nbRoutes = 0;
|
||||
Ipv6RoutingTableEntry route;
|
||||
|
||||
routing = routingHelper.GetStaticRouting (ipv6);
|
||||
|
||||
std::cout << "Routing table of " << n << " : " << std::endl;
|
||||
std::cout << "Destination\t\t\t\t" << "Gateway\t\t\t\t\t" << "Interface\t" << "Prefix to use" << std::endl;
|
||||
|
||||
nbRoutes = routing->GetNRoutes ();
|
||||
for(uint32_t i = 0; i < nbRoutes; i++)
|
||||
{
|
||||
route = routing->GetRoute (i);
|
||||
std::cout << route.GetDest () << "\t"
|
||||
<< route.GetGateway () << "\t"
|
||||
<< route.GetInterface () << "\t"
|
||||
<< route.GetPrefixToUse () << "\t"
|
||||
<< std::endl;
|
||||
}
|
||||
}
|
||||
|
||||
/**
|
||||
* \brief Add an host route.
|
||||
* \param n node
|
||||
* \param dst destination address
|
||||
* \param nextHop next hop for destination
|
||||
* \param interface output interface
|
||||
*/
|
||||
inline void AddHostRouteTo (Ptr<Node>& n, Ipv6Address dst, Ipv6Address nextHop, uint32_t interface)
|
||||
{
|
||||
Ptr<Ipv6StaticRouting> routing = 0;
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<Ipv6> ipv6 = n->GetObject<Ipv6> ();
|
||||
|
||||
routing = routingHelper.GetStaticRouting (ipv6);
|
||||
routing->AddHostRouteTo (dst, nextHop, interface);
|
||||
}
|
||||
};
|
||||
|
||||
int main (int argc, char **argv)
|
||||
{
|
||||
#if 0
|
||||
LogComponentEnable ("Icmpv6RedirectExample", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
#endif
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Icmpv6RedirectExample", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> sta1 = CreateObject<Node> ();
|
||||
Ptr<Node> r1 = CreateObject<Node> ();
|
||||
@@ -131,8 +81,6 @@ int main (int argc, char **argv)
|
||||
NodeContainer net2 (r2, sta2);
|
||||
NodeContainer all (sta1, r1, r2, sta2);
|
||||
|
||||
StackHelper stackHelper;
|
||||
|
||||
InternetStackHelper internetv6;
|
||||
internetv6.Install (all);
|
||||
|
||||
@@ -148,17 +96,24 @@ int main (int argc, char **argv)
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic1 = ipv6.Assign (ndc1);
|
||||
iic1.SetRouter (2, true);
|
||||
iic1.SetRouter (1, true);
|
||||
iic1.SetForwarding (2, true);
|
||||
iic1.SetForwarding (1, true);
|
||||
iic1.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic2 = ipv6.Assign (ndc2);
|
||||
iic2.SetRouter (0, true);
|
||||
iic2.SetForwarding (0, true);
|
||||
iic2.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
stackHelper.AddHostRouteTo (r1, iic2.GetAddress (1, 1), iic1.GetAddress (2, 1), iic1.GetInterfaceIndex (1));
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
|
||||
Simulator::Schedule (Seconds (0.0), &StackHelper::PrintRoutingTable, &stackHelper, r1);
|
||||
Simulator::Schedule (Seconds (3.0), &StackHelper::PrintRoutingTable, &stackHelper, sta1);
|
||||
// manually inject a static route to the second router.
|
||||
Ptr<Ipv6StaticRouting> routing = routingHelper.GetStaticRouting (r1->GetObject<Ipv6> ());
|
||||
routing->AddHostRouteTo (iic2.GetAddress (1, 1), iic1.GetAddress (2, 0), iic1.GetInterfaceIndex (1));
|
||||
|
||||
Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper> (&std::cout);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (0.0), r1, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (3.0), sta1, routingStream);
|
||||
|
||||
NS_LOG_INFO ("Create Applications.");
|
||||
uint32_t packetSize = 1024;
|
||||
|
||||
@@ -50,19 +50,23 @@ NS_LOG_COMPONENT_DEFINE ("LooseRoutingIpv6Example");
|
||||
|
||||
int main (int argc, char **argv)
|
||||
{
|
||||
#if 0
|
||||
LogComponentEnable ("Ipv6ExtensionLooseRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Extension", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
#endif
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ipv6ExtensionLooseRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Extension", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> h0 = CreateObject<Node> ();
|
||||
Ptr<Node> h1 = CreateObject<Node> ();
|
||||
@@ -106,31 +110,41 @@ int main (int argc, char **argv)
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i1 = ipv6.Assign (d1);
|
||||
i1.SetRouter (1, true);
|
||||
i1.SetForwarding (1, true);
|
||||
i1.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i2 = ipv6.Assign (d2);
|
||||
i2.SetRouter (1, true);
|
||||
i2.SetForwarding (1, true);
|
||||
i2.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:3::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i3 = ipv6.Assign (d3);
|
||||
i3.SetRouter (0, true);
|
||||
i3.SetRouter (1, true);
|
||||
i3.SetForwarding (0, true);
|
||||
i3.SetDefaultRouteInAllNodes (0);
|
||||
i3.SetForwarding (1, true);
|
||||
i3.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:4::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i4 = ipv6.Assign (d4);
|
||||
i4.SetRouter (0, true);
|
||||
i4.SetRouter (1, true);
|
||||
i4.SetForwarding (0, true);
|
||||
i4.SetDefaultRouteInAllNodes (0);
|
||||
i4.SetForwarding (1, true);
|
||||
i4.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:5::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i5 = ipv6.Assign (d5);
|
||||
i5.SetRouter (0, true);
|
||||
i5.SetRouter (1, true);
|
||||
i5.SetForwarding (0, true);
|
||||
i5.SetDefaultRouteInAllNodes (0);
|
||||
i5.SetForwarding (1, true);
|
||||
i5.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:6::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i6 = ipv6.Assign (d6);
|
||||
i6.SetRouter (0, true);
|
||||
i6.SetRouter (1, true);
|
||||
i6.SetForwarding (0, true);
|
||||
i6.SetDefaultRouteInAllNodes (0);
|
||||
i6.SetForwarding (1, true);
|
||||
i6.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
NS_LOG_INFO ("Create Applications.");
|
||||
|
||||
|
||||
+15
-11
@@ -41,21 +41,25 @@ NS_LOG_COMPONENT_DEFINE ("Ping6Example");
|
||||
|
||||
int main (int argc, char **argv)
|
||||
{
|
||||
#if 0
|
||||
LogComponentEnable ("Ping6Example", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Ipv6EndPointDemux", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6ListRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
#endif
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ping6Example", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Ipv6EndPointDemux", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6ListRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
NodeContainer n;
|
||||
n.Create (4);
|
||||
|
||||
@@ -49,69 +49,56 @@ using namespace ns3;
|
||||
NS_LOG_COMPONENT_DEFINE ("RadvdTwoPrefixExample");
|
||||
|
||||
/**
|
||||
* \class StackHelper
|
||||
* \brief Helper to set or get some IPv6 information about nodes.
|
||||
* \class IpAddressHelper
|
||||
* \brief Helper to print a node's IP addresses.
|
||||
*/
|
||||
class StackHelper
|
||||
class IpAddressHelper
|
||||
{
|
||||
public:
|
||||
/**
|
||||
* \brief Add an address to a IPv6 node.
|
||||
* \param n node
|
||||
* \param interface interface index
|
||||
* \param address IPv6 address to add
|
||||
*/
|
||||
inline void AddAddress (Ptr<Node>& n, uint32_t interface, Ipv6Address address)
|
||||
{
|
||||
Ptr<Ipv6> ipv6 = n->GetObject<Ipv6> ();
|
||||
ipv6->AddAddress (interface, address);
|
||||
}
|
||||
|
||||
/**
|
||||
* \brief Print the routing table.
|
||||
* \brief Print the node's IP addresses.
|
||||
* \param n the node
|
||||
*/
|
||||
inline void PrintRoutingTable (Ptr<Node>& n)
|
||||
inline void PrintIpAddresses (Ptr<Node>& n)
|
||||
{
|
||||
Ptr<Ipv6StaticRouting> routing = 0;
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<Ipv6> ipv6 = n->GetObject<Ipv6> ();
|
||||
uint32_t nbRoutes = 0;
|
||||
Ipv6RoutingTableEntry route;
|
||||
uint32_t nInterfaces = ipv6->GetNInterfaces();
|
||||
|
||||
routing = routingHelper.GetStaticRouting (ipv6);
|
||||
std::cout << "Node: " << ipv6->GetObject<Node> ()->GetId ()
|
||||
<< " Time: " << Simulator::Now ().GetSeconds () << "s "
|
||||
<< "IPv6 addresses" << std::endl;
|
||||
std::cout << "(Interface index, Address index)\t" << "IPv6 Address" << std::endl;
|
||||
|
||||
std::cout << "Routing table of " << n << " : " << std::endl;
|
||||
std::cout << "Destination\t\t\t\t" << "Gateway\t\t\t\t\t" << "Interface\t" << "Prefix to use" << std::endl;
|
||||
|
||||
nbRoutes = routing->GetNRoutes ();
|
||||
for (uint32_t i = 0; i < nbRoutes; i++)
|
||||
for (uint32_t i = 0; i < nInterfaces; i++)
|
||||
{
|
||||
route = routing->GetRoute (i);
|
||||
std::cout << route.GetDest () << "\t"
|
||||
<< route.GetGateway () << "\t"
|
||||
<< route.GetInterface () << "\t"
|
||||
<< route.GetPrefixToUse () << "\t"
|
||||
<< std::endl;
|
||||
for (uint32_t j = 0; j < ipv6->GetNAddresses(i); j++)
|
||||
{
|
||||
std::cout << "(" << int(i) << "," << int(j) << ")\t" << ipv6->GetAddress(i,j) << std::endl;
|
||||
}
|
||||
}
|
||||
std::cout << std::endl;
|
||||
}
|
||||
};
|
||||
|
||||
int main (int argc, char** argv)
|
||||
{
|
||||
#if 0
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6RawSocketImpl", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("RadvdApplication", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
#endif
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6RawSocketImpl", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("RadvdApplication", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> n0 = CreateObject<Node> ();
|
||||
Ptr<Node> r = CreateObject<Node> ();
|
||||
@@ -120,7 +107,6 @@ int main (int argc, char** argv)
|
||||
NodeContainer net1 (n0, r);
|
||||
NodeContainer net2 (r, n1);
|
||||
NodeContainer all (n0, r, n1);
|
||||
StackHelper stackHelper;
|
||||
|
||||
NS_LOG_INFO ("Create IPv6 Internet Stack");
|
||||
InternetStackHelper internetv6;
|
||||
@@ -145,18 +131,21 @@ int main (int argc, char** argv)
|
||||
NetDeviceContainer tmp2;
|
||||
tmp2.Add (d1.Get (1)); /* R */
|
||||
Ipv6InterfaceContainer iicr1 = ipv6.Assign (tmp2); /* R interface to the first subnet is just statically assigned */
|
||||
iicr1.SetRouter (0, true);
|
||||
iicr1.SetForwarding (0, true);
|
||||
iicr1.SetDefaultRouteInAllNodes (0);
|
||||
iic1.Add (iicr1);
|
||||
|
||||
/* add another IPv6 address for second prefix advertised on first subnet */
|
||||
stackHelper.AddAddress (r, iic1.GetInterfaceIndex (1), Ipv6Address ("2001:ABCD::2"));
|
||||
ipv6.SetBase (Ipv6Address ("2001:ABCD::2"), Ipv6Prefix (64));
|
||||
ipv6.Assign (tmp2);
|
||||
|
||||
/* second subnet R - n1 */
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
NetDeviceContainer tmp3;
|
||||
tmp3.Add (d2.Get (0)); /* R */
|
||||
Ipv6InterfaceContainer iicr2 = ipv6.Assign (tmp3); /* R interface */
|
||||
iicr2.SetRouter (0, true);
|
||||
iicr2.SetForwarding (0, true);
|
||||
iicr2.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
NetDeviceContainer tmp4;
|
||||
tmp4.Add (d2.Get (1)); /* n1 */
|
||||
@@ -164,29 +153,39 @@ int main (int argc, char** argv)
|
||||
iic2.Add (iicr2);
|
||||
|
||||
/* radvd configuration */
|
||||
Ipv6Address prefix ("2001:ABCD::0"); /* create the prefix */
|
||||
Ipv6Address prefixBis ("2001:1::0"); /* create the prefix */
|
||||
Ipv6Address prefix2 ("2001:2::0"); /* create the prefix */
|
||||
uint32_t indexRouter = iic1.GetInterfaceIndex (1); /* R interface (n0 - R) */
|
||||
uint32_t indexRouter2 = iic2.GetInterfaceIndex (1); /* R interface (R - n1) */
|
||||
Ptr<Radvd> radvd = CreateObject<Radvd> ();
|
||||
Ptr<RadvdInterface> routerInterface = Create<RadvdInterface> (indexRouter, 2000, 1000);
|
||||
Ptr<RadvdPrefix> routerPrefix = Create<RadvdPrefix> (prefix, 64, 3, 5);
|
||||
Ptr<RadvdPrefix> routerPrefixBis = Create<RadvdPrefix> (prefixBis, 64, 3, 5);
|
||||
Ptr<RadvdInterface> routerInterface2 = Create<RadvdInterface> (indexRouter2, 2000, 1000);
|
||||
Ptr<RadvdPrefix> routerPrefix2 = Create<RadvdPrefix> (prefix2, 64, 3, 5);
|
||||
RadvdHelper radvdHelper;
|
||||
/* R interface (n0 - R) */
|
||||
radvdHelper.AddAnnouncedPrefix(iic1.GetInterfaceIndex (1), Ipv6Address("2001:ABCD::0"), 64);
|
||||
radvdHelper.AddAnnouncedPrefix(iic1.GetInterfaceIndex (1), Ipv6Address("2001:1::0"), 64);
|
||||
|
||||
/* first interface advertise two prefixes (2001:1::/64 and 2001:ABCD::/64) */
|
||||
/* prefix is added in the inverse order in packet */
|
||||
routerInterface->AddPrefix (routerPrefix);
|
||||
routerInterface->AddPrefix (routerPrefixBis);
|
||||
routerInterface2->AddPrefix (routerPrefix2);
|
||||
radvd->AddConfiguration (routerInterface);
|
||||
radvd->AddConfiguration (routerInterface2);
|
||||
// Set some non-standard timers so the simulation is not taking ages
|
||||
Ptr<RadvdInterface> routerInterface = radvdHelper.GetRadvdInterface(iic1.GetInterfaceIndex (1));
|
||||
routerInterface->SetMaxRtrAdvInterval (2000);
|
||||
routerInterface->SetMinRtrAdvInterval (1000);
|
||||
RadvdInterface::RadvdPrefixList prefixList = routerInterface->GetPrefixes ();
|
||||
for (RadvdInterface::RadvdPrefixListI iter = prefixList.begin(); iter != prefixList.end(); iter++)
|
||||
{
|
||||
(*iter)->SetPreferredLifeTime (3);
|
||||
(*iter)->SetValidLifeTime (5);
|
||||
}
|
||||
|
||||
r->AddApplication (radvd);
|
||||
radvd->SetStartTime (Seconds (1.0));
|
||||
radvd->SetStopTime (Seconds (2.0));
|
||||
/* R interface (R - n1) */
|
||||
radvdHelper.AddAnnouncedPrefix(iic2.GetInterfaceIndex (1), Ipv6Address("2001:2::0"), 64);
|
||||
|
||||
// Set some non-standard timers so the simulation is not taking ages
|
||||
routerInterface = radvdHelper.GetRadvdInterface(iic2.GetInterfaceIndex (1));
|
||||
routerInterface->SetMaxRtrAdvInterval (2000);
|
||||
routerInterface->SetMinRtrAdvInterval (1000);
|
||||
prefixList = routerInterface->GetPrefixes ();
|
||||
for (RadvdInterface::RadvdPrefixListI iter = prefixList.begin(); iter != prefixList.end(); iter++)
|
||||
{
|
||||
(*iter)->SetPreferredLifeTime (3);
|
||||
(*iter)->SetValidLifeTime (5);
|
||||
}
|
||||
|
||||
ApplicationContainer radvdApps = radvdHelper.Install(r);
|
||||
radvdApps.Start (Seconds (1.0));
|
||||
radvdApps.Stop (Seconds (2.0));
|
||||
|
||||
/* Create a Ping6 application to send ICMPv6 echo request from n0 to n1 via R */
|
||||
uint32_t packetSize = 1024;
|
||||
@@ -205,10 +204,16 @@ int main (int argc, char** argv)
|
||||
apps.Start (Seconds (2.0));
|
||||
apps.Stop (Seconds (9.0));
|
||||
|
||||
Ipv6StaticRoutingHelper routingHelper;
|
||||
Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper> (&std::cout);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (2.0), n0, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (10.0), n0, routingStream);
|
||||
|
||||
IpAddressHelper ipAddressHelper;
|
||||
/* RA should be received, two prefixes + routes + default route should be present */
|
||||
Simulator::Schedule (Seconds (2.0), &StackHelper::PrintRoutingTable, &stackHelper, n0);
|
||||
Simulator::Schedule (Seconds (2.0), &IpAddressHelper::PrintIpAddresses, &ipAddressHelper, n0);
|
||||
/* at the end, RA addresses and routes should be cleared */
|
||||
Simulator::Schedule (Seconds (10.0), &StackHelper::PrintRoutingTable, &stackHelper, n0);
|
||||
Simulator::Schedule (Seconds (10.0), &IpAddressHelper::PrintIpAddresses, &ipAddressHelper, n0);
|
||||
|
||||
AsciiTraceHelper ascii;
|
||||
csma.EnableAsciiAll (ascii.CreateFileStream ("radvd-two-prefix.tr"));
|
||||
|
||||
+25
-28
@@ -47,19 +47,23 @@ NS_LOG_COMPONENT_DEFINE ("RadvdExample");
|
||||
|
||||
int main (int argc, char** argv)
|
||||
{
|
||||
#if 0
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6RawSocketImpl", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("RadvdApplication", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
#endif
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6RawSocketImpl", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("RadvdApplication", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> n0 = CreateObject<Node> ();
|
||||
Ptr<Node> r = CreateObject<Node> ();
|
||||
@@ -92,7 +96,8 @@ int main (int argc, char** argv)
|
||||
NetDeviceContainer tmp2;
|
||||
tmp2.Add (d1.Get (1)); /* R */
|
||||
Ipv6InterfaceContainer iicr1 = ipv6.Assign (tmp2); /* R interface to the first subnet is just statically assigned */
|
||||
iicr1.SetRouter (0, true);
|
||||
iicr1.SetForwarding (0, true);
|
||||
iicr1.SetDefaultRouteInAllNodes (0);
|
||||
iic1.Add (iicr1);
|
||||
|
||||
/* second subnet R - n1 */
|
||||
@@ -100,7 +105,8 @@ int main (int argc, char** argv)
|
||||
NetDeviceContainer tmp3;
|
||||
tmp3.Add (d2.Get (0)); /* R */
|
||||
Ipv6InterfaceContainer iicr2 = ipv6.Assign (tmp3); /* R interface */
|
||||
iicr2.SetRouter (0, true);
|
||||
iicr2.SetForwarding (0, true);
|
||||
iicr2.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
NetDeviceContainer tmp4;
|
||||
tmp4.Add (d2.Get (1)); /* n1 */
|
||||
@@ -108,24 +114,15 @@ int main (int argc, char** argv)
|
||||
iic2.Add (iicr2);
|
||||
|
||||
/* radvd configuration */
|
||||
Ipv6Address prefix ("2001:1::0"); /* create the prefix */
|
||||
Ipv6Address prefix2 ("2001:2::0"); /* create the prefix */
|
||||
uint32_t indexRouter = iic1.GetInterfaceIndex (1); /* R interface (n0 - R) */
|
||||
uint32_t indexRouter2 = iic2.GetInterfaceIndex (1); /* R interface (R - n1) */
|
||||
Ptr<Radvd> radvd = CreateObject<Radvd> ();
|
||||
Ptr<RadvdInterface> routerInterface = Create<RadvdInterface> (indexRouter, 5000, 1000);
|
||||
Ptr<RadvdPrefix> routerPrefix = Create<RadvdPrefix> (prefix, 64, 3, 5);
|
||||
Ptr<RadvdInterface> routerInterface2 = Create<RadvdInterface> (indexRouter2, 5000, 1000);
|
||||
Ptr<RadvdPrefix> routerPrefix2 = Create<RadvdPrefix> (prefix2, 64, 3, 5);
|
||||
RadvdHelper radvdHelper;
|
||||
/* R interface (n0 - R) */
|
||||
radvdHelper.AddAnnouncedPrefix(iic1.GetInterfaceIndex (1), Ipv6Address("2001:1::0"), 64);
|
||||
/* R interface (R - n1) */
|
||||
radvdHelper.AddAnnouncedPrefix(iic2.GetInterfaceIndex (1), Ipv6Address("2001:2::0"), 64);
|
||||
|
||||
routerInterface->AddPrefix (routerPrefix);
|
||||
routerInterface2->AddPrefix (routerPrefix2);
|
||||
radvd->AddConfiguration (routerInterface);
|
||||
radvd->AddConfiguration (routerInterface2);
|
||||
|
||||
r->AddApplication (radvd);
|
||||
radvd->SetStartTime (Seconds (1.0));
|
||||
radvd->SetStopTime (Seconds (10.0));
|
||||
ApplicationContainer radvdApps = radvdHelper.Install (r);
|
||||
radvdApps.Start (Seconds (1.0));
|
||||
radvdApps.Stop (Seconds (10.0));
|
||||
|
||||
/* Create a Ping6 application to send ICMPv6 echo request from n0 to n1 via R */
|
||||
uint32_t packetSize = 1024;
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
+11
-5
@@ -1,13 +1,13 @@
|
||||
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-
|
||||
|
||||
def build(bld):
|
||||
obj = bld.create_ns3_program('icmpv6-redirect', ['csma', 'internet'])
|
||||
obj = bld.create_ns3_program('icmpv6-redirect', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'icmpv6-redirect.cc'
|
||||
|
||||
obj = bld.create_ns3_program('ping6', ['csma', 'internet'])
|
||||
obj = bld.create_ns3_program('ping6', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'ping6.cc'
|
||||
|
||||
obj = bld.create_ns3_program('radvd', ['csma', 'internet'])
|
||||
obj = bld.create_ns3_program('radvd', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'radvd.cc'
|
||||
|
||||
obj = bld.create_ns3_program('radvd-two-prefix', ['csma', 'internet', 'applications'])
|
||||
@@ -16,9 +16,15 @@ def build(bld):
|
||||
obj = bld.create_ns3_program('test-ipv6', ['point-to-point', 'internet'])
|
||||
obj.source = 'test-ipv6.cc'
|
||||
|
||||
obj = bld.create_ns3_program('fragmentation-ipv6', ['csma', 'internet'])
|
||||
obj = bld.create_ns3_program('fragmentation-ipv6', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'fragmentation-ipv6.cc'
|
||||
|
||||
obj = bld.create_ns3_program('fragmentation-ipv6-two-MTU', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'fragmentation-ipv6-two-MTU.cc'
|
||||
|
||||
obj = bld.create_ns3_program('loose-routing-ipv6', ['csma', 'internet'])
|
||||
obj = bld.create_ns3_program('loose-routing-ipv6', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'loose-routing-ipv6.cc'
|
||||
|
||||
obj = bld.create_ns3_program('wsn-ping6', ['lr-wpan', 'internet', 'sixlowpan', 'mobility', 'applications'])
|
||||
obj.source = 'wsn-ping6.cc'
|
||||
|
||||
|
||||
@@ -0,0 +1,141 @@
|
||||
/* -*- Mode: C++; c-file-style: "gnu"; indent-tabs-mode:nil; -*- */
|
||||
/*
|
||||
* Copyright (c) 2014 Universita' di Firenze
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation;
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
*
|
||||
* Author: Tommaso Pecorella <tommaso.pecorella@unifi.it>
|
||||
*/
|
||||
|
||||
// Network topology
|
||||
//
|
||||
// n0 n1
|
||||
// | |
|
||||
// =================
|
||||
// WSN (802.15.4)
|
||||
//
|
||||
// - ICMPv6 echo request flows from n0 to n1 and back with ICMPv6 echo reply
|
||||
// - DropTail queues
|
||||
// - Tracing of queues and packet receptions to file "wsn-ping6.tr"
|
||||
//
|
||||
// This example is based on the "ping6.cc" example.
|
||||
|
||||
#include <fstream>
|
||||
#include "ns3/core-module.h"
|
||||
#include "ns3/internet-module.h"
|
||||
#include "ns3/sixlowpan-module.h"
|
||||
#include "ns3/lr-wpan-module.h"
|
||||
#include "ns3/applications-module.h"
|
||||
#include "ns3/mobility-module.h"
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("Ping6WsnExample");
|
||||
|
||||
int main (int argc, char **argv)
|
||||
{
|
||||
bool verbose = false;
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("Ping6WsnExample", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Ipv6EndPointDemux", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6L3Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6StaticRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6ListRouting", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("SixLowPanNetDevice", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
NodeContainer nodes;
|
||||
nodes.Create (2);
|
||||
|
||||
// Set seed for random numbers
|
||||
SeedManager::SetSeed (167);
|
||||
|
||||
// Install mobility
|
||||
MobilityHelper mobility;
|
||||
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
|
||||
|
||||
Ptr<ListPositionAllocator> nodesPositionAlloc = CreateObject<ListPositionAllocator> ();
|
||||
nodesPositionAlloc->Add (Vector (0.0, 0.0, 0.0));
|
||||
nodesPositionAlloc->Add (Vector (50.0, 0.0, 0.0));
|
||||
mobility.SetPositionAllocator (nodesPositionAlloc);
|
||||
mobility.Install (nodes);
|
||||
|
||||
NS_LOG_INFO ("Create channels.");
|
||||
LrWpanHelper lrWpanHelper;
|
||||
// Add and install the LrWpanNetDevice for each node
|
||||
// lrWpanHelper.EnableLogComponents();
|
||||
NetDeviceContainer devContainer = lrWpanHelper.Install(nodes);
|
||||
lrWpanHelper.AssociateToPan (devContainer, 10);
|
||||
|
||||
std::cout << "Created " << devContainer.GetN() << " devices" << std::endl;
|
||||
std::cout << "There are " << nodes.GetN() << " nodes" << std::endl;
|
||||
|
||||
/* Install IPv4/IPv6 stack */
|
||||
NS_LOG_INFO ("Install Internet stack.");
|
||||
InternetStackHelper internetv6;
|
||||
internetv6.SetIpv4StackInstall (false);
|
||||
internetv6.Install (nodes);
|
||||
|
||||
// Install 6LowPan layer
|
||||
NS_LOG_INFO ("Install 6LoWPAN.");
|
||||
SixLowPanHelper sixlowpan;
|
||||
NetDeviceContainer six1 = sixlowpan.Install (devContainer);
|
||||
|
||||
NS_LOG_INFO ("Assign addresses.");
|
||||
Ipv6AddressHelper ipv6;
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i = ipv6.Assign (six1);
|
||||
|
||||
NS_LOG_INFO ("Create Applications.");
|
||||
|
||||
/* Create a Ping6 application to send ICMPv6 echo request from node zero to
|
||||
* all-nodes (ff02::1).
|
||||
*/
|
||||
uint32_t packetSize = 10;
|
||||
uint32_t maxPacketCount = 5;
|
||||
Time interPacketInterval = Seconds (1.);
|
||||
Ping6Helper ping6;
|
||||
|
||||
ping6.SetLocal (i.GetAddress (0, 1));
|
||||
ping6.SetRemote (i.GetAddress (1, 1));
|
||||
// ping6.SetRemote (Ipv6Address::GetAllNodesMulticast ());
|
||||
|
||||
ping6.SetAttribute ("MaxPackets", UintegerValue (maxPacketCount));
|
||||
ping6.SetAttribute ("Interval", TimeValue (interPacketInterval));
|
||||
ping6.SetAttribute ("PacketSize", UintegerValue (packetSize));
|
||||
ApplicationContainer apps = ping6.Install (nodes.Get (0));
|
||||
apps.Start (Seconds (2.0));
|
||||
apps.Stop (Seconds (10.0));
|
||||
|
||||
AsciiTraceHelper ascii;
|
||||
lrWpanHelper.EnableAsciiAll (ascii.CreateFileStream ("ping6wsn.tr"));
|
||||
lrWpanHelper.EnablePcapAll (std::string ("ping6wsn"), true);
|
||||
|
||||
NS_LOG_INFO ("Run Simulation.");
|
||||
Simulator::Run ();
|
||||
Simulator::Destroy ();
|
||||
NS_LOG_INFO ("Done.");
|
||||
}
|
||||
|
||||
@@ -44,7 +44,6 @@
|
||||
#include <string>
|
||||
#include <vector>
|
||||
#include <cstdlib>
|
||||
#include <time.h>
|
||||
|
||||
#include "ns3/core-module.h"
|
||||
#include "ns3/network-module.h"
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
@@ -1,5 +1,5 @@
|
||||
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-
|
||||
|
||||
def build(bld):
|
||||
obj = bld.create_ns3_program('object-names', ['core', 'csma', 'internet'])
|
||||
obj = bld.create_ns3_program('object-names', ['core', 'csma', 'internet', 'applications'])
|
||||
obj.source = 'object-names.cc'
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
@@ -1,7 +1,7 @@
|
||||
## -*- Mode: python; py-indent-offset: 4; indent-tabs-mode: nil; coding: utf-8; -*-
|
||||
|
||||
def build(bld):
|
||||
obj = bld.create_ns3_program('realtime-udp-echo', ['csma', 'internet'])
|
||||
obj = bld.create_ns3_program('realtime-udp-echo', ['csma', 'internet', 'applications'])
|
||||
obj.source = 'realtime-udp-echo.cc'
|
||||
|
||||
bld.register_ns3_script('realtime-udp-echo.py', ['csma', 'internet', 'applications'])
|
||||
|
||||
@@ -119,7 +119,7 @@ RoutingExperiment::RoutingExperiment ()
|
||||
{
|
||||
}
|
||||
|
||||
std::string
|
||||
static inline std::string
|
||||
PrintReceivedPacket (Ptr<Socket> socket, Ptr<Packet> packet)
|
||||
{
|
||||
SocketAddressTag tag;
|
||||
@@ -343,7 +343,7 @@ RoutingExperiment::Run (int nSinks, double txp, std::string CSVfileName)
|
||||
onoff1.SetAttribute ("OnTime", StringValue ("ns3::ConstantRandomVariable[Constant=1.0]"));
|
||||
onoff1.SetAttribute ("OffTime", StringValue ("ns3::ConstantRandomVariable[Constant=0.0]"));
|
||||
|
||||
for (int i = 0; i <= nSinks - 1; i++)
|
||||
for (int i = 0; i < nSinks; i++)
|
||||
{
|
||||
Ptr<Socket> sink = SetupPacketReceive (adhocInterfaces.GetAddress (i), adhocNodes.Get (i));
|
||||
|
||||
|
||||
@@ -0,0 +1,268 @@
|
||||
/* -*- Mode:C++; c-file-style:"gnu"; indent-tabs-mode:nil; -*- */
|
||||
/*
|
||||
* Copyright (c) 2014 Universita' di Firenze, Italy
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or modify
|
||||
* it under the terms of the GNU General Public License version 2 as
|
||||
* published by the Free Software Foundation;
|
||||
*
|
||||
* This program is distributed in the hope that it will be useful,
|
||||
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
* GNU General Public License for more details.
|
||||
*
|
||||
* You should have received a copy of the GNU General Public License
|
||||
* along with this program; if not, write to the Free Software
|
||||
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
||||
*
|
||||
* Author: Tommaso Pecorella <tommaso.pecorella@unifi.it>
|
||||
*/
|
||||
|
||||
// Network topology
|
||||
//
|
||||
// SRC
|
||||
// |<=== source network
|
||||
// A-----B
|
||||
// \ / \ all networks have cost 1, except
|
||||
// \ / | for the direct link from C to D, which
|
||||
// C / has cost 10
|
||||
// | /
|
||||
// |/
|
||||
// D
|
||||
// |<=== target network
|
||||
// DST
|
||||
//
|
||||
//
|
||||
// A, B, C and D are RIPng routers.
|
||||
// A and D are configured with static addresses.
|
||||
// SRC and DST will exchange packets.
|
||||
//
|
||||
// After about 3 seconds, the topology is built, and Echo Reply will be received.
|
||||
// After 40 seconds, the link between B and D will break, causing a route failure.
|
||||
// After 44 seconds from the failure, the routers will recovery from the failure.
|
||||
// Split Horizoning should affect the recovery time, but it is not. See the manual
|
||||
// for an explanation of this effect.
|
||||
//
|
||||
// If "showPings" is enabled, the user will see:
|
||||
// 1) if the ping has been acknowledged
|
||||
// 2) if a Destination Unreachable has been received by the sender
|
||||
// 3) nothing, when the Echo Request has been received by the destination but
|
||||
// the Echo Reply is unable to reach the sender.
|
||||
// Examining the .pcap files with Wireshark can confirm this effect.
|
||||
|
||||
|
||||
#include <fstream>
|
||||
#include "ns3/core-module.h"
|
||||
#include "ns3/internet-module.h"
|
||||
#include "ns3/csma-module.h"
|
||||
#include "ns3/applications-module.h"
|
||||
#include "ns3/ipv6-static-routing-helper.h"
|
||||
#include "ns3/ipv6-routing-table-entry.h"
|
||||
|
||||
using namespace ns3;
|
||||
|
||||
NS_LOG_COMPONENT_DEFINE ("RipNgSimpleRouting");
|
||||
|
||||
void TearDownLink (Ptr<Node> nodeA, Ptr<Node> nodeB, uint32_t interfaceA, uint32_t interfaceB)
|
||||
{
|
||||
nodeA->GetObject<Ipv6> ()->SetDown (interfaceA);
|
||||
nodeB->GetObject<Ipv6> ()->SetDown (interfaceB);
|
||||
}
|
||||
|
||||
int main (int argc, char **argv)
|
||||
{
|
||||
bool verbose = false;
|
||||
bool printRoutingTables = false;
|
||||
bool showPings = false;
|
||||
std::string SplitHorizon ("PoisonReverse");
|
||||
|
||||
CommandLine cmd;
|
||||
cmd.AddValue ("verbose", "turn on log components", verbose);
|
||||
cmd.AddValue ("printRoutingTables", "Print routing tables at 30, 60 and 90 seconds", printRoutingTables);
|
||||
cmd.AddValue ("showPings", "Show Ping6 reception", showPings);
|
||||
cmd.AddValue ("splitHorizonStrategy", "Split Horizon strategy to use (NoSplitHorizon, SplitHorizon, PoisonReverse)", SplitHorizon);
|
||||
cmd.Parse (argc, argv);
|
||||
|
||||
if (verbose)
|
||||
{
|
||||
LogComponentEnable ("RipNgSimpleRouting", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("RipNg", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_INFO);
|
||||
LogComponentEnable ("Ipv6Interface", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Icmpv6L4Protocol", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("NdiscCache", LOG_LEVEL_ALL);
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_ALL);
|
||||
}
|
||||
|
||||
if (showPings)
|
||||
{
|
||||
LogComponentEnable ("Ping6Application", LOG_LEVEL_INFO);
|
||||
}
|
||||
|
||||
if (SplitHorizon == "NoSplitHorizon")
|
||||
{
|
||||
Config::SetDefault ("ns3::RipNg::SplitHorizon", EnumValue (RipNg::NO_SPLIT_HORIZON));
|
||||
}
|
||||
else if (SplitHorizon == "SplitHorizon")
|
||||
{
|
||||
Config::SetDefault ("ns3::RipNg::SplitHorizon", EnumValue (RipNg::SPLIT_HORIZON));
|
||||
}
|
||||
else
|
||||
{
|
||||
Config::SetDefault ("ns3::RipNg::SplitHorizon", EnumValue (RipNg::POISON_REVERSE));
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create nodes.");
|
||||
Ptr<Node> src = CreateObject<Node> ();
|
||||
Names::Add ("SrcNode", src);
|
||||
Ptr<Node> dst = CreateObject<Node> ();
|
||||
Names::Add ("DstNode", dst);
|
||||
Ptr<Node> a = CreateObject<Node> ();
|
||||
Names::Add ("RouterA", a);
|
||||
Ptr<Node> b = CreateObject<Node> ();
|
||||
Names::Add ("RouterB", b);
|
||||
Ptr<Node> c = CreateObject<Node> ();
|
||||
Names::Add ("RouterC", c);
|
||||
Ptr<Node> d = CreateObject<Node> ();
|
||||
Names::Add ("RouterD", d);
|
||||
NodeContainer net1 (src, a);
|
||||
NodeContainer net2 (a, b);
|
||||
NodeContainer net3 (a, c);
|
||||
NodeContainer net4 (b, c);
|
||||
NodeContainer net5 (c, d);
|
||||
NodeContainer net6 (b, d);
|
||||
NodeContainer net7 (d, dst);
|
||||
NodeContainer routers (a, b, c, d);
|
||||
NodeContainer nodes (src, dst);
|
||||
|
||||
|
||||
NS_LOG_INFO ("Create channels.");
|
||||
CsmaHelper csma;
|
||||
csma.SetChannelAttribute ("DataRate", DataRateValue (5000000));
|
||||
csma.SetChannelAttribute ("Delay", TimeValue (MilliSeconds (2)));
|
||||
NetDeviceContainer ndc1 = csma.Install (net1);
|
||||
NetDeviceContainer ndc2 = csma.Install (net2);
|
||||
NetDeviceContainer ndc3 = csma.Install (net3);
|
||||
NetDeviceContainer ndc4 = csma.Install (net4);
|
||||
NetDeviceContainer ndc5 = csma.Install (net5);
|
||||
NetDeviceContainer ndc6 = csma.Install (net6);
|
||||
NetDeviceContainer ndc7 = csma.Install (net7);
|
||||
|
||||
NS_LOG_INFO ("Create IPv6 and routing");
|
||||
RipNgHelper ripNgRouting;
|
||||
|
||||
// Rule of thumb:
|
||||
// Interfaces are added sequentially, starting from 0
|
||||
// However, interface 0 is always the loopback...
|
||||
ripNgRouting.ExcludeInterface (a, 1);
|
||||
ripNgRouting.ExcludeInterface (d, 3);
|
||||
|
||||
ripNgRouting.SetInterfaceMetric (c, 3, 10);
|
||||
ripNgRouting.SetInterfaceMetric (d, 1, 10);
|
||||
|
||||
Ipv6ListRoutingHelper listRH;
|
||||
listRH.Add (ripNgRouting, 0);
|
||||
|
||||
InternetStackHelper internetv6;
|
||||
internetv6.SetIpv4StackInstall (false);
|
||||
internetv6.SetRoutingHelper (listRH);
|
||||
internetv6.Install (routers);
|
||||
|
||||
InternetStackHelper internetv6Nodes;
|
||||
internetv6Nodes.SetIpv4StackInstall (false);
|
||||
internetv6Nodes.Install (nodes);
|
||||
|
||||
// Assign addresses.
|
||||
// The source and destination networks have global addresses
|
||||
// The "core" network just needs link-local addresses for routing.
|
||||
// We assign global addresses to the routers as well to receive
|
||||
// ICMPv6 errors.
|
||||
NS_LOG_INFO ("Assign IPv6 Addresses.");
|
||||
Ipv6AddressHelper ipv6;
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic1 = ipv6.Assign (ndc1);
|
||||
iic1.SetForwarding (1, true);
|
||||
iic1.SetDefaultRouteInAllNodes (1);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:0:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic2 = ipv6.Assign (ndc2);
|
||||
iic2.SetForwarding (0, true);
|
||||
iic2.SetForwarding (1, true);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:0:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic3 = ipv6.Assign (ndc3);
|
||||
iic3.SetForwarding (0, true);
|
||||
iic3.SetForwarding (1, true);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:0:3::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic4 = ipv6.Assign (ndc4);
|
||||
iic4.SetForwarding (0, true);
|
||||
iic4.SetForwarding (1, true);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:0:4::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic5 = ipv6.Assign (ndc5);
|
||||
iic5.SetForwarding (0, true);
|
||||
iic5.SetForwarding (1, true);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:0:5::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic6 = ipv6.Assign (ndc6);
|
||||
iic6.SetForwarding (0, true);
|
||||
iic6.SetForwarding (1, true);
|
||||
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer iic7 = ipv6.Assign (ndc7);
|
||||
iic7.SetForwarding (0, true);
|
||||
iic7.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
if (printRoutingTables)
|
||||
{
|
||||
RipNgHelper routingHelper;
|
||||
|
||||
Ptr<OutputStreamWrapper> routingStream = Create<OutputStreamWrapper> (&std::cout);
|
||||
|
||||
routingHelper.PrintRoutingTableAt (Seconds (30.0), a, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (30.0), b, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (30.0), c, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (30.0), d, routingStream);
|
||||
|
||||
routingHelper.PrintRoutingTableAt (Seconds (60.0), a, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (60.0), b, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (60.0), c, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (60.0), d, routingStream);
|
||||
|
||||
routingHelper.PrintRoutingTableAt (Seconds (90.0), a, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (90.0), b, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (90.0), c, routingStream);
|
||||
routingHelper.PrintRoutingTableAt (Seconds (90.0), d, routingStream);
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Create Applications.");
|
||||
uint32_t packetSize = 1024;
|
||||
uint32_t maxPacketCount = 100;
|
||||
Time interPacketInterval = Seconds (1.0);
|
||||
Ping6Helper ping6;
|
||||
|
||||
ping6.SetLocal (iic1.GetAddress (0, 1));
|
||||
ping6.SetRemote (iic7.GetAddress (1, 1));
|
||||
ping6.SetAttribute ("MaxPackets", UintegerValue (maxPacketCount));
|
||||
ping6.SetAttribute ("Interval", TimeValue (interPacketInterval));
|
||||
ping6.SetAttribute ("PacketSize", UintegerValue (packetSize));
|
||||
ApplicationContainer apps = ping6.Install (src);
|
||||
apps.Start (Seconds (1.0));
|
||||
apps.Stop (Seconds (110.0));
|
||||
|
||||
AsciiTraceHelper ascii;
|
||||
csma.EnableAsciiAll (ascii.CreateFileStream ("ripng-simple-routing.tr"));
|
||||
csma.EnablePcapAll ("ripng-simple-routing", true);
|
||||
|
||||
Simulator::Schedule (Seconds (40), &TearDownLink, b, d, 3, 2);
|
||||
|
||||
/* Now, do the actual simulation. */
|
||||
NS_LOG_INFO ("Run Simulation.");
|
||||
Simulator::Stop (Seconds (120));
|
||||
Simulator::Run ();
|
||||
Simulator::Destroy ();
|
||||
NS_LOG_INFO ("Done.");
|
||||
}
|
||||
|
||||
@@ -149,11 +149,10 @@ main (int argc, char *argv[])
|
||||
p2p.EnablePcapAll ("simple-global-routing");
|
||||
|
||||
// Flow Monitor
|
||||
Ptr<FlowMonitor> flowmon;
|
||||
FlowMonitorHelper flowmonHelper;
|
||||
if (enableFlowMonitor)
|
||||
{
|
||||
FlowMonitorHelper flowmonHelper;
|
||||
flowmon = flowmonHelper.InstallAll ();
|
||||
flowmonHelper.InstallAll ();
|
||||
}
|
||||
|
||||
NS_LOG_INFO ("Run Simulation.");
|
||||
@@ -163,7 +162,7 @@ main (int argc, char *argv[])
|
||||
|
||||
if (enableFlowMonitor)
|
||||
{
|
||||
flowmon->SerializeToXmlFile ("simple-global-routing.flowmon", false, false);
|
||||
flowmonHelper.SerializeToXmlFile ("simple-global-routing.flowmon", false, false);
|
||||
}
|
||||
|
||||
Simulator::Destroy ();
|
||||
|
||||
@@ -130,10 +130,12 @@ int main (int argc, char** argv)
|
||||
Ipv6AddressHelper ipv6;
|
||||
ipv6.SetBase (Ipv6Address ("2001:1::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i1 = ipv6.Assign (d1);
|
||||
i1.SetRouter (1, true);
|
||||
i1.SetForwarding (1, true);
|
||||
i1.SetDefaultRouteInAllNodes (1);
|
||||
ipv6.SetBase (Ipv6Address ("2001:2::"), Ipv6Prefix (64));
|
||||
Ipv6InterfaceContainer i2 = ipv6.Assign (d2);
|
||||
i2.SetRouter (0, true);
|
||||
i2.SetForwarding (0, true);
|
||||
i2.SetDefaultRouteInAllNodes (0);
|
||||
|
||||
stackHelper.PrintRoutingTable (n0);
|
||||
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
@@ -2,19 +2,19 @@
|
||||
|
||||
def build(bld):
|
||||
obj = bld.create_ns3_program('dynamic-global-routing',
|
||||
['point-to-point', 'csma', 'internet'])
|
||||
['point-to-point', 'csma', 'internet', 'applications'])
|
||||
obj.source = 'dynamic-global-routing.cc'
|
||||
|
||||
obj = bld.create_ns3_program('static-routing-slash32',
|
||||
['point-to-point', 'csma', 'internet'])
|
||||
['point-to-point', 'csma', 'internet', 'applications'])
|
||||
obj.source = 'static-routing-slash32.cc'
|
||||
|
||||
obj = bld.create_ns3_program('global-routing-slash32',
|
||||
['point-to-point', 'csma', 'internet'])
|
||||
['point-to-point', 'csma', 'internet', 'applications'])
|
||||
obj.source = 'global-routing-slash32.cc'
|
||||
|
||||
obj = bld.create_ns3_program('global-injection-slash32',
|
||||
['point-to-point', 'csma', 'internet'])
|
||||
['point-to-point', 'csma', 'internet', 'applications'])
|
||||
obj.source = 'global-injection-slash32.cc'
|
||||
|
||||
obj = bld.create_ns3_program('simple-global-routing',
|
||||
@@ -25,16 +25,20 @@ def build(bld):
|
||||
['point-to-point', 'internet', 'applications'])
|
||||
obj.source = 'simple-alternate-routing.cc'
|
||||
|
||||
obj = bld.create_ns3_program( 'mixed-global-routing',
|
||||
['point-to-point', 'internet', 'csma'])
|
||||
obj = bld.create_ns3_program('mixed-global-routing',
|
||||
['point-to-point', 'internet', 'csma', 'applications'])
|
||||
obj.source = 'mixed-global-routing.cc'
|
||||
|
||||
obj = bld.create_ns3_program('simple-routing-ping6',
|
||||
['csma', 'internet'])
|
||||
['csma', 'internet', 'applications'])
|
||||
obj.source = 'simple-routing-ping6.cc'
|
||||
|
||||
obj = bld.create_ns3_program('manet-routing-compare',
|
||||
['wifi', 'dsr', 'dsdv', 'aodv', 'olsr', 'internet', 'applications'])
|
||||
obj.source = 'manet-routing-compare.cc'
|
||||
|
||||
obj = bld.create_ns3_program('ripng-simple-network',
|
||||
['csma', 'internet', 'applications'])
|
||||
obj.source = 'ripng-simple-network.cc'
|
||||
|
||||
bld.register_ns3_script('simple-routing-ping6.py', ['csma', 'internet', 'applications'])
|
||||
|
||||
Vendored
-1
@@ -1 +0,0 @@
|
||||
exec "`dirname "$0"`"/../../waf "$@"
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user