在上篇 flowid和ptype的賦值與作用 中，提出了問題。
按照逐步搜索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~~~~~