目錄

• 階段目標
• 設計描述
• • 1、實體編址
  • 2、路由表設計
  • 3、路由配置
  • 4、路由器的存儲轉發
  • 5、端到端的圖片傳輸
• 測試情況
• 其他想說的話

階段目標

本階段需要對實體進行編址，實現NET層的IP地址到MAC層地址的映射，解決各層實體的標定區分和數據投遞，同時網絡層記錄路由表，并且可以按照路由進行轉發，實現端到端的信息交換。
本階段是整個項目的最終階段，也就是將整個項目進行整合，要體現在一定的拓撲上利用層次化的模型，模擬真實的虛、實通信情況。

設計描述

1、實體編址

報文格式
IP報文格式采用字節（字符）形式設計,網絡層數據包格式如下：

目的IP源IP數據字節下一跳IP

3	1	ABCD	2

由于所有例程中網元均的網絡層均只有一個，因此不方便像現實路由器對每個端口分別分配IP，此處僅以與設備號相同的U8類型的一字節整數作為設備的IP。同時由于之前LNK層設計過程中對各端口查找是通過find_port()查找MAC表映射得到端口號，因此此處為了簡化，也不再需要重新對每個端口分配單獨的MAC地址，一個設備共用一個跟設備號數值相同的3bit二進制MAC地址。而區別每個端口通過find_port()函數實現，實現簡化設計。（大概相當于不同的端口號替代了現實意義的端口具有不同的MAC地址）

因此，NET層和LNK層實體之間的映射通過NET層的int find_port(U8 IP，U8* nextIP)得到對應低層的端口號以及下一跳的IP地址來實現，免去了ARP協議此類的設計。

此處，由于受限于已有的參考例程和例程中完整的接口體系，不增加接口傳遞參數的復雜程度，。為簡化設計，LNK層從NET層獲取下一跳IP地址然后映射為MAC地址，通過查看報文最后一位U8類型的字符數據來得到目的MAC地址，雖然在一定程度上不服從層次模型中低層不能查看高層的內容的規定，但在不增加層間接口傳輸的除data和len數據以外的參數的情況下，保證不會改變源、目的IP地址的情況下，大大簡化了設計。
（
現在回顧起來覺得有人可能會問，為什么數據包格式要加入下一跳的IP，直接通過先后查路由表和查MAC表不就好了嗎，這樣根據目的MAC地址知道下一跳的出口了？
但是事實情況由于課程組給的拓撲中，路由器均是一個高層NET層，多個獨立的一個低層LNK層和一個PHY層綁定，這樣根本無法和之前LNK層設計的交換機部分一個LNK層和多個PHY層綁定形成統一；并且即使對路由器的LNK層均有MAC表，也會因為LNK層轉發的進出口不同導致不同LNK層學到的MAC表不一樣。這樣也不方便上下層之間交互設計。
所以這個地方的下一跳IP其實也包含有記錄下一個MAC地址的意味。
所以這只是我當時能想到的比較好的解決辦法，雖然看起來并不是那么規范。
）

具體映射是下一跳單字節IP（U8類型）地址同數值映射為3bit二進制的MAC地址（U8類型），映射函數為LNK層的IP_to_mac()。

同時，從APP層輸入的字符中，最后一個字節表示數據希望傳到的目的設備號。便于從用戶層面傳達希望到達的目的IP。（后面向下傳遞到NET層，不會將這一位作為數據參與接下來的傳輸）

涉及函數：

int add_IP(U8* s, int len, U8 dstIP, U8* S);//添加源、目的IP地址 int find_port(U8 dstIP, U8* nexthop);//查找出口端口號以及下一跳IP

2、路由表設計

Router Table

DstIPNexthopPortMetric

3	1	0	1

路由表結構體 struct Router_table {U8 destination; //目的地“IP”,1個字節U8 nexthop; //下一跳IPint port; //出口端口號int metric; //度量 }; 本階段設計主要用到的是除Metric以外前三個參數，因為是采用人工配置靜態路由的方式，Metric沒有被利用起來，僅在此表示路由表有設計度量這一表項。//全局路由表聲明 struct Router_table* rt; int table_len;--------路由表函數--------- void print_router_table();//打印全局路由表 void init_router_table();//初始化路由表

3、路由配置

在本階段的路由配置過程中，采用靜態路由的方式，在初始化時進行人工配置。起初設計時僅針對NET層低層LNK實體超過1個的進行初始化配置靜態路由表，但后來發現在單獨PC的NET層進行向下傳輸存在MAC地址映射問題問題。故對單獨的PC在程序中也有“路由表”的配置，但此處“路由表”的實質其實是配置默認網關的IP，即下一跳的IP。

4、路由器的存儲轉發

路由器跟交換機類似，都具有存儲轉發的功能，因此也可以參考交換機的Timeout（）中的循環隊列進行定時轉發。（可以回顧階段三的設計）

struct queue_t {int front;int rear;U8* data[MAX_QUE];int len[MAX_QUE];int next_hop[MAX_QUE];int src_hop[MAX_QUE]; };

5、端到端的圖片傳輸

在本階段實現端到端圖片傳輸時，采用base64的編碼方式對圖片編碼為string，然后再轉換為U8類型的字節數據進行發送，并在接收端進行解碼輸出。

測試情況

1、六個網元混合組網拓撲按路由表轉發測試情況

設備2的路由表配置

設備5向設備4發送數據
設備5

設備4

可以看到，設備4APP層正確的接收到了設備5發送來的字符串，證明按路由表轉發正常，可以實現端到端正常的信息交換；需要特別說明的是，由于設備2LNK層的實體0連續兩次接收應答幀校驗錯誤，故進行了2次重傳，導致設備4APP層多接收到了兩次重復字符串。（當時測試時忽略了誤碼率的問題，如果設置誤碼率為0，應該只會接收到一次數據）

2、圖片發送情況（設備6向設備3發送圖片）
發送圖片test.jpg并編碼

解碼接收圖片out.jpg

其他想說的話

本階段主要實現了在靜態路由下，路由器的尋徑轉發功能，完成了端到端的信息交流，以及利用base64編碼進行圖片傳輸。

本階段的難點感覺并不在NET層的代碼編寫上面，而是在各層自定義代碼的協同上面，在使各層代碼相互協調合作的情況上，讓我花費了很多的時間和精力。

同時由于網絡層的路由表沒有完成動態路由的原因，導致路由表中度量（Metric）一參數并沒有被很好的利用起來，沒有體現選路的最優化原則。并且靜態路由在使用和健壯性上也不是很好，也反映出現實中大多路由器采用動態路由的應用意義。

再者，反思前面的階段，由于鏈路層采用4位CRC校驗和停等協議進行差錯控制，以及沒有采用分片傳輸的原因，導致本階段進行混合組網端到端傳輸的效率明顯不夠，特別是圖片傳輸時，在物理模擬軟件還設置有一定誤碼率的時候，僅能傳輸像素較小的圖片（測試用例好像像素僅10×14），像素稍微過大，即數據量過大，就會導致中間的某一環傳輸出現問題，不停的需要重傳，幾乎無法正確傳輸過去。這也是為什么我后來反思如果設置能夠設計分片功能，整個通信傳輸會更加的準確高效。（當然沒有誤碼率肯定能夠傳輸較大的圖片）

整個項目已經完結，回顧下來，覺得還有許多不足和可以改進的地方。也發現對許多功能的設計有了新的想法，或者是原來沒想出來的問題有了一些想法。回顧整個過程的時候，腦海里回想起了這一學期一個人抗壓，一個人解決大大小小的問題，一次次克服畏難情緒，最終把項目一點一點自己推進的情景。雖然比起周圍同學確實很累，但是給我最大的體會就是，曾經我認為再難克服的困難，也會在咬牙中一點一點地被克服，在壓力中前進，才應該是人生的一種積極樂觀的常態；這不僅是這學期的計通網帶給我的，也包括此期間發生的許多其他種種事情。

總結

以上是生活随笔為你收集整理的计算机网络项目——最小网元设计（阶段四）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。