바로 second.cc를 분석하기 전에, 앞선 first.cc 해체 분석에서 우리는 LOG기능과 관련된 코드를 여러 줄 보았다.
하지만 우리가 정작 코드를 실행했을 때는, 그 많던 로그들 중 일부만 보였다.
모두가 알다시피, 코딩의 기본 of 기본인 디버깅에 대해서는 제대로 알고 가야할것같아, (제목 번호가 알파인 이유)
ns-3 Tutorial 공식 문서를 찾아보았다.
참고 문서 -
https://www.nsnam.org/docs/release/3.40/tutorial/ns-3-tutorial.pdf
로깅 모듈
ns-3 자체적으로 지원하는 로그 모듈은 7단계의 level로 구성되어있다.
• LOG_ERROR — 에러 메세지 로그 (연관 매크로: NS_LOG_ERROR);
• LOG_WARN — 경고 메세지 로그 ( 연관 매크로: NS_LOG_WARN);
• LOG_DEBUG — 비교적 드문 임시 디버깅 메시지 로그 (연관 매크로: NS_LOG_DEBUG);
• LOG_INFO — 프로그램 실행에 관련된 INFO 로그 (연관 매크로: NS_LOG_INFO);
• LOG_FUNCTION — 호출된 함수를 설명해주는 로그
(두 가지 연관 매크로:
NS_LOG_FUNCTION, member functions에 사용,
NS_LOG_FUNCTION_NOARGS, static functions에 사용);
• LOG_LOGIC – 함수의 논리 흐름 설명 로그 (연관 매크로: NS_LOG_LOGIC);
• LOG_ALL — 위의 모든 로그 내용 로그 (연관 매크로 없음).
각 LOG_TYPE에는 LOG_LEVEL_TYPE이 있으며, 이를 사용하면 해당 레벨 이하의 모든 레벨을 로깅할 수 있다.
(이로 인해 LOG_ERROR와 LOG_LEVEL_ERROR는 기능적으로 동등하다.)
예를 들어, 레벨 4인 LOG_INFO를 활성화하면 NS_LOG_INFO 매크로에서 제공하는 메시지만 활성화되며,
LOG_LEVEL_INFO를 활성화하면
레벨 3인 NS_LOG_DEBUG,
레벨 2인 NS_LOG_WARN 및
레벨 1인 NS_LOG_ERROR 매크로에서 제공하는 메시지도 활성화 된다.
이 외에도 추가적으로, 레벨 구분 없이 항상 출력되는 로그 종류가 하나 있다.
• NS_LOG_UNCOND – 무조건 출력 로그 (연관 레벨 없음).
myfirst.cc 만들기
이제, first.cc에서 사용되었던 로그 코드들을 다시 살펴보기 위해, 나만의 mock code를 하나 build 할 것이다.
ns-3 튜토리얼에서는 mock 코드의 위치를 example/scratch로 제안하고 있으므로,
그 위치에 myfirst.cc를 만들어서, 코드를 복사 붙여넣기 했다.
우리가 살펴볼 첫 로그 코드는 아래다.
NS_LOG_COMPONENT_DEFINE("FirstScriptExample");
얘는 아까 살펴본 로그 종류중에는 없었지만, 우리가 이 코드에서 사용할 NS_LOG의 이름을 지어주는 매크로이다.
만약 우리가 아래와 같은 코드를 추가로 작성하고.
NS_LOG_INFO("Creating Topology");
아래 명령어를 실행한 후
$ export NS_LOG=FirstScriptExample=info
./ns3 run myfirst를 실행하면 다음과 같이 출력된다.

NS_LOG의 이름이 FirstScriptExample인 NS_LOG중
NS_LOG_INFO인 Creating Topology를 export하게 되었다.
LogComponentEnable("UdpEchoClientApplication", LOG_LEVEL_INFO);
LogComponentEnable("UdpEchoServerApplication", LOG_LEVEL_INFO);
그렇다면 이미 작성된 위와 같은 로그도 같은 방법으로 확인해 볼 수 있을 것 같아,
아래와 같은 명령어를 실행 후, 코드를 돌려보았다.
$ export NS_LOG=UdpEchoClientApplication=level_all

실행 결과로 UDP echo 클라이언트 응용에 대한 모든 행적(로그)을 볼 수 있었다.
1. UdpEchoClient 객체 생성
2. DataSize 세팅
3. 응용 실행
4. 전송 스케줄링 (예약)
5. 전송 (및 전송했다고 프린트)
6. 수신 (및 읽고 받았다고 프린트)
7. 응용 종료
8. destroy (?)
같은 방법으로 당연히 UDP echo 서버 응용 로그도 확인할 수 있다.

위 두 로그로 미루어 보아,
클라이언트에 대한 "At time ~ "은 클라이언트가 작성하고,
서버에 대한 "At time ~ "은 서버가 작성하는것을 알 수 있다. (당연하지만)
이렇게 로그를 이용한 디버깅 방법을 간단하게 알아보았다.
이외에도 cmd.addvalue() 를 이용한 변수값 변경 디버깅 방법도 있는데,
이는 추후에 내가 궁금해지면 (...) 이 글에 내용을 더 추가하도록 하겠다.
'개인공부' 카테고리의 다른 글
| [MQTT / Python / IoT] LCFS Queue 구현 (0) | 2025.12.26 |
|---|---|
| [MQTT / Python / IoT] Python으로 구현하는 MQTT (0) | 2025.12.01 |
| [NS-3] 2. second.cc 해체 분석 (0) | 2025.11.24 |
| [NS-3] 1. first.cc 해체 분석 (0) | 2025.11.20 |
| [NS-3] 0. 시작하기 (0) | 2025.11.19 |