flowid与pkttype的区别，赋值与作用

http://blog.csdn.net/lruiq/article/details/7005430

在ip header中有fid_（flowid）这个字段，

cmn头(数据包的common头)中有pype(pkttpye)，

根据flowid来区分具体几个业务流(指数量)，试图根据pkttype来区分上层的业务类型。

于是实验中的tcl脚本模拟了：

一个从节点1到节点4的cbr业务流，传输层代理是udpAgent。

同时另外一个是1到4的ftp业务，传输层代理是tcpAgent。

运行脚本发现，两种报文的iph->fid_=2，cbr的ptype=2，而ftp的ptype是0，查看common/packet.h知PT_CBR=2，PT_TCP=0； 

先说fid_，搜索该变量在整个project中的引用位置，未发现可用信息；然后通过flowid（hdr_ip中定义为 int& flowid( ){return fid_;}）来搜索，会发现fid_在Agent的initPkt(Packet *)中赋值，被赋予的是agent中的fid_字段。

而initPkt会在allockPkt中调用，即在产生每个报文时，将agent的fid_赋予ip报头中的fid_。（~ns/common/Agent.cc）

Agent的fid_字段又是什么时候赋的值呢？

再次搜索agent的fid_字段，发现在Agent的delay_bind_dispatch( )和delay_bind_init_all( )有用到，虽然不明白具体这两个函数怎么实现的，但大概用处是把Agent的一些变量到映像的tcl对象中的变量，其中就包括我们考虑的fid_。一个传输层代理下的所有报文都是相同的flowid

没有额外设置的话，所有传输层代理产生报文的flowid都是相同的默认值。它只是提供了这么一个字段，并没有用而已，ns2里struct hdr_ip中对fid_的注释是ipv6 flow id。在delay_bind_dispatch(
)中发现，将解释对象Agent的成员变量class_和fid_均绑定到编译对象Agent的fid_，这就说可能会在tcl文件中改变了fid_,回头看tcl运行脚本，果然有$udp set class_ 2,更改一下class_的值，运行时pkt的fid_如预期改变；将“class_”换成“fid_”,同此。

去掉tcl脚本对class_或fid_的赋值，测试，发现fid_是0。这个默认的0是哪里来的？编译器？还是ns-default.tcl？答案是ns-default.tcl。（~/ns/tcl/lib/ns-default.tcl）

在ns-default.tcl中 有下面一段，第一句即是设置fid的默认值，将最后一句的0设成3，重新make、执行，得出的结果是fid_=3。

Agent set fid_ 0

Agent set prio_ 0

Agent set agent_addr_ -1

Agent set agent_port_ -1

Agent set dst_addr_ -1

Agent set dst_port_ -1

Agent set flags_ 0

Agent set ttl_ 32 ; # arbitrary choice here

Agent set debug_ false

Agent set class_ 0

顺便考虑一下，什么时候会用default里的值？

[ 每一个绑定的变量当对象创建时都自动初始化为缺省值。缺省值是解释对象所属otcl类（或其某个祖先类）的同名成员变量。这个初始化过程是绑定时自动完成的。绑定过程将检查解释对象的类，以及该对象的所有祖先类，找到该变量在其中有定义的第一个类，它使用这个类中定义的变量值来初始化该变量。如果在所有层次中都找不到该变量的定义，将会打印出一条警告信息。大多数绑定变量的初始值是在～ns/tcl/lib/ns-default.tcl中定义的

 
----《NS与网络模拟》(P48) 徐雷鸣等 人民邮电出版社 ]


 另class_好像经常拿来nam或trace的时候区分节点或流，标记不同的颜色等。也就是利用fid_值来区分，比如2记为蓝色（***瞎说的***）等

之前认为ns可以自己识别不同的业务流，然后各自分配一个唯一的fid_,事实并不是如此，只能认为给fid_赋值。这点可能不太符合实际应用，由用户在自己指定fid_，不过ns作为模拟工具，所有业务是由编写人员一一添进去的，所以人为指定符合要求的fid_在模拟实验中是符合逻辑的。

按照逐步搜索fid_的方法，搜索hdr_cmn的ptype字段，同样发现该字段由Agent的ptype字段赋值。 

对于CBR-traffic -> Agent/udp ->node的模型，从高往低考虑， 

对于解释类Application/Traffic/CBR, 查看其对应编译类CBR_Traffic的源码（~ns/tools/cbr_traffic.cc&cbr_traffic.h） 

 函数很少，很容易在CBR_Traffic::init( )看到agent_->set_pkttype(PT_CBR)一句，当已知传输层代理是TCP或TFRC时则不再设置成PT_CBR这点不清楚是为什么。

其中agent_是该app绑定的传输层代理，当执行到tcl脚本的“$ftp attach-agent $tcp”或“$cbr attach-agent $udp”相同功能的语句时，agent_赋值[[【Alipcation::command( )】。（~ns/apps/app.cc） 

整个赋值顺序是 

 先有传输层udpAgent，new时将ptype设置成PT_UDP（~ns/apps/udp.cc） 

 应用层Application/Traffic/CBR与传输层绑定时，cbr 的agent指向代理层agent 

 tcl脚本执行"$cbr start"时，调用位于cbr::start( )里的cbr::init( )，将udpAgent的ptype置成PT_CBR;

再看$ftp（~ns/tcl/lib/ns-source.tcl）,

在其拥有的init、start等方法中，未设置ptype，所以绑定tcp时，ptype仍然是PT_TCP

更改方法：FTP的start方法里加上一句    “ $self set_pkttype 27” 或者27换成PT_FTP

   Application/FTP instproc start {} {

      $self set_pkttype 27

      [$self agent] send -1

    }

当然Application的command函数中，要加上相应的处理

在argc=3的情况下，加上如下的处理分支

if(strcmp(argv[1],"set_pkttype")==0){

   agent_->set_pkttype(packet_t(atoi(argv[2]))); //如果写的是PT_FTP转换方式不同

   return (TCL_OK);

  }

重新make，测试即可发现，ptype已是27~~~~~

http://blog.csdn.net/lruiq/article/details/7005430

在ip header中有fid_（flowid）这个字段，

cmn头(数据包的common头)中有pype(pkttpye)，

根据flowid来区分具体几个业务流(指数量)，试图根据pkttype来区分上层的业务类型。

于是实验中的tcl脚本模拟了：

一个从节点1到节点4的cbr业务流，传输层代理是udpAgent。

同时另外一个是1到4的ftp业务，传输层代理是tcpAgent。

运行脚本发现，两种报文的iph->fid_=2，cbr的ptype=2，而ftp的ptype是0，查看common/packet.h知PT_CBR=2，PT_TCP=0； 

先说fid_，搜索该变量在整个project中的引用位置，未发现可用信息；然后通过flowid（hdr_ip中定义为 int& flowid( ){return fid_;}）来搜索，会发现fid_在Agent的initPkt(Packet *)中赋值，被赋予的是agent中的fid_字段。

而initPkt会在allockPkt中调用，即在产生每个报文时，将agent的fid_赋予ip报头中的fid_。（~ns/common/Agent.cc）

Agent的fid_字段又是什么时候赋的值呢？

再次搜索agent的fid_字段，发现在Agent的delay_bind_dispatch( )和delay_bind_init_all( )有用到，虽然不明白具体这两个函数怎么实现的，但大概用处是把Agent的一些变量到映像的tcl对象中的变量，其中就包括我们考虑的fid_。一个传输层代理下的所有报文都是相同的flowid

没有额外设置的话，所有传输层代理产生报文的flowid都是相同的默认值。它只是提供了这么一个字段，并没有用而已，ns2里struct hdr_ip中对fid_的注释是ipv6 flow id。在delay_bind_dispatch(
)中发现，将解释对象Agent的成员变量class_和fid_均绑定到编译对象Agent的fid_，这就说可能会在tcl文件中改变了fid_,回头看tcl运行脚本，果然有$udp set class_ 2,更改一下class_的值，运行时pkt的fid_如预期改变；将“class_”换成“fid_”,同此。

去掉tcl脚本对class_或fid_的赋值，测试，发现fid_是0。这个默认的0是哪里来的？编译器？还是ns-default.tcl？答案是ns-default.tcl。（~/ns/tcl/lib/ns-default.tcl）

在ns-default.tcl中 有下面一段，第一句即是设置fid的默认值，将最后一句的0设成3，重新make、执行，得出的结果是fid_=3。

Agent set fid_ 0

Agent set prio_ 0

Agent set agent_addr_ -1

Agent set agent_port_ -1

Agent set dst_addr_ -1

Agent set dst_port_ -1

Agent set flags_ 0

Agent set ttl_ 32 ; # arbitrary choice here

Agent set debug_ false

Agent set class_ 0

顺便考虑一下，什么时候会用default里的值？

[ 每一个绑定的变量当对象创建时都自动初始化为缺省值。缺省值是解释对象所属otcl类（或其某个祖先类）的同名成员变量。这个初始化过程是绑定时自动完成的。绑定过程将检查解释对象的类，以及该对象的所有祖先类，找到该变量在其中有定义的第一个类，它使用这个类中定义的变量值来初始化该变量。如果在所有层次中都找不到该变量的定义，将会打印出一条警告信息。大多数绑定变量的初始值是在～ns/tcl/lib/ns-default.tcl中定义的

 
----《NS与网络模拟》(P48) 徐雷鸣等 人民邮电出版社 ]


 另class_好像经常拿来nam或trace的时候区分节点或流，标记不同的颜色等。也就是利用fid_值来区分，比如2记为蓝色（***瞎说的***）等

之前认为ns可以自己识别不同的业务流，然后各自分配一个唯一的fid_,事实并不是如此，只能认为给fid_赋值。这点可能不太符合实际应用，由用户在自己指定fid_，不过ns作为模拟工具，所有业务是由编写人员一一添进去的，所以人为指定符合要求的fid_在模拟实验中是符合逻辑的。

按照逐步搜索fid_的方法，搜索hdr_cmn的ptype字段，同样发现该字段由Agent的ptype字段赋值。 

对于CBR-traffic -> Agent/udp ->node的模型，从高往低考虑， 

对于解释类Application/Traffic/CBR, 查看其对应编译类CBR_Traffic的源码（~ns/tools/cbr_traffic.cc&cbr_traffic.h） 

 函数很少，很容易在CBR_Traffic::init( )看到agent_->set_pkttype(PT_CBR)一句，当已知传输层代理是TCP或TFRC时则不再设置成PT_CBR这点不清楚是为什么。

其中agent_是该app绑定的传输层代理，当执行到tcl脚本的“$ftp attach-agent $tcp”或“$cbr attach-agent $udp”相同功能的语句时，agent_赋值[[【Alipcation::command( )】。（~ns/apps/app.cc） 

整个赋值顺序是 

 先有传输层udpAgent，new时将ptype设置成PT_UDP（~ns/apps/udp.cc） 

 应用层Application/Traffic/CBR与传输层绑定时，cbr 的agent指向代理层agent 

 tcl脚本执行"$cbr start"时，调用位于cbr::start( )里的cbr::init( )，将udpAgent的ptype置成PT_CBR;

再看$ftp（~ns/tcl/lib/ns-source.tcl）,

在其拥有的init、start等方法中，未设置ptype，所以绑定tcp时，ptype仍然是PT_TCP

更改方法：FTP的start方法里加上一句    “ $self set_pkttype 27” 或者27换成PT_FTP

   Application/FTP instproc start {} {

      $self set_pkttype 27

      [$self agent] send -1

    }

当然Application的command函数中，要加上相应的处理

在argc=3的情况下，加上如下的处理分支

if(strcmp(argv[1],"set_pkttype")==0){

   agent_->set_pkttype(packet_t(atoi(argv[2]))); //如果写的是PT_FTP转换方式不同

   return (TCL_OK);

  }

重新make，测试即可发现，ptype已是27~~~~~