ns-3 네트워크 시뮬레이터 튜토리얼. 제5장

1,2 장
3화
4화

5가지 설정
5.1 로깅 모듈 사용
5.1.1 로깅 개요
5.1.2 로깅 활성화
5.1.3 코드에 로깅 추가
5.2 명령줄 인수 사용
5.2.1 기본 속성 값 재정의
5.2.2 자신만의 명령 캡처
5.3 추적 시스템 사용
5.3.1 ASCII 추적
ASCII 추적 구문 분석
5.3.2 PCAP 추적

장 5

조정

5.1 로깅 모듈 사용

우리는 이미 스크립트를 보면서 ns-3 로깅 모듈을 간략하게 살펴보았습니다. 첫 번째.cc. 이번 장에서는 로깅 하위 시스템의 가능한 용도를 자세히 살펴보겠습니다.

5.1.1 로깅 개요

많은 대규모 시스템은 일종의 메시지 로깅 기능을 지원하며 ns-3도 예외는 아닙니다. 경우에 따라 "운영자 콘솔"(일반적으로 Unix 기반 시스템에서는 stderr)에 오류 메시지만 기록됩니다. 다른 시스템에서는 더 자세한 정보와 함께 경고 메시지가 표시될 수 있습니다. 어떤 경우에는 출력을 빠르게 흐리게 할 수 있는 디버그 메시지를 출력하는 데 로깅 도구가 사용됩니다.

ns-3에서 사용되는 subHRD는 이러한 모든 수준의 정보 콘텐츠가 유용하다고 가정하고 메시지 로깅에 대한 선택적이고 계층화된 접근 방식을 제공합니다. 로깅은 완전히 비활성화하거나, 구성 요소별로 또는 전체적으로 활성화할 수 있습니다. 이를 위해 조정 가능한 수준의 정보 콘텐츠가 사용됩니다. ns-3 로깅 모듈은 시뮬레이션에서 유용한 정보를 얻는 비교적 간단한 방법을 제공합니다.

모델에서 데이터를 추출하기 위한 범용 메커니즘인 추적을 제공한다는 점을 이해해야 합니다. 이는 시뮬레이션을 위한 기본 출력이 되어야 합니다(추적 시스템에 대한 자세한 내용은 튜토리얼 섹션 5.3을 참조하세요). 로깅은 디버깅 정보, 경고, 오류 메시지를 얻거나 언제든지 스크립트나 모델에서 메시지를 신속하게 출력하기 위해 선호되는 방법입니다.

현재 시스템은 정보 내용이 증가하는 순서대로 로그 메시지의 XNUMX가지 수준(유형)을 정의합니다.

• LOG_ERROR - 오류 메시지 로깅(관련 매크로: NS_LOG_ERROR);
• LOG_WARN - 경고 메시지 기록(관련 매크로: NS_LOG_WARN);
• LOG_DEBUG - 상대적으로 드문 특수 디버그 메시지를 기록합니다(관련 매크로: NS_LOG_DEBUG).
• LOG_INFO - 프로그램 진행에 관한 정보 메시지 등록(관련 매크로: NS_LOG_INFO)
• LOG_FUNCTION - 호출된 각 함수(두 개의 관련 매크로: 멤버 함수에 사용되는 NS_LOG_FUNCTION 및 정적 함수에 사용되는 NS_LOG_FUNCTION_NOARGS)를 설명하는 메시지를 기록합니다.
• LOG_LOGIC - 함수 내의 논리적 흐름을 설명하는 로깅 메시지(관련 매크로: NS_LOG_LOGIC)
• LOG_ALL - 위에 언급된 모든 내용을 기록합니다(관련 매크로 없음).
  각 유형(LOG_TYPE)에는 LOG_LEVEL_TYPE도 있으며, 이를 사용하면 자체 수준 외에도 그 위의 모든 수준을 기록할 수 있습니다. (결과적으로 LOG_ERROR와 LOG_LEVEL_ERROR, LOG_ALL과 LOG_LEVEL_ALL은 기능적으로 동일합니다.) 예를 들어 LOG_INFO를 활성화하면 NS_LOG_INFO 매크로에서 제공하는 메시지만 허용하는 반면, LOG_LEVEL_INFO를 활성화하면 NS_LOG_DEBUG, NS_LOG_WARN 및 NS_LOG_ERROR 매크로에서 제공하는 메시지도 포함됩니다.

또한 로깅 수준이나 선택 구성 요소에 관계없이 항상 표시되는 무조건 로깅 매크로를 제공합니다.

• NS_LOG_UNCOND - 관련 메시지의 무조건 로깅(관련 로깅 수준 없음)

각 수준은 개별적으로 또는 누적적으로 쿼리할 수 있습니다. 로깅은 sh 환경 변수 NS_LOG를 사용하거나 시스템 함수 호출을 로깅하여 구성할 수 있습니다. 앞서 살펴본 것처럼 로깅 시스템에는 Doxygen 문서가 있으며 아직 검토하지 않았다면 지금 검토해 볼 수 있는 좋은 시간입니다.

이제 문서를 매우 자세히 읽었으므로 해당 지식을 활용하여 예제 스크립트에서 흥미로운 정보를 얻어 보겠습니다. 스크래치/myfirst.cc이미 컴파일한 것입니다.

5.1.2 로깅 활성화

NS_LOG 환경 변수를 사용하여 더 많은 로그를 실행해 보겠습니다. 먼저 방향을 파악하기 위해 이전에 했던 것처럼 마지막 스크립트를 실행합니다.

$ ./waf --run scratch/myfirst

첫 번째 ns-3 예제 프로그램의 친숙한 출력이 표시됩니다.

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

위에 표시된 "전송" 및 "수신" 메시지는 실제로는 다음에서 기록된 메시지입니다. UdpEchoClient응용 프로그램 и UdpEchoServer응용 프로그램. 예를 들어, NS_LOG 환경 변수를 통해 로깅 수준을 설정하여 클라이언트 애플리케이션에 추가 정보를 인쇄하도록 요청할 수 있습니다.

이제부터는 "VARIABLE=value" 구문을 사용하는 sh와 같은 쉘을 사용하고 있다고 가정하겠습니다. csh와 유사한 셸을 사용하는 경우 예제를 해당 셸에서 요구하는 "setenv 변수 값" 구문으로 변환해야 합니다.

현재 UDP 에코 클라이언트 애플리케이션은 다음 코드 줄에 응답합니다. 스크래치/myfirst.cc,

LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);

로깅 수준 LOG_LEVEL_INFO를 활성화합니다. 로깅 수준 플래그를 전달하면 실제로 해당 수준과 모든 하위 수준이 활성화됩니다. 이 경우 NS_LOG_INFO, NS_LOG_DEBUG, NS_LOG_WARN 및 NS_LOG_ERROR를 활성화했습니다. NS_LOG 환경 변수를 다음과 같이 설정하면 스크립트 변경이나 재컴파일 없이 로깅 수준을 높이고 더 많은 정보를 얻을 수 있습니다.

$ export NS_LOG=UdpEchoClientApplication=level_all

따라서 sh 쉘 변수 NS_LOG를 다음 값으로 설정합니다.

UdpEchoClientApplication=level_all

할당의 왼쪽은 구성하려는 기록된 구성 요소의 이름이고 오른쪽은 적용할 플래그입니다. 이 경우 애플리케이션에서 모든 수준의 디버깅을 활성화하겠습니다. NS_LOG를 이런 방식으로 설정하여 스크립트를 실행하면 ns-3 로깅 시스템이 변경 사항을 수락하고 다음 출력이 표시됩니다.

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

애플리케이션에서 제공하는 추가 디버깅 정보는 이제 NS_LOG_FUNCTION 수준에 있습니다. 스크립트 실행 중 함수 호출의 모든 인스턴스를 표시합니다. 일반적으로 메소드 함수에서는 (최소한) 사용하는 것이 바람직합니다.NS_LOG_FUNCTION (this)... 사용 NS_LOG_FUNCTION_NOARGS ()
정적 함수에서만 가능합니다. 그러나 ns-3 시스템은 로깅 기능을 지원할 필요가 없습니다. 얼마나 많은 정보가 기록되는지에 대한 결정은 개별 모델 개발자에게 달려 있습니다. echo 애플리케이션의 경우 대량의 로깅 출력이 가능합니다.

이제 애플리케이션에서 수행된 함수 호출 로그를 볼 수 있습니다. 자세히 보면 줄 사이에 콜론이 있는 것을 볼 수 있습니다. UdpEchoClient응용 프로그램 그리고 C++ 범위 연산자(: :)를 볼 수 있는 메서드의 이름입니다. 이는 의도적인 것입니다.

이는 실제로 클래스 이름이 아니라 로깅 구성 요소의 이름입니다. 소스 파일과 클래스가 일치하는 경우 일반적으로 클래스 이름이지만 실제로는 클래스 이름이 아니며 이중 콜론 대신 단일 콜론이 있다는 점을 알아야 합니다. 이는 상대적으로 미묘한 방법으로 클래스 이름에서 로깅 Bean 이름을 개념적으로 분리하는 데 도움이 되는 방법입니다.

그러나 경우에 따라 실제로 로그 메시지를 생성하는 방법을 확인하는 것이 어려울 수 있습니다. 위의 텍스트를 보시면 "라는 줄이 어디에 있는지 궁금하실 것입니다.Received 1024 bytes from 10.1.1.2" 레벨을 설정하면 이 문제를 해결할 수 있습니다. 접두사_펑크 NS_LOG 환경 변수에. 다음을 시도해 보세요:

$ export 'NS_LOG=UdpEchoClientApplication=level_all|prefix_func'

OR 연산을 나타내는 데 사용하는 세로 막대도 Unix 파이프 커넥터이기 때문에 따옴표가 필요합니다. 이제 스크립트를 실행하면 로깅 시스템이 특정 로그의 모든 메시지 앞에 구성 요소 이름이 붙는 것을 확인하는 것을 볼 수 있습니다.

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

이제 UDP 에코 클라이언트 애플리케이션에서 오는 모든 메시지가 이와 같이 식별되는 것을 볼 수 있습니다. 메시지 "Received 1024 bytes from 10.1.1.2"는 이제 에코 클라이언트 애플리케이션에서 오는 것으로 명확하게 식별됩니다. 나머지 메시지는 UDP 에코 서버 애플리케이션에서 와야 합니다. NS_LOG 환경 변수에 콜론으로 구분된 구성 요소 목록을 입력하여 이 구성 요소를 활성화할 수 있습니다.

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

경고: 위의 예제 텍스트에서 문서 형식을 지정하는 데 사용되는 콜론(:) 뒤의 개행 문자를 제거해야 합니다. 이제 스크립트를 실행하면 클라이언트 및 서버 에코 애플리케이션의 모든 로그 메시지가 표시됩니다. 디버깅할 때 이것이 매우 유용할 수 있다는 것을 알 수 있습니다.

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

로그 메시지가 생성된 시뮬레이션 시간을 볼 수 있으면 유용할 때도 있습니다. OR 비트를 추가하면 됩니다. 접두사_시간:

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

이번에도 위의 개행 문자를 제거해야 합니다. 이제 스크립트를 실행하면 다음 출력이 표시됩니다.

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

생성자는 다음과 같습니다. UDPEcho서버 시뮬레이션 중에 0초 동안 호출되었습니다. 이는 실제로 시뮬레이션이 시작되기 전에 발생하지만 시간은 XNUMX초로 표시됩니다. 생성자 메시지도 마찬가지입니다. UDPEcho클라이언트.

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

스크립트를 기억하세요. 스크래치/first.cc 시뮬레이션 시작 XNUMX초 전에 에코 서버 애플리케이션을 시작했습니다. 이제 그 방법을 볼 수 있습니다 응용 프로그램 시작 서버는 실제로 첫 번째 순간에 호출됩니다. 스크립트에서 요청한 대로 시뮬레이션의 두 번째 초에 에코 클라이언트가 시작되는 것을 볼 수도 있습니다.

이제 통화 시 시뮬레이션 진행 상황을 확인할 수 있습니다. 일정전송 HandleRead 콜백을 호출하는 클라이언트에서 에코 서버 애플리케이션으로 보냅니다. 지점 간 링크를 통해 패킷을 보내는 데 경과된 시간은 3,69밀리초입니다. 에코 서버가 패킷에 응답했다는 메시지를 기록한 다음, 채널 지연 후 에코 클라이언트가 HandleRead 메서드에서 에코 패킷을 수신하는 것을 볼 수 있습니다.

이 시뮬레이션에서는 여러분도 모르는 사이에 많은 일이 일어납니다. 그러나 시스템의 모든 로깅 구성 요소를 활성화하면 전체 프로세스를 매우 쉽게 추적할 수 있습니다. NS_LOG 변수를 다음 값으로 설정해보세요.

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

위의 별표는 로깅 구성 요소의 와일드카드 문자입니다. 여기에는 시뮬레이션에 사용된 모든 구성 요소의 모든 항목이 포함됩니다. 여기서 출력을 재현하지는 않겠지만(작성 당시에는 단일 에코 패킷에 대해 1265줄의 출력이 생성됨) 이 정보를 파일로 리디렉션하고 즐겨 사용하는 편집기에서 볼 수 있습니다.

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

저는 개인적으로 문제가 있고 어디서 문제가 발생했는지 전혀 알 수 없을 때 매우 장황한 로깅 버전을 사용합니다. 중단점을 설정하거나 디버거에서 코드를 단계별로 실행하지 않고도 매우 쉽게 코드 실행을 따라갈 수 있습니다. 내가 가장 좋아하는 편집기에서 출력을 편집하고 내가 기대하는 것을 찾아보고 예상하지 못한 일이 일어나는 것을 볼 수 있습니다. 무엇이 잘못되고 있는지에 대한 일반적인 아이디어를 얻은 후에는 디버거로 뛰어들어 문제를 자세히 조사합니다. 이러한 유형의 출력은 스크립트가 완전히 예상치 못한 작업을 수행할 때 특히 유용할 수 있습니다. 디버거만 사용하면 트위스트를 완전히 놓칠 수 있습니다. 등록을 하면 그러한 전환이 눈에 띄게 됩니다.

5.1.3 코드에 로깅 추가

여러 매크로에서 로그 구성 요소를 호출하여 시뮬레이션에 새 항목을 추가할 수 있습니다. 스크립트로 해보자 myfirst.cc, "clean" 디렉토리에 있습니다. 이 시나리오에서는 로깅 구성 요소를 정의했다는 점을 기억하세요.

NS_LOG_COMPONENT_DEFINE ("FirstScriptExample");

NS_LOG 환경 변수를 다양한 수준에서 설정하여 이 구성 요소의 모든 메시지 로깅을 활성화할 수 있다는 것을 알고 계십니다. 계속해서 스크립트에 몇 가지 항목을 추가해 보겠습니다. 정보 수준 메시지를 로그에 추가하는 데 사용되는 매크로는 NS_LOG_INFO입니다. 스크립트가 "토폴로지 생성" 단계에 있음을 알려주는 메시지(노드 생성을 시작하기 직전)를 추가해 보겠습니다. 이는 다음 코드 조각에서 수행됩니다.
열어 라. 스크래치/myfirst.cc 좋아하는 편집기에서 다음 줄을 추가하세요.
NS_LOG_INFO ("Creating Topology");
줄 바로 앞에,

NodeContainer nodes;
nodes.Create (2);

이제 다음을 사용하여 스크립트를 컴파일하십시오. waf, NS_LOG 변수를 지워 이전에 활성화한 로깅 스트림을 비활성화합니다.

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

연결된 로깅 구성 요소(FirstScriptExample)가 활성화되지 않았기 때문에 새 메시지가 표시되지 않습니다. 메시지를 보려면 로깅 구성 요소를 활성화해야 합니다. FirstScript예 NS_LOG_INFO보다 낮지 않은 수준입니다. 이 특정 로깅 수준을 보려면 다음과 같이 활성화하면 됩니다.

$ export NS_LOG=FirstScriptExample=info

지금 스크립트를 실행하면 "Creating Topology"라는 새 메시지가 표시됩니다.

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

5.2 명령줄 인수 사용

5.2.1 기본 속성 값 재정의

편집이나 빌드 없이 ns-3 스크립트의 동작을 변경하는 또 다른 방법은 명령줄 인수를 사용하는 것입니다. 우리는 명령줄 인수를 구문 분석하고 결과에 따라 로컬 및 전역 변수를 자동으로 설정하는 메커니즘을 제공합니다.

명령줄 인수 시스템을 사용하는 첫 번째 단계는 명령줄 구문 분석기를 선언하는 것입니다. 이는 다음 코드에서와 같이 (메인 프로그램에서) 매우 쉽게 수행할 수 있습니다.

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

이 간단한 두 줄짜리 코드 조각은 실제로 그 자체로 매우 유용합니다. ns-3 전역 변수 및 속성 시스템에 대한 문이 열립니다. 기본 스크립트 함수의 시작 부분에 두 줄의 코드를 추가해 보겠습니다. 스크래치/myfirst.cc. 계속해서 스크립트를 컴파일하고 실행합니다. 실행 시 다음과 같이 도움 요청을 합니다.

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

이 명령은 묻습니다. 와프 스크립트 실행 스크래치/myfirst 명령줄 인수를 전달합니다. —인쇄도움말. 인수가 의도된 프로그램을 나타내려면 따옴표가 필요합니다. 명령줄 파서가 인수를 감지합니다. —인쇄도움말 답변이 표시됩니다.

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

이제 옵션을 살펴보자 —인쇄 속성. 우리는 first.cc 스크립트를 연구할 때 이미 ns-3 속성 시스템을 언급했습니다. 우리는 다음과 같은 코드 줄을 보았습니다.

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

그리고 그들은 그렇게 말했어요 데이터 속도 실제로는 속성입니다 PointToPointNet장치. 명령줄 인수 구문 분석기를 사용하여 속성을 살펴보겠습니다. PointToPointNet장치. 도움말 목록에는 우리가 제공해야 할 사항이 나와 있습니다. 유형 ID. 관심 있는 속성이 속하는 클래스의 이름입니다. 우리의 경우에는 ns3::PointToPointNetDevice. 계속 앞으로 나아가자, 들어가자,

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

시스템은 이 네트워크 장치 유형의 모든 속성을 인쇄합니다. 목록의 속성 중 다음이 표시됩니다.

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

이는 객체를 생성할 때 시스템에서 사용되는 기본값입니다. PointToPointNet장치. 매개변수를 사용하여 이 기본값을 재정의합니다. 속성 в 포인트투포인트도우미 더 높은. 지점 간 장치 및 채널에는 기본값을 사용하겠습니다. 이를 위해 통화를 삭제하겠습니다. SetDevice속성 и SetChannel속성 으로 myfirst.cc, 깨끗한 디렉토리에 있습니다.

이제 스크립트는 간단히 선언해야 합니다. 포인트투포인트도우미 아래 예와 같이 설치 작업을 수행하지 마십시오.

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

계속해서 다음을 사용하여 새 스크립트를 작성하십시오. 와프 (./와프) 다시 돌아가서 UDP 에코 서버 애플리케이션의 일부 항목을 포함하고 시간 접두어를 포함해 보겠습니다.

$ export 'NS_LOG=UdpEchoServerApplication=level_all|prefix_time'

스크립트를 실행하면 다음 출력이 표시됩니다.

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

마지막으로 시뮬레이션 시간을 살펴봤을 때, 에코 서버가 패킷을 수신한 순간은 2,00369초였습니다.

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

이제 그는 2.25732초 안에 패킷을 받습니다. 이는 단순히 PointToPointNetDevice 데이터 속도를 초당 32768메가비트에서 기본값인 초당 XNUMX비트로 재설정하기 때문입니다. 명령줄을 사용하여 새로운 DataRate를 대체한다면 시뮬레이션 속도를 다시 높일 수 있습니다. 도움말 요소에 포함된 공식에 따라 다음과 같이 이 작업을 수행합니다.

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

이렇게 하면 DataRate 속성이 기본값인 초당 XNUMX메가비트로 반환됩니다. 결과에 놀랐나요? 스크립트의 원래 동작을 반환하려면 빛의 속도와 일치하도록 채널 지연도 설정해야 합니다. 네트워크 장치에 대해 했던 것처럼 명령줄 시스템에 채널 속성을 인쇄하도록 요청할 수 있습니다.

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

채널 지연 속성이 다음과 같이 설정되어 있음을 알 수 있습니다.

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

그런 다음 명령줄 시스템을 통해 이러한 기본값을 모두 설정할 수 있습니다.

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

이 경우 스크립트에서 DataRate 및 Delay를 명시적으로 설정했을 때의 시간을 복원합니다.

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

2,00369초 후에 서버에서 패킷을 다시 수신한다는 점에 유의하세요. 실제로 이 방법으로 스크립트에 사용된 속성을 설정할 수 있습니다. 특히 MaxPackets 속성을 XNUMX이 아닌 값으로 설정할 수 있습니다. UDPEcho클라이언트.

어떻게 사용하시겠습니까? 시도 해봐. 기본 속성 값을 재정의하고 명시적으로 설정한 위치를 주석 처리해야 한다는 점을 기억하세요. 최대 패킷 스크립트에서. 그런 다음 스크립트를 다시 작성해야 합니다. 명령줄을 사용하여 새 기본 속성 값 설정에 대한 구문 도움말을 얻을 수도 있습니다. 이 내용을 이해하고 나면 명령줄에 표시되는 패키지 수를 제어할 수 있습니다. 우리는 공부하는 사람들이기 때문에 명령줄은 다음과 같아야 합니다.

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

이 시점에서 발생하는 자연스러운 질문은 이러한 모든 속성의 존재를 어떻게 알 수 있느냐는 것입니다. 다시 말하지만, 명령줄 시스템에는 이 문제에 대한 도움말 기능이 있습니다. 명령줄에 도움을 요청하면 다음을 확인해야 합니다.

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

"PrintGroups" 인수를 선택하면 등록된 모든 그룹 목록이 표시됩니다. 유형 ID. 그룹 이름은 소스 디렉터리에 있는 모듈 이름과 일치합니다(대문자로 표시됨). 모든 정보를 한 번에 인쇄하면 용량이 너무 커지므로 추가 필터를 사용하여 그룹별로 정보를 인쇄할 수 있습니다. 따라서 다시 지점 간 모듈에 초점을 맞추겠습니다.

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

여기에서 속성 조회에 사용 가능한 TypeId 이름을 찾을 수 있습니다. 예를 들어
--PrintAttributes = ns3 :: PointToPointChannel위에 표시된 대로.

속성에 대해 배우는 또 다른 방법은 Doxygen ns‑3을 이용하는 것입니다. 시뮬레이터에 등록된 모든 속성을 나열하는 페이지가 있습니다.

5.2.2 자신만의 명령 캡처

명령줄 시스템을 통해 자신만의 후크를 추가할 수도 있습니다. 이는 명령줄 파서 방법을 사용하여 매우 간단하게 수행됩니다. 값을 추가.
이 기능을 사용하여 완전히 다른 방식으로 표시할 패키지 수를 지정해 보겠습니다. 라는 지역 변수를 추가해 보겠습니다. n패킷 함수로 본관. 이전 기본 동작과 일치하도록 XNUMX로 설정하겠습니다. 명령줄 파서가 이 값을 변경할 수 있도록 하려면 파서에서 이 값을 캡처해야 합니다. 호출을 추가하면 됩니다. 값을 추가. 가서 스크립트를 바꿔보세요 스크래치/myfirst.cc 따라서 다음 코드부터 시작하려면

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

MaxPackets 속성을 설정하는 스크립트 지점까지 아래로 스크롤하고 아래와 같이 상수 1 대신 nPackets 변수로 설정되도록 변경합니다.

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

이제 스크립트를 실행하고 -PrintHelp 인수를 제공하면 새 사용자 인수가 표시됩니다. 도움말 표시에 나열됩니다. 입력하다,

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

전송되는 패킷 수를 변경하려면 명령줄 인수 -nPackets를 설정하면 됩니다.

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

이제 이제 보아야 합니다.

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

이제 두 개의 패키지를 보냈습니다. 꽤 간단하지 않나요?
ns-3 사용자로서 명령줄 인수 시스템을 사용하여 전역 값과 속성을 조작할 수 있음을 알 수 있습니다. 모델 작성자인 경우 개체에 새 특성을 추가할 수 있으며 명령줄 시스템을 통해 사용자가 해당 특성을 자동으로 구성할 수 있습니다. 스크립트 작성자라면 스크립트에 새 변수를 추가하고 이를 명령줄 시스템에 원활하게 연결할 수 있습니다.

5.3 추적 시스템 사용

모델링의 전체 요점은 추가 연구를 위한 출력을 생성하는 것이며, ns-3 추적 시스템은 이를 위한 주요 메커니즘입니다. ns-3은 C++ 프로그램이므로 C++ 프로그램에서 출력을 생성하는 표준 방법을 사용할 수 있습니다.

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

로깅 모듈을 사용하여 솔루션에 약간의 구조를 추가할 수도 있습니다. 이 접근 방식으로 인해 발생하는 알려진 문제가 많이 있으므로 이러한 문제를 해결하기 위해 일반 이벤트 추적 하위 시스템을 제공했습니다.

ns-3 추적 시스템의 주요 목표는 다음과 같습니다.

• 기본 작업의 경우 추적 시스템을 통해 사용자는 인기 있는 소스에 대한 표준 추적을 생성하고 추적을 생성하는 개체를 선택할 수 있습니다.

• 중급 사용자는 시뮬레이터 코어를 수정하지 않고도 추적 시스템을 확장하여 생성된 출력 형식을 변경하거나 새로운 추적 소스를 삽입할 수 있어야 합니다.

• 고급 사용자는 시뮬레이터 코어를 수정하여 새로운 추적 소스와 싱크를 추가할 수 있습니다. ns-3 추적 시스템은 독립적인 추적 소스 및 수신기의 원칙과 소스를 소비자에 연결하기 위한 통합 메커니즘을 기반으로 구축되었습니다.

ns-3 추적 시스템은 독립적인 추적 소스 및 수신기의 원칙과 소스를 수신기에 연결하기 위한 통합 메커니즘을 기반으로 구축되었습니다. 추적 소스는 시뮬레이션에서 발생하는 이벤트에 신호를 보내고 관심 있는 기본 데이터에 대한 액세스를 제공할 수 있는 개체입니다. 예를 들어 추적 소스는 네트워크 장치가 패킷을 수신한 시기를 표시하고 관심 있는 추적 수신기가 패킷의 콘텐츠를 사용할 수 있도록 할 수 있습니다.

싱크가 제공하는 정보를 사용하여 실제로 유용한 작업을 수행하는 코드의 다른 부분과 "결합"되지 않는 한 추적 소스 자체는 쓸모가 없습니다. 추적 프로그램은 추적 소스에서 제공하는 이벤트 및 데이터의 소비자입니다. 예를 들어, 이전 예의 추적 소스에 연결된 경우 수신된 패킷에서 관심 있는 부분을 인쇄하는 추적 싱크를 만들 수 있습니다.

이렇게 명시적으로 분리하는 이유는 사용자가 시뮬레이터 코어를 편집하고 다시 컴파일할 필요 없이 새로운 싱크 유형을 기존 추적 소스에 연결할 수 있도록 하기 위한 것입니다. 따라서 위의 예에서 사용자는 스크립트에서 새 추적 프로그램을 정의하고 사용자 스크립트를 편집하는 것만으로 시뮬레이션 코어에 정의된 기존 추적 소스에 연결할 수 있습니다.

이 튜토리얼에서는 사전 정의된 소스 및 싱크 중 일부를 살펴보고 사용자 측에서 최소한의 노력으로 구성할 수 있는 방법을 보여줍니다. 추적 네임스페이스 확장 및 새 추적 소스 생성을 포함한 고급 추적 구성에 대한 자세한 내용은 ns-3 매뉴얼 또는 방법 섹션을 참조하세요.

5.3.1 ASCII 추적

ns-3은 간단한 패킷 추적을 설정할 때 세부 정보를 제공하는 데 도움이 되는 낮은 수준의 추적 시스템을 제공하는 도우미 기능을 제공합니다. 이 기능을 활성화하면 ASCII 파일로 출력이 표시됩니다. ns-2 출력에 익숙한 사람들에게 이러한 유형의 추적은 다음과 유사합니다. out.tr, 이는 많은 스크립트에 의해 생성됩니다.

본론으로 돌아가서 스크래치/myfirst.cc 스크립트에 일부 ASCII 추적 결과를 추가해 보겠습니다. 통화 직전 Simulator :: Run (), 다음 코드 줄을 추가합니다.
AsciiTraceHelper ascii;

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

다른 많은 ns-3 관용구와 마찬가지로 이 코드는 도우미 개체를 사용하여 ASCII 추적을 생성합니다. 두 번째 줄에는 두 개의 중첩된 메서드 호출이 포함되어 있습니다. "내부" 방법 생성파일스트림() 익명 객체 관용구를 사용하여 스택에 객체 이름 없이 파일 스트림 객체를 생성하고 이를 호출된 메서드에 전달합니다. 앞으로 이에 대해 더 자세히 설명하겠지만, 이 시점에서 알아야 할 것은 다음과 같은 파일을 나타내는 객체를 생성한다는 것입니다. myfirst.tr ns-3으로 전송합니다. 우리는 생성된 객체를 전체 수명 동안 관리하도록 ns-3에 맡깁니다. 그 동안 C++ 스트림 객체 복사 생성자와 관련된 거의 알려지지 않은(의도적인) 제한으로 인해 발생하는 문제를 해결합니다.

외부 통화 AsciiAll 활성화() 모든 지점 간 장치 연결에 대한 시뮬레이션에 ASCII 추적을 포함하고 (지정된) 추적 수신기가 패킷 이동 정보를 ASCII 형식으로 기록하도록 보조자에게 알립니다.

ns-2에 익숙한 사람들에게 추적된 이벤트는 이벤트 "+", "-", "d" 및 "r"을 기록하는 알려진 추적점과 동일합니다.
이제 스크립트를 빌드하고 명령줄에서 실행할 수 있습니다.

$ ./waf --run scratch/myfirst

이전과 마찬가지로 Waf에서 여러 메시지가 표시되고 실행 중인 프로그램의 일부 메시지와 함께 "'빌드'가 성공적으로 완료되었습니다"라는 메시지가 표시됩니다.

실행 시 프로그램은 다음과 같은 파일을 생성합니다. myfirst.tr. 작품의 특성상 와프, 기본적으로 파일은 로컬 디렉터리가 아닌 저장소의 최상위 디렉터리에 생성됩니다. 추적이 저장되는 경로를 변경하려면 Waf 매개변수를 사용하여 지정할 수 있습니다. --cwd. 아직 이 작업을 수행하지 않았으므로 즐겨 사용하는 편집기에서 ASCII 추적 파일 myfirst.tr을 보려면 저장소의 최상위 디렉터리로 이동해야 합니다.

ASCII 추적 구문 분석

상당히 조밀한 형태로 많은 정보가 있지만 가장 먼저 주목해야 할 것은 파일이 개별 줄로 구성되어 있다는 것입니다. 이는 보기 창을 더 넓게 확장하면 명확하게 표시됩니다.

파일의 각 줄은 추적 이벤트에 해당합니다. 이 경우 시뮬레이션의 각 지점 간 네트워크 장치에 있는 전송 대기열의 이벤트를 추적합니다. 전송 큐는 지점 간 링크를 위해 각 패킷이 통과해야 하는 큐입니다. 추적 파일의 각 줄은 단일 문자로 시작하고 그 뒤에 공백이 있습니다. 이 기호의 의미는 다음과 같습니다.

+: 장치 대기열에서 대기열 작업이 발생했습니다.
-: 장치 큐에서 요소 검색 작업이 발생했습니다.
d: 일반적으로 대기열이 가득 차서 패킷이 삭제되었습니다.
r: 패킷이 네트워크 장치에 의해 수신되었습니다.

추적 파일의 첫 번째 줄을 자세히 살펴보겠습니다. 명확성을 위해 들여쓰기를 사용하여 여러 부분으로 나누고 왼쪽에 줄 번호를 표시하겠습니다.

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

이 확장 추적 이벤트의 첫 번째 섹션(라인 0)은 작업입니다. 여기에 + 기호가 있는데 이는 전송을 위한 대기열 작업에 해당합니다. 두 번째 섹션(라인 1)은 초 단위로 표현되는 시뮬레이션 시간입니다. 우리가 요청한 내용을 기억하실 것입니다. UdpEchoClient응용 프로그램 XNUMX초 안에 패킷 전송을 시작합니다. 여기서 우리는 이것이 실제로 일어나고 있다는 확인을 봅니다.

추적 예제의 다음 섹션(2행)에서는 이 이벤트(네임스페이스 추적을 나타냄)를 생성한 추적 소스를 보여줍니다. 추적 네임스페이스는 파일 시스템 네임스페이스와 비슷하게 생각할 수 있습니다. 네임스페이스의 루트는 다음과 같습니다. 노드 목록. 이는 기본 ns-3 코드에서 관리하는 컨테이너에 해당합니다. 여기에는 스크립트에서 생성된 모든 노드가 포함됩니다. 파일 시스템의 루트에 디렉터리가 있을 수 있는 것처럼 노드 목록 우리는 많은 노드를 가질 수 있습니다. 따라서 /NodeList/0 행은 일반적으로 "노드 0"으로 생각되는 NodeList의 null 노드를 나타냅니다. 각 노드에는 설치된 장치 목록이 있습니다. 이 목록은 네임스페이스 옆에 위치합니다. 이 추적 이벤트가 다음에서 비롯된 것을 볼 수 있습니다. 장치 목록/0, 이는 노드에 설치된 null 장치입니다.

다음 하위 문자열, $ ns3 :: PointToPointNetDevice, 어떤 장치가 위치 0에 있는지 알려줍니다. 즉, 노드 XNUMX의 장치 목록입니다. XNUMX행에 있는 + 연산은 장치의 전송 대기열에 요소가 추가되었음을 의미합니다. 이는 "트랙 경로"의 마지막 세그먼트에 반영됩니다. TxQueue/인큐.

추적의 나머지 섹션은 상당히 직관적이어야 합니다. 3-4행은 패킷이 지점간 프로토콜로 캡슐화되었음을 나타냅니다. 5-7행은 패킷에 IP4 버전 헤더가 있고 IP 주소에서 시작되었음을 보여줍니다. 10.1.1.1 ~을위한 것입니다. 10.1.1.2. 라인 8-9는 이 패킷에 UDP 헤더가 있음을 보여주고 마지막으로 라인 10은 페이로드가 예상되는 1024바이트임을 보여줍니다.

추적 파일의 다음 줄은 동일한 패킷이 동일한 노드의 전송 큐에서 당겨졌음을 보여줍니다.

추적 파일의 세 번째 줄은 패킷이 에코 서버 호스트의 네트워크 장치에서 수신되었음을 보여줍니다. 아래에 그 사건을 재현해 두었습니다.

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

이제 추적 작업은 r이고 시뮬레이션 시간은 2,25732초로 늘어났습니다. 자습서를 주의 깊게 따랐다면 이는 네트워크 장치의 DataRate 및 Link Delay를 기본값으로 두었음을 의미합니다. 이 시제는 이전 섹션에서 보았듯이 익숙할 것입니다.

추적 소스 네임스페이스 항목(라인 2)은 이 이벤트가 노드 1(/노드 목록/1) 패킷은 추적 소스(/)에 의해 수신됩니다.맥알엑스). 파일에 남아 있는 추적을 보면 토폴로지 전체에서 패킷의 이동을 추적하는 것이 상당히 쉬울 것입니다.

5.3.2 PCAP 추적

ns-3 장치 도우미를 사용하여 .pcap 형식의 추적 파일을 생성할 수도 있습니다. 두문자어 pcap (보통 소문자로 작성됨)은 패킷 캡처를 나타내며 실제로는 .pcap 파일 형식 정의를 포함하는 API입니다. 이 형식을 읽고 표시할 수 있는 가장 널리 사용되는 프로그램은 다음과 같습니다. 와이어 샤크 (이전에 불렀던 미묘한). 그러나 이 패킷 형식을 사용하는 트래픽 추적 분석기가 많이 있습니다. 우리는 사용자가 pcap 추적을 분석하는 데 사용할 수 있는 다양한 도구를 사용하도록 권장합니다. 이 튜토리얼에서는 다음을 사용하여 pcap 추적을 보는 데 중점을 둘 것입니다. TCP 덤프.

pcap 추적 활성화는 한 줄의 코드로 수행됩니다.

pointToPoint.EnablePcapAll ("myfirst");

방금 추가한 ASCII 추적 코드 뒤에 이 코드 줄을 붙여넣으세요. 스크래치/myfirst.cc. "myfirst.pcap"이나 이와 유사한 문자열은 전달하지 않고 "myfirst" 문자열만 전달했습니다. 이는 매개변수가 전체 파일 이름이 아닌 접두사이기 때문입니다. 시뮬레이션 중에 보조자는 실제로 각 지점 간 장치에 대한 추적 파일을 생성합니다. 파일 이름은 접두사, 노드 번호, 장치 번호 및 접미사 "를 사용하여 구성됩니다.pcap".

예제 스크립트의 경우 "myfirst-0-0.pcap"그리고"myfirst-1-0.pcap"는 각각 노드 0-장치 0 및 노드 1-장치 0에 대한 pcap 추적입니다. pcap 추적을 활성화하는 코드 줄을 추가한 후에는 일반적인 방법으로 스크립트를 실행할 수 있습니다.

$ ./waf --run scratch/myfirst

배포판의 최상위 디렉터리를 보면 세 개의 파일이 보일 것입니다: ASCII 추적 파일 myfirst.tr, 이전에 연구한 파일 myfirst-0-0.pcap и myfirst-1-0.pcap - 방금 생성한 새 pcap 파일입니다.

tcpdump를 사용하여 출력 읽기

현재 pcap 파일을 보는 가장 쉬운 방법은 tcpdump를 사용하는 것입니다.

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

덤프에서 myfirst-0-0.pcap (클라이언트 장치) 시뮬레이션 2초 후에 에코 패킷이 전송되는 것을 볼 수 있습니다. 두 번째 덤프를 보면 (myfirst-1-0.pcap), 2,257324초에 패킷이 수신되는 것을 볼 수 있습니다. 두 번째 덤프에서는 패킷이 2.257324초에 반환되고 마지막으로 첫 번째 덤프에서 2.514648초에 클라이언트가 패킷을 다시 수신한 것을 볼 수 있습니다.

Wireshark로 출력 읽기

익숙하지 않은 경우 와이어 샤크, 프로그램과 문서를 다운로드할 수 있는 웹사이트가 있습니다: http://www.wireshark.org/. 와이어 샤크 이러한 추적 파일을 표시하는 데 사용할 수 있는 GUI입니다. Wireshark가 있으면 추적 파일을 열고 마치 패킷 스니퍼를 사용하여 패킷을 캡처한 것처럼 내용을 표시할 수 있습니다.

출처 : habr.com