基于VxWorks的全IP開發平臺進程通信處理機制＊

2013-08-27 08:33:12賀冰琰

單片機與嵌入式系統應用 2013年2期

關鍵詞：進程

賀冰琰

（集美大學計算機工程學院，廈門361021）

引言

隨著IP技術的迅速發展，“Everything over IP”的觀念已深入人心。眾多移動通信設備制造商都致力于基于全IP交換平臺之上的3G、4G 產品開發，基于全IP構建開放通信體系架構，真正作到核心網和無線網絡各個產品的模塊化、積木化。將核心網、無線接入網統一考慮，做到技術上的重用、接口上的統一，避免獨立開發各模塊特別是底層開發可能存在的重復勞動，實現全業務融合，打造一體化的可增值、可擴展的多業務集成通信平臺，已成為業界共識［1］。在整個系統設計的過程中，主要的目標在于軟件支撐的統一性，這要求相關的硬件系統也需要統一考慮成一個硬件平臺的概念。這樣將來就可以在統一的軟件支撐上開發各種不同的應用業務。

1 全IP開發平臺架構

全IP交換平臺基于Crossbar的三層交換，可根據系統容量需求和實際應用要求配置。當容量較大時，采用CrossBar＋線卡方式實現三層交換方式，具體線卡配置的數目根據實際數據流量以及資源在各個應用實體的利用情況確定。當容量較小時，采用線卡互連提供三層交換。位于全IP交換平臺之上的移動通信設備單板需要實現的移動通信功能靠Host（主）CPU 完成。本文中的全IP開發平臺選用AMCC 的NP7250、NPX5700和NPX5800交換套片作為硬件基礎，主CPU 是MPC8260，主CPU 上的操作系統是VxWorks。其中，NP7250主要實現級連線卡的作用，完成基本信元／包的轉發功能；NPX5700 是流量控制芯片，實現對數據流的輸入接納和輸出調度功能，是IP開發平臺QoS保證的核心，兩套NPX5700構成雙向10 Gbps的處理能力；NPX5800 是一種交換網芯片，用于連接NPX5700，實現交換功能，。［2］

全IP交換平臺系統架構如圖1所示，在嵌入式操作系統VxWorks之上還有一個操作系統子系統，該層是VxWorks封裝層。嵌入式操作系統封裝層的目的之一是對上層應用屏蔽底層硬件、OS、網絡的差別，給上層應用軟件提供統一規范的調用接口，大大降低了應用軟件開發人員的開發難度，也使開發出的應用軟件有較好的跨平臺性、可移植性、可維護性和代碼繼承性。封裝層一般會對進程管理、內存管理、進程通信等核心功能進行重新定義和優化，以適應特定應用領域的開發需求。

下面以通信類嵌入式設備應用領域為背景來討論操作系統子系統中的進程通信管理模塊設計和實現方案。

圖1 全IP交換平臺架構

2 進程通信模塊設計

通信模塊為進程之間的通信提供統一的接口。各個處理器都處于一個以太網上，前臺單板之間互相可以直達，沒有中間路由，前后臺之間通過OMP 轉發。根據通信區域的不同可分為：①相同處理器內同一任務下的進程間通信；②相同處理器內不同任務下的進程間通信；③相同處理器內的任務之間的通信；④相同處理器內的進程到任務的通信；⑤相同處理器內的任務到進程的通信；⑥不同處理器間的進程間通信。

底層協議類型包括可靠通信協議（TCP）和不可靠通信協議（UDP）。對話方式主要采用以下5種：①處理器內廣播（內部消息機制）；②分布式系統內組播（UDP）；③分布式系統內廣播（UDP）；④多對多通信（UDP），也就是無連接的點對點通信；⑤點對點通信（TCP 和內部消息機制）。

2.1 通信處理流程

同一處理器內任務之間通信流程：每個調度任務建立一個郵箱，其他任務也建立自己的郵箱，進程發送到另一個任務的進程的消息首先發送到目的進程所在任務的郵箱中進行緩存，然后由調度任務派發到目的進程的消息隊列中；進程到其他類型任務的消息發送到相應任務的郵箱，其他類型的任務之間消息發送到對方郵箱。根據為應用提供的消息類型將任務間消息發送分類。發送異步緊迫消息，將消息發送到任務消息隊列的頭部；發送異步普通消息，將消息發送到任務消息隊列的尾部。

同一任務內的進程通信流程如圖2所示，每一個進程擁有一個消息隊列，進程向同一任務內進程發送，通過內部接口直接將消息掛到另一個進程的消息隊列中。進程向同一任務內進程發送同步應答消息，不通過任務郵箱，目的進程的狀態直接改變即可。任務內的進程間通信不能通過任務的郵箱進行轉發，這是為了避免在郵箱滿的時候任務向自己的郵箱發送消息，導致任務死鎖。

圖2 同一任務內的進程間通信

不同處理器間的進程通信流程如圖3所示，下面根據不同的對話方式分別描述通信處理流程。

圖3 進程間通信流程

①點對點通信。每個需要通信的處理器之間維護一條TCP連接，所有連接組成連接表。進程通過接口發送的消息首先掛在相應的連接的發送隊列中。通信任務在連接表中的所有連接上監測鏈路狀態，在連接寫就緒時依序發送連接發送隊列中的消息，在連接讀就緒時接收連接上的消息并向上層轉發，在連接異常時告警并恢復鏈路狀態，在檢查報到達的時候將鏈路丟失的檢查報清零。

②多對多通信。使用一個公用的UDP套接口，發送時指定協議類型為不可靠傳輸協議的時候，根據邏輯地址查找到對應的IP地址，直接從UDP套接口上發送出去。組播任務同樣守護在UDP套接口上，當套接口讀就緒的時候接收消息并向上層轉發。

③組播。采用靜態分組的方法，每一個組播組對應一個到組播地址，所有這種對應關系組成分組表。每一處理器可以加入特定組播組，也可以隨時脫離組播組。組播任務守護在組播組表的組播套接口上，在套接口讀就緒時接收消息并向上層轉發。進程直接在組播套接字上發送消息。

④廣播。分組表中有一個特殊項用作廣播，該組成員為系統內所有處理器，組播任務在該項上守護，進行和上面相同的處理。

⑤處理器內廣播。向同一個進程類型的實例分別發送一條消息的拷貝。

消息的派發過程如圖4所示。調度任務從自己的郵箱接收消息，并負責向各個進程的消息隊列中派發，在派發的過程中區別消息的類型。根據消息類型描述處理流程，派發同步應答消息時，將目標進程轉入就緒狀態，設置解除阻塞原因為應答到；派發同步超時消息時，將目標進程轉入就緒狀態，設置解除阻塞原因為同步超時；派發延時結束消息時，將目標進程轉入就緒狀態，設置解除阻塞原因為延時結束；派發其他類型的消息時，將消息掛到目標進程消息隊列尾部，如果目標進程因為沒有消息而阻塞，將目標進程轉入就緒狀態。

圖4 消息的派發

2.2 TCP連接狀態機設計

TCP連接的狀態記錄在TCP連接控制塊的狀態域里面，本端上層應用發起TCP連接建立請求時，TCP連接的狀態遷移如圖5所示。①沒有激活狀態：接收到來自上層應用的連接發起請求后，向對端發起連接，進入等待寫就緒狀態。②等待寫就緒狀態：如果接收到本端套接字的寫就緒事件，向對端發送檢查報，進入等待對端檢查報狀態；如果接收到對端連接請求（連接請求1）并且對端IP地址比自己的IP地址小，拒絕請求，繼續等待；如果接收到對端連接請求（連接請求2）并且對端IP地址比自己的IP地址大，接收請求，終止本端發起的連接過程，啟動連接接收的狀態機。③等待檢查報狀態：收到檢查報后，連接成功，進入工作狀態；如果接收到對端連接請求（連接請求1）并且對端IP地址比自己的IP地址小，拒絕請求，繼續等待；如果接收到對端連接請求（連接請求2）并且對端IP地址比自己的IP 地址大，接收請求，終止本端發起的連接過程，啟動連接接收的狀態機。④工作狀態：如果收到數據收發請求，則進行數據收發，并保持狀態；如果收到連接的關閉請求，則關閉本連接，轉到連接沒有激活狀態；如果收到對端的連接建立請求，則啟動連接的接收狀態機，并保持現在的連接在工作狀態。

圖5 發起TCP連接建立時的狀態遷移

在上述各種狀態下收到連接異常的信息都異常關閉連接，轉到連接沒有激活狀態。

本端收到對端發起TCP連接建立請求時，TCP連接的狀態遷移如圖6所示。①沒有激活狀態：接收到對端的連接請求后，進入等待檢查報狀態；②等待檢查報狀態：如果接收到對端的檢查報，進入等待寫就緒狀態；如果接收到對端連接請求，接收請求，終止上次的連接過程，進入等待檢查報狀態；③等待寫就緒狀態：如果收到寫就緒事件，向對端發送檢查報，連接成功，如果以前存在工作的鏈路，關閉該鏈路，本鏈路投入工作狀態；如果接收到對端連接請求，接收請求，終止本次連接過程，切換到等待檢查報狀態；④工作狀態：如果收到數據收發請求，則進行數據收發，并保持狀態；如果收到連接的關閉請求，則關閉本連接，轉到連接沒有激活狀態；如果收到對端的連接建立請求，則啟動備份連接的建立狀態機，并保持狀態。