Implementing a New Manet Unicast Routing Protocol in NS2 번역입니다.
수정할 내용이 있으면 바로 알려주세요.
NS2에서 새로운 Manet 유니캐스트 라우팅 프로토콜을 구현하기
1 소개
작년 동안에, 우리는 ns-유저들 메일링 리스트에서 같은 질문을 요구하는 많은 사람들을 목격해왔다. 내가 NS2에 적합한 내 소유의 프로토콜을 어떻게 개발하는가? 이 문서를 작성함으로써 우리는 NS-2.27에 적합한 manet 라우팅 프로토콜 더할 필요가 있는 그런 연구자들을 돕기를 희망한다. 우리는 우리의 문서를 유니캐스트 프로토콜에 초점을 맞춘다. 그 문서는 ns-2에서 시뮬레이션들을 수행하는 것에 그럭저럭 잘 아는 그런 사람들을 목표로 하고, 그들은 그들 소유의 프로토콜들을 구현하기 위해서 한 단계 앞으로 가기를 원한다. 이 문장에서 우리가 기술한 모든 것은 NS2의 2.27 버전과 관련이 있지만, 그것은 다른 버전들에서도 마찬가지로 유용할 것이다.
우리는 독자가 NS2 기본들을 잘 안다고 가정한다. 그것은 “Marc Greis’ Tutorial” [1]을 읽었고 적어도 대부분 이해했다는 것을 의미한다. 만약 네가 “The ns Manual” [2], 특히 3-5, 10-12, 15-16, 23, 25 그리고 29장을 또한 훑어본다면 매우 유용할 것이다. 우리는 이런 문장 처음부터 끝까지 여러 번 그것들을 언급할 것이고 네가 그것들을 읽도록 격려할 것이다. 너의 소유의 라우팅 프로토콜을 코딩하기 전에, 너는 다른 구현된 프로토콜들로 시뮬레이션들을 어떻게 수행하는 지 알아야 하고 너는 시뮬레이터를 잘 알고 편안하게 느낄 것으로 예상된다. 이것은 이 문서를 읽는 동안에 많은 오해들과 의심들을 피할 것이다.
게다가 이 tutorial은 프로그래밍에 관한 것이다. 너는 C++과 (조금) Tcl 프로그래밍에 대한 지식이 필요하다. 만약 네가 이런 프로그래밍 언어들을 충분히 경험되지 않았다면, 너는 인터넷에서 자유로이 이용 가능한 그것들에 관한 임의의 훌륭한 자원들을 첫째로 읽어야 한다.
2 시작하면서
우리는 protoname으로 불리는 새로운 manet 라우팅 프로토콜을 단계별로 구현할 예정이다. 이 프로토콜은 유용하지 않지만, 다른 라우팅 프로토콜들과 함께 몇 개의 공통점들을 가지기엔 충분히 일반적이다. 너도 알 것이기 때문에 (만약 아니라면, 우리가 말했던 것을 첫째로 읽어라!) 우리는 C++를 사용해서 라우팅 프로토콜을 구현할 예정이고 그리고 나서 우리는 Tcl 스트립트들로 시나리오들을 기술하는 시뮬레이션들을 할 것이다.
우리의 코드를 할당하기 위해서 우리는 너의 NS2 기반 디렉토리 안쪽에 protoname으로 불리는 새로운 디렉토리를 첫째로 생성할 것이다. 우리는 거기에 5 개의 파일들을 생성할 것이다:
protoname.h 이것은 (만약 있다면) 모든 필요한 타이머들이 정의될 것인 헤더 파일이고 프로토콜의 기능성을 수행하는 라우팅 에이전트이다.
protoname.cc 이 파일 안에는 모든 타이머들, 라우팅 에이전트 그리고 Tcl 후크들이 실제로 구현된다.
protoname_pkt.h 여기에는 MANET에서 노드들 사이에 교환할 필요가 있는 모든 패킷들 protoname 프로토콜이 선언된다.
protoname_rtable.h 우리 소유의 라우팅 표가 선언되는 헤더 파일
protoname_rtable.cc 라우팅 표 구현
너는 원하는 대로 너의 코드를 조직화할 수 있다. 즉, 너는 그런 이름들 또는 다른 것들과 함께 파일들을 더 또는 덜 생성할 수 있다; 그것은 단지 힌트이다. 우리의 조언은 그런 파일들을 적어도 사용하는 것이고 그것들이 필요한 만큼 더 생성하는 것이다.
이제 우리는 우리의 “물리적인” 구조 (파일들)를 가지고 있기 때문에, “논리적인” 것 (클래스들)을 계속하자. NS2에서 라우팅 프로토콜을 구현하기 위해서 너는 에이전트 클래스로부터 물려받음으로써 에이전트를 생성해야 한다. 10장 [2]의 맨 처음에서 우리는 “에이전트들은 네트워크-레이어 패킷들이 구성되거나 소비되는 엔드포인트들을 의미하고, 다양한 레이어들에서 프로토콜들의 구현 안에 사용된다”를 읽을 수 있다. 네가 이해할 수 있는 대로, 이것은 우리가 우리의 라우팅 프로토콜을 구현하기 위해서 코드를 해야할 것인 주된 클래스이다. 게다가, 이 클래스는 Tcl 인터페이스와 연계를 제공하고, 그래서 우리는 Tcl 안에 쓰여진 시뮬레이션 스크립트들을 통해서 우리의 라우팅 프로토콜을 제어할 수 있을 것이다.
우리의 라우팅 에이전트는 내부의 상태와 (항상 필요하지는 않는) 라우팅 표를 유지할 것이다. 내부의 상태는 새로운 클래스로써 또는 라우팅 에이전트 안쪽에 속성들의 집합으로써 나타낼 수 있다. 우리는 새로운 클래스, protoname_rtable로써 라우팅 표를 다룰 수 있을 것이다.
또한 우리의 새로운 프로토콜은 자신의 제어 패킷들의 형식을 의미할 것인 적어도 하나의 새로운 패킷 유형을 정의해야 한다. 우리가 말했던 대로 이런 패킷 유형들은 protoname/protoname_pkt.h에 정의된다. 그 프로토콜이 주기적으로 또는 이벤트의 발생으로부터 약간의 시간 후에 패킷들을 보낼 필요가 있을 때, 타이머 클래스에 의지하는 것은 매우 유용하다. 우리는 규칙적인 간격들에서 이런 패킷들을 보내기 위해서 우리 소유의 타이머들을 코드하는 예를 보여준다. 타이머들은 많은 다른 경우들에서도 또한 유용하다. 정해진 시간에서 지워져야 하는 내부 정보의 몇 가지 종류들을 저장할 필요가 있는 protoname을 상상해라. 가장 좋은 해결책은 그런 일을 할 수 있는 맞춤의 타이머를 생성하는 것이다. 타이머는 라우팅 표 안에서 입력의 시간수명을 명시하기 위해서 또한 사용되어야 한다. 일반적으로, 우리가 주어진 시간에서 업무를 스케쥴해야할 때는 언제나 타이머를 사용할 것이다.
세부적인 것들로 가기전에 우리가 알아야 하는 또 다른 중요한 클래스가 있다. 트레이스 클래스는 시뮬레이션 동안에 무엇이 일어 났는지에 대한 정보를 가진 로그 파일들을 쓰기 위한 기반이다.
그리고 마지막 힌트: 네가 너의 코드 안에 디버그 메시지를 프린트 하기를 원할 때, 25장 [2]에서 제안되는 것처럼 디버그() 함수를 사용하는 것은 도움이 된다. 이것은 네가 너의 시뮬레이션 스크립트들로부터 디버깅을 켜거나 끄도록 허락하고 다른 프로그래머들이 읽는 것이 쉽다.
3 패킷 유형들
이제 네가 기초들을 벌써 알기 때문에, 새로운 파일을 생성하고 그것을 protoname/protoname_pkt.h 이라고 부르자. 여기에서 우리는 우리의 새로운 패킷(들) 유형과 관련된 모든 데이터 구조들, 상수들, 매크로들을 넣을 예정이다. 다음 예제를 보자.
protoname/protoname_pkt.h
1: #ifndef __protoname_pkt_h__
2: #define __protoname_pkt_h__
3:
4: #include <packet.h>
5:
6: #define HDR_PROTONAME_PKT(p) hdr_protoname_pkt::access(p)
7:
8: struct hdr_protoname_pkt {
9:
10: nsaddr_t pkt_src_; // Node which originated this packet
11: u_int16_t pkt_len_; // Packet length (in bytes)
12: u_int8_t pkt_seq_num_; // Packet sequence number
13:
14: inline nsaddr_t& pkt_src() { return pkt_src_; }
15: inline u_int16_t& pkt_len() { return pkt_len_; }
16: inline u_int8_t& pkt_seq_num() { return pkt_seq_num_; }
17:
18: static int offset_;
19: inline static int& offset() { return offset_; }
20: inline static hdr_protoname_pkt* access(const Packet* p) {
21: return (hdr_protoname_pkt*)p->access(offset_);
22: }
23:
24: };
25:
26: #endif
줄들 8-24는 우리가 정의하는 중인 새로운 패킷 유형을 의미하는 hdr_protoname_pkt를 선언한다. 줄들 10-12에서 우리는 우리의 패킷이 가지는 3가지 처리되지 않은 속성들을 볼 수 있다. 그것들은 다음의 유형들이다:
nsaddr_t 네가 NS2에서 네트워크 주소를 선언하기를 원할 때마다 매번 너는 이 유형을 사용해야 한다.
u_int16_t 16 비트들 부호 없는 정수
u_int8_t 8 비트들 부호 없는 정수
이런 모든 유형들과 더 많은 것들은 헤더 파일 config.h 안에 정의된다. 우리는 독자가 이런 파일을 훑어보고 거기에 정의된 유형들을 사용하는 것을 격려한다. 다른 변수들과 그것들을 구별하기 위한 밑줄과 함께 끝내기로 예상되는 처리 되지 않은 속성들의 이름들은 또한 언급할 만한 가치가 있다. (25장 [2]를 보라)
줄들 14-16은 정의된 속성들을 위한 멤버 함수들이다. 이것은 의무적이지는 않지만 12장 [2]에서 제안되는 “좋은 습관”이다 (그리고 우리는 그것을 실제로 지원한다!)
줄 4는 패킷 클래스를 정의하는 파일 common/packet.h를 포함한다. (12장 [2]를 보라) 패킷들은 시뮬레이션 안에서 오브젝트들 사이에 정보를 교환하기 위해서 사용되고, 우리의 목표는 우리의 새로운 struct hdr_protoname_pkt를 그것들에 더하는 것이다. 우리의 제어 패킷들을 그렇게 하는 것은 시뮬레이션 안에서 노드들에 의해서 보내지고 받아들여 질 수 있을 것이다. 우리가 그것을 어떻게 할 수 있는가? 이런 질문에 답하기 위해서 우리는 모든 패킷 헤더들이 패킷 클래스에 의해서 어떻게 저장되는 지를 알아야 하고, 그 답은 패킷들의 필드들이 보관되는 부호 없는 케릭터들의 배열 (비트들의 가방)을 사용하는 것이다. 구체적인 패킷 헤더에 접속하기 위해서 그것이 위치되는 오프셋을 제공할 필요가 있다. 그리고 그것은 정확하게 우리가 줄들 18-22를 통해서 하는 것이다. 우리는 고정된 (모든 hdr_protoname_pkt 구조들에 공통적인) 오프셋, 그것에 접속하기 위한 하나의 멤버 함수 그리고 하나의 패킷이 주어진 hdr_protoname_pkt을 되돌려보내는 함수를 정의한다. 게다가, 줄 6에서 우리는 이런 마지막 함수를 사용하기 위한 매크로를 생성한다.
하나의 업무가 남아있다: 우리의 패킷 헤더를 Tcl 인터페이스에 묶는 것. 우리는 다음의 코드로 protoname/protoname.cc 안에 그렇게 할 것이다. 우리가 볼 수 있듯이 우리는 우리의 패킷 헤더의 오프셋을 Tcl을 통해서 접근하기 쉽게 하는 중이다.
protoname/protoname.cc
1: int protoname_pkt::offset_;
2: static class ProtonameHeaderClass : public PacketHeaderClass {
3: public:
4: ProtonameHeaderClass() : PacketHeaderClass(“PacketHeader/Protoname”,
5: sizeof(hdr_protoname_pkt)) {
6: bind_offset(&hdr_protoname_pkt::offset_);
7: }
8: } class_rtProtoProtoname_hdr;
4 라우팅 에이전트
이제 우리는 에이전트 자체의 프로그래밍을 시작한다. protoname/protoname.h 안쪽에 우리는 그것의 작업을 하는데 있어서 프로토콜을 돕도록 요구되는 속성들과 함수들을 포함하는 Protoname이라 불리는 새로운 클래스를 정의한다. 타이머들의 사용을 묘사하기 위해서 우리는 protoname이 몇 개의 제어 패킷들을 주기적으로 발산할 필요가 있는 예방의 라우팅 프로토콜임을 가정한다. 다음 코드는 그런 예제를 보여준다.
protoname/protoname.h
1: #ifndef __protoname_h__
2: #define __protoname_h__
3:
4: #include “protoname_pkt.h”
5: #include <agent.h>
6: #include <packet.h>
7: #include <trace.h>
8: #include <timer-handler.h>
9: #include <random.h>
10: #include <classifier-port.h>
11:
12: #define CURRENT_TIME Scheduler::instance().clock()
13: #define JITTER (Random::uniform()*0.5)
14:
15: class Protoname; // forward declaration
16:
17: /* Timers */
18:
19: class Protoname_PktTimer : public TimerHandler {
20: public:
21: Protoname_PktTimer(Protoname* agent) : TimerHandler() {
22: agent_ = agent;
23: }
24: protected:
25: Protoname* agent_;
7
26: virtual void expire(Event* e);
27: };
28:
29: /* Agent */
30:
31: class Protoname : public Agent {
32:
33: /* Friends */
34: friend class Protoname_PktTimer;
35:
36: /* Private members */
37: nsaddr_t ra_addr_;
38: protoname_state state_;
39: protoname_rtable rtable_;
40: int accesible_var_;
41: u_int8_t seq_num_;
42:
43: protected:
44:
45: PortClassifier* dmux_; // For passing packets up to agents.
46: Trace* logtarget_; // For logging.
47: Protoname_PktTimer pkt_timer_; // Timer for sending packets.
48:
49: inline nsaddr_t& ra_addr() { return ra_addr_; }
50: inline protoname_state& state() { return state_; }
51: inline int& accessible_var() { return accessible_var_; }
52:
53: void forward_data(Packet*);
54: void recv_protoname_pkt(Packet*);
55: void send_protoname_pkt();
56:
57: void reset_protoname_pkt_timer();
58:
59: public:
60:
61: Protoname(nsaddr_t);
62: int command(int, const char*const*);
63: void recv(Packet*, Handler*);
64:
65: };
66:
67: #endif
줄들 4-10은 우리의 에이전트에 의해서 요구되는 헤더 파일들을 포함하기 위해서 사용된다. 아래에 우리는 그것들이 무엇을 위해 유용한지를 설명한다.
protoname/protoname_pkt.h 우리의 패킷 헤더를 정의한다.
common/agent.h 에이전트 기반 클래스를 정의한다.
common/packet.h 패킷 클래스를 정의한다.
common/timer-handler.h TimerHandler 기반 클래스를 정의한다. 우리는 우리의 맞춤 타이머들을 생성하기 위해서 그것을 사용할 것이다.
trace/trace.h 시뮬레이션 결과를 트레이스 파일로 쓰기 위해 사용되는, 트레이스 클래스를 정의한다.
tools/random.h 가짜의-랜덤 숫자들을 발생시키는 데 유용한, 랜덤 클래스를 정의한다. 우리는 그것을 곧 사용할 것이다.
classifier/classifier-port.h 패킷들을 상위 레이어들에게 올려 보내기 위해서 사용되는 포트분류자 클래스를 정의한다.
줄 12는 시뮬레이터 시계 안에 현재 시간을 얻기 위한 유용한 매크로를 정의한다. 그것은 스케쥴러 클래스의 단일의 인스턴스에 접속함으로써 실행된다. 이 오브젝트는 시뮬레이션 동안에 생산된 모든 이벤트들과 시뮬레이터의 내부 시계를 관리한다. (4장 [2]을 보라)
또 다른 매크로는 줄 13에 있다. 그것은 [0-0.5] 간격 안쪽에 랜덤 숫자를 획득하기 위한 단지 쉬운 방법이다. 이것은 결국에 충돌들을 생산하고 그래서 이런 패킷들을 송신하는 시간에서 딜레이되는, 자신의 이웃들과 함께 노드의 동기화를 피하기 위해 제어 패킷들의 송신을 랜덤화하기 위해서 보통 사용된다.[1]
줄들 19-27은 주기적인 제어 패킷들을 송신하기 위한 우리의 맞춤 타이머를 선언한다. 우리의 Protoname_PktTimer 클래스는 TimerHandler로부터 물려받고 그것을 생성하는 라우팅 에이전트에 관계가 있다. 이것은 라우팅 에이전트에게 새로운 제어 패킷을 전송하고 다음 것을 스케쥴하라고 말하기 위한 콜백으로써 사용된다. 우리는 expire() 방법에 어떻게 과부하가 걸리는 지를 기술할 때, 뒤에 이것을 더 봐야 한다. 이런 콜백들을 실행하기 위해서 라우팅 에이전트는 동료 클래스로써 Protoname_PktTimer를 다룰 필요가 있다. (줄 34)
Protoname 클래스는 줄들 31-65 내에 정의된다. 그것은 자신 소유의 주소, 내부의 상태, 라우팅 표, Tcl에서 접근하기 쉬운 변수 그리고 시퀀스 넘버들을 출력 패킷들에 할당하기 위한 카운터 (줄들 37-41)를 캡슐화한다. protoname_state_는 클래스 자체 또는 그것의 작업을 하기 위해서 Protoname 클래스에 의해 요구되는 속성들의 집합일 수 있다. accessible_var_는 Tcl 스크립트들 또는 쉘 명령어들로부터 읽혀지고 쓰여지는 것으로 생각된다. 이것은 많은 상황들에서 유용한데 왜냐하면 그것은 유저들이 시뮬레이터의 재-컴파일없이 자신들의 스크립트들을 통해서 시뮬레이션 행동을 바꾸는 것을 허락하기 때문이다.
포트분류자 오브젝트는 줄 45에서 선언된다. 너는 노드의 구조를 이해하기 위해서 5장 [2]를 읽어야 한다. 거기서 노드가 주소 분류자와 포트 분류자로 어떻게 구성되는 지 너는 볼 수 있을 것이다. 첫 번째는 적절한 링크로 들어오는 패킷들을 안내하거나 그것들을 상위 레이어 에이전트에게 충당하기 위해서 그것들을 운반할 것인, 포트 분류자에게로 그것들을 통과하기 위해서 사용된다. 그것이 라우팅 에이전트가 포트 분류자를 필요로 하는 이유이다. 그것이 자신으로 예정된 데이터 패킷들을 받을 때 그것은 일치하는 에이전트에게 그것들을 주기 위해서 dmux_를 사용할 것이다.[2] 모바일 노드의 세부적인 아키텍처는 [2]의 16장에서 설명된다.
또 다른 중요한 속성은 트레이스 오브젝트이다. (줄 46을 보라) 그것은 트레이스 파일 안에 저장되기 위한 로그들을 생산하기 위해서 사용된다. 우리의 예제에서 유저가 Tcl 인터페이스에서 그것을 요청할 때마다 라우팅 표의 내용들을 쓰기 위해서 우리는 그것을 사용한다. 만약 네가 패킷들에 관해서 트레이싱 정보를 쓰는 데만 단지 관심이 있다면 이것이 필수는 아니다. 그 경우에서, 그런 로깅 함수들은 다른 위치에서 구현된다. (우리가 6절에서 봐야 할 것처럼)
줄 47은 우리의 맞춤 타이머를 선언한다. 그리고 줄들 49-51은 몇 개의 내부 속성들에 접속하기 위한 멤버 함수들이다.
줄 53에서 함수는 데이터 패킷들을 그것들의 올바른 목적지로 전송하기 위해서 사용될 것이다. 줄 54에서 함수는 제어 패킷이 받아들여질 때마다 호출될 것이고, 줄 55에서 그것은 제어 패킷을 전송하기 위해서 선포된다. 줄 57은 우리의 맞춤 타이머 기한 만료를 스케쥴하기 위해서 사용되는 함수를 선언한다.
줄들 61-63은 클래스 Protoname의 공개 함수들을 포함한다. 건설자는 라우팅 에이전트의 주소로써 사용되는 식별자를 인수로써 받는다. Protoname은 구현될 필요가 있는 두 개의 메인 함수들을 에이전트 기반 클래스로부터 물려받는다: recv()와 command(). recv()는 에이전트가 패킷을 받을 때마다 불려진다. 노드 자체 (실제로는 UDP 또는 TCP와 같은 상위 레이어)가 패킷을 발생하는 중이거나 다른 노드로부터 패킷을 받는 중일 때 이것은 일어날 것이다. command() 함수는 3장 [2]에서 기술된 것처럼 Tcl로부터 선포된다. 그것은 우리의 Tcl 코드로부터 몇 개의 업무를 하도록 C++ 오브젝트에게 요청하기 위한 방식이다. 한번 우리가 절 4.3을 경험하면 너는 이것을 더 이해할 것이다.
이제 너는 Protoname의 인터페이스가 어떻게 있는 지 알기 때문에, 그것의 구현을 계속할 시간이다. 다음 하위 절들은 protoname/protoname.cc 파일과 관련된다.
4.1 Tcl hooks
우리는 우리 소유의 패킷을 Tcl에 묶는 법을 3절에서 보았다. 이제 우리는 우리의 에이전트 클래스를 위해 같은 것을 할 것이다. 그 목적은 Protoname에게 Tcl로부터 예시되도록 하는 것이다. 그렇게 하기 위해서 우리는 다음의 코드에서 묘사된 것처럼 클래스 TclClass로부터 물려받아야 한다.
protoname/protoname.cc
1: static class ProtonameClass : public TclClass {
2: public:
3: ProtonameClass() : TclClass(“Agent/Protoname”) {}
4: TclObject* create(int argc, const char*const* argv) {
5: assert(argc == 5);
6: return (new Protoname((nsaddr_t)Address::instance().str2addr(argv[4])));
7: }
8: } class_rtProtoProtoname;
클래스 건설자는 줄 3에 있고 그것은 인수로써 스트링 “Agent/Protoname”을 가진 기반 클래스를 호출한다. 이것은 본문의 방법에서 이 에이전트를 위한 클래스 계층을 의미한다.
줄들 4-7에서 우리는 TclObject로써 새로운 Protoname 인스턴스를 되돌려주는 create()로 불리는 함수를 구현한다. argv는 “<오브젝트의 이름> <$self> <$클래스> <$proc> <유저 인수>” 형태이다. (더 많은 정보를 위해서 [2]의 3장을 보라) 이런 특별한 경우에서 그것은 “<오브젝트의 이름> <$self> Agent/Protoname create-shadow <id>”이다. 이것 때문에, 줄 6에서 우리는 argv[4]에서 시작되는 식별자를 가진 새로운 Protoname 오브젝트를 되돌려준다. 우리는 스트링에서 nsaddr_t 유형을 얻기 위해 주소 클래스를 사용한다.
4.2 타이머들
우리가 타이머들에 대해 protoname/protoname.cc 안에서 코드해야 하는 모두는 expire() 방법이다. 타이머들은 11장 [2]에 세부적으로 되어있다. 이것을 구현하는 것은 매우 쉬운데 왜냐하면 우리는 단지 새로운 제어 패킷을 보내고 타이머 자체를 다시 스케쥴하기를 단지 원하기 때문이다. 우리의 설계 결정들에 따라서 두 개의 업무들은 라우팅 에이전트에 의해서 실행되어야 하고, 그래서 우리는 다음의 예제에서처럼 이런 콜백들을 선포한다.
protoname/protoname.cc
1: void
2: Protoname_PktTimer::expire(Event* e) {
3: agent_->send_protoname_pkt();
4: agent_->reset_protoname_pkt_timer();
5: }
4.3 에이전트
4.3.1 건설자
건설자 구현과 함께 시작해보자. 아래 줄 1에서 볼 수 있는 것처럼, 우리는 PT_PROTONAME을 통과하는 기반 클래스를 위한 건설자를 인수로써 호출함으로써 시작한다. 이런 상수는 뒤에 정의될 것이고 그것은 이런 라우팅 에이전트에 의해서 보내지고 받아들여지는 제어 패킷들을 식별하기 위해서 사용된다. 같은 줄에서 우리는 우리의 Protoname_PktTimer 오브젝트를 생성한다.
하자마자 우리는 이제 Tcl로부터 읽혀지고 쓰여질 것인 논리 속성으로써 accessible_var_을 묶는다. 정수로써 이 변수를 묶기 위해서, 우리는 bind_bool() 대신에 bind() 함수를 사용해야 한다.
줄 3은 주어진 식별자를 라우팅 에이전트의 주소로 저장한다.
protoname/protoname.cc
1: Protoname::Protoname(nsaddr_t id) : Agent(PT_PROTONAME), pkt_timer_(this) {
2: bind_bool(“accessible_var_”, &accessible_var_);
3: ra_addr_ = id;
4: }
Tcl 스크립트들로부터 접근하는 것은 꽤 단순하다. 다음 예제는 accessible_var_의 값을 true로 설정한다.
simulation.tcl
1: Agent/Protoname set accesible_var_ true
