TclCL机制

接触NS2这么长时间了，对TclCL机制一直都是半知半解，今天重新看了书，做以下笔记：

我们以TcpAgent的相关代码为例，重新回顾一下TclCL。

首先，在tcp.p中的TcpAgent类声明如下：

class TcpAgent::public Agent {

public:

   TcpAgent();

   Virtual void recv(Packet*,Handle*);

   Virtual void timeout(int tno);

   Virtual void timeout_nonrtx(int tno);

   Int command(int argc,const char* const* argv);

   Virtual void sendmsg(int nbytes,const char *flags=0);

………

}

其父类Agent是TclObject的后代。然后，在tcp.cc中定义了一个TclClass的子类：

Static class TcpClass::public TclClass {

Public:

TcpClass():TclClass(“Agent/TCP”) {}

TclObject* create(int,const char*const*){

    Return(new TcpAgent());

}

}class_tcp;

这里需要注意的是 ，此处不仅声明了这个类，而且将其实例化了，创建了一个实例class_tcp。因此，当NS刚刚运行时，这个类的构造函数就被执行了一次，导致的结果是：有两个Otcl类，Agent和Agent/TCP被声明了，同时class_tcp和Agent/TCP的关联关系别登记了下来。

假设NS开始运行了，在用户的tcl脚本中正在执行“new Agent/TCP”。那么在new｛｝过程中，一个Agent/TCP的解释对象被创建了，并且调用了它的实例过程init｛｝，让我们来看Agent/TCP的init过程：

Agent/TCP instproc init {} {

  Eval $self next

  Set ns [Simulation instance]

$ns create-eventtrace Event $self

}

这里，父类的init过程被最先调用，这最终导致基类SplitObject的init过程被调用，在那里create-shadow方法负责创建影像对象，根据TclClass所登记的关联关系，class_tcp的create函数被调用了，class_tcp的create函数创建出一个TcpAgent对象，并返回了其指针，这个编译对象的指针在后面的command函数时是要用到的。创建编译对象时，它的构造函数被执行了，让我们再看TcpAgent的构造函数：

TcpAgent:: TcpAgent():Agent(PT_TCP).

   T_seqno_(0),t_rtt_(0),t_srtt_(0),t_rttvar_(0).

   T_backoff_(0),ts_peer_(0)…

{

……

   Bind(“rtt_”,&t_rtt_);

   Bind(“seqno_”,&curseq_);

   Bind(“cwnd_”,&cwnd_);

……..

}

此处建立了几个绑定变量，于是在解释对象中有了rtt_、seqno_、cwnd_等变量，并且自此以后这些变量和它们所各自绑定的编译对象的成员变量在任何时候都取相同值，在绑定时，这些变量被初始化了，被设置为Agent/TCP（或其某个父类）中定义的同名变量的取值，我们注意到这些便来那个的缺省值是在~/ns/tcl/lib/ns-defoult.tcl中被设置的：

Agent/TCP set rtt_ 0

Agent/TCP set seqno_ 0

Agent/TCP set cwnd_ 0

…….

这些脚本是在NS开始运行之后而先于用户的TCl脚本之前被执行的，因此，当创建对象过程中绑定变量时，这部分脚本已经被执行了。这些缺省值是有效的，至此，互为影像的解释对象和编译对象就创建完成了。之后，当要执行这个解释对象的一个操作时，如果该操作不是一个有效的实例过程或命令，就会利用刚才保存的编译对象的指针，去调用编译对象的command函数。

在command函数中，根据传入的命令行参数执行操作，并返回TCL_OK或TCL_ERROR来告知解释器操作成功与否，为了使得这些操作有类似otcl实例过程一样的基础性，在com函数最后调用了其父类的command函数。在command函数中实现向解释器传递执行结果。