基于A(yíng)DSP-BF537嵌入式FTP服務(wù)器的設計與實(shí)現

0引言

隨著(zhù)嵌入式設備的不斷發(fā)展，其對通信也提出了越來(lái)越高的要求。FTP(File Transfer Protocol)作為internet上最早提供的服務(wù)之一，至今仍然被人們廣泛使用，FTP是實(shí)現文件傳輸服務(wù)的最主要的規范。當需要考慮到文件傳輸安全、傳輸質(zhì)量、訪(fǎng)問(wèn)控制等諸多因素時(shí)，FTP服務(wù)器就成了解決文件傳輸問(wèn)題的關(guān)鍵所在。

然而，有時(shí)嵌入式系統的開(kāi)發(fā)環(huán)境并不支持FTP協(xié)議(如ADSP的集成開(kāi)發(fā)環(huán)境Visual DSP++)，在這種情況下，利用已有的LWIP堆棧中的一些基礎函數來(lái)構建一個(gè)FTP服務(wù)器，正是本文要詳細探討的話(huà)題。

1 文件傳輸過(guò)程

FTP協(xié)議與一般的Intemet協(xié)議不同。Intemet協(xié)議通常采用一個(gè)TCP連接來(lái)傳送信息(如HTTP協(xié)議)；而FTP協(xié)議則采用兩個(gè)TCP連接來(lái)實(shí)現文件的傳輸，其中一個(gè)用來(lái)為文件傳輸下命令，另一個(gè)則實(shí)現真正的傳輸過(guò)程。圖1所示是FTP文件傳輸的原理圖。

客戶(hù)端想要獲取存放在服務(wù)器上的文件時(shí)，應先通過(guò)一個(gè)預定義的端口號21主動(dòng)與服務(wù)器建立連接，服務(wù)器收到請求后，通過(guò)3次握手，就可在進(jìn)行FTP命令處理的用戶(hù)協(xié)議解釋器(PI)和服務(wù)器協(xié)議解釋器之間建立一條TCP連接。該連接始終等待用戶(hù)和服務(wù)器之間的通信，并傳輸用戶(hù)輸入的所有FTP命令和服務(wù)器的應答，即FTP傳輸中的命令連接。

當客戶(hù)通過(guò)交互式用戶(hù)界面向FTP服務(wù)器發(fā)出要下載服務(wù)器上某一文件的命令時(shí)，該命令即被送到用戶(hù)協(xié)議解釋器，并由用戶(hù)協(xié)議解釋器進(jìn)行處理。FTP將在服務(wù)器端口號20上打開(kāi)一個(gè)數據TCP連接。在數據連接上傳送完本次請求需傳送的文件之后，它將關(guān)閉數據連接，直到再有文件傳送請求時(shí)再重新打開(kāi)。因此，在FTP中，控制連接在整個(gè)用戶(hù)會(huì )話(huà)期間一直打開(kāi)著(zhù)，而數據連接則是一條臨時(shí)連接，當且僅當執行文件傳輸過(guò)程時(shí)才被創(chuàng )建。

FTP服務(wù)器的內部結構可根據不同的需求，選擇不同的服務(wù)器模式。因為服務(wù)器模式?jīng)Q定著(zhù)設計結構，而不同的設計結構又很大程度地影響著(zhù)FTP服務(wù)器的性能。服務(wù)器的模式主要有循環(huán)服務(wù)器和并發(fā)服務(wù)器。

1.1循環(huán)服務(wù)器

循環(huán)服務(wù)器只適應于最簡(jiǎn)單的應用協(xié)議，它采用客戶(hù)輪流等待的工作方式。但它的設計、編程、調試和修改都比較簡(jiǎn)單，在其響應時(shí)間可以滿(mǎn)足需求的條件下(這個(gè)時(shí)間可以在本地或全局網(wǎng)絡(luò )中進(jìn)行測試)，可以采用循環(huán)服務(wù)器模式。

1.2 并發(fā)服務(wù)器

如果構建一個(gè)響應需要大量的I／O操作，且各個(gè)請求所需要的處理時(shí)間差別非常大，或服務(wù)器在一臺多處理器的計算機上運行，則可引入并發(fā)性方法來(lái)縮短響應時(shí)間。大多數并發(fā)服務(wù)器使用多個(gè)進(jìn)程以及多個(gè)線(xiàn)程。其線(xiàn)程可分為兩類(lèi)：主服務(wù)器線(xiàn)程和從服務(wù)器線(xiàn)程。然而，在有些情況下，一些操作系統創(chuàng )建一個(gè)線(xiàn)程的開(kāi)銷(xiāo)很大，服務(wù)器無(wú)法承擔為每個(gè)請求或每個(gè)連接都創(chuàng )建一個(gè)線(xiàn)程的重負時(shí)，可采用單線(xiàn)程的并發(fā)模式。

2 嵌入式FTP服務(wù)器的實(shí)現

圖2所示是以ADSP-BF537為核心的嵌入式系統的硬件組成框圖。圖中，基于Blackfin處理器的ADSP--BF537具有接口豐富，性能優(yōu)良，價(jià)格低廉等特點(diǎn)，并具有強大的多媒體數據處理能力。ADSP的集成開(kāi)發(fā)環(huán)境Visual DSP++中嵌入了實(shí)時(shí)操作系統內核VDK，適合于多任務(wù)多線(xiàn)程的嵌入式操作。此外，ADI還提供了一個(gè)用于Blackfin系列嵌入式處理器的LwIP協(xié)議棧端口，利用它可以快速將一個(gè)獨立的嵌入式應用聯(lián)網(wǎng)。圖2中的BF537可通過(guò)網(wǎng)絡(luò )芯片LAN8187實(shí)現與上位機之間的網(wǎng)絡(luò )通信，同時(shí)利用自身的PPI口實(shí)現與存儲陣列的通信和管理。

由于系統中的服務(wù)器和客戶(hù)端在同一個(gè)局域網(wǎng)內，考慮到硬件芯片本身的特點(diǎn)，在文件下載時(shí)，與存儲陣列的通信只能通過(guò)同一套PPI總線(xiàn)，因此，較好的方式是一次只接受一個(gè)用戶(hù)的下載請求，于是可構建一個(gè)循環(huán)服務(wù)器來(lái)滿(mǎn)足需求。

出于安全性考慮，服務(wù)器通常只接受用戶(hù)名／密碼的登錄方式。登錄時(shí)所需的用戶(hù)名和密碼存放在存儲板中。每次收到用戶(hù)請求信息后，先從存儲板處獲得已有的用戶(hù)信息并比較，若與其中任何一個(gè)相符合，則發(fā)送接受請求信息，否則，回送拒絕信息。用戶(hù)登陸成功后，服務(wù)器會(huì )響應它的各種操作。圖3所示是FTP服務(wù)器的操作流程圖。

當用戶(hù)需要下載文件時(shí)，需先獲取文件列表。文件列表存放于存儲板中，可先由服務(wù)器向存儲板發(fā)送回送文件列表的請求，在得到響應后。再通過(guò)網(wǎng)絡(luò )回送給用戶(hù)，由用戶(hù)從中選擇所需下載文件的文件名，并發(fā)送給服務(wù)器。服務(wù)器收到文件名后，先判斷其所屬的文件夾，再由此向對應存儲板發(fā)送下載該文件的命令。存儲板通過(guò)PPI向管理板回送信息(在此每包數據的大小為64KB)，管理板每緩存完十包數據后，將通過(guò)網(wǎng)絡(luò )回送給用戶(hù)。需要指出的是，一開(kāi)始，在實(shí)際的下載過(guò)程中，有時(shí)文件會(huì )出現丟幀現象，而且跟網(wǎng)絡(luò )狀況有關(guān)。經(jīng)過(guò)分析其原因是網(wǎng)絡(luò )速度與PPI傳輸相比過(guò)慢而導致接收緩存溢出，從而引起下載過(guò)程中的數據丟失。于是，可采取流控的下載方式。事實(shí)上，存儲板并不會(huì )一下將所有數據都連續地發(fā)送過(guò)來(lái)，而是每發(fā)送完十包以后，再等待控制板的確認包?？刂瓢逯挥性趯⑺袛祿纪ㄟ^(guò)網(wǎng)路發(fā)送完畢后，才給存儲板發(fā)送確認包，以等待接收下一次的十包數據。以此循環(huán)，直至下載完成。其命令處理流程圖如圖4所示。

3 結束語(yǔ)

在嵌入式系統中，依靠通信技術(shù)可以創(chuàng )造出很多十分有用的產(chǎn)品，本文重點(diǎn)介紹了一個(gè)以DSP為核心所構建的嵌入式FTP服務(wù)器的實(shí)現方法。且經(jīng)實(shí)際檢驗，運行狀況良好。本方法對其它形式的嵌入式系統的FTP下載功能，也有很強的借鑒意義。