引言

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

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

1、 文件傳輸過程

FTP協(xié)議與一般的Intemet協(xié)議不同。Intemet協(xié)議通常采用一個(gè)TCP連接來傳送信息（如HTTP協(xié)議）；而FTP協(xié)議則采用兩個(gè)TCP連接來實(shí)現(xiàn)文件的傳輸，其中一個(gè)用來為文件傳輸下命令，另一個(gè)則實(shí)現(xiàn)真正的傳輸過程。圖1所示是FTP文件傳輸?shù)脑韴D。

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

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

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

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

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

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

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

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

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

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

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

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

3 、結(jié)束語

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

責(zé)任編輯：gt