基于ACR/Tbit路由器的硬件抽象層的通用性軟件結構設計

　　2.2 三次握手過程

　　每個客戶端與服務器端進行真正的數(shù)據(jù)傳輸之前,首先要進行一個握手的建立過程,如圖3所示。握手過程成功后則表示雙方通信通道正常,只有在得知握手成功后雙方才可以正常地收發(fā)報文,從而克服了UDP協(xié)議方式的面向無連接性。為了隨時檢測和維護雙方鏈路的通連性,每個客戶端與服務端在一定的間隔時間內(nèi)要互發(fā)KEEPALIVE報文。如果在規(guī)定的時間內(nèi)收不到對方的KEEPALIVE報文,說明斷鏈,要進行相應的斷鏈處理。

　　圖3 握手建立過程

　　2.3 接收端丟失確認及滑動窗口

　　發(fā)送UDP報文時在自定義的內(nèi)部數(shù)據(jù)頭中加入所發(fā)送數(shù)據(jù)的序號,接收端收到后發(fā)送確認信息,如果發(fā)送方在規(guī)定時間內(nèi)沒有收到確認信息,則認為該包丟失,會連同原包的序號重新發(fā)送。

　　滑動窗口的目的主要是為了實現(xiàn)流量控制,防止擁塞。每個發(fā)送方維護一個重發(fā)隊列,保存著一定數(shù)量的發(fā)送而沒被確認的報文,該隊列剩余空間的大小可以限制應用部分發(fā)包的速率。由于UDP協(xié)議是基于消息的傳輸協(xié)議而非基于流的,因此不必考慮發(fā)送端可以接收多少數(shù)據(jù),只需知道能否接收數(shù)據(jù)即可。

　　總之,采用UDP傳輸控制方式主要考慮到其傳輸簡單快速、額外開銷較小的特點,但這是以犧牲一定的可靠性為前提的,因此必須在應用程序中增加可靠性保護機制。在實際應用中證明上述方法可靠高效,能夠維護內(nèi)部通信有序、快速的數(shù)據(jù)傳輸。

　　3 基于多用戶的用戶接入管理

　　在Linux操作系統(tǒng)下,系統(tǒng)把設備映射為一個特殊的設備文件,用戶程序可以像對其他文件一樣對該設備文件進行讀寫操作。虛擬驅動模塊運行在Linux操作系統(tǒng)下,模擬從處理單元上的接口單元,形成收發(fā)協(xié)議報文功能和數(shù)量與此一致的硬件抽象層虛擬接口單元。因此,每個實際的接口單元都在內(nèi)核中對應一個注冊的虛擬設備,以便于上層控制軟件對數(shù)據(jù)平面的管理與數(shù)據(jù)交互。

　　3.1 多用戶虛擬設備驅動程序的動態(tài)加載

　　虛擬驅動在內(nèi)核中的功能通過動態(tài)加載方式實現(xiàn)。通常的動態(tài)加載方式是將驅動程序作為一個整體模塊,在需要時再加入內(nèi)核;由于多用戶接入方式使得在某一時刻內(nèi)核中注冊的接口單元數(shù)量不確定,如果實施一次性加載會冗余太多,不利于資源的有效利用。因此,在內(nèi)核中加載一個基本模塊的前提下,實現(xiàn)各虛擬設備的動態(tài)加載過程,達到以一個基本的虛擬設備控制多個設備驅動模塊的功能。

　　如圖4所示,對虛擬驅動設備的控制由內(nèi)部通信模塊與設備管理模塊共同完成。設備管理模塊通過內(nèi)部通信模塊下達加載、卸載虛擬驅動的命令,通過內(nèi)部通信模塊與虛擬驅動的控制通道進行。內(nèi)部通信模塊通過調用ioctl()采用不同的命令字完成對虛擬驅動模塊的控制過程。

　　圖4模塊動態(tài)加載過程

　　基本驅動模塊的加載采用通常的驅動模塊加載方式,即調用module_init()函數(shù)進行基本模塊的初始化及在內(nèi)核中的注冊過程。以該基本驅動模塊為基礎,當內(nèi)部通信模塊收到加載某個用戶設備接口的命令后,通過調用該基本模塊的Base_ioctl()在內(nèi)核中注冊一個新的驅動設備,該注冊設備才是與實際接口單元相對應的虛擬驅動模塊,應用程序對用戶設備數(shù)據(jù)的讀寫都是通過這些注冊的接口設備而非基本設備提供的標準函數(shù)進行。這樣的動態(tài)加載過程使得當沒有設備加載時在內(nèi)核中只存在一個基本的虛擬驅動模塊,只有需要注冊的用戶才將其對應的設備接口的虛擬驅動模塊加載到內(nèi)核中,從而減少系統(tǒng)冗余,便于管理。

　　各用戶接口單元與虛擬驅動的數(shù)據(jù)交互通過內(nèi)部通信模塊與虛擬驅動的數(shù)據(jù)通道進行,所對應的系統(tǒng)調用為該注冊設備的dev_ioctl()。在該功能函數(shù)中,實現(xiàn)用戶空間與內(nèi)核空間的數(shù)據(jù)交互。

　　3.2 對多用戶接口設備虛擬驅動的管理

　　為實現(xiàn)內(nèi)核虛擬驅動模塊與實際接口單元的一一對應,必須解決各驅動模塊的命名原則問題。將每個實際接口單元在接入段拓撲中的位置設置為不同的參數(shù),在內(nèi)部通信中這些參數(shù)作為傳輸數(shù)據(jù)的報頭信息出現(xiàn),根據(jù)它們可以生成一個唯一的字符串作為對應該接口單元的虛擬驅動設備名稱,而且根據(jù)設備名稱亦可還原出實際接口單元的拓撲信息,以供內(nèi)部通信使用。在內(nèi)核中維護一個由各注冊設備名稱所組成的動態(tài)鏈表,每個鏈表節(jié)點維護一個收發(fā)報文的數(shù)據(jù)隊列,虛擬驅動與其他模塊的數(shù)據(jù)交互都通過該鏈表進行。

　　3.3 對虛擬設備數(shù)據(jù)讀寫過程

　　對數(shù)據(jù)的讀寫過程主要是在虛擬驅動模塊、內(nèi)部通信模塊及上層控制軟件之間進行。虛擬驅動模塊運行在內(nèi)核空間,而內(nèi)部通信模塊運行在用戶空間,因此,主要解決用戶空間與內(nèi)核空間的數(shù)據(jù)傳遞問題。通過memcpy_tofs()及memcpy_fromfs()系統(tǒng)調用用戶空間與內(nèi)核空間的數(shù)據(jù)交互。

　　在內(nèi)核中維護一個由各注冊設備名稱所組成的動態(tài)鏈表,每個鏈表節(jié)點維護一個收發(fā)報文的數(shù)據(jù)隊列,虛擬驅動與其他模塊的數(shù)據(jù)交互都通過該鏈表進行。接收報文過程:內(nèi)部通信模塊將從接口單元接收的報文通過ioctl()調用傳給虛擬驅動。該函數(shù)通過struct net_device *dev結構找到對應的虛擬設備的dev_ioctl()功能函數(shù),調用memcpy_fromfs()將數(shù)據(jù)拷貝至內(nèi)核空間,經(jīng)過處理后通過netif_rx()函數(shù)通知上層協(xié)議有數(shù)據(jù)傳入。發(fā)送報文過程:虛擬驅動將從上層軟件取出的數(shù)據(jù)放至自身維護的通過虛擬接口設備名稱維護的數(shù)據(jù)隊列中,內(nèi)部通信模塊通過ioctl()論詢各接口設備數(shù)據(jù)隊列是否有數(shù)據(jù)可讀,如果有數(shù)據(jù),虛擬驅動通過memcpy_tofs()調用將數(shù)據(jù)拷貝至用戶空間提供的緩沖區(qū)中。

　　文中針對大規(guī)模用戶接入方式的特性,討論了一種基于ACR/Tbit路由器的硬件抽象層的通用性軟件結構設計及實現(xiàn)方式,并研究了其關鍵技術,包括基于UDP傳輸方式的內(nèi)部通信的可靠性實現(xiàn)及基于多用戶的動態(tài)模塊加載技術,適用于路由器承載業(yè)務量的擴展和多用戶接入特性,并且在上層軟件實現(xiàn)中,基本上可以不考慮底層硬件細節(jié),增強了路由器的開放性及可擴展性。