# 無線及寬頻網路 week7 1102951 劉宗翰
## 第一題
### 分別走三條路徑之截圖
**<p class="text-center">僅有n1-n3鏈路斷開之情形：將尋找最短路徑n1-n2-n3</p>**
**<p class="text-center">n1-n3鏈路以及n1-n2鏈路斷開之情形：將尋找最短路徑n1-n5-n6-n3</p>**
**<p class="text-center">無鏈路斷開之情形：將尋找最短路徑n1-n3</p>**
### 程式碼內含其簡要說明

set ns [new Simulator]

if {$argc==1} {
	set par [lindex $argv 0]
	if {$par=="DV"} {
		$ns rtproto DV
	}
}

$ns color 1 Blue

#Open the NAM trace file
set file1 [open out.nam w]
$ns namtrace-all $file1

proc finish {} {
        global ns file1
        $ns flush-trace
        close $file1
        exec nam out.nam &
        exit 0
}

set n0 [$ns node]
set n1 [$ns node]
set n2 [$ns node]
set n3 [$ns node]
set n4 [$ns node]
# 新增n5,n6兩節點
set n5 [$ns node]
set n6 [$ns node]

$ns duplex-link $n0 $n1 0.5Mb 10ms DropTail
$ns duplex-link $n1 $n2 0.5Mb 10ms DropTail
$ns duplex-link $n1 $n3 0.5Mb 10ms DropTail
$ns duplex-link $n3 $n4 0.5Mb 10ms DropTail
$ns duplex-link $n3 $n2 0.5Mb 10ms DropTail
# 新增三條鏈路，分別為n1-n5, n5-n6, n6-n3，頻寬0.5Mbps，延遲10ms，採DropTail封包丟棄方式
$ns duplex-link $n1 $n5 0.5Mb 10ms DropTail
$ns duplex-link $n5 $n6 0.5Mb 10ms DropTail
$ns duplex-link $n6 $n3 0.5Mb 10ms DropTail

$ns duplex-link-op $n0 $n1 orient right
$ns duplex-link-op $n1 $n2 orient right
$ns duplex-link-op $n1 $n3 orient down
$ns duplex-link-op $n3 $n4 orient right
$ns duplex-link-op $n3 $n2 orient right-up
# 新增nam繪圖
$ns duplex-link-op $n1 $n5 orient up
$ns duplex-link-op $n5 $n6 orient right
$ns duplex-link-op $n6 $n3 orient down

set tcp [new Agent/TCP]
$tcp set fid_ 1
$ns attach-agent $n0 $tcp
set sink [new Agent/TCPSink]
$ns attach-agent $n4 $sink
$ns connect $tcp $sink

set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ftp set type_ FTP

$ns rtmodel-at 1.0 down $n1 $n3
# 在1.3秒將n1-n2斷線
$ns rtmodel-at 1.3 down $n1 $n2
# 在1.6秒將n1-n2恢復
$ns rtmodel-at 1.6 up $n1 $n2
$ns rtmodel-at 2.0 up $n1 $n3

$ns at 0.1 "$ftp start"

$ns at 3.0 "finish"

$ns run

### 簡要說明
此nam模擬採Distance Vector(DV)，一種動態路由的方式執行，當節點以及鏈路有更新時，節點將會廣播新的路由表給周圍的節點，依此類推廣播至所有節點，相較於靜態路由，Distance Vector(DV)在鏈路有斷掉時，節點能夠自動更新其路由表，以此讓封包能夠繼續順利傳送，而靜態路由則須人工手動更新路由表，可能導致封包無法繼續順利傳送。
## 第二題
### Tahoe與Reno之sn比較情形
#### awk程式(sn.awk)含簡要說明

{
   action = $1;
   time = $2;
   from = $3;
   to = $4;
   seq_no = $11;
   # 當封包從n1-n2，且為接收時，紀錄時間與封包編號
	if (from==1 && to==2 && action == "r") 
		printf("%f %d\n", time, seq_no)
}

#### 圖表
**<p class="text-center">Tahoe與Reno之sn比較圖表</p>**
#### 簡要說明
可以看到Tahoe的sn狀況與Reno差別不大，但是還是可以再一些細節中看出Tahoe和Reno的差別，比如說約莫在2.1秒、3.8秒、5.5秒、7秒、8.3秒時，當封包遺失時，Reno的重傳時間較Tahoe來的快，這是因為Reno中的Fast Retansmit技術，只需收到三個Duplicate ACK就會重傳該封包，相較之下，沒有Fast Retansmit技術的Tahoe則須等待Timeout才能重傳該封包。
### Tahoe與Reno之loss比較情形
#### awk程式(loss.awk)含簡要說明

{
   action = $1;
   time = $2;
   from = $3;
   to = $4;
   seq_no = $11;
   # 當封包從n1-n2，且為丟棄時，紀錄時間與封包編號	
    if (from==1 && to==2 && action == "d") 
		printf("%f %d\n", time, seq_no)
}

#### 圖表
**<p class="text-center">Tahoe與Reno之loss比較圖表</p>**
#### 簡要說明
可以看到，約莫在2.1秒、3.8秒、5.5秒、7秒、8.3秒時，Tahoe和Reno相繼發生了封包遺失，而之所以Reno封包遺失的時間較Tahoe來得早是因為Reno的Fast Recovery的cwnd = cwnd / 2，相較於Tahoe的Fast Recovery的cwnd = 1，重啟時傳輸的封包數量較多，因此發生loss的時間較Tahoe來得早。
## 第三題
### Tahoe與Reno之throughput比較情形
#### awk程式(throughput.awk)含簡要說明

BEGIN {
    init=0;
    i=0;
}
{
   action = $1;
   time = $2;
   from = $3;
   to = $4;
   pktsize = $6;
   # 當封包從n1-n2，且為接收時，累計封包大小
     if(from==1 && to==2 && action=="r") {
         pkt_byte_sum[i+1]=pkt_byte_sum[i]+ pktsize;
        
        if(init==0) {
            start_time = time;
            init = 1;
        }
        
        end_time[i] = time;
        i = i+1;
    }
}
END {
    # 開始設throughput為0
    printf("%.2f\t%.2f\n", end_time[0], 0);
    # 紀錄每個每個時段之throughtput
    for(j=1 ; j<i ; j++){
        th = pkt_byte_sum[j] / (end_time[j] - start_time)*8/1000;
        printf("%.2f\t%.2f\n", end_time[j], th);
    }
    # 結尾設throughput為0
    printf("%.2f\t%.2f\n", end_time[i-1], 0);
}

#### 圖表
**<p class="text-center">Tahoe與Reno之throughput比較圖表</p>**
#### 簡要說明
圖表中Reno的throughtput略高於Tahoe，這是因為Reno在丟包後會進行Fast Retransmit技術，即在檢測到輕微的丟包（通過三個重複ACK）時，不會直接重置擁塞視窗至初始值，而是將其減半，然後進行快速恢復。這樣可以更快地恢復到較高的吞吐量，而Tahoe在任何丟包後，擁塞視窗會重置為 1，並重新進行慢啟動，導致恢復速度較慢，整體吞吐量偏低。
### Tahoe與Reno之cwnd比較情形
#### awk程式(cwnd.awk)含簡要說明

{
   time = $1;
   cwnd = $2;
    printf("%f %d\n", time, cwnd)
}

#### 圖表
**<p class="text-center">Tahoe與Reno之cwnd比較圖表</p>**
#### 簡要說明
* TCP Tahoe：每當發生丟包時，會直接重置cwnd到1，重新進行慢啟動。這種設計使得每次丟包後的增長非常緩慢。
* TCP Reno：在檢測到輕微的丟包（例如三個重複ACK）時，不會重置cwnd到1，而是將cwnd減半後進行快速恢復，然後逐步增加到丟包前的大小。因此，Reno的cwnd能更快地恢復到較高值，使得其吞吐量也隨之增高。