目前，大多數(shù)路由器均采用分布式轉(zhuǎn)發(fā),、集中式路由處理的體系結(jié)構(gòu)^[1],。該結(jié)構(gòu)方式使主處理單元與各從處理單元可以根據(jù)所處位置及執(zhí)行任務(wù)的不同采用不同的處理方式，但也使頂層管理軟件對底層各從處理單元難以進(jìn)行協(xié)調(diào)統(tǒng)一的管理,。硬件抽象層HAL(Hardware Abstraction Layer)在邏輯上介于底層硬件與上層協(xié)議軟件之間,，維護(hù)兩者之間的數(shù)據(jù)傳遞，并對底層各接口模塊進(jìn)行管理,，屏蔽底層硬件細(xì)節(jié),，使得應(yīng)用軟件可以通過控制HAL達(dá)到操縱底層硬件的目的。高性能路由器硬件抽象層的提出^[2]成功解決了分布式路由器面臨的通用性支撐軟件系統(tǒng)結(jié)構(gòu)的設(shè)計(jì)問題,，為構(gòu)建開放通用的路由器軟件基礎(chǔ)平臺(tái)提供了保證,。
　　隨著路由器承載業(yè)務(wù)能力的不斷增強(qiáng)，大規(guī)模接入?yún)R聚路由器的設(shè)計(jì)與實(shí)現(xiàn)也被提上了議事日程,。ACR(大規(guī)模接入?yún)R聚路由器)是3Tnet(高性能寬帶網(wǎng))網(wǎng)絡(luò)的關(guān)鍵設(shè)備,。該設(shè)備采用ACR寬帶接入方式，即通過帶有遠(yuǎn)端用戶接口單元(RIU),、基于以太網(wǎng)傳輸接口的分合路器(EMDi)組成樹形分叉地域分布式系統(tǒng)構(gòu)架,，保證大規(guī)模的用戶直接接入骨干高速網(wǎng)絡(luò)，實(shí)現(xiàn)視頻點(diǎn)播,、網(wǎng)絡(luò)電視、IP電話等寬帶業(yè)務(wù),，從而更加減化了網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu),，使業(yè)務(wù)引入更加快速,，運(yùn)營策略更加多樣化。
　　大規(guī)模用戶接入方式也給路由器硬件抽象層的實(shí)現(xiàn)方式及信息的實(shí)時(shí),、高速傳輸提出了新的挑戰(zhàn),，主要表現(xiàn)在以下幾個(gè)方面：首先，承載業(yè)務(wù)量的數(shù)量及種類的增多對路由器內(nèi)部通信的實(shí)時(shí)性,、高效性提出了更多的要求,；其次，大規(guī)模用戶接入方式增加了路由器對外接口的數(shù)量,，從而帶來了設(shè)備管理上的難度,；再次，從系統(tǒng)的通用性及可擴(kuò)展性考慮,，要求構(gòu)建一種具有可擴(kuò)展性且不依賴于硬件具體實(shí)現(xiàn)方式的軟件體系結(jié)構(gòu),，方便路由軟件的移植和應(yīng)用。由此可見,，硬件抽象層的高度穩(wěn)定性,、可擴(kuò)展性及可靠性將直接影響路由器的各項(xiàng)性能指標(biāo)。
　　由于大規(guī)模用戶接入方式的特性,，使得以前基于IPv6路由器的硬件抽象層的實(shí)現(xiàn)方式已經(jīng)不適應(yīng)數(shù)據(jù)高速傳輸及多用戶接入的管理方式,。本文將在討論硬件抽象層基本結(jié)構(gòu)的基礎(chǔ)上，提出一種適用于大規(guī)模接入?yún)R聚路由器的HAL的通用性軟件結(jié)構(gòu)設(shè)計(jì)及實(shí)現(xiàn)方式,，提供高效,、可靠的內(nèi)部通信，并針對多用戶接入數(shù)量不確定的情況,，提出動(dòng)態(tài)加載" title="加載">加載虛擬驅(qū)動(dòng)模塊" title="驅(qū)動(dòng)模塊">驅(qū)動(dòng)模塊的實(shí)現(xiàn)方法,，增強(qiáng)路由器面向ACR接入方式的可用性。
1 硬件抽象層基本結(jié)構(gòu)及功能實(shí)現(xiàn)
　　根據(jù)文獻(xiàn)^[2]提出的方案,，高性能路由器硬件抽象層可分為內(nèi)部通信,、虛擬驅(qū)動(dòng)及設(shè)備管理三大模塊，這三部分模塊相互配合,，共同完成面向?qū)嶋H的用戶設(shè)備接口的功能模擬及硬件細(xì)節(jié)的屏蔽,，并對其進(jìn)行統(tǒng)一協(xié)調(diào)的管理。硬件抽象層對用戶設(shè)備接口的功能模擬主要由虛擬驅(qū)動(dòng)模塊完成,，包括數(shù)據(jù)包的收發(fā)及協(xié)議報(bào)文的預(yù)處理等工作,，為上層協(xié)議軟件提供標(biāo)準(zhǔn)的API函數(shù)；而對用戶設(shè)備的接口管理則由上層網(wǎng)絡(luò)管理軟件通過設(shè)備管理模塊對其進(jìn)行管理配置及監(jiān)控,；內(nèi)部通信模塊" title="通信模塊">通信模塊運(yùn)行于內(nèi)部以太網(wǎng)絡(luò),，協(xié)調(diào)各模塊之間的功能接口，保證各從處理單元與主處理單元之間實(shí)時(shí)可靠的數(shù)據(jù)傳輸。其基本結(jié)構(gòu)如圖1所示,。

　　根據(jù)各模塊的功能可知,，硬件抽象層內(nèi)部通信模塊是各分處理單元與主處理單元信息交互的重要傳輸通道。內(nèi)部通信模塊匯集各底層設(shè)備的數(shù)據(jù)并根據(jù)類型分流至各上層處理模塊,，同時(shí),，數(shù)據(jù)維護(hù)模塊對虛擬設(shè)備及各處理單元的維護(hù)信息也需要通過內(nèi)部通信模塊進(jìn)行。因此,，內(nèi)部通信模塊采用何種基于內(nèi)部以太網(wǎng)的數(shù)據(jù)傳輸實(shí)現(xiàn)方式,，對路由器內(nèi)部數(shù)據(jù)的實(shí)時(shí)、有效,、可靠傳輸起著至關(guān)重要的作用,。當(dāng)前內(nèi)部通信模塊采用基于分隔符的TCP傳輸方式，在應(yīng)用層數(shù)據(jù)包的起始部分附加有特定格式的分隔符和數(shù)據(jù)長度域,，解決了由于Nagle算法產(chǎn)生的包粘滯問題^[3],。但該方式?jīng)]能解決TCP傳輸方式的消耗過大、實(shí)時(shí)性不強(qiáng)的問題^[4],。同時(shí),，消除分割符恢復(fù)報(bào)文的完整性也增加了應(yīng)用程序的處理復(fù)雜度，從而不可避免地增加系統(tǒng)的開銷并降低系統(tǒng)的實(shí)時(shí)性,。系統(tǒng)的實(shí)時(shí)性對于用戶業(yè)務(wù)急劇增多的ACR路由器而言是一個(gè)迫切需要解決的問題,。UDP是一個(gè)面向消息的傳輸協(xié)議^[5]，其最大數(shù)據(jù)緩沖區(qū)長度為8192～65536字節(jié),，滿足一次傳輸一個(gè)完整報(bào)文的條件,。在內(nèi)部以太網(wǎng)中采用UDP傳輸方式具有明顯的優(yōu)勢。但由于UDP協(xié)議的無連接性,，導(dǎo)致它是一個(gè)不可靠傳輸,，文中第二部分將討論如何實(shí)現(xiàn)一種基于UDP的內(nèi)部通信的可靠性傳輸機(jī)制。
　　硬件抽象層對用戶設(shè)備接口的功能模擬主要通過虛擬驅(qū)動(dòng)進(jìn)行,，路由器業(yè)務(wù)類型的擴(kuò)展使得用戶接口數(shù)量增多并呈現(xiàn)接入時(shí)間的不確定性,，從而帶來用戶設(shè)備管理上的難度。針對此種情況,，文中第三部分提出動(dòng)態(tài)加載虛擬驅(qū)動(dòng)模塊的實(shí)現(xiàn)方法,，增強(qiáng)路由器面向多用戶接入方式的可用性。
2 基于UDP傳輸方式的內(nèi)部通信的可靠性實(shí)現(xiàn)
　　內(nèi)部通信模塊處于硬件抽象層的底層,，運(yùn)行于內(nèi)部交換網(wǎng)絡(luò),，完成底層硬件與上層控制軟件的數(shù)據(jù)傳輸，實(shí)現(xiàn)對底層硬件的初步屏蔽分離,；針對分布式體系結(jié)構(gòu)特點(diǎn)及多用戶接入的業(yè)務(wù)需求,，內(nèi)部通信模塊以Client\Server的方式分別運(yùn)行于主處理單元模塊及各線路接口單元模塊上,，采用UDP傳輸協(xié)議進(jìn)行通信，主要基于以下幾點(diǎn)考慮：
　　首先,，UDP協(xié)議是一個(gè)無連接協(xié)議,，傳輸數(shù)據(jù)之前源端與終端不需建立連接,，因此不需維護(hù)連接狀態(tài),。這樣服務(wù)器端可以使用一個(gè)或幾個(gè)端口同時(shí)向多個(gè)客戶端發(fā)送消息，符合分布式結(jié)構(gòu)體系的要求,。
　　其次,，UDP信息包很短，只有8個(gè)字節(jié),，相對于TCP的20個(gè)字節(jié)的信息包的額外開銷很小,，便于數(shù)據(jù)的快速傳遞。
　　再次,，吞吐量不受擁塞控制算法的調(diào)節(jié),，只受應(yīng)用軟件生成數(shù)據(jù)的速率、傳輸帶寬和計(jì)算機(jī)性能的影響,，適用于內(nèi)部以太網(wǎng)絡(luò)的數(shù)據(jù)傳輸,。
　　但由于UDP方式的無連接性，使得UDP傳輸?shù)目煽啃圆粡?qiáng),。而可靠性是內(nèi)部通信模塊所必須具有的性能,，因此考慮在應(yīng)用軟件中實(shí)現(xiàn)UDP傳輸方式的可靠性保證，主要采用以下方式：
2.1 多線程無連接的C/S通信方式
　　服務(wù)器端運(yùn)行在Linux操作系統(tǒng)下,，采用多線程方式收發(fā)各類數(shù)據(jù),；客戶端運(yùn)行在Vxworks操作系統(tǒng)，采用多任務(wù)方式收發(fā)各類數(shù)據(jù),。這樣由于多線程及多任務(wù)并行運(yùn)行的特性,，在內(nèi)部以太網(wǎng)的傳輸條件下，使得收發(fā)數(shù)據(jù)的速率可以滿足系統(tǒng)的要求,?；镜幕赨DP協(xié)議的無連接客戶端/服務(wù)器端通信程序如圖2所示。

　　該通信過程采用多個(gè)客戶端(各從處理單元)對一個(gè)服務(wù)器端(主處理單元)的方式,，使多個(gè)用戶接口模塊可以在不同時(shí)間接入主控,。內(nèi)部通信根據(jù)所傳遞數(shù)據(jù)的不同類型，采用相對固定的不同的端口號,，不同的客戶端采用不同的IP地址,，從相同的端口收發(fā)同類數(shù)據(jù)。在服務(wù)器端通過select()系統(tǒng)調(diào)用,，既可以輪詢各個(gè)socket端口以便及時(shí)接收不同端口的數(shù)據(jù),，又起到定時(shí)器的作用,。當(dāng)規(guī)定時(shí)間內(nèi)收不到數(shù)據(jù)時(shí)，能夠及時(shí)返回繼續(xù)在阻塞模式下等待,，從而既能及時(shí)收發(fā)數(shù)據(jù),，又降低資源消耗。
2.2 三次握手過程
　　每個(gè)客戶端與服務(wù)器端進(jìn)行真正的數(shù)據(jù)傳輸之前,，首先要進(jìn)行一個(gè)握手的建立過程,，如圖3所示。握手過程成功后則表示雙方通信通道正常,，只有在得知握手成功后雙方才可以正常地收發(fā)報(bào)文,，從而克服了UDP協(xié)議方式的面向無連接性。為了隨時(shí)檢測和維護(hù)雙方鏈路的通連性,，每個(gè)客戶端與服務(wù)端在一定的間隔時(shí)間內(nèi)要互發(fā)KEEPALIVE報(bào)文,。如果在規(guī)定的時(shí)間內(nèi)收不到對方的KEEPALIVE報(bào)文，說明斷鏈,，要進(jìn)行相應(yīng)的斷鏈處理,。

2.3 接收端丟失確認(rèn)及滑動(dòng)窗口
　　發(fā)送UDP報(bào)文時(shí)在自定義的內(nèi)部數(shù)據(jù)頭中加入所發(fā)送數(shù)據(jù)的序號，接收端收到后發(fā)送確認(rèn)信息,，如果發(fā)送方在規(guī)定時(shí)間內(nèi)沒有收到確認(rèn)信息,，則認(rèn)為該包丟失，會(huì)連同原包的序號重新發(fā)送,。
　　滑動(dòng)窗口的目的主要是為了實(shí)現(xiàn)流量控制,，防止擁塞。每個(gè)發(fā)送方維護(hù)一個(gè)重發(fā)隊(duì)列,，保存著一定數(shù)量的發(fā)送而沒被確認(rèn)的報(bào)文,，該隊(duì)列剩余空間的大小可以限制應(yīng)用部分發(fā)包的速率。由于UDP協(xié)議是基于消息的傳輸協(xié)議而非基于流的,，因此不必考慮發(fā)送端可以接收多少數(shù)據(jù),，只需知道能否接收數(shù)據(jù)即可。
　　總之,，采用UDP傳輸控制方式主要考慮到其傳輸簡單快速,、額外開銷較小的特點(diǎn)，但這是以犧牲一定的可靠性為前提的,，因此必須在應(yīng)用程序中增加可靠性保護(hù)機(jī)制,。在實(shí)際應(yīng)用中證明上述方法可靠高效，能夠維護(hù)內(nèi)部通信有序,、快速的數(shù)據(jù)傳輸,。
3 基于多用戶的用戶接入管理
　　在Linux操作系統(tǒng)下，系統(tǒng)把設(shè)備映射為一個(gè)特殊的設(shè)備文件,，用戶程序可以像對其他文件一樣對該設(shè)備文件進(jìn)行讀寫操作,。虛擬驅(qū)動(dòng)模塊運(yùn)行在Linux操作系統(tǒng)下,，模擬從處理單元上的接口單元，形成收發(fā)協(xié)議報(bào)文功能和數(shù)量與此一致的硬件抽象層虛擬接口單元,。因此,，每個(gè)實(shí)際的接口單元都在內(nèi)核中對應(yīng)一個(gè)注冊的虛擬設(shè)備，以便于上層控制軟件對數(shù)據(jù)平面的管理與數(shù)據(jù)交互,。
3.1 多用戶虛擬設(shè)備驅(qū)動(dòng)程序的動(dòng)態(tài)加載
　　虛擬驅(qū)動(dòng)在內(nèi)核中的功能通過動(dòng)態(tài)加載方式實(shí)現(xiàn),。通常的動(dòng)態(tài)加載方式是將驅(qū)動(dòng)程序作為一個(gè)整體模塊，在需要時(shí)再加入內(nèi)核^[6],；由于多用戶接入方式使得在某一時(shí)刻內(nèi)核中注冊的接口單元數(shù)量不確定,，如果實(shí)施一次性加載會(huì)冗余太多,，不利于資源的有效利用,。因此，在內(nèi)核中加載一個(gè)基本模塊的前提下,，實(shí)現(xiàn)各虛擬設(shè)備的動(dòng)態(tài)加載過程,，達(dá)到以一個(gè)基本的虛擬設(shè)備控制多個(gè)設(shè)備驅(qū)動(dòng)模塊的功能。
　　如圖4所示,，對虛擬驅(qū)動(dòng)設(shè)備的控制由內(nèi)部通信模塊與設(shè)備管理模塊共同完成,。設(shè)備管理模塊通過內(nèi)部通信模塊下達(dá)加載、卸載虛擬驅(qū)動(dòng)的命令,，通過內(nèi)部通信模塊與虛擬驅(qū)動(dòng)的控制通道進(jìn)行,。內(nèi)部通信模塊通過調(diào)用ioctl()采用不同的命令字完成對虛擬驅(qū)動(dòng)模塊的控制過程。

　　基本驅(qū)動(dòng)模塊的加載采用通常的驅(qū)動(dòng)模塊加載方式,，即調(diào)用module_init()函數(shù)進(jìn)行基本模塊的初始化及在內(nèi)核中的注冊過程,。以該基本驅(qū)動(dòng)模塊為基礎(chǔ)，當(dāng)內(nèi)部通信模塊收到加載某個(gè)用戶設(shè)備接口的命令后,，通過調(diào)用該基本模塊的Base_ioctl()在內(nèi)核中注冊一個(gè)新的驅(qū)動(dòng)設(shè)備,，該注冊設(shè)備才是與實(shí)際接口單元相對應(yīng)的虛擬驅(qū)動(dòng)模塊，應(yīng)用程序?qū)τ脩粼O(shè)備數(shù)據(jù)的讀寫都是通過這些注冊的接口設(shè)備而非基本設(shè)備提供的標(biāo)準(zhǔn)函數(shù)進(jìn)行,。這樣的動(dòng)態(tài)加載過程使得當(dāng)沒有設(shè)備加載時(shí)在內(nèi)核中只存在一個(gè)基本的虛擬驅(qū)動(dòng)模塊,，只有需要注冊的用戶才將其對應(yīng)的設(shè)備接口的虛擬驅(qū)動(dòng)模塊加載到內(nèi)核中，從而減少系統(tǒng)冗余,，便于管理,。
　　各用戶接口單元與虛擬驅(qū)動(dòng)的數(shù)據(jù)交互通過內(nèi)部通信模塊與虛擬驅(qū)動(dòng)的數(shù)據(jù)通道進(jìn)行，所對應(yīng)的系統(tǒng)調(diào)用為該注冊設(shè)備的dev_ioctl(),。在該功能函數(shù)中,，實(shí)現(xiàn)用戶空間與內(nèi)核空間的數(shù)據(jù)交互。
3.2 對多用戶接口設(shè)備虛擬驅(qū)動(dòng)的管理
　　為實(shí)現(xiàn)內(nèi)核虛擬驅(qū)動(dòng)模塊與實(shí)際接口單元的一一對應(yīng),，必須解決各驅(qū)動(dòng)模塊的命名原則問題,。將每個(gè)實(shí)際接口單元在接入段拓?fù)渲械奈恢迷O(shè)置為不同的參數(shù),，在內(nèi)部通信中這些參數(shù)作為傳輸數(shù)據(jù)的報(bào)頭信息出現(xiàn)，根據(jù)它們可以生成一個(gè)唯一的字符串作為對應(yīng)該接口單元的虛擬驅(qū)動(dòng)設(shè)備名稱,，而且根據(jù)設(shè)備名稱亦可還原出實(shí)際接口單元的拓?fù)湫畔?，以供?nèi)部通信使用。在內(nèi)核中維護(hù)一個(gè)由各注冊設(shè)備名稱所組成的動(dòng)態(tài)鏈表,，每個(gè)鏈表節(jié)點(diǎn)維護(hù)一個(gè)收發(fā)報(bào)文的數(shù)據(jù)隊(duì)列,，虛擬驅(qū)動(dòng)與其他模塊的數(shù)據(jù)交互都通過該鏈表進(jìn)行。
3.3 對虛擬設(shè)備數(shù)據(jù)讀寫過程
　　對數(shù)據(jù)的讀寫過程主要是在虛擬驅(qū)動(dòng)模塊,、內(nèi)部通信模塊及上層控制軟件之間進(jìn)行,。虛擬驅(qū)動(dòng)模塊運(yùn)行在內(nèi)核空間，而內(nèi)部通信模塊運(yùn)行在用戶空間,，因此,，主要解決用戶空間與內(nèi)核空間的數(shù)據(jù)傳遞問題。通過memcpy_tofs()及memcpy_fromfs()系統(tǒng)調(diào)用用戶空間與內(nèi)核空間的數(shù)據(jù)交互,。
　　在內(nèi)核中維護(hù)一個(gè)由各注冊設(shè)備名稱所組成的動(dòng)態(tài)鏈表,，每個(gè)鏈表節(jié)點(diǎn)維護(hù)一個(gè)收發(fā)報(bào)文的數(shù)據(jù)隊(duì)列，虛擬驅(qū)動(dòng)與其他模塊的數(shù)據(jù)交互都通過該鏈表進(jìn)行,。接收報(bào)文過程：內(nèi)部通信模塊將從接口單元接收的報(bào)文通過ioctl()調(diào)用傳給虛擬驅(qū)動(dòng),。該函數(shù)通過struct net_device *dev結(jié)構(gòu)找到對應(yīng)的虛擬設(shè)備的dev_ioctl()功能函數(shù)，調(diào)用memcpy_fromfs()將數(shù)據(jù)拷貝至內(nèi)核空間,，經(jīng)過處理后通過netif_rx()函數(shù)通知上層協(xié)議有數(shù)據(jù)傳入,。發(fā)送報(bào)文過程：虛擬驅(qū)動(dòng)將從上層軟件取出的數(shù)據(jù)放至自身維護(hù)的通過虛擬接口設(shè)備名稱維護(hù)的數(shù)據(jù)隊(duì)列中，內(nèi)部通信模塊通過ioctl()論詢各接口設(shè)備數(shù)據(jù)隊(duì)列是否有數(shù)據(jù)可讀,，如果有數(shù)據(jù),，虛擬驅(qū)動(dòng)通過memcpy_tofs()調(diào)用將數(shù)據(jù)拷貝至用戶空間提供的緩沖區(qū)中。
　　文中針對大規(guī)模用戶接入方式的特性,，討論了一種基于ACR/Tbit路由器的硬件抽象層的通用性軟件結(jié)構(gòu)設(shè)計(jì)及實(shí)現(xiàn)方式,，并研究了其關(guān)鍵技術(shù)，包括基于UDP傳輸方式的內(nèi)部通信的可靠性實(shí)現(xiàn)及基于多用戶的動(dòng)態(tài)模塊加載技術(shù),，適用于路由器承載業(yè)務(wù)量的擴(kuò)展和多用戶接入特性,，并且在上層軟件實(shí)現(xiàn)中，基本上可以不考慮底層硬件細(xì)節(jié),，增強(qiáng)了路由器的開放性及可擴(kuò)展性,。