時間：2022-07-06 14:40:00
開篇：寫作不僅是一種記錄，更是一種創(chuàng)造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇文件傳輸協(xié)議，希望這些內(nèi)容能成為您創(chuàng)作過程中的良師益友，陪伴您不斷探索和進步。
關鍵詞： VxWorks； FTP； 分包傳輸； 在線更新
中圖分類號： TN919?34； TP311.1 文獻標識碼： A 文章編號： 1004?373X（2013）24?0050?05
Research and implementation of file transfer method under VxWork
WANG Hao1， JIA Liang1， LI Yong?tian2
（1. Electronic and Information Engineering Institute， Shenyang Aerospace University， Shenyang 110136， China；
2. Beijing Fangtian Changjiu Science and Technology Ltd， beijing 100084， China）
Abstract： In a project development process， in order to meet the needs of online Flash update of DSP application program in data acquisition system， first of all， the application program is downloaded to the system controller memory by means of the Tornado development environment built?in FTP server， then encapsulated into packets to transmit， and finally the application program update is realized. The program solves the problem that when data dump space is less than the size of data transfer file， and the subpackage transmission in several times is required. The entire software development process is performed in the Tornado development environment， which is able to complete the subpackage error?free transmission of application files. The practical application shows that the software program designed according to the scheme can achieve a good Flash online update， has the characteristics of subpackage transmission and data accuracy， and can meet the design requirements.
Keywords： VxWorks； FTP； subpackage transmission； online update
隨著計算機技術、半導體技術以及軟件技術的飛速發(fā)展，嵌入式微處理器的性能也得到不斷提高，嵌入式操作系統(tǒng)的種類更是層出不窮，從而使得嵌入式系統(tǒng)在越來越多的領域得到更加廣泛的應用。其中，美國Wind River System公司于1983年設計開發(fā)的一種嵌入式實時操作系統(tǒng)（RTOS）VxWorks憑借其可移植性強等優(yōu)點得到了廣泛的應用[1]。VxWorks提供的系統(tǒng)接口要比其他操作系統(tǒng)豐富，因此選擇它來作為嵌入式采集系統(tǒng)的軟件控制平臺，可以大大提高開發(fā)的效率[2]。本文應用Motorola公司的MCP?750PowerPC嵌入式CPCI單板機作為系統(tǒng)控制器及北京方天長久科技有限公司的FTC?6010作為數(shù)據(jù)采集板組成數(shù)據(jù)采集系統(tǒng)。在開發(fā)過程中，考慮到了數(shù)據(jù)采集板有可能工作在不方便拆卸的場合，無法使用下載器對數(shù)據(jù)采集板上的DSP進行應用程序的更新，本文的研究重點就是實現(xiàn)對數(shù)據(jù)采集板上的DSP應用程序進行在線FLASH更新，從而擺脫下載器的束縛。基于以上考慮，規(guī)定了一份適合于本數(shù)據(jù)采集系統(tǒng)需要的分包文件傳輸協(xié)議，并在此基礎上用C語言封裝了一個基于VxWorks下的功能模塊，此功能模塊的設計成功的實現(xiàn)了DSP程序在線FLASH更新，滿足了開發(fā)的需要。
1 數(shù)據(jù)采集系統(tǒng)分析介紹
1.1 系統(tǒng)總體結構及軟硬件開發(fā)環(huán)境
數(shù)據(jù)采集系統(tǒng)基于CPCI總線實現(xiàn)，系統(tǒng)總體結構及軟硬件開發(fā)環(huán)境如圖1所示，上位機Tornado IDE（VxWorks集成開發(fā)環(huán)境）通過以太網(wǎng)絡和MCP?750PowerPC嵌入式單板機相連，MCP?750作為CPCI總線控制器通過CPCI總線控制數(shù)據(jù)采集板（FTC?6010），同時通過串口輸出信息到上位機，便于操作。
圖1 系統(tǒng)總體結構及軟硬件開發(fā)環(huán)境
1.2 DSP應用程序在線FLASH更新時數(shù)據(jù)流向
圖2簡要給出了DSP應用程序在線FLASH更新時數(shù)據(jù)的流向，上位機使用FTP通過網(wǎng)絡 將應用程序的二進制文件下載到系統(tǒng)控制器的內(nèi)存中，再從系統(tǒng)控制器的內(nèi)存中通過CPCI總線將文件傳送至數(shù)據(jù)采集板上DSP外接的FLASH中，最后實現(xiàn)FLASH的更新。在傳送過程中，由于系統(tǒng)控制器與數(shù)據(jù)采集板上的DSP需要通過DPSRAM進行交互，而DPSRAM的存儲空間有限，此時就需要將應用程序文件分包進行傳輸，傳輸協(xié)議的制定就顯得至關重要了，需要保證數(shù)據(jù)傳輸正確，傳輸過程不丟包。
圖2 DSP應用程序在線FLASH更新時數(shù)據(jù)流向
2 FTP文件傳輸
2.1 FTP介紹
文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）是TCP/IP 的一種具體應用，工作在OSI 模型的第7層， TCP 模型的第4層， 即應用層。FTP要求客戶向服務器提供用戶注冊名和口令， 服務器拒絕非法用戶的訪問。但是鏈接一旦建立成功， 一個或多個文本或圖像二進制文件都能被傳送， FTP 不必擔心可靠性和連接的管理， 因為FTP 依靠TCP 正確執(zhí)行這些功能[3]。Tornado開發(fā)環(huán)境自帶FTP服務器，常見用于系統(tǒng)成功引導后，下載VxWorks的運行時映象，需正確配置用戶名，密碼和路徑[4]。
2.2 VxWorks下FTP程序的編寫
可以直接使用VxWorks提供的幾個API函數(shù)進行FTP程序的編寫，實現(xiàn)從上位機將應用程序文件下載到系統(tǒng)控制器的內(nèi)存中的目的，這里主要介紹三個：ftpXfer、ftpReplyGet和ftpCommand，幾個函數(shù)的原型和主要用法如下[5]：
ftpXfer的作用是初始化通過FTP傳輸?shù)奈募?/p>
STATUS ftpXfer
（
char * host，
/*ftp服務器的IP地址，點分十進制，格式類似于"10.0.0.1" */
char * user， /*訪問ftp服務器的用戶名 */
char * passwd， /*訪問ftp服務器的密碼 */
char * acct， /*一般不用，直接填寫為空字符串就可以了*/
char * cmd， /*發(fā)送給FTP服務器的命令，例如讀取命令為"RETR"*/
char * dirname， /*待訪問文件所在的目錄*/
char * filename， /*待訪問文件的文件名*/
int * pCtrlSock， /*存儲返回的文件描述符，也就是常說的fd*/
int * pDataSock /*存儲返回的待訪問文件的文件描述符*/
）
此例程按以下順序發(fā)起通過FTP服務器傳輸文件：
（1）建立一個連接到指定的主機上的FTP服務器；
（2）在指定的主機上設置好用戶名，密碼和賬號；
（3）發(fā)送文件傳輸類型命令；
（4）發(fā)送文件所在的目錄以及文件名命令；
（5）將指定的轉移命令和指定的文件名作為參數(shù)，建立一個數(shù)據(jù)連接。典型的傳輸命令為STOR %S：寫入到一個遠程文件；RETR%S：讀取一個遠程文件。
由此產(chǎn)生的控制和數(shù)據(jù)連接文件描述符分別通過pCtrlSock和pDataSock返回。
調(diào)用這個程序后，數(shù)據(jù)可以被讀取或寫入到遠程服務器返回的文件描述符pDataSock中。當所有傳入的數(shù)據(jù)被讀取（讀取數(shù)據(jù)套接字由EOF表示）和/或所有傳出的數(shù)據(jù)已寫入，應關閉數(shù)據(jù)套接字fd。
這時候應該調(diào)用函數(shù)ftpReplyGet（），用來接收控制套接字的最后的回復。
int ftpReplyGet
（
int ctrlSock， /*連接FTP control socket文件描述符fd*/
BOOL expecteof /* TRUE = EOF expected， FALSE = EOF is error */
）
若沒有錯誤，應調(diào)用函數(shù)ftpCommand（）關閉control socket。
int ftpCommand
（
int ctrlSock， /* 連接FTP control socket文件描述符fd */
char * fmt， /* 待傳遞的ftp命令 */
int arg1， /* ftp命令的參數(shù)*/
int arg2，
int arg3，
int arg4，
int arg5，
int arg6
）
如果FTP命令不涉及數(shù)據(jù)傳輸（例如文件刪除或重命名），pDataSock應該是NULL，在這種情況下，不會建立數(shù)據(jù)連接。函數(shù)返回為OK或ERROR（有socket不能創(chuàng)建或不能進行連接）。
FTP文件傳輸?shù)娜窟^程如圖3所示。
圖3 VxWorks下FTP文件傳輸過程
程序關鍵代碼如下：
/* initiate a transfer via a remote FTP server to read a remote file */
if（ERROR==ftpXfer（UNIX_HOST，USER，PASSWD，""，"RETR %s"，W_DIR，F(xiàn)ILE，&ctrlSock，
&dataSock））
{
perror（"Error in initiating a transfer via a remote FTP server"）；
return ERROR；
}
/* read the remote file data to buffer */
while（（NumBytes=read（dataSock，buff，sizeof（buff）））>0）
{
buff+=NumBytes；
}
if（NumBytes
{
perror （"Error in reading"）； /* read error */
return （ERROR）；
}
close（dataSock）；
/* Get an FTP command reply to see whether EOF is encountered */
if（ftpReplyGet（ctrlSock，TRUE）！=FTP_COMPLETE）
{
perror （"positive completion failed"）；
return （ERROR）；
}
/* Send QUIT FTP command */
if（ftpCommand（ctrlSock，"QUIT"，0，0，0，0，0，0）！=FTP_COMPLETE）
{
perror （"QUIT FTP command positive completion failed"）；
return （ERROR）；
}
close （ctrlSock）；
3 分包文件傳輸協(xié)議的制定與實現(xiàn)
3.1 分包文件傳輸協(xié)議制定
通過本文前兩節(jié)的分析和應用，文件已經(jīng)成功的從上位機下載到了系統(tǒng)控制器的內(nèi)存當中，本節(jié)著重介紹如何從系統(tǒng)控制器的內(nèi)存中將文件封裝成數(shù)據(jù)包分次傳送給DPSRAM，如何通知DSP將數(shù)據(jù)包取走，如何得到DSP的應答之后傳送下一個數(shù)據(jù)包，如何判斷數(shù)據(jù)包全部傳送完成等，簡而言之，就是分包文件傳輸協(xié)議的制定，圖4用流程圖的形式對整個過程進行了詳細的描述。
下面以數(shù)據(jù)包包含的信息要素為例介紹分包文件傳輸協(xié)議，每個數(shù)據(jù)包包含以下信息要素，如圖5所示。
系統(tǒng)控制器將數(shù)據(jù)包寫入DPSRAM之后，會發(fā)起DPSRAM左端口中斷，DSP檢測到中斷后從DPSRAM中取走數(shù)據(jù)包。
控制命令字的主要作用是告知DSP，此數(shù)據(jù)包數(shù)據(jù)空間中的數(shù)據(jù)是用于FLASH更新用的，需要將其寫入FLASH中。
數(shù)據(jù)包長度的主要作用是告知DSP即將要讀取的數(shù)據(jù)包中數(shù)據(jù)空間的長度，以便DSP將其寫入到FLASH對應的空間中。
圖4 分包文件傳送過程
圖5 數(shù)據(jù)包的信息要素
數(shù)據(jù)包序號的主要作用是告知DSP，此次傳輸?shù)氖堑趲讉€數(shù)據(jù)包，防止傳輸過程中丟包。
數(shù)據(jù)寫入標記分為3種：根據(jù)數(shù)據(jù)包序號，如果傳輸?shù)氖堑谝粋€數(shù)據(jù)包，則表示數(shù)據(jù)包傳輸開始；如果傳輸?shù)氖侵虚g的數(shù)據(jù)包，則表示數(shù)據(jù)包繼續(xù)傳輸；如果接收到的是最后一個數(shù)據(jù)包，則表示數(shù)據(jù)包傳輸完成。
CRC校驗和的主要作用是便于DSP比較數(shù)據(jù)傳輸之前的檢驗和與自己根據(jù)接收到的數(shù)據(jù)計算出來的校驗和是否一致，借此判斷數(shù)據(jù)傳輸過程中有無丟數(shù)現(xiàn)象發(fā)生。文件總的大小的主要作用是告知DSP需要擦除多大的FLASH空間用于存儲更新后的文件。
3.2 分包文件傳輸協(xié)議實現(xiàn)
協(xié)議的實現(xiàn)主要用到了以下幾個關鍵函數(shù)：
（1）數(shù)據(jù)包協(xié)議頭的封裝
UINT32 gfWriteLong（UINT32 x，UINT32 y）
{
*（UINT32*）x=y；
return y；
}
此函數(shù)用于封裝數(shù)據(jù)包協(xié)議頭，將數(shù)據(jù)包協(xié)議頭信息寫入相應的地址空間中。
（2）CRC校驗和算法[6]
本文采用一種按位計算的方法計算校驗和，和DSP計算出來的校驗和相比較，防止數(shù) 據(jù)傳輸過程中出現(xiàn)差錯，關鍵代碼如下：
UINT32 gfCRCCheckSum（char *ptr，unsigned long len）
{
unsigned char i；unsigned long crc=0；
while（len??！=0）
{
for（i=0x80；i！=0；i/=2）
{
if（（crc&0x8000）！=0）
{
crc*=2；
crc^=0x1021；
}
else
{
crc*=2；
}
if（（*ptr&i）！=0）
{
crc^=0x1021；
}
}
ptr++；
}
return crc；
}
（3）應答機制
應答機制的作用是得到DSP接收完一個數(shù)據(jù)包之后反饋回來的信息（用數(shù)值表示），如為數(shù)據(jù)傳輸正確，則打印出提示提示語句后接著傳送下一個數(shù)據(jù)包；如為校驗和出錯，則說明數(shù)據(jù)包傳送過程中發(fā)生了丟數(shù)等現(xiàn)象，打印出語句后直接結束退出；如為FLASH更新完成，則說明所有數(shù)據(jù)包傳送完成，且正確的寫入到FLASH中了，打印出提示語句后直接結束退出；如為FLASH更新出錯，則說明所有數(shù)據(jù)包傳送完成，但沒有正確的寫入到FLASH中，打印出提示語句后直接結束退出。
關鍵代碼如下：
STATUS gfDSPACKCMD（int handle，UINT32 ACKAddress）
{
UINT32 ACKCMD；
ACKCMD=*（*ACKAddress）；
switch（ACKCMD）
{
case DSP_ACK_OK：
printf（"＼nData Packet Send Success and Data Right！＼n＼n"）；
break；
case ERROR_CHECKSUM：
printf（"＼nData packet CRC CheckSum ERROR！＼n"）；
break；
case FLASH_UPDATE_OK：
printf（"＼n＼nFlash Data Updates Over！！！＼n"）；
break；
case ERROR_FLASH_DATA：
printf（"＼nFlash data write error！＼n"）；
break；
default：
printf（"＼nAcknowledge command word error！＼n"）；
break；
}
return OK；
}
4 實際應用
基于以上分析研究，編寫了相應的程序，并在數(shù)據(jù)采集系統(tǒng)中進行了多次試驗，試驗結果如表1所示，從試驗結果可以看出，本文所介紹的方法可以保證數(shù)據(jù)傳輸?shù)臏蚀_性，滿足了DSP程序在線FLASH更新的需求。
表1 FLASH更新測試結果
5 結 論
本文結合實際項目開發(fā)過程中遇到的實際問題，概述了一種 VxWorks下簡單文件傳輸?shù)脑砗途唧w的軟件實現(xiàn)方法。實際應用證明，按照此種方式編寫的程序代碼簡單，實用，可以很好的進行文件數(shù)據(jù)分包傳輸。
參考文獻
[1] 李署東，吳昊，杜祝.VxWorks下點對點簡單文件傳輸?shù)膶崿F(xiàn)[J].中國水運，2011，11（1）：84?87.
[2] 唐曉平.VxWorks在cPCI高速數(shù)據(jù)采集系統(tǒng)中的應用研究[D].長沙：國防科學技術大學，2008.
[3] 黃世權.FTP協(xié)議分析和安全研究[J].微計算機信息，2008，24（2?3）：93?94.
[4] 馮先成，李寒，張鐵男.基于MPC850 VxWorks系統(tǒng)的BSP設計[J].計算機與數(shù)字工程，2012，40（6）：39?43.
關鍵詞：FTP； Struts2； Web
Abstract: the application Struts2 framework to build FTP access to services Web platform, and to realize the FTP file to traverse and check.
Keywords: FTP; Struts2; Web
中圖分類號： TU323.5 文獻標識碼：A文章編號：
前言
文件傳輸協(xié)議（File Transfer Protocol，簡稱FTP）是TCP/IP網(wǎng)絡上計算機之間相互傳送文件的協(xié)議[1]，具有資源共享，管理方便等優(yōu)點。在傳統(tǒng)的C/S結構中，用戶需要借助客戶端軟件（如FileZilla、CuteFTP等）來訪問FTP服務器。隨著信息技術的發(fā)展，系統(tǒng)和應用都在不斷推陳出新，這些軟件的穩(wěn)定性和兼容性將面臨考驗。
本文設計的平臺充分利用Java程序跨平臺性的特點，并采取基于MVC的Web應用開發(fā)框架Struts2, 在B/S結構的基礎上應用了文件傳輸協(xié)議, 使用戶在訪問FTP時更方便和有效。
一、框架簡介
Struts 是Apache軟件基金會贊助的一個開源項目[2]。它通過采用 Java Servlet/JSP 技術，實現(xiàn)了基于Java EE Web應用的MVC設計模式的應用框架。
MVC將軟件系統(tǒng)分為三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。Struts 框架清楚地展現(xiàn)MVC模型的特性[3]：
1） Controller：當用戶在客戶端發(fā)出請求以后，ActionServlet將負責分配該請求，通過查詢配置文件struts.xml中的ActionMapping映射，找到用來處理請求的Actition類；
2） Model：表單內(nèi)容被提交到ActionForm，由相應的Actition類來處理數(shù)據(jù)，通過帶有封裝的方法和屬性的Bean來執(zhí)行業(yè)務邏輯，然后Actition將處理結果返回給ActionServlet；[4]
3） View：根據(jù)Action返回的字符串將結果返回到JSP交互頁面。
設計思路
1 建立工程
在Java的web項目中添加與Struts2相關的Jar包，以及訪問FTP所需的類庫（commons-net.jar）。
2 設計交互頁面
頁面名稱 功能描述
LoginFTP.jsp FTP登錄頁面
FileList.jsp 資源列表頁面
ReadFile.jsp 文本顯示頁面
3 編寫控制層
類名 功能描述
ReadFileAction.java 控制文本讀取
LoginAction.java 控制用戶登錄
4 實現(xiàn)業(yè)務邏輯
類名 功能描述
MyFtpClient.java 實現(xiàn)對FTP的訪問
TextReader.java 讀取文本文件
SpecialStr.java 字符編碼處理
其中，MyFtpClient類的算法抽象如下：
public class MyFTPClient {
/**登錄方法*/
public void login(String hostName, String userName, String password) {
// 連接到主機名為hostName的ftp服務器
// 輸入用戶名userName和密碼password進行驗證
}
/**遍歷方法*/
public List getFileList(String remoteDir) {
// 遍歷當前目錄remoteDir下的文件和文件夾
foreach (FILE file : files) {
// 將每個文件夾和文件的記錄在List類型的fileList
}
// 返回fileList供Action和JSP使用
}
/**關閉方法*/
public void close(){
// 使用IO包關閉流斷開FTP連接
}
}
二、系統(tǒng)實現(xiàn)
1 開發(fā)環(huán)境
在 Windows 環(huán)境下運行，開發(fā)工具為Eclipse Helios Service Release 2和Tomcat 6，JDK版本為J2se 6.0。
2功能實現(xiàn)
1.使用已有FTP賬戶驗證登錄；
2.顯示文件列表，選取和查看目錄；
3.選擇文本文件進行查看,結果如圖1-1所示：
圖1-1顯示結果
三、結論
利用Java技術建立的FTP服務的訪問具有跨平臺性,采用的FTP訪問組件避免了功能組件的繁瑣編碼，使得開發(fā)人員能將更多的精力投入到業(yè)務邏輯的實現(xiàn)和數(shù)據(jù)模型的建立。在接下來的工作中，Struts2架構還可以與Spring、Hibernate等組件相結合，將滿足更多需求，具有較好的可擴展性。
參考文獻
[1] 李南方, 文件傳輸協(xié)議——FTP簡介, 《武鋼大學學報》, 1999年03期
[2] struts.省略/
[3] 官全龍, 姚國祥, 基于Struts的應用架構的研究, 《計算機工程與設計》, 2005年12期
關鍵詞：萬維網(wǎng)；WWW；HTTP；FTP；Web服務器
WWW（World Wide Web，3W，Web）中文譯名為萬維網(wǎng)，環(huán)球信息網(wǎng)等。是歐洲核物理研究中心（CERN）為全球范圍的科學家利用Internet建立在客戶機/服務器模型之上，為了方便地進行通信、交流和查詢所建立的。Internet采用超文本和超媒體的信息組織方式，將信息的鏈接擴展到整個Internet上。萬維網(wǎng)是一個分布式的超媒體（Hypermedia）系統(tǒng)，它是超文本（Hypertext）系統(tǒng)的擴充，所謂超文本是包含指向其他文檔的鏈接文本，超文本是萬維網(wǎng)的基礎，在萬維網(wǎng)中，主要使用了兩個協(xié)議，分別是HTTP協(xié)議和FTP協(xié)議。
1 HTTP協(xié)議
超文本傳輸協(xié)議（Hypertext Transfer Protocol，HTTP）提供了訪問超文本信息的功能，是萬維網(wǎng)與Web服務器之間的通信協(xié)議，屬于應用層。HTTP協(xié)議是用于分布式協(xié)作超文本信息系統(tǒng)的、通用的、面向對象的協(xié)議。可以用于傳輸各種超文本頁面和數(shù)據(jù)。
HTTP協(xié)議包括以下4個步驟：
第一，建立連接。客戶端向服務器發(fā)出建立連接HTTP報文的請求，服務端將響應發(fā)送回客戶端，連接建立。
第二，發(fā)送請求。客戶端按照HTTP協(xié)議通過連接線路向服務端發(fā)送請求。
第三，給出應答。服務器按照客戶端的要求給出應答，將結果HTML文件返回給客戶端。
第四，關閉連接。客戶端接到HTTP報文請求后關閉連接。
HTTP協(xié)議是基于TCP/IP之上的協(xié)議，它不僅保證是否能夠正確傳輸超文本文檔，而且還要確定傳輸文檔中的哪一部分，以及哪部分內(nèi)容首先顯示等。通常HTTP報文消息包括客戶向服務器的請求報文和服務器向客戶的響應報文。這兩種類型的報文消息由一個起始行，一個或者多個頭域，一個指示結束的空行和消息體組成。HTTP的報文結構包括通用首部、請求首部、響應首部、實體首部和實體主體五個部分。每個頭域由，和三部分組成。（注意：域名與大小寫無關，可以在域值前添加任何數(shù)量的空格符，可將萬維網(wǎng)的頭域擴展為多行。）
通用域名首部包含請求和響應報文，其中的頭域還包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via等。對通用頭域的擴展要求通訊雙方都支持，如果存在不支持的通用頭域，一般將會作為實體處理。
一次HTTP操作其工作過程可分為以下幾步：
第一，瀏覽器分析鏈接指向頁面的URL。
第二，瀏覽器向DNS請求解析IP地址。
第三，域名系統(tǒng)DNS解析出微軟服務器的IP地址。
第四，瀏覽器與該服務器建立TCP鏈接。
第五，瀏覽器發(fā)出HTTP請求GET。
第六，服務器通過HTTP響應把文件index.heml發(fā)送給瀏覽器。
第七，TCP連接釋放。
第八，瀏覽器將文件index.heml進行解釋，并將Web頁顯示給用戶。
如果在以上過程中的某一步出現(xiàn)錯誤，那么產(chǎn)生錯誤的信息將返回到客戶端，由顯示屏輸出。對于用戶來說，這些過程是由HTTP自己完成的，用戶只要用鼠標點擊，等待信息顯示就可以了。HTTP采用TCP作為運輸層協(xié)議，保證了數(shù)據(jù)的可靠傳輸，HTTP不需要考慮數(shù)據(jù)在傳輸過程中丟失后是怎樣重傳的，但是HTTP協(xié)議本身是無連接的，即通信雙方在交換HTTP報文之前不需要先建立HTTP鏈接。
2 FTP協(xié)議
文件傳輸協(xié)議（File Transfer Protocol，F(xiàn)TP）是因特網(wǎng)上使用最廣泛的文件傳輸協(xié)議，F(xiàn)TP運行在TCP上采用客戶/服務器模型，包括兩個組成部分，分別為FTP服務器、FTP客戶端。其中FTP服務器用來存儲文件，用戶可以使用FTP客戶端通過FTP協(xié)議訪問位于服務器上的資源。FTP使用20和21這兩個端口，如果采用主動模式，那么數(shù)據(jù)傳輸端口就是20；如果采用被動模式，數(shù)據(jù)傳輸端口就是21。
FTP提供以下功能：
第一，提供不同種類的主機系統(tǒng)之間的傳輸。
第二，使用戶對遠程服務器上的文件進行管理。
第三，提供文件共享能力。
另FTP還有兩種模式，主動方式Standard（PORT方式），被動方式Passive（PASV方式）。Standard模式下FTP客戶端發(fā)送PORT命令到服務器。Passive模式下FTP的客戶端發(fā)送PASV命令到FTP Server。
Port：FTP客戶端與服務器的21端口建立控制連接，用來傳輸控制信息，客戶端發(fā)送請求，通過控制連接發(fā)送給服務器端的控制進程。服務器通過自己的數(shù)據(jù)連接端口連接至客戶端的指定端口并發(fā)送數(shù)據(jù)。
FTP服務器在很多情況下是不支持PASV模式的，因為很多防火墻在設置時，是不允許接受外部發(fā)起連接的，因而位于防火墻后或內(nèi)網(wǎng)的客戶端無法穿過防火墻打開FTP服務器的高端端口，故許多內(nèi)網(wǎng)的客戶端不能用PORT模式登陸FTP服務器，造成無法連接。
文件交換協(xié)議（File Exchange Protoco，F(xiàn)XP）相當于是FTP的控制器，也可以認為FXP本身其實就是FTP的一個子集，使一個FTP客戶端控制兩個FTP服務器，在兩個服務器之間傳送文件。FTP協(xié)議的任務是使計算機將文件傳送至另一臺計算機，它與這兩臺計算機所處的位置、聯(lián)接的方式、是否使用相同的計算機操作系統(tǒng)均沒有關系。例如，兩臺計算機通過FTP協(xié)議連接，并且能夠成功地訪問Internet，用戶就可以使用FTP命令來傳輸文件。
其傳輸方式可分為兩大類：ASCII傳輸和二進制數(shù)據(jù)傳輸。
ASCII傳輸模式：若客戶端當時正在拷貝的文件中包含的簡單ASCII碼，在機器上運行的是不同的操作系統(tǒng)，當文件傳輸時，F(xiàn)TP協(xié)議通常會自動地調(diào)整文件的內(nèi)容以便于將文件“翻譯”成另一臺計算機存儲的文本文件格式，就是我們通常所說的翻譯。但是時常會有這樣的情況發(fā)生，用戶正在傳輸?shù)奈募牟皇俏谋疚募鼈兛赡苁浅绦颉?shù)據(jù)庫、字處理文件或者壓縮文件等信息。那么這時，ASCII傳輸模式則會消耗大量的時間、資源進行翻譯，與我們所希望的相去甚遠，于是，出現(xiàn)了第二種傳輸方式，二進制傳輸。
參考文獻：
[1] 沈紅，李愛華.計算機網(wǎng)絡（第二版）[M].清華大學出版社，2010.
[2] 謝希仁.計算機網(wǎng)絡（第5版）[M].電子工業(yè)出版社，2011.
作者簡介：周開強（1993―），男，黑龍江慶安人。
1 物聯(lián)網(wǎng)
物聯(lián)網(wǎng)主要指的是末端設施和設備,主要包括工業(yè)系統(tǒng)、傳感器以及貼在射頻識別器上各種設備、攜帶無線終端的車輛和個人等。通過各種無線、有線,長距離或短距離的相互連通實現(xiàn)對數(shù)據(jù)傳輸。物聯(lián)網(wǎng)就是利用傳感器,實時對需要的數(shù)據(jù)進行采集、互動、連接,采集的信息的類型可以是電信號、光信號、化學信號等,利用各種可能存在的網(wǎng)絡接入,實現(xiàn)物與人、物與物之間的連接,從而實現(xiàn)對物品的智能化管理和識別。因此,可以簡單的將物聯(lián)網(wǎng)描述為,利用傳感器獲取物理環(huán)境信息,然后利用通信網(wǎng)絡對信息進行傳遞,再利用云計算平臺,實現(xiàn)對復雜信息的處理。
2 系統(tǒng)的設計與實現(xiàn)
2.1 設計方案
系統(tǒng)的具體實現(xiàn)方案:在測井現(xiàn)場利用傳感器獲取待測油井的數(shù)據(jù),將數(shù)據(jù)利用專用的電量將測得護具傳送給計算機,然后利用計算機對數(shù)據(jù)進行處理后,利用GPRS將傳遞到企業(yè)內(nèi)部,數(shù)據(jù)最終將會被送到測控中心,從而實現(xiàn)對數(shù)據(jù)的遠程傳輸
2.2 網(wǎng)絡傳輸協(xié)議
利用GPRS對數(shù)據(jù)進行傳輸面臨協(xié)議選擇,TCP和UDP是目前應用最廣泛的兩種協(xié)議,對協(xié)議的選擇需要依據(jù)系統(tǒng)運行的實際情況而定。TCP協(xié)議數(shù)據(jù)的傳遞面向連接具有較高的可靠性,比較適合應用在順序不重復、大批量的數(shù)據(jù)傳遞。但需要注意,TCP提供的數(shù)據(jù)傳輸不會對數(shù)據(jù)的便捷進行記錄,因此如果數(shù)據(jù)傳遞過程中采用的方式是數(shù)據(jù)包,需要對包的同步問題加以考慮。測井在數(shù)據(jù)傳遞過程中對數(shù)據(jù)量的要求較大,同時網(wǎng)絡環(huán)境十分復雜。此外,從目前的情況來看,在實際測試過程中,如果對TCP協(xié)議進行利用,數(shù)據(jù)在吞吐率上完全可以滿足使用要求。UDP協(xié)議與TCP相比更加簡單,靈活度高,建立連接較為容易,會對數(shù)據(jù)的邊界進行保留。其最大的不足它提供的數(shù)據(jù)包通信的方式并不可靠,在復雜的網(wǎng)絡環(huán)境下的應用要十分謹慎,如果程序對出現(xiàn)的問題處理不當,可能會造成協(xié)議崩潰,從而導致系統(tǒng)無法正常運行。
2.3 測試通訊方案
為了對系統(tǒng)的可行性進行驗證,在中國聯(lián)通和中國移動兩種網(wǎng)絡的支持下對數(shù)據(jù)的傳輸效果進行驗證。在數(shù)據(jù)驗證過程中,利用自行編程的通訊程序對油田實地進行測試。測試過程中主要涉及到的性能有:RTK、吞吐量、時延、誤幀率的平均值。根據(jù)測試結果對公眾移動網(wǎng)絡是否滿足傳輸需求進行確定。同時,可以通過現(xiàn)場測試了解用戶要求,使其為通訊協(xié)議設計提供參考。
2.4 設計通訊協(xié)議
(1)雙發(fā)送隊列。
石油測井數(shù)據(jù)傳輸系統(tǒng),不僅要能夠實現(xiàn)對測井中數(shù)據(jù)的傳遞,同時還應當實現(xiàn)文件的傳輸。測井數(shù)據(jù)傳輸在實時性上具有較高的要求,在文件的傳輸上實時性要求相對則較低,一般來說能夠在規(guī)定的一段時間內(nèi)完成文件傳輸即可。因此,在實際工作中,如果傳輸數(shù)據(jù)的寬帶有限,為了確保測數(shù)據(jù)傳遞的實時性,應當對測井數(shù)據(jù)和文件傳輸兩者制定相應的優(yōu)先級機制。方案如下:將發(fā)送隊列分為兩列,一列為測井數(shù)據(jù),另一列則為文件傳輸隊列,同時應當在文件傳送隊列上安置一個標志,對發(fā)送權限進行限制,該標志只有則測井數(shù)據(jù)發(fā)送結束后,才會生效,標志生效后,文件傳送隊列發(fā)送數(shù)據(jù),然后安置的標志將會再一次回到原位置,依次循環(huán)。
(2)后退N幀協(xié)議。
在數(shù)據(jù)傳輸過程中,如果采用簡單的協(xié)議,RTT的時延一般約為500ms,這對數(shù)據(jù)傳輸?shù)膶崟r性產(chǎn)生了一定影響,為了提高通訊協(xié)議效率,可以對后退N幀協(xié)議進行應用,這種協(xié)議處于非受限協(xié)議和等停協(xié)議之間,對其進行應用可以緩解因為傳輸距離過大,導致等停協(xié)議效率低問題的發(fā)生。后退N幀協(xié)議一般只在測井數(shù)據(jù)中使用,并不在文件傳輸中使用,對于文件傳輸?shù)木S護有更高層的ZMOG協(xié)議完成,在線程發(fā)送上只是簡單進行發(fā)送,并不會進行等待和確認。測井數(shù)據(jù)傳輸系統(tǒng)在通訊上需要是雙向的,因此在實際工程中,必須是由接收線程和發(fā)送線程兩者相互系統(tǒng)工作,接收線程和發(fā)送線程兩者之間的信息要能相互傳遞,其中最重要的一點就是,接收線程應當能夠將ARQ應當信號傳送給發(fā)送線程,從而確保發(fā)送線程在運行過程中能夠順利完成發(fā)送任務,確保整個系統(tǒng)的安全運行。
［關鍵詞］數(shù)字圖書館元數(shù)據(jù)對象數(shù)據(jù)856字段
一、傳統(tǒng)圖書館向數(shù)字圖書館的過渡
隨著計算機網(wǎng)絡技術及應用的發(fā)展和普及，讀者獲取信息和交流信息的方式發(fā)生了極大的變化。在數(shù)字化圖書館的構建中，數(shù)據(jù)資源應當包括兩個基本組成部分：元數(shù)據(jù)和對象數(shù)據(jù)。
元數(shù)據(jù)包包含的內(nèi)容是對原始信息資源（即對象數(shù)據(jù)）的描述，其作用是使用數(shù)據(jù)用戶能夠通過檢索對相關原始信息資源進行選擇和定位，并提供調(diào)取對象數(shù)據(jù)的手段，例如以ISO2709格式存放的各種文獻信息和非文獻信息。對象數(shù)據(jù)包括印刷文獻的數(shù)字化圖像、各種含有輸出格式控制信息的數(shù)字化文檔、其它圖像、聲音、錄像信息。
二、856字段在元數(shù)據(jù)中的應用
在數(shù)字圖書館中，如何把元數(shù)據(jù)與對象數(shù)據(jù)進行有機的結合呢？其結合點又在哪里呢？我們知道，數(shù)據(jù)格式的標準化是數(shù)據(jù)得以交流和共享的基礎，圖書館所積累的數(shù)據(jù)資源能否跨平臺遷移，關鍵要解決標準的問題，因此，擴充機讀目錄格式，增加856電子資源定位字段以連接元數(shù)據(jù)和對象數(shù)據(jù)，就是解決這一問題的關鍵。
856字段，電子資源定位與檢索(Electronic Location and Access)包括定位與檢索電子資源所需要的信息。當文獻資源或其子集可以通過電子方式獲取時，可在書目記錄中啟用856字段。另外，該字段也可用于定位與檢索書目記錄中著錄的非電子資源的電子版或其相關的電子資源。856字段應當屬于元數(shù)據(jù)，在CNMARC中，沒有關于此字段的定義，但我們可以根據(jù)UNIMARC進行擴充，以滿足對電子資源訪問的需要。
對于856字段，具體定義如下：
指示符1：用來定義電子資源的檢索方法。如果電子資源可以通過多種檢索方法獲取，那么該字段可以重復。
#無信息提供
指沒有提供關于檢索方法的信息。
0電子郵件 (Email)
指通過“郵件傳輸協(xié)議”(Mail Transfer Protocol，簡稱MAIL TP)檢索電子資源。
1文件傳輸協(xié)議 (FTP)
指通過“文件傳輸協(xié)議”(File Transfer Protocol，簡稱FTP)方式檢索電子資源。
2遠程登錄(Telnet)
指應用Telnet等遠程登錄方式檢索電子資源。
3撥號入網(wǎng)(Dial-up)
指通過傳統(tǒng)的電話撥號入網(wǎng)方式檢索電子資源。
4超文本傳輸協(xié)議(HTTP)
指通過超文本傳輸協(xié)議(Hypertext Transfer Protocol，簡稱HTTP)檢索電子資源。
7檢索方法在$y中說明
電子資源的檢索方法不是通過定義的指示符值來表示，而是通過記錄在子字段$2的標識性代碼識別。
指示符2：未定義，空位
現(xiàn)就一些常用字段應用作以介紹。
$b檢索號碼 (有則必備，可重復)
包含與主機相關的檢索號碼。如果文獻是Internet資源，它指的是互聯(lián)網(wǎng)協(xié)議地址(Internet Protocol，簡稱IP)；如果用電話撥號上網(wǎng)，它指的可能是電話號碼。這一數(shù)據(jù)不是靜態(tài)地存儲在某一地方，而是經(jīng)常變化且可以由系統(tǒng)自動生成。
例 856 3#$alocis.loc.gov$b140.147.254.3$mlconline@loc.gov$t3270$tline mo
de (e.g.，vt100)$vM-F 06:00-21:30 USA EST， Sat. 08:30-17:00 USA EST， Sun.13:00-17:00 USA EST
注： 本字段是利用電話撥號入網(wǎng)方式獲取電子資源的實例。包含主機域名（$a）、IP地址（$b）、用戶可以和資源提供者聯(lián)系的email地址（$m）、仿真終端（$t）和檢索時間（$v）等信息。
$d路徑 (有則必備，可重復)
$d包含的路徑信息用于說明文件存儲位置的邏輯目錄與子目錄名稱的序列。
$f電子文件名稱 (有則必備，可重復)
$f包含存儲在子字段$d指定的目錄/子目錄下的電子文件名稱。
例 856 1#$d/pub/EIS/vol*no*/adobe$f*.pdf$lanonymous$qapplication/pdf
注： $d記錄路徑，$f記錄文件名稱，$o記錄操作系統(tǒng)，$i記錄登錄信息，此處為匿名登錄，$q記錄文件的格式類型。
三、856字段的實現(xiàn)方式
以MARC記錄格式為基礎，通過856字段描述網(wǎng)絡化電子資源的特性、連接方式和提取操作要求。MARC是圖書館描述、存儲、交換、處理以及檢索信息的基礎，經(jīng)過不斷發(fā)展已被圖書館用來描述和存取電子信息資源， 856字段可利用MARC記錄描述網(wǎng)絡化電子資源(包括網(wǎng)頁、電子期刊、telnet系統(tǒng)、FTP站點等)的特征、連接方式和提取要求。
網(wǎng)絡用戶通過瀏覽器各種元數(shù)據(jù)輸出結果，都將采用動態(tài)頁面方式產(chǎn)生，傳送到用戶端的信息格式符合HTML語言的基本規(guī)范。為改善顯示效果而嵌入的特殊內(nèi)容，可以采用三種方式：ASP、JAVA SCRIPT或ACTIVE X控件。
對于各種數(shù)字資源，目前比較成熟的技術解決辦法是：
數(shù)字視頻文件：各種視頻信息采集，并通過在頁面文件中嵌入ActiveMovie對象定義，實現(xiàn)以Web頁面方式實時傳輸，實時播放視頻流式文件。
數(shù)字音頻文件：各種音頻信息采集，并通過頁面文件中嵌入ActiveMovie對象定義，實現(xiàn)以Web頁面方式實時傳輸，實時播放音頻流式文件。
連續(xù)多幅圖像文件：各種圖像信息采集，并通過頁面文件中嵌入Java Script定義信息，以Web頁面方式分頁（幀）傳輸圖像，并可翻頁或查看指定頁（幀）。
電子圖書：利用快速掃描儀，將多頁圖書正文打包形成PDF文件。
通過這種處理，圖書館就能夠在原有元數(shù)據(jù)的基礎上，通過856字段這個切入點，把相關的對象數(shù)據(jù)（電子資源）連接起來，并且，在查找到相關的元數(shù)據(jù)信息（例如書目信息）之后，就可進入相關鏈接，訪問其數(shù)字資源，一步到位地滿足讀者的信息需求。
參考文獻
［1］《中國機讀目錄格式使用手冊》，北京圖書館，華藝出版社.
一、流媒體技術的傳輸方式
流媒體技術的傳輸方式主要有兩種，一種是順序流式傳輸，主要是指利用超文本傳輸協(xié)議傳送文件的傳送方式；另一種就是實時流式傳輸，指實時廣播，或者是應用實時流協(xié)議等的傳輸方式。
1.順序流式傳輸方式順序流式傳輸方式就是指按順序下載多媒體文件數(shù)據(jù)包，在下載文件的同時用戶可觀看在線內(nèi)容，但在給定時刻，用戶只能使用已下載的多媒體文件部分，并不可以跳轉到尚未下載的部分。由于標準的HTTP服務器也可以進行順序流式傳輸，而且還不需要其他特殊的協(xié)議，所以順序流式傳輸也被稱作HTTP流式傳輸。另外，由于用戶通過順序流式傳輸方式下載的多媒體文件是無損下載，加上這種傳輸方式需要用戶在使用多媒體文件前必須通過時延，所以這種傳輸方式多用于高質(zhì)量的短片段，如片頭、片尾和廣告，保證播放的最終質(zhì)量，并不適合長片段和有隨機訪問要求的情況，如講座、演說與演示；也不支持現(xiàn)場廣播，所以在一定程度上，順序流式傳輸方式屬于點播技術。
2.實時流式傳輸方式在采用實時流式傳輸方式傳送文件的時候，需要進行實時傳送，所以這種傳輸方式最為適合現(xiàn)場廣播和隨機訪問，用戶根據(jù)自身的實際情況快進或后退，觀看自己需要或感興趣的內(nèi)容的內(nèi)容。但采用這種方式傳輸多媒體文件時，需要保證媒體信號帶寬和網(wǎng)絡連接相互匹配，這樣，傳輸?shù)亩嗝襟w文件內(nèi)同才可以進行實時使用，但這也意味著圖像的質(zhì)量較差。
二、目前流媒體技術的應用狀況
1.遠程教學流媒體技術的應用為遠程教學提供了聲音和音頻，通過增添學習內(nèi)容的趣味性，激發(fā)學生的學習興趣，解決了傳統(tǒng)的單一性等負面問題。教師在教學過程中，通過在線播放與教學內(nèi)容相關的視頻，把傳統(tǒng)的教學模式多樣化，而學員也能夠針對自身的不足，自由地選擇想要學習的內(nèi)容或章節(jié)，提高學生學習主觀能動性的同時也能夠節(jié)省學生的學習時間。另外，流媒體技術的應用也能夠提高遠程教學的互動性，師生不僅能夠相互溝通，學生之間也能夠相互交流學習經(jīng)驗。最后，部分大型或跨國企業(yè)也可以通過遠程教學，對員工進行教育和培訓，這些都是歸功于流媒體技術的應用和發(fā)展。
2.直播網(wǎng)絡視頻隨著時代的進步，流媒體技術已經(jīng)成為第四代媒體技術之一。加上網(wǎng)絡傳播的全球性、快捷性，有很多大型的新聞娛樂媒體都趁著這個時機，通過互聯(lián)網(wǎng)提供視頻的直播，其中，流媒體技術的發(fā)展為在網(wǎng)絡上直播視頻提供了極大的幫助。目前流媒體的視頻直播應用突破了網(wǎng)絡帶寬的限制，實現(xiàn)了多媒體文件的高質(zhì)量影音傳輸，令不論是什么環(huán)境的用戶都可以隨時隨地通過網(wǎng)絡，利用媒體技術觀看多媒體信息。
3.進行電視電話會議如今經(jīng)濟全球化，不少跨國企業(yè)的高層管理都通過視頻會議商討企業(yè)的發(fā)展前景，而視頻會議系統(tǒng)是指通過互聯(lián)網(wǎng)或其它數(shù)據(jù)網(wǎng)絡，雙方進行視頻或語音開展的一種交互式多媒體通信業(yè)務。視頻會議系統(tǒng)與流媒體技術應用相結合，可以充分利用流媒體技術的可訪問性、可擴展性以及對帶寬的有效利用性，實現(xiàn)視頻會議內(nèi)容的廣播和錄播，滿足視頻會議的如上需求。
三、結語
做為一種具備極高數(shù)據(jù)傳輸率的無線技術，UWB（Ultra Wideband，超寬帶）已被提出多年。但是直到現(xiàn)在，眾多廠商也還不能夠就其標準達成一致，同時沒有任何UWB產(chǎn)品上市。今年晚些時候在UWB開始嵌入到從PDA到數(shù)碼相機的任何數(shù)字設備之中時，這種情況或會發(fā)生變化。但可能不會只有一種標準存在，至少目前將有兩種標準，這意味著即使消費者的移動電話和手提電腦都嵌入了對UWB的支持，它們之間可能也無法直接通訊。
由于在UWB的標準上兩個競爭的集團一直在推動各自的建議，IEEE為UWB發(fā)展統(tǒng)一標準（802.15.3a）的努力已經(jīng)陷入僵局兩年之久。這種競爭可能會導致其中一種標準獲勝，也可能使雙方達成某種妥協(xié)，但在UWB上似乎達成妥協(xié)沒有可能：兩個集團都在推動自己技術的發(fā)展，都展示了自己的原型樣機，并在年初獲得了FCC的批準。
UWB論壇是第一個展示可運行系統(tǒng)并獲得FCC批準的集團，該論壇由摩托羅拉倡導，成員有100多家，大多為小型公司。另一個競爭集團WiMedia聯(lián)盟則較晚展示了其系統(tǒng)，該集團只有35家成員公司，但基本都是些在業(yè)內(nèi)有影響力的企業(yè)。該聯(lián)盟由Intel發(fā)起，吸引了包括諾基亞、索尼和惠普在內(nèi)的其他一些主要供應商。論壇和聯(lián)盟都允諾了相似的性能，即在數(shù)英尺距離上提供500Mbps數(shù)據(jù)傳輸速率，但在物理層和MAC層上，兩個標準具有很大不同。
即使硬件產(chǎn)品可以同時支持兩種版本的UWB（目前還沒有廠家做出此承諾），但在應用層上，兩種標準的協(xié)同工作仍然存在問題。大多數(shù)UWB建議者的遠期目標是將連接PC與顯示器、DVD碟機與電視機等線纜連線變成為無線連接。短期來看，主要應用還將注重于文件傳輸、便攜電腦之間傳遞PowerPoint演示文檔或從數(shù)碼相機上傳照片。僅就WiMedia來看，在其上運行的文件傳輸協(xié)議至少有不同三種。
到目前為止，WiMedia聯(lián)盟只展示了一種應用層協(xié)議：無線USB，該協(xié)議同樣主要由Intel提出。對于其他協(xié)議的計劃仍在進行當中。例如WiMedia上的本地IP，以及IEEE1394（又稱為火線，最初由蘋果公司提出，是USB的一種競爭方案）在WiMedia上運行的無線版本。USB和火線之間的不兼容問題已經(jīng)持續(xù)多年，這使得很多高端PC只能同時容納兩種接口。消除線纜可能會使這種問題更加激化，因為這同時會消除兩種規(guī)范對應的物理接口，而正是不同的物理接口才使用戶能夠分辨使用的是哪種規(guī)范的接口。
關鍵詞 流媒體;點播;構建
中圖分類號 G206文獻標識碼 A文章編號 1674-6708(2010)17-0004-02
隨著網(wǎng)絡技術的飛速發(fā)展,校園網(wǎng)絡帶寬不斷拓展,網(wǎng)絡的應用更加豐富,網(wǎng)絡信息已經(jīng)從原來只用文本、圖像、聲音文件,發(fā)展到視/音頻信號組合等大容量形式文件。近年來,流媒體技術的成熟與廣泛應用,使這些文件的播放更加方便、快速、流暢,并實現(xiàn)了教學資源、會議、講座通過網(wǎng)絡直播、點播,使學生可以隨時隨地根據(jù)自己需要,選擇學習自己感興趣的知識,改變了網(wǎng)絡教育的傳統(tǒng)模式,促進遠程教學、網(wǎng)絡教學的發(fā)展上了一個新的臺階。
1 流媒體技術簡介
流媒體技術也稱流式媒體技術,就是把連續(xù)的視/音頻信息經(jīng)過壓縮處理后放上網(wǎng)站服務器,讓用戶一邊下載一邊觀看、收聽,而不要等整個壓縮文件下載到自己的計算機上才可以觀看的網(wǎng)絡傳輸技術。流媒體在播放前并不需要下載整個文件,只將開始部分內(nèi)容存入內(nèi)存,等待幾秒或十幾秒后,流媒體數(shù)據(jù)流隨時傳送隨時播放,所以,在播放過程中用戶避免了等待整個文件全部從Internet/Intranet上下載完成才能觀看的缺點。
目前,比較流行流媒體技術及產(chǎn)品主要有三大“流派”:一是Real Networks公司的Real Media;二是蘋果公司的QuickTime;三是微軟的Windows Media。其中Windows Media 與Windows集成在一起,使用方便,用戶最為廣泛。它主要包括Media Tools,Media Services和Media Player3部分:Media Tools提供了一系列的流處理工具,Media Services是流媒體服務器端的程序,它支持單播、組播、廣播和點播等多種媒體播放方式;Media Player是客戶端的播放應用程序,它負責媒體的播放,主要文件格式有.asf和.wmv等。
Windows Media技術提供了一系列流式媒體服務工具,用以創(chuàng)建、制作、、播放和管理等一整套解決方案,還免費提供了開發(fā)工具包(SDK)代二次開發(fā)使用。為網(wǎng)絡流媒體播放系統(tǒng)組建提供了極大的便利。本文就以運用Windows Media軟件,提供流媒體點播解決方案。
2 網(wǎng)絡VOD傳輸方式
VOD (Video On Demand)即視頻點播技術的簡稱。視頻點播是計算機技術、網(wǎng)絡技術、多媒體技術發(fā)展的產(chǎn)物,是一項全新的信息服務。它擺脫了傳統(tǒng)視頻受時空限制的束縛,解決了一個想看什么節(jié)目就看什么,想何時看就何時看的問題。VOD常用的傳輸方式主要有兩種,一種是順序流式傳輸,另一種是實時流式傳輸。
2.1順序流式傳輸
順序流式傳輸是順序下載,在下載文件的同時用戶可以觀看,而且用戶只能觀看已下載的那部分,而不能要求跳到還未下載的部分。順序流式文件可以放在標準HTTP或FTP服務器上,可用標準HTTP服務發(fā)送,而不需要特殊協(xié)議,它不支持現(xiàn)場廣播。
2.2實時流式傳輸
實時流式傳輸中,音視頻信息可被實時觀看到。即用戶想從那開始看就可以從那開始看,在觀看過程中用戶可快進或后退以觀看前面或后面的內(nèi)容。實時流傳輸與順序流式傳輸不同,它需要專用的流媒體服務器與傳輸協(xié)議,如QuickTime Streaming Services、Real Services與Windows Media Services。這些服務器允許你對媒體發(fā)送進行更多級別的控制,因而系統(tǒng)設置、管理比標準HTTP服務器更復雜。實時流式傳輸還需要特殊網(wǎng)絡協(xié)議,如:RTSP (Real time Streaming Protocol)或MMS (Microsoft Media Services)。
順序流傳輸?shù)膶崿F(xiàn)方法簡單,但播放進程只能按順序從頭到尾,在網(wǎng)絡教學應用中不能控制。比如,對于重點難點,老師需要反復播放某一片段的內(nèi)容,采用順序流就無法實現(xiàn)了。為了克服這一缺點,我們利用微軟的Windows Media,實現(xiàn)實時流點播,使校園網(wǎng)中教師與學生都可以控制視/音資源,以將豐富的教學素材引入到課堂,有利于學校教學資源網(wǎng)絡化。
3 校園網(wǎng)實時流VOD系統(tǒng)開發(fā)
我們要求校園網(wǎng)絡中的多媒體數(shù)據(jù)以實時流形式傳輸,它與傳統(tǒng)的文件傳輸數(shù)據(jù)不同,多媒體數(shù)據(jù)一旦開始傳輸,就必須穩(wěn)定的速率傳送到用戶桌面,以保證播放效果。網(wǎng)絡擁堵、進程中斷、I/O瓶頸都可能導致傳送延遲,引起數(shù)據(jù)流傳輸阻塞。下面筆者以我校校園網(wǎng)為基礎,以Windows Media提供的系統(tǒng)軟件為例,探討流媒體點播系統(tǒng)的組建。
3.1校園網(wǎng)VOD系統(tǒng)基本功能要求
1) 可以讓一個節(jié)目在同一個時間內(nèi)供多個用戶同時點播;
2)提供全屏播放,暫停、停止、快倒、快播、跳播的功能;
3)提供A/V數(shù)據(jù)庫的增添、刪除、查詢等管理能力;
4)支持節(jié)目名的檢索,能夠以極快的速度查找到想要的資源。
3.2系統(tǒng)組成
為了滿足校園網(wǎng)VOD系統(tǒng)基本功能要求,實現(xiàn)校園網(wǎng)絡流媒體的實時流式傳輸,我校VOD系統(tǒng)主要由以下幾個部分組成,如圖1所示。
1)節(jié)目源:攝像機、電視機、VCD光盤;
2)A/V捕獲和壓縮編碼:A/V捕獲卡,編碼軟件Media Encoder,將捕獲的A/V信號進行編碼壓縮后送到多媒體播放服務器,采集格式是微軟的流媒體格式,如:.asf、.wmv等;
3)Windows Media Services:設置點播服務,運行流播放軟件播放視/音頻;
4)終端工作站:使用IE瀏覽器,用于實時點播A/V節(jié)目。
從系統(tǒng)硬件結構看,它與一般的一個點播系統(tǒng)沒什么區(qū)別,實時流的實現(xiàn)關鍵技術主要是在軟件上進行必要的設置和對播放器編碼程序進行控制。
3.3系統(tǒng)實現(xiàn)的關鍵技術
1)Windows Media Services的設置。在Windows Media Services上設置點播服務站,將要點播的視/音頻文件映射到該站點上,這是實現(xiàn)實時點播的一個技術關鍵。如果將點播視/音頻文件映射到IIS服務上,就無法實現(xiàn)對流的實時控制,只能順序流傳輸,HTTP方式只能以順序流的方式播放流媒體。
可以說,“點播”指的是一種典型的文件傳輸過程,在這個過程中,只將單獨的數(shù)據(jù)副本從源位置發(fā)送到請求該數(shù)據(jù)的每個客戶端。設置點播站后,所播放的文件實際是通過Media Services的點播站,其傳輸協(xié)議是mms,其URL由服務器名、虛擬點播站名和流文件名(*.wmv *.wma *.asf)組成。
設置 Windows Media Services 的過程極其簡單:
(1)將Windows Media 文件(*.ASF 或* .WMA)放置在運行 Windows Media 管理器的 NT Services 上的 ASFROOT 目錄中。
(2)創(chuàng)建 ASX 或 WAX 文件,該文件是頁面與 Windows Media 文件之間提供鏈接的、文本形式的元文件。對于 ASX 文件,代碼如下所示:
(4)更改 標記中的路徑,以使其指向Windows Media 文件。
(5)將該文件保存到 Windows Media 文件所在的同一個文件夾中,并將其擴展名從 .txt 更改為 .asx 或 .wax。
2)A/V節(jié)目編碼。為了使錄制視/音頻資源實現(xiàn)實時流點播,首先要對其進行編碼。在用Windows Media Encoder對節(jié)目編碼時要做注意二點,才能夠實現(xiàn)節(jié)目隨著拖動播放,一是在設置文件輸出分發(fā)時,應選擇“文件將從windows Media服務器傳輸”;二是文件保存時要選擇“將索引添加到文件”。如果沒有做到這兩點,則需要用Encoder重新處理,或者用Windows Media Tools將文件重新編輯一下。
3)終端工作站配置。在點播工作站,可以用Media Player來點播服務器中的資源,對于將Media Player嵌入網(wǎng)頁的代碼設計者可根據(jù)所用網(wǎng)頁制作軟件進行編寫。
4 結論
本文的設計實例是筆者借助于本校原來完善的局域網(wǎng)組建的流媒體點播系統(tǒng),設計、開發(fā)符合我校視頻點播的應用要求,目的就是將教學、娛樂、資訊與網(wǎng)絡集成在一起,實現(xiàn)交互和實時的管理和服務,以更好的發(fā)揮校園網(wǎng)絡的作用,改善教師教學的手段,學生自主學習的機會。
參考文獻
[1]馬武.多媒體技術及應用[M].北京:清華大學出版社,2008.
【關鍵詞】傳輸系統(tǒng);集成信息化;校驗碼;事件;監(jiān)聽機制
引言
目前，隨著企業(yè)集約化管理的需求，使用集成平臺處理業(yè)務、數(shù)據(jù)、信息已經(jīng)滲透到企業(yè)安全、生產(chǎn)各個環(huán)節(jié)。數(shù)據(jù)、文件之間共享被越來越多的集成應用系統(tǒng)所使用，如實時監(jiān)測數(shù)據(jù)文本、圖文圖紙、資料文件等，需要構建一套企業(yè)集成類信息化平臺，對作業(yè)現(xiàn)場各子系統(tǒng)數(shù)據(jù)進行集成與應用，達到實時監(jiān)視與集中調(diào)度的目標。在某些應用場景下，數(shù)據(jù)在傳輸過程中需要考慮上傳的及時性與數(shù)據(jù)的連續(xù)性，以保證對現(xiàn)場環(huán)境的實時監(jiān)視，以保證對預警和故障的及時處理;同時在應用分析過程中，需要對現(xiàn)場數(shù)據(jù)的連續(xù)性分析，以保證數(shù)據(jù)的完整性和數(shù)據(jù)分析結果的準確性。
常規(guī)的文件傳輸系統(tǒng)更適應于下行多于上行傳輸?shù)膱鼍啊６谄髽I(yè)的信息化集成平臺上，客戶端對上傳文件的需求更為強烈。客戶端存在有大量的文件需要上傳至服務器，以實現(xiàn)數(shù)據(jù)處理、解析與存儲備份及文件歸檔存儲與備份等。常規(guī)的文件傳輸系統(tǒng)有以下缺點：一、上行與下行不對等，更注重下行傳輸;二、傳輸權限不易控制，權限認證手段種類繁多，步驟繁瑣，例如FTP模式;三、對于大量小文件和頻繁傳輸?shù)膱鼍埃募鬏斝实拖拢鄶?shù)情況下需要驗證請求再傳輸。
1.實現(xiàn)目標
本文針對現(xiàn)有企業(yè)生產(chǎn)過程實時監(jiān)測與應用平臺中，基層單位小文件，多客戶端，安全高效頻繁傳輸?shù)膽眯枨螅O計一種基于TCP協(xié)議的遠程高效文件傳輸系統(tǒng)，達到數(shù)據(jù)及時、高效、穩(wěn)定傳輸，主要實現(xiàn)基于文件夾、文件創(chuàng)建事件的監(jiān)聽觸發(fā)上傳機制;一次握手，終身傳輸機制;自定義分發(fā)機制，滿足多種業(yè)務應用;分塊多線程傳輸機制提高傳輸效率;分級故障診斷等系統(tǒng)功能，同時該系統(tǒng)的核心技術亦可作為企業(yè)網(wǎng)盤的核心技術。
2.設計實現(xiàn)
系統(tǒng)基于TCP/IP技術，采用Socket方式進行設計，面向SOA的架構思路，利用windows服務實現(xiàn)在服務端提供服務，定義好數(shù)據(jù)傳輸方式，傳輸協(xié)議，數(shù)據(jù)格式，同時通過ip地址和端口進行服務訪問。客戶端通過連接服務器指定的端口進行消息交互。程序拓撲結構如圖1所示。
圖1 系統(tǒng)架構圖
系統(tǒng)設計實現(xiàn)主要利用.Net Remoting技術，在windows 服務中注冊文件傳輸服務，客戶端利用Windows應用程序實現(xiàn)，在實現(xiàn)中利用分布式的設計思想，便于程序與系統(tǒng)功能擴展。
.NET遠程處理（.NET Remoting）是微軟 .NET Framework 中的一種網(wǎng)絡通信技術，提供了一種允許對象通過應用程序域與另一對象進行交互的框架。可以使用 SOAP 以外的協(xié)議來通信，而在服務端和客戶端之間所操作的方法近乎相同，客戶端可以不必考慮使用的協(xié)議，即可訪問服務端所開放的對象。
在Remoting中是通過通道（channel）來實現(xiàn)兩個應用程序域之間對象的通信的。
客戶端通過Remoting訪問通道以獲得服務端對象，再通過解析為客戶端對象，遠程對象代碼運行在服務器上，然后客戶端再通過Remoting連接服務器，獲得該服務對象并通過序列化在客戶端運行。
3.研究內(nèi)容
3.1 統(tǒng)一權限認證體系的設計與實現(xiàn)
建立統(tǒng)一的權限認證體系，以控制文件傳輸權限，權限認證主要通過客戶端調(diào)用服務器接口進行權限認證，如果正常登陸，則進行文件同步及創(chuàng)建監(jiān)聽事件。
3.2 大文件分塊傳輸與算法設計
針對大文件傳輸特殊性要求，需要考慮對文件進行分塊多線程進行傳輸，因此需要設定文件塊大小的閾值，如512kb，小于等于512K時為小文件，反之為大文件;大文件分為多塊之后，在傳輸之前每塊均提取自身校驗碼;同時向服務器發(fā)送對應的文件基本信息及分塊信息，校驗碼與文件均進行傳輸;同時系統(tǒng)根據(jù)文件分塊個數(shù)分配多個線程的傳輸;單塊數(shù)據(jù)傳輸后，仍使用同樣的算法提取校驗碼，與原始校驗碼對比驗證以確定當前數(shù)據(jù)塊是否正確接收。各分塊傳輸完成后，根據(jù)文件塊索引，實現(xiàn)文件合并。
圖2 文件分塊傳輸邏輯圖
3.3 文件轉換庫的設計
在某些特殊情況下，需要考慮規(guī)定接收文件的格式，比如圖片類僅支持bmp、jpg、png和gif;客戶端能夠獲取格式規(guī)定，并對本地的相關文件實現(xiàn)文件轉換算法，例如傳輸圖片文件時，客戶端生成tiff格式的文件，則必須將該文件轉換為bmp、jpg、png或gif中的一種才可以上傳。對于客戶端本身操作的文件，不符合格式的文件都可以通過算法轉換為標準格式的文件。
因此在文件版?zhèn)鬏敯姹具^程中，需要考慮文件轉換庫的設計，即記錄客戶端文件名稱、文件特征碼、文件擴展名、服務端文件名稱、轉換后文件特征碼、文件擴展名，服務器在啟動過程中，掃描服務器某目錄下的文件列表名稱及校驗碼，與客戶端對應目錄文件校驗碼進行第一次比對，對服務器端不存在或不一致的文件名及校驗碼進行同步上傳，文件信息比對主要用在客戶端啟動時，其他時間主要通過文件夾或文件事件進行同步更新。
3.4 敏捷傳輸機制的設計
在傳統(tǒng)的傳輸設計過程中，主要通過時間輪詢的方式判斷某目錄下文件是否發(fā)生了變化，同時對于某些文件處于變化狀態(tài)中，然后進行對應的事件，在這種情況下既不利于文件的及時傳輸與數(shù)據(jù)的更新，也不利于程序的設計實現(xiàn)，變化中的狀態(tài)文件需要加鎖進行處理，否則會造成文件半個的傳輸或者傳輸異常。
系統(tǒng)在設計過程中采用C#中的FileSystem Watcher組件，實現(xiàn)對文件系統(tǒng)的監(jiān)視，當目錄或者文件發(fā)生增加、修改、刪除等事件完成時，進行相關的事件驅動，快速地啟動業(yè)務處理。系統(tǒng)主要針對FileSystemWatcher的Changed，Created，Deleted，Renamed等FileSystemEventArgs事件，實現(xiàn)當客戶端創(chuàng)建目錄或文件時，通過文件夾或文件創(chuàng)建成功事件，激發(fā)客戶端通過服務器端接口創(chuàng)建對應目錄或文件;當客戶端更改目錄時，通過文件夾更改成功事件，激發(fā)客戶端通過服務器端接口更改對應目錄;當客戶端刪除目錄時，通過文件夾刪除成功事件，激發(fā)客戶端通過服務器端接口刪除對應目錄及目錄中文件;
3.5 故障處理及重傳方法的設計
系統(tǒng)基于網(wǎng)絡傳輸，在傳輸過程中，難免因為網(wǎng)絡故障而導致的傳輸網(wǎng)絡中斷，在公司集成化信息平臺中，需要考慮不間斷運行，因此需要及時對網(wǎng)絡傳輸進行診斷，并提供一定的定位功能，可通過提示窗、控制臺輸出、日志記錄等多種功能提供故障定位信息，例如網(wǎng)絡中斷異常、文件轉換失敗等故障均有記錄可查，可輔助解決故障，同時根據(jù)故障狀態(tài)或故障類型將故障劃分類別，根據(jù)持續(xù)時間進行分級報警，進行窗體閃爍或語音報警提醒。
在傳輸過程中，網(wǎng)絡中斷，在傳輸中間過程會導致部分文件的中斷或不完整，在服務器端通過文件校驗對文件塊進行檢查，當發(fā)現(xiàn)文件塊出現(xiàn)傳輸錯誤則向客戶端發(fā)出錯誤回執(zhí)，進行重發(fā)。
3.6 斷點續(xù)傳的設計
由于實時監(jiān)測平臺數(shù)據(jù)完整性要求，需要對傳輸?shù)臄?shù)據(jù)保持完整性，因此需要考慮文件時間戳標識對文件進行本地化存儲，當發(fā)生網(wǎng)絡中斷時，文件暫存到本地，網(wǎng)絡通斷時，根據(jù)文件列表，依據(jù)文件的創(chuàng)建時間進行順序上傳，以保證數(shù)據(jù)有序性。
4.功能測試
測試環(huán)境采用局域網(wǎng)內(nèi)的三臺機器，一臺作為服務器，兩臺作為客戶端，分別實現(xiàn)對服務端與客戶端程序部署。
4.1 測試準備
（1）建立客戶端信息目錄庫：客戶端目錄庫存儲服務器地址、登錄賬號、密碼、共享路徑、是否自定驗證登陸。如在客戶端程序配置文件中服務器地址（192.168.1.1）、登陸賬戶（ABC）、密碼（加密源碼：123456）、共享路徑為D：＼F1;D：＼F2。
（2）服務器初始化：設定好存放路徑，如：G：＼Data。在服務器上創(chuàng)建好實際路徑，并將路徑名稱保存在配置文件中，加載轉換對應的校驗碼庫列表（主要與客戶端轉換后文件對比分析）。
（3）客戶端初始化：監(jiān)聽共享路徑為D：＼F1;D：＼F2下文件或者目錄操作事件，同時在啟動過程中，通過輸入用戶名、密碼完成權限認證后，實現(xiàn)本地目錄下文件監(jiān)聽。
4.2 過程測試
（1）初始自動同步：客戶端登陸驗證完成后，進行對應（舉例D：＼F1;D：＼F2下）目錄對應的服務器目錄進行文件校驗碼的獲取，如服務器對應G：＼Data＼ABC＼F1目錄下有一個文件D1.DOC，對應的文件校驗碼為AFCD1238，文件大小為1.32M，一個文件D2.DOC，對應的文件校驗碼為ABCD1238，文件大小為500K，F(xiàn)2目錄不存在，則根據(jù)事件創(chuàng)建F2目錄，則服務器上G：＼Data＼ABC＼F2目錄;客戶端D：＼F1下有文件D1.DOC，對應的文件校驗碼為AFFF1238，文件大小為1.32M，一個文件D2.DOC，對應的文件校驗碼為ABCD1238，文件大小為500K。D：＼F2有一個P1.TIFF文件，根據(jù)對應的文件名和校驗碼進行判斷，本次上傳F1下的D1.DOC和F2下的P1.TIFF文件;
（2）文件傳輸：對于F1下的D1.DOC文件：根據(jù)前文示例，將512kb作為劃分文件大小的標準，大于512kb的文件，按照每塊512kb大小將整個文件分割成三個文件塊之后再傳輸，傳輸完成后合成，進行保存，同時可根據(jù)服務器線程管理，啟動線程資源分配，如服務器共有1000個接收線程，有空閑上傳線程2個，則分配2個線程進行并行上傳，服務器空閑線程為0，如先傳遞先兩個512KB文件，文件傳輸完畢，則通知服務器線程回收，服務器空閑線程大于2，則單獨分配1個空閑線程進行剩余數(shù)據(jù)塊的傳輸，傳輸完成后，回收線程，所有塊均傳輸完成后，合并所有塊，完成大文件傳輸。對于F2下的P1.TIFF文件進行上傳轉換，采用SaveAs方式進行文件另存，同時將文件校驗碼記錄到對應庫中，以便于重傳判別。
（3）故障處理及重傳：傳輸過程中，通過停止網(wǎng)卡工作或斷開網(wǎng)線方式進行，系統(tǒng)進行網(wǎng)絡傳輸中斷提醒，當中斷故障持續(xù)5分鐘，進行使用日志提醒或提示窗;故障持續(xù)時間超過10分鐘則報警升級，通過語音報警箱進行提醒;同時對某一個特殊類型文件進行轉換上傳時，當文件轉換失敗進行記錄可查。
（4）其他測試：網(wǎng)絡中斷以后，文件本地化暫存的斷點續(xù)傳測試，文件進行本地化暫存，當網(wǎng)絡通以后，進行文件順序上傳。客戶端對應目錄下的文件、目錄創(chuàng)建、刪除、更新事件，服務端相關事件的響應。
（5）退出：當客戶程序退出時，與服務端消息交互，服務端進行對應退出信息的記錄，以防止客戶端用戶在文件數(shù)據(jù)傳輸過程中非法操作的追蹤。
4.3 測試結果
通過測試，該文件傳輸系統(tǒng)高效的進行了文件的傳輸，解決了傳統(tǒng)傳輸模式效率、穩(wěn)定性及可控性問題，該系統(tǒng)更適合大量小文件頻繁傳輸，有利于在企業(yè)集約化監(jiān)測監(jiān)管信息化平臺中的數(shù)據(jù)共享集成。同時，服務端文件傳輸塊的設計根據(jù)程序運行過程進行實時調(diào)整，以保證大文件所占比率在整個文件傳輸系統(tǒng)中的5%以下，從而避免過多的文件切塊傳輸與合并另存，提高文件傳輸效率。
5.總結
本文就一種高效文件傳輸系統(tǒng)的設計與實現(xiàn)展開論述，系統(tǒng)就企業(yè)集約化監(jiān)測監(jiān)管信息化平臺中的數(shù)據(jù)、文件之間共享建立了穩(wěn)定高效的傳輸通道，在項目應用起著有至關重要的作用。在后期系統(tǒng)完善中尚需要考慮服務器端的可靠性，同時實現(xiàn)基于SOAP的多種協(xié)議的傳輸以滿足越過服務器，實現(xiàn)SOCKET等被屏蔽的功能，以及建立統(tǒng)一的管理平臺，支持多語言及遠程管理功能。
參考文獻
[1]高珍珍.跨庫集成檢索系統(tǒng)中數(shù)據(jù)源連接器的半自動生成[D].北京師范大學.
[2]趙文濤，魏紅格.礦業(yè)信息異構數(shù)據(jù)庫集成模型的研究[J].工礦自動化，2008（06）.
[3]林懷恭，聶瑞華，等.基于ESB的共享數(shù)據(jù)中心的研究與實現(xiàn)[J].計算機應用與軟件，2010，5.
[4]韓建國，楊漢宏，等.神華集團數(shù)字礦山建設研究[J].工礦自動化，2013（03）.
傳統(tǒng)的視頻傳輸具有傳輸延時、抖動、丟包等缺點，在人們生活水平越來越高對網(wǎng)絡視頻的要求也越來越高的情況下，隨著視頻編碼和互聯(lián)網(wǎng)的快速發(fā)展，H.264視頻編碼標準壓縮性能良好、適應性強等特點再結合RTP協(xié)議作為質(zhì)量保證，能夠很好地解決傳統(tǒng)視頻傳輸中的缺點，保證視頻的完整、清晰、準確。實踐證明，這種結合對于自適應傳輸機制具有很好的適用性和廣闊的發(fā)展前景。
1 自適應傳輸機制的研究現(xiàn)狀
自適應傳輸機制是一種利用網(wǎng)絡技術對網(wǎng)絡動態(tài)進行測試評估，再通過調(diào)節(jié)適應機制以達到實時調(diào)整視頻傳輸速率來滿足寬帶網(wǎng)速。其原理是利用視頻接收端反饋到發(fā)送端的網(wǎng)絡動態(tài)來調(diào)整視頻傳輸以保證視頻質(zhì)量完好。
2 H.264視頻編碼標準與RTP協(xié)議的適用性探討
2.1 H.264簡介
H.264是新一代視頻編碼標準，在H.261、H.263的基礎上，通過對相關性能的改進和完善，使其具備更多特性和更優(yōu)的性能。比如，H.264的編碼效率更高，傳輸?shù)囊曨l畫質(zhì)更優(yōu)，對視頻傳輸過程中出現(xiàn)差錯能夠較快恢復等等。其性能主要在于幾個方面的改進：①運動估計多樣化，新一代H.264具有高精度估計、多宏塊劃分模式估計、多幀參考估計等特點，相比于傳統(tǒng)的視頻編碼標準，其不僅為相同的宏塊提供了不同的編碼模式使其運動矢量的數(shù)量增加，而且提高了運動矢量位移的精度，此外，為了使編碼更優(yōu)，提供了多個參考幀從中擇優(yōu)應用。②DTC變換單位變小，傳統(tǒng)的DTC變換單位多是8×8塊，但H.264以4×4塊作為DTC的變換單位，其塊的減小，使得視頻在傳輸過程中更加精確。③幀內(nèi)預測更加準確，在H.264中，塊內(nèi)提供了十幾種像素來供其進行幀內(nèi)預測，同時用已編碼像素作為參考值加權預測，從而達到預測值精準的目的。④VLC統(tǒng)一，H.264的編碼方式有兩種，一種為CABAC，即二進制算數(shù)編碼，另一種為VLC、UVLC統(tǒng)一編碼，前者較后者要復雜，但效果更佳。H.264的性能決定其能夠保證視頻傳輸?shù)馁|(zhì)量，具有良好的適用性。
2.2 RTP協(xié)議簡介
RTP協(xié)議，是目前應用最廣的服務協(xié)議，尤其在視頻或數(shù)據(jù)量大的文件傳輸中獨占鰲頭，也是最為可靠的實時傳輸協(xié)議。RTP協(xié)議實際是由RTP和RTCP構成，其中，RTP用于數(shù)據(jù)，僅僅是為了使數(shù)據(jù)根據(jù)其提供的數(shù)據(jù)源標志、負載指示等進行實時傳輸，另外，在數(shù)據(jù)接收的過程中，可以利用RTP提供的資料對接收信息進行排序或同步等。而RTCP用于控制。在大數(shù)據(jù)流或者單獨視頻下，都可進行實時質(zhì)量監(jiān)控并及時傳送相關信息，RTCP反饋的信息能夠反映出視頻在傳輸過程中是否延時或者丟包等情況，RTCP就相當于數(shù)據(jù)傳輸?shù)难劬Γ軌蚍答亴崟r的視頻傳輸是否順暢，并以此來判斷網(wǎng)絡的現(xiàn)狀。相比于其他傳輸協(xié)議，RTP協(xié)議在H.264視頻傳輸上更具優(yōu)勢，相比于UDP協(xié)議，RTP更加可靠，UDP只是針對簡單的報文傳輸，無法保證視頻傳輸?shù)耐暾院唾|(zhì)量。而TCP雖然是可靠的可連接的傳輸協(xié)議，但是其啟動慢，此外，其自身的擁塞控制和超時重傳機制不適合視頻傳輸。
3 基于RTP的H.264視頻自適應傳輸機制網(wǎng)絡端設計
基于RTP的H.264視頻自適應傳輸機制系統(tǒng)的設計主要有三個方面：服務器、網(wǎng)絡傳輸、客戶端，下文主要從網(wǎng)絡端系統(tǒng)設計進行探討。
3.1 擁塞控制算法
H.264視頻傳輸一般數(shù)據(jù)量較大，在傳輸?shù)倪^程中，容易出現(xiàn)擁堵情況，從而導致丟包、延時等現(xiàn)象發(fā)生。擁塞控制算法主要采用AIMD算法，即
3.4 結果分析
經(jīng)過實驗證明，雖然改進后的算法僅僅相對于AIMD算法稍微改進，但是其對于視頻傳輸具有重要作用，在不同的網(wǎng)絡狀況下，不僅降低丟包率，而且提高了視頻傳輸質(zhì)量。
4 結束語
視頻傳輸是時下互聯(lián)網(wǎng)的熱點，而Internet由于自身的局限，對于復雜的網(wǎng)絡狀況無法保證視頻傳輸?shù)馁|(zhì)量，因此，探索新的傳輸方式來保證視頻傳輸質(zhì)量是當下網(wǎng)絡研究的重點，自適應傳輸機制在RTP的H.264視頻雖然能夠在一定程度上解決視頻傳輸質(zhì)量問題，但還存在許多不足，仍需不斷地探索并加以改進。
參考文獻
[1]李校林，劉利權，張杰.基于RTP的H.264視頻流實時打包傳輸?shù)难芯縖J].計算機科學與工程，2012，34（5）：168-171.
[2]李瑞鋒.基于RTP的H.264視頻自適應傳輸機制研究[D].長安大學，2011.
[3]盛先剛.基于RTP的H.264視頻傳輸系統(tǒng)研究[D].西安電子科技大學，2006.
在運用信息技術教學過程中，若只是一味地將書本知識制作成電子課件，不加以任何修飾地播放給學生，大部分學生會產(chǎn)生倦怠心理，從而無法領會信息技術教學的真正用意，對學習狀態(tài)以及學習積極性產(chǎn)生不利影響。基于此種情況，教學拓展被逐步引入高中信息技術教學中，這一教學活動旨在通過信息技術教學與學生日常生活相結合的方式，幫助高中生建立科學的思維方法和探究方法，提高學生分析問題和解決問題的能力，最終實現(xiàn)其均衡而富有個性的發(fā)展。
1 教學拓展在高中信息技術教學中的應用意義
教學拓展作為將高中信息技術教學與高中生日常生活緊密相連的有效工具，其意義表現(xiàn)在兩方面。[1]一方面，教學拓展過程中，教師可以通過創(chuàng)設輕松詼諧的教學環(huán)境，降低性格偏內(nèi)向的學生對發(fā)言的恐懼，在學生發(fā)言或回答問題后，采取口頭或書面表揚的方式，增強學生學習的自信心，并且?guī)椭鷮W生獲得成功的體驗。另一方面，教學拓展可以幫助教師利用學生的好奇心來提高學習興趣，只有學生對將信息技術運用于學習中有探索精神并且對將所學知識運用于實際生活有強烈渴望，才可能激發(fā)其創(chuàng)新潛能。教師在拓展教學中若能恰當?shù)乩脤W生的好奇心來完成教學任務，便可激發(fā)學生的學習欲望，對培養(yǎng)學生學習的自主性和創(chuàng)新性都可起到積極作用。[2]
2 教學拓展在高中信息技術教學應用中的策略
教學拓展貫穿高中信息技術教學中的每個環(huán)節(jié)，無論是課堂教學還是課后學生自學或教師輔導，教學拓展都發(fā)揮著不可替代的作用。
2.1 展示學校官方網(wǎng)站及豐富網(wǎng)站內(nèi)容
當前我國高中普遍擁有各自的官方網(wǎng)站，各科教師應在所教學科第一課時將本學科官方網(wǎng)站告知學生并向學生說明網(wǎng)站中所教學科的相關信息，使學生能夠在課堂教學期間在教師的指導下瀏覽學科信息，從而對所學課文有更深刻的了解。另外，學生可以結合自身經(jīng)歷或在生活中遇到的人和事，完善學校網(wǎng)站內(nèi)容，將學科信息中出現(xiàn)的不足之處改編成經(jīng)過查驗證實的文字圖片資料或在缺漏處增添新的、真實的內(nèi)容，最大限度發(fā)掘學生自主學習能力。[3]
例如，某中學官方網(wǎng)站根據(jù)高中生學習需求將所有學科分為語文組、數(shù)學組、英語組等九大組別，每個組別中包含課時安排、課文內(nèi)容及資料和成績查詢等子類別，高中生只需輸入學號及密碼即可進行瀏覽、查詢和修改。尤其在進行內(nèi)容修改時，學生應在教師的指導下運用自身生活經(jīng)驗展開聯(lián)想，遇到問題時應積極思考，結合自身經(jīng)歷自主解決，逐步提高自我思考和自主學習的能力。
2.2 增加學校網(wǎng)站論壇管理員
學校官方網(wǎng)站中可設置學習論壇，為高中生提供網(wǎng)絡交流的平臺。學生可在論壇中自身遇到的疑難知識點，與全校師生進行探討；也可在論壇中自身學習心得和經(jīng)驗教訓，供學生借鑒參考，并且為教師加深對學生的了解提供依據(jù)。如果論壇訪問量達到一定數(shù)額，則需征召論壇管理員，各班選派的管理員應實行輪換制，以保證更多的學生能夠參與其中。學校官網(wǎng)論壇一般會招收多名管理員，這就需要每位管理員各有分工、互相配合、共同完成論壇管理工作，這不僅有助于增強學生對所在班級學校的責任感，而且可以培養(yǎng)學生在生活中為人處世的能力。
2.3 利用校園網(wǎng)上傳學生作業(yè)
學校機房為了便于統(tǒng)一管理，一般都配有還原卡，因此，學生第二天無法查詢當天儲存在電腦中的資料，這將不利于學生資料的保存。目前我國普遍使用Serv-U軟件于電腦服務器上設定文件傳輸協(xié)議，便于主機間共享文件，高中信息技術教學中可采用此種方法上傳學生資料至電腦。教師需注冊兩個賬號，一個是權限限定為除文件保存外不能進行復制、刪除的學生賬號，另一個是擁有保存、復制和刪除文件功能的教師賬號，此種方法有利于防止學生作弊。
教師在每一個學生的作品均上傳至文件傳輸協(xié)議服務器后，需對所教班級的學生作品做出優(yōu)劣評定。作品從傳送、送達文件傳輸協(xié)議服務器至教師評定整個過程中，學生都無法看到非本人作品文檔，即使傳送出現(xiàn)錯誤也只有教師可以將其重新傳送。而當教師評定結束后，可開放學生賬號權限，學生可瀏覽其他學生作品文檔并與自身作品相比較，找出自身不足并加以改正。設置文件傳輸協(xié)議傳送學生作業(yè)的方式，一方面可以提高教師教學工作效率，另一方面也可以促進學生間交互合作學習，激發(fā)學生學習興趣，從而使學生的學習生活更加輕松。
2.4 建立班級微信群
課堂教學占據(jù)了高中生校園學習的大部分時間，在遇到疑難知識點時，只有極少數(shù)學生可以抽出時間向教師提問并獲得滿意解答，這將造成學生課堂上遺留的問題越積越多，對學生有效掌握學科知識產(chǎn)生不利影響，最終導致學生學習積極性減弱甚至喪失。高中生生活中QQ、微信等聊天工具的使用愈加頻繁，在信息技術教學中，QQ等聊天工具除了方便溝通這一傳統(tǒng)功能外，更可以促進學生間關于學習上疑難問題的交流，以幫助學生共同進步。
例如，某地一中學在信息技術教學中采用建立微信群的方式，具體來說學生可以將課堂上積累的問題以圖片或文字的形式上傳至班級微信群中，并集中在中餐或晚餐時間由各科目教師進行講解。另外，為了監(jiān)督學生是否認真學習，教師可以采取隨機抽查的方式，讓學生上傳實時畫面至群里。微信群中的語言平實活潑，多源于網(wǎng)絡、源于生活，類似“贊一個”等網(wǎng)絡用語的使用提升了性格內(nèi)向學生發(fā)言的膽量和積極性。
2.5 樹立信息技術教學榜樣
高中學習階段，部分學生通過科學合理利用信息技術，在學業(yè)完成上取得了不俗的成績。另外，部分學生在學習文化知識之余，將所學知識運用于日常生活中，讓課堂知識為日常生活服務。教師應在信息技術教學過程中積極宣傳此類將信息技術科學融入日常學習生活中的實例，并且宣傳實例的主人公應是學生周圍熟悉的同學和朋友，以達到在學生中產(chǎn)生共鳴、提高學生學習興趣的目的。
例如，高中化學實驗中，由于化學試劑一般采用瓶裝，使用時一般會多次提取，這就造成試劑瓶內(nèi)試劑逐漸減少而空氣不斷增多，導致試劑氧化變質(zhì)甚至失效。某地一高中生由醫(yī)院輸液這一生活現(xiàn)象引發(fā)聯(lián)想，結合所學化學知識，思索出仿照吊瓶使用柔軟材料制作化學試劑瓶的想法，經(jīng)過網(wǎng)絡查閱相關化學資料和反復試驗，此高中生最終研制出可廣泛應用于科研所和試驗室的化學試劑儲取裝置并獲得國家發(fā)明專利。教師可將類似事例通過學校官網(wǎng)或教育類網(wǎng)站進行宣傳，并向學生講授相關學科知識，這不僅有利于激發(fā)學生的學習熱情，而且可以促使其積極思考，并提高學習效率。
3 結束語
關鍵詞：計算機網(wǎng)絡；課程；知識；系統(tǒng)化
計算機網(wǎng)絡課知識很多，而且錯綜復雜，教材一般是將計算機網(wǎng)絡內(nèi)容按“塊”組織并展開的，如計算機網(wǎng)絡概述、物理層、數(shù)據(jù)鏈路層、局域網(wǎng)、廣域網(wǎng)、網(wǎng)絡層、運輸層、應用層、網(wǎng)絡安全、網(wǎng)絡應用等。同樣，授課一般也是依教材的內(nèi)容和次序進行組織，一塊一塊內(nèi)容、一堂課一堂課講解，因此，學生積累的是點，最多也就是面的知識，而計算機網(wǎng)絡是一個系統(tǒng)，學生僅僅掌握面的知識不是課程的目的，把面的知識變成立體的知識并形成系統(tǒng)，知識才能活起來、才能有用。
目前，計算機網(wǎng)絡課程教材均沒有對計算機網(wǎng)絡知識進行梳理、總結的內(nèi)容。在計算機網(wǎng)絡課程內(nèi)容介紹完成后，對計算機網(wǎng)絡課程內(nèi)容進行梳理總結很重要。通過教學實踐，我們發(fā)現(xiàn)采用穿插、聯(lián)系和系統(tǒng)的方法能夠讓學生將學到的知識形成系統(tǒng)。
1構建和配置網(wǎng)絡系統(tǒng)
1.1從簡單網(wǎng)絡及其配置說起
兩臺計算機通過雙絞線連接起來，說明雙絞線4根線的作用、水晶頭連線的做法、連通檢測工具，交叉線和直通線用法。兩臺主機配置IP地址、子網(wǎng)掩碼，用Ping檢查網(wǎng)絡是否連通，將文件夾作為共享資源。通過Ping命令的功能復習ICMP協(xié)議。
通過共享集線器或者交換機連接主機組成小的
局域網(wǎng)。結合本校網(wǎng)絡實驗室設備，配置交換機的IP地址，配置VLAN，檢查VLAN配置是否正確。據(jù)此，介紹共享集線器工作原理、特點、工作的層、網(wǎng)絡的拓撲結構。介紹交換機工作原理、特點、工作的層，區(qū)分半雙工和全雙工工作方式，由交換機組成的VLAN工作原理、應用場合。
在這個基礎上，系統(tǒng)介紹以太網(wǎng)的組成、以太網(wǎng)的擴展(包括中繼器、網(wǎng)橋、集線器的級聯(lián))、高速以太網(wǎng)等。
通過路由器連接兩個局域網(wǎng)，結合本校網(wǎng)絡實驗室設備，配置路由器的IP地址、靜態(tài)路由表，主機IP地址、子網(wǎng)掩碼和網(wǎng)關。據(jù)此，介紹路由器的工作原理、路由表及其形成。進一步通過2個路由器連接3個網(wǎng)絡，其中中間是廣域網(wǎng)，并以此作為一個小的自治系統(tǒng)，配置路由器的內(nèi)部網(wǎng)關協(xié)議RIP。在這個基礎上，總結自治系統(tǒng)及其內(nèi)部網(wǎng)關協(xié)議IGP和外部網(wǎng)關協(xié)議EGP。
如果有可能，可以對幾個典型的網(wǎng)絡案例進行分析[1]。
1.2從接入互聯(lián)網(wǎng)談起
通過本地IP地址和全局IP地址，引入服務器、NAT和VPN。分別介紹它們的工作原理、應用場合、上網(wǎng)的特點。
通過家庭上網(wǎng)，介紹ADSL工作原理、連接方法。介紹家庭無線路由器工作原理、連接方法、上網(wǎng)的特點。
介紹一個單位網(wǎng)絡的基本構成，包括拓撲結構、傳輸介質(zhì)、設備配置、結構化布線方案和接入因特網(wǎng)方法。拓撲結構主要突出星型結構，傳輸介質(zhì)主要突出雙絞線和光纖。以自己熟悉的當前運行的單位或者政府(例如區(qū))網(wǎng)絡為例進行分析。通過碰撞域和信號不失真?zhèn)鬏斁嚯x解析采用傳輸介質(zhì)的最大長度。
介紹工業(yè)現(xiàn)場典型網(wǎng)絡構成、拓撲結構、設備配置。拓撲結構主要突出總線結構，同時介紹RS485和CAN總線等。設備包括PLC、工控機和嵌入式裝置。
介紹本校校園網(wǎng)的構成(包括校內(nèi)無線網(wǎng))、本城市內(nèi)校園網(wǎng)的連接、如何連入中國教育與科研網(wǎng)[2]。
2把IP地址及其相關問題聯(lián)系在一起
先提出下列問題：“如果學生宿舍兩臺計算機通過集線器連在一起，如果IP地址分別配置成192.168.1.1和192.168.2.1，這兩臺計算機是否無法打交道？”學生當然是能夠回答的。但如果提出“計算機為什么要同時采用IP地址和硬件地址？”這個問題，有不少學生說不到位。課程總結時，通過第一個問題，復習IP地址的分類、子網(wǎng)掩碼、網(wǎng)絡號、主機號等。通過IP地址分類的缺限，介紹子網(wǎng)和超網(wǎng)(CIDR)原理、計算方法及其與它們有關路由器查找路由算法的變化。通過IP地址存在的問題，對IPV6主要特點作個介紹。
通過第二個問題，介紹IP地址用于找到目的主機所在的網(wǎng)絡，而在同一個網(wǎng)絡中數(shù)據(jù)采用的是數(shù)據(jù)鏈路層的幀傳輸，而幀采用是硬件地址(封裝在MAC 幀中稱為MAC地址)，通過ARP可以將目的主機的IP地址查到對應的硬件地址。
關于計算機在廣域網(wǎng)中的地址，將最簡單的層次結構地址與EUI-48地址進行對比，說明它們的共同點和不同點。
在由IP地址得到網(wǎng)絡號和主機號基礎上，引入單播、廣播、多播。通過上面的介紹，單播就不需要更多說明，主要是廣播和多播。關于廣播，說明IP地址如何表達廣播地址，硬件地址如何表達廣播地址，通過ARP給廣播舉例。關于多播，介紹IP使用D類地址支持多播，以太網(wǎng)多播地址表達方法以及它們的映射關系。關于多播其他內(nèi)容包括IGMP，因為內(nèi)容多，應該專門梳理。
在介紹硬件地址和IP地址的基礎上，引入域名和DNS，域名需要說明域名樹型結構，DNS需要說明它的作用、DNS服務器的分布、由域名查找對應的IP地址的過程。從而形成了域名――IP地址――硬件地址系統(tǒng)知識鏈。
3為了提供更好的“服務”費盡心血
3.1理解兩種“連接”服務
計算機網(wǎng)絡從不同層面提供面向連接可靠的服務和無連接不可靠的服務，而且由此產(chǎn)生了很多相關問題，學生不易理解，認為交給目的主機的所有數(shù)據(jù)都應該是正確的和完整的。為了進一步理解這兩種服務的特點，可以先大致介紹文件傳輸、IP電話等工作原理，讓學生明白，有些應用到達目的主機的所有數(shù)據(jù)都必須是正確的和完整的，例如文件傳輸。有些應用(例如IP電話)實時性比可靠性更重要，個別數(shù)據(jù)包丟失或者不正確并不影響它的使用。在這個基礎上進行總結，為了適應不同應用的需要，計算機網(wǎng)絡需要同時提供面向連接服務和無連接服務。然后，從運輸層、網(wǎng)絡層和數(shù)據(jù)鏈路層分別展開說明。
UDP和TCP是TCP/IP體系運輸層提供的無連接服務和面向連接服務，在應用層，DNS、RIP、DHCP、SNMP、IP電話、流式多媒體通信等都采用UDP服務，而HTTP、FTP、SMTP、TELNET等都采用TCP服務。因為UDP是無連接服務，所以它報文格式首部比較簡單。TCP是面向連接服務，所以它報文格式首部非常復雜。TCP為了實現(xiàn)可靠數(shù)據(jù)傳輸，傳輸前需要建立連接，連接成功才能進行數(shù)據(jù)傳輸，傳輸結束后需要釋放連接。為了可靠建立連接，需要3次握手。數(shù)據(jù)傳輸時，通過“窗口”協(xié)調(diào)雙方的傳輸節(jié)奏，通過檢驗和判斷接收到的數(shù)據(jù)是否正確，通過確認報文通知發(fā)送方已經(jīng)接收到的數(shù)據(jù)情況，等等。傳輸結束，需要雙向釋放連接。通過上面UDP和TCP數(shù)據(jù)傳輸穿插和比較，把許多概念聯(lián)系起來，區(qū)分開來[3]。
TCP/IP體系的網(wǎng)際層提供的是無連接的IP服務。
在數(shù)據(jù)鏈路層，以前非常流行的連續(xù)的ARQ協(xié)議是面向連接的可靠的數(shù)據(jù)傳輸協(xié)議，所以，需要包含建立連接、數(shù)據(jù)傳輸、釋放連接過程，幀頭部包含序號字段，用于描述當前傳輸?shù)膸木幪柡徒邮辗綄κ盏降膸_認，用FCS字段表達數(shù)據(jù)檢驗，用確認幀告訴發(fā)送方接收的幀是否正確。而當前流行的PPP協(xié)議的幀格式中沒有序號字段，因為它是無連接的傳輸協(xié)議。同樣，以太網(wǎng)也是采用無連接傳輸協(xié)議，所以，以太網(wǎng)V2標準和IEEE的802.3標準的MAC幀格式都很簡單。實際上，無連接的傳輸協(xié)議并不一定就是不可靠的數(shù)據(jù)傳輸，像以太網(wǎng)本身傳輸很少出錯，由于協(xié)議簡單，所以網(wǎng)絡的傳輸效率非常高。
參考文獻：
[1] 張衛(wèi),俞黎陽. 計算機網(wǎng)絡工程[M]. 2版. 北京:清華大學出版社,2009:284-289.
[2] 吳功宜,吳英. 計算機網(wǎng)絡應用技術教程[M]. 3版. 北京:清華大學出版社,2010:210-224.
[3] 謝希仁. 計算機網(wǎng)絡 [M]. 5版. 北京:電子工業(yè)出版社,2008:1-306.
[4] 吳功宜,吳英. 計算機網(wǎng)絡應用技術教程題解與實驗指導[M]. 3版. 北京:清華大學出版社,2009:17-37.
[5] 陳鳴,常強林,岳振軍. 計算機網(wǎng)絡實驗教程:從原理到實踐[M]. 北京:機械工業(yè)出版社,2007:1-417.
[6] 張曾科. 計算機網(wǎng)絡 [M]. 3版. 北京:清華大學出版社,2009:233-270.
Interweave, Associate and Systematization:The Practice and Think about the Summary Course of Computer Network
ZHENG A-qi
(College of Computer Science &Technology, Nanjing Normal University, Nanjing 210097, China)
