在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分篇吧----