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

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

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

• 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 - 연관된 메시지의 무조건 로깅(연관된 로깅 수준 없이).

각 레벨은 개별적으로 또는 누적적으로 요청할 수 있습니다. 로깅은 NS_LOG sh 환경 변수를 사용하거나 시스템 함수 호출을 로깅하여 구성할 수 있습니다. 앞서 설명한 대로 로깅 시스템에는 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 시스템이 로깅 기능을 지원해야 하는 것은 아닙니다. 얼마나 많은 정보를 기록할 것인지에 대한 결정은 각 모델 개발자에게 달려 있습니다. 에코 애플리케이션의 경우, 로깅을 위해 많은 양의 출력을 사용할 수 있습니다.

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

실제로 이는 클래스 이름이 아니라 로깅 구성 요소의 이름입니다. 소스 파일과 클래스 사이에 대응관계가 있는 경우 일반적으로 클래스 이름이지만, 실제로는 클래스 이름이 아니며 콜론이 두 개 아닌 단일 콜론으로 되어 있다는 점을 알아야 합니다. 이는 로깅 구성 요소 이름과 클래스 이름을 비교적 미묘한 방식으로 개념적으로 분리하는 데 도움이 되는 방법입니다.

그러나 어떤 경우에는 실제로 어떤 메서드가 로그 메시지를 생성하는지 판단하기 어려울 수 있습니다. 위의 텍스트를 보면 "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()

생성자는 다음을 참고하세요. UdpEchoServer 시뮬레이션 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 시뮬레이션이 시작되기 1초 전에 에코 서버 애플리케이션을 시작했습니다. 이제 당신은 방법을 볼 수 있습니다 응용 프로그램 시작 실제로 서버는 첫 번째 초에 호출됩니다. 스크립트에서 요청한 대로 에코 클라이언트가 시뮬레이션의 두 번째 초에 시작된다는 점도 확인할 수 있습니다.

이제 통화 중에 시뮬레이션 진행 상황을 확인할 수 있습니다. 일정전송 에코 서버 애플리케이션에서 HandleRead 콜백에 대해 Send를 호출하는 클라이언트에서. 지점 간 링크를 통해 패킷을 전송하는 데 걸리는 시간은 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

지금 스크립트를 실행하면 "토폴로지 생성 중"이라는 새 메시지가 표시됩니다.

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를 대체한다면 시뮬레이션 속도를 다시 높일 수 있습니다. 우리는 help 요소에 내포된 공식에 따라 다음과 같이 이를 수행할 것입니다.

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

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

$ ./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패킷 함수로 본관. 이전 기본 동작과 일치하도록 1로 설정하겠습니다. 명령줄 파서가 이 값을 변경할 수 있도록 하려면 이 값을 파서에 캡처해야 합니다. 우리는 도전을 추가하여 이를 수행합니다. 값을 추가. 가서 스크립트를 편집하세요 스크래치/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, 여러 스크립트에 의해 생성됩니다.

이제 본격적으로 scratch/myfirst.cc 스크립트에 ASCII 추적 결과를 추가해 보겠습니다. 전화하기 직전 Simulator :: Run ()다음 코드 줄을 추가합니다.
AsciiTraceHelper ascii;

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

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

외부 호출 AsciiAll 활성화() 시뮬레이션에서 모든 지점 간 장치 연결에 대해 ASCII 추적을 활성화하고, (지정된) 추적 수신기가 패킷 이동 정보를 ASCII 형식으로 기록하도록 하려는 것을 보조자에게 알려줍니다.

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

$ ./waf --run scratch/myfirst

이전에 여러 번 그랬듯이, Waf에서 몇 개의 메시지가 나온 다음 실행 중인 프로그램에서 몇 가지 메시지와 함께 "'빌드'가 성공적으로 완료되었습니다"라는 메시지가 표시됩니다.

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

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응용 프로그램 2초 안에 패킷 전송을 시작합니다. 여기서 우리는 이것이 실제로 일어나고 있다는 것을 확인할 수 있습니다.

추적 예제의 다음 섹션(2번째 줄)은 어떤 추적 소스가 이 이벤트를 생성했는지(네임스페이스 추적 지정) 보여줍니다. 추적 네임스페이스는 파일 시스템 네임스페이스와 매우 비슷하다고 생각할 수 있습니다. 네임스페이스의 루트는 다음과 같습니다. 노드 목록. 이는 ns-3 코어 코드에서 관리되는 컨테이너에 해당합니다. 여기에는 스크립트에서 생성된 모든 노드가 포함됩니다. 파일 시스템이 루트에 디렉토리를 가질 수 있는 것처럼 노드 목록 노드는 여러 개 가질 수 있습니다. 따라서 문자열 /NodeList/0은 NodeList의 0번째 노드를 나타내며, 일반적으로 이를 "노드 XNUMX"이라고 이해합니다. 각 노드에는 설치된 장치 목록이 포함되어 있습니다. 이 목록은 네임스페이스의 다음 위치에 있습니다. 이 추적 이벤트가 다음에서 발생하는 것을 볼 수 있습니다. 장치 목록/0이는 노드에 설치된 제로 디바이스입니다.

다음 하위 문자열, $ ns3 :: PointToPointNetDevice, 0 노드 장치 목록의 XNUMX 위치에 있는 장치를 알려줍니다. XNUMX번째 줄의 + 연산은 장치의 전송 대기열에 요소가 추가되었음을 의미합니다. 이는 "경로"의 마지막 부분에 반영됩니다. TxQueue/인큐.

추적의 나머지 섹션은 매우 직관적일 것입니다. 3~4번째 줄은 패킷이 지점 간 프로토콜로 캡슐화되었음을 나타냅니다. 5-7번째 줄은 패킷의 IP 버전 헤더가 4이고 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초로 늘어났습니다. 튜토리얼의 지침을 주의 깊게 따랐다면 네트워크 장치의 데이터 전송 속도와 링크 지연 시간을 기본값으로 놔둔 것입니다. 이번에는 이전 섹션에서 보았듯이 익숙할 것입니다.

추적 소스 네임스페이스 항목(라인 2)은 이 이벤트가 노드 1(/)에서 발생한다는 것을 반영하도록 변경되었습니다.노드 목록/1) 및 패킷은 추적 소스(/)에 의해 수신됩니다.맥알엑스). 파일에서 남은 추적 내용을 살펴보면 토폴로지에서 패킷의 이동을 비교적 쉽게 따라갈 수 있을 것입니다.

5.3.2 PCAP 추적

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

pcap 추적을 활성화하는 작업은 한 줄의 코드로 완료됩니다.

pointToPoint.EnablePcapAll ("myfirst");

방금 추가한 ASCII 추적 코드 뒤에 이 코드 줄을 삽입하세요. 스크래치/myfirst.cc. "myfirst" 문자열만 전달하고 "myfirst.pcap"이나 이와 비슷한 문자열은 전달하지 않았다는 점에 유의하세요. 이는 매개변수가 전체 파일 이름이 아니라 접두사이기 때문입니다. 시뮬레이션 중에 보조자는 실제로 각 지점 간 장치에 대한 추적 파일을 생성합니다. 파일 이름은 접두사, 노드 번호, 장치 번호, 접미사 "를 사용하여 구성됩니다.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/. 와이어 샤크 — 이러한 추적 파일을 표시하는 데 사용할 수 있는 그래픽 사용자 인터페이스입니다. Wireshark가 있다면 모든 추적 파일을 열어 패킷 분석기를 사용하여 패킷을 캡처한 것처럼 내용을 표시할 수 있습니다.

출처 : habr.com