20th. Part: IPv6suite 的 IPProccessing 用的是 IPv4d 資料夾中的架構.
21th. Part: Mac 層要加入 0x86DD 代表 IPv6 訊息
20th. Part: IPv6suite 的 IPProccessing 用的是 IPv4d 資料夾中的架構.
21th. Part: Mac 層要加入 0x86DD 代表 IPv6 訊息
一個有經驗的 Developer 對於剛接手的已存在的只有程式碼軟體開發專案,要能 了解這個軟體的架構是什麼至少要花數個小時,如果這個軟體專案有 Model Diagram,則這個 Developer 則很快就可以了解這個軟體架構。
一般而言 Diagramming Language 都應該提供下列資訊:
‧Overall architecture of the system ‧System dependencies ‧Complexity ‧Flow of information through a system ‧Business requirements ‧Database organization and structure ‧Source code – including almost every aspect of object-oriented development ‧Deployment configurations
一個軟體專案如果有使用 Visual Models,我們就能從比較高的層次去看這個 Project, 藉由從較高層次圖去找尋 Fine-Grained Diagram。 這樣的方法可以幫助 Architect 和 Engineer 直覺地 (Intuitively) 掌握住問題並解決它, 軟體問題容易掌握 ,時間自然縮短,品質自然提高。
18th. Part: NetworkLayer6.ned: disable OSPF, RSVP 原 protocolMapping = "6:0,17:1,1:2,2:3,46:4,89:5"; 表示 TCP (6):0, UDP (17):1, ICMP (1):2, IGMP (2):3, RSVP (46):4, OSPF (89):5 考慮到保證將來 DualStack 相容性,因此不更改原對應數字,而從後面再繼續補加.
暫時補加 ICMPv6 (58):2, ROUTING (43), MOBILITY (135) protocolMapping 後添上 58:6,43:7,135:8
19th. Part: 照著 Winodws 步驟,以 TicToc10 為基礎編譯. OMNET++/Sample/INET6Test: 修改 IP6Datagram.msg 以通過 compiler.
這次是針對 "模擬" 來做修正:
目前採用方式 -> 全改用 int , short, long 來宣告,皆遠大於所需位元數
Review: Global Dynamic Home Agent Discovery on Mobile IPv6 Q1. 訊息流程一不一樣? Ay: -> 原不需用 RR An: -> 模擬該重做
外: Paper 檢查注意:
先討論做某件事的老方法,
再和新解決方法建立關聯.
提案前先確定它有效,成功 提綱:
要有完整的 survey, 也就是完整的 view
針對某些很明確的問題來想出正確可靠的解決辦法,細節要想透及交待清楚
1. 想解決什麼樣的問題
2. 清楚地告訴大家有人是如何解決
3. 想解決問題的完整步驟是什麼* 完整解決問題的方法及步驟
新 r 33.908773621 3 MAC --- 334 mipv6_bu 70 [13a 1 4 800] ------- [4196353:0 0:0 32 4198400] 舊 s -t 1.000075000 -Hs 22 -Hd 2147483647 -Ni 22 -Nx 100.00 -Ny 2200.00 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw --- -Ma 0 -Md ffffffff -Ms 14 -Mt 800 -Is 4222977.0 -Id 2147483647.0 -It ipv6_sol -Il 100 -If 0 -Ii 1 -Iv 255
欄位: event type 事件類型)
有四種基本事件類型
還有一種特別類型
欄位 2: general flag
-t: time (時間)
欄位 3: Next hop info (下一站的資訊)
-Hs: id for this node -Hd: id for next hop towards the destination
欄位 4: Node property type tag (節點屬性類型標籤
-Ni: node id (節點 ID) -Nx –Ny -Nz: node s x/y/z coordinate (節點 x/y/z 的座標位置) -Ne: node energy level -Nl: trace level, such as AGT, RTR, MAC -Nw: reason for the event (事件發生原因)
欄位 5: packet info at MAC level (封包在 Mac 層的資訊)
-Ma: duration -Md: dest’s ethernet address -Ms: src’s ethernet address -Mt: ethernet type
欄位 6: Packet information at IP level (封包在 IP 層的資訊)
-Is: source address. Source port number (來源位置,a.b 其中 a 為節點 ID, b 為埠號 -Id: dest address.dest port number (目的位置) -It: packet type (封包類型) -Il: packet size (封包大小) -If: flow id (資料流 ID) -Ii: unique id (唯一的 ID 編號) -Iv: ttl value (Time To Live 的值)
欄位 7: 封包在應用層的資訊。
包含的應用程式類型如 arp, tcp 或者是 adhoc 路由協定,這個欄位都是以 P 所開頭的, 且標籤為隨著應用程式不同而不同
Trace 檔分析:
Packet Loss 數量計算: 不考慮 Out-of-Order 情況時,Packet Loss 數量的計算方法最簡單,每一個封包在傳送端發送前,傳送端都會給封包一個序號,序號是連續性的,因此若是在接收到發現序號有不連續的發生,則可視為有封包的移失。
OWD&IPDV 計算: 最重要的欄位是 Sending Time (傳送時間) 和 Sequence Number (封包序號), 可以用來計算出 One Way Delay (OWD) 和 IP Delay Variance (IPDV,或是 Jitter)。
One Way Delay = 接收時間 – 傳送時間
IPDV = | 目前量測到的 OWD - 上一次量測到的 OWD|
http://140.116.72.80/~smallko/ns2/wireless1.htm http://www.k-lug.org/~griswold/NS2/ns2-trace-formats.html http://www.ee.surrey.ac.uk/Personal/L.Wood/ns/