在iph中有fid_（flowid）这个字段，
cmn头中有pype(pkttpye)，
试图根据pkttype来区分上层的业务类型，根据flowid来区分具体几个业务流。
于是实验中的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_。在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_在模拟实验中是符合逻辑的。
ptype分篇吧----