葉紀聽

摘要：跟著Internet的遍及和工業(yè)自動化的迅速發(fā)展，網(wǎng)絡(luò)已深化家庭、單位、工廠、自動化操控領(lǐng)域。大家在各個地方都可經(jīng)過互聯(lián)網(wǎng)來交流信息，因而網(wǎng)絡(luò)數(shù)據(jù)傳輸就顯得尤為的重要。在VB中就供給了撐持數(shù)據(jù)傳輸?shù)目丶纾篧insock控件和MSComm控件等。經(jīng)過程序開發(fā)和控件的運用， 可完成網(wǎng)絡(luò)的數(shù)據(jù)通信，滿意網(wǎng)絡(luò)用戶對數(shù)據(jù)通信和數(shù)據(jù)交流的需要。

關(guān)鍵詞：vb編程；文件；網(wǎng)絡(luò)數(shù)據(jù)；傳遞

中圖分類號：TP311 文獻標(biāo)識碼：A 文章編號：1009-3044（2014）22-5235-05

1 VB網(wǎng)絡(luò)文件數(shù)據(jù)傳輸及通信概述

1.1 數(shù)據(jù)通訊方法按傳輸方向

分有：

1） 單工通訊：在單工信道上信息只能在一個方向傳送。

2） 半雙工通訊：在半雙工信道上，通訊的雙方可替換發(fā)送和接納信息。

3） 全雙工通訊：一種能夠一起進行雙向信息傳送的通訊方法。

1.2交流方法

1） 線路交流：交流的特色是樹立銜接需求等候較長的時刻。

特色：銜接樹立后通路是專用的。不再有傳輸推遲，這種交流方法適合于傳輸大量的數(shù)據(jù)。在傳輸少量信息時功率不高。

2） 報文交流：

特色：不樹立專用鏈路。線路利用率較高。電子郵件系統(tǒng)（例如E-Mail）適合選用報文交流方法。

虛電路能夠是暫時的，即會話開端樹立，會話完畢撤除，這叫虛呼叫；也能夠是持久的，即通訊雙方一開機就自動樹立，直到一方（或一起）關(guān)機才撤除。這叫持久虛電路。 分組交流的特色：數(shù)據(jù)包有固定的長度。選用固定的、短的分組相對于報文交流是一個重要的長處。除了交流結(jié)點的存儲緩沖區(qū)能夠不些外，也帶來了傳播時延的削減，分組交流也意味著按分組糾錯：發(fā)現(xiàn)過錯只需重發(fā)犯錯的分組，使通訊功率提高。

2 VB網(wǎng)絡(luò)文件數(shù)據(jù)傳遞性能需求

2.1 穩(wěn)定性

在程序規(guī)劃中應(yīng)當(dāng)考慮到各種可能發(fā)作的狀況，進而避免慣例或許一些低級過錯。一旦發(fā)作任何過錯或突發(fā)事件，體系要可以正常運轉(zhuǎn)甚至及時糾錯，不至于癱瘓而使得軟件無法運轉(zhuǎn)下去。那么在規(guī)劃關(guān)于一些不慣例的輸入和操作均作了相應(yīng)的約束，從某種程度上提升了軟件的穩(wěn)定性。

2.2 易用性

本程序僅僅是一個雛形，簡單上手，操作簡單，運用進程一望而知。有關(guān)指令標(biāo)志處置和暫時處置均運用文件，操作起來對比簡潔。

3 VB網(wǎng)絡(luò)文件數(shù)據(jù)通信協(xié)議

在開始編程之前首先應(yīng)當(dāng)對客戶端和服務(wù)器之間的通信協(xié)議進行定義，以便雙方在通信過程中可以方便的識別彼此的通信指令和標(biāo)志。

1） 服務(wù)器端通信協(xié)議定義如表1所示：

2） 客戶端通信協(xié)議定義如下：

3 VB網(wǎng)絡(luò)文件數(shù)據(jù)動態(tài)添加客戶端

單個客戶端與服務(wù)器經(jīng)過winsock控件完成通訊今后，有必要聯(lián)系實際情況完成多個客戶端與服務(wù)器之間的數(shù)據(jù)通訊，這就涉及到服務(wù)器需求有動態(tài)增加客戶端的才能，與懇求銜接的客戶端樹立彼此間銜接。

在規(guī)劃中我選用winsock數(shù)組來完成服務(wù)器端的動態(tài)增加功用，winsock（0）規(guī)劃為服務(wù)器端一向堅持監(jiān)聽客戶端銜接懇求的控件，假如監(jiān)聽到有客戶端的銜接懇求，首要查找數(shù)組中是否存在閑暇的winsock（x），假如存在，則運用該winsock（x）與之樹立銜接，反之加載一個新的winsock數(shù)組控件與之樹立銜接。一旦與客戶端樹立銜接成功后，服務(wù)器將把該winsock的數(shù)組下標(biāo)發(fā)送給該客戶端，如服務(wù)器端是運用winsock（2）與客戶端樹立銜接，則將索引2發(fā)送給客戶端，此時該客戶端就作為“2號客戶端”，一起在服務(wù)器端的listbox客戶端狀況列表中作為2號客戶端顯現(xiàn)。

4 VB網(wǎng)絡(luò)文件數(shù)據(jù)傳輸模塊

文件傳輸?shù)耐瓿墒滓窃诳蛻舳颂幹?，客戶端接納到服務(wù)器端的文件傳輸?shù)闹噶詈?，采納相應(yīng)的處置。文件傳輸首要分兩種狀況來處置：

4.1 單個文件傳輸

理論上單個文件傳輸相關(guān)于整個文件夾的傳輸要簡略的多，服務(wù)器端發(fā)送指令：Winsock1（ClientIndex）.SendData "Opt_pa" & Label2.Caption，其間"Opt_pa"為單個文件傳輸?shù)南笳?，Label2.Caption為該文件在客戶端的絕對途徑?？蛻舳藙e離信息后，依據(jù)文件途徑獲得該文件的長度，先向服務(wù)器端發(fā)送該文件的長度Winsock1.SendData "Fl_Len" & LenFile1，意圖是為了在文件傳輸過程中能夠判別該文件是不是傳輸結(jié)束。

服務(wù)器端回送一個"Ins_Tr"的確認象征后，客戶端開端對該文件進行傳輸。對文件的傳輸?shù)脑敿毻瓿桑枰伎紟追N狀況，關(guān)于小型文件能夠直接使用WINSOCK傳輸，可是關(guān)于大型文件或視頻文件的傳輸必須選用分割技能來完成，根據(jù)以上的思考，不管是大型文件仍是小型的文件的傳輸首要判別其長度是不是大于65535，假如小于則直接傳輸，不然對該文件進行分塊傳輸（以8K為一個傳輸塊），數(shù)據(jù)塊傳輸結(jié)束后，還必須思考所剩下的數(shù)據(jù)，假如存在剩下的數(shù)據(jù)也要進行傳輸。

4.2 整個文件夾的傳輸

依照常理來說，關(guān)于文件夾的傳輸本來即是對文件的循環(huán)傳輸，原理是：依據(jù)服務(wù)器端給定的文件夾途徑Winsock1（ClientIndex）.SendData "Opt～pa" & Label2.Caption，其間"Opt～pa"為文件夾傳輸象征，Label2.Caption為文件夾的絕對途徑，客戶端別離途徑后首要查找該文件夾下的一切子文件夾和文件的稱號，保存在文件中傳輸?shù)椒?wù)器端，在服務(wù)器端樹立該文件夾及其包括的一切子目錄和文件稱號，然后客戶端循環(huán)傳輸文件。

上述中理論上能夠完成整個文件夾的傳輸，可是顯著完成起來比較雜亂，比方該文件夾下所嵌套的子文件夾比較深，所包括的文件也比較多，那么在傳輸過程中所要思考的疑問也就十分的雜亂，要思考同級目錄中的文件傳輸和下級文件的傳輸。通過屢次實驗后，找到一種替代方法，同樣能夠是完成整個文件夾的傳輸，但在原理上有差異于上面的傳輸途徑：首要是使用微軟rar.exe和unrar.exe能夠簡略的完成文件夾的傳輸。起原理是客戶端別離文件夾途徑后，調(diào)用rar.exe對該文件夾進行緊縮處置，這樣一來不管文件夾下嵌套有多深，包括了多少個文件，一并作打包處置，然后傳輸給服務(wù)器端；服務(wù)器端徹底接納該緊縮文件到指定途徑下，對該緊縮文件進行解緊縮處置，以此來完成對整個文件夾的傳輸。

4.3 主要功能實現(xiàn)代碼分析

1） 服務(wù)器端動態(tài)添加客戶端實現(xiàn)代碼：

整體上現(xiàn)已完成所需要的功用需要，當(dāng)然在某些方面依然需要進一步完善，比方客戶端因不確定要素封閉或許網(wǎng)絡(luò)斷開，那么服務(wù)器端采取怎樣的措施來應(yīng)對；文件傳輸進程中所顯示的進度條如何能夠準(zhǔn)確的反應(yīng)當(dāng)時文件實踐所傳輸?shù)臓顩r等等，因為時間的問題，這些不足之處都是值得進一步研討的當(dāng)?shù)?，在爾后將逐步完善這些功用。

參考文獻：

[1] 范逸之，陳立元.Visual Basic 與RS-232串行通訊操控[M].北京：清華大學(xué)出版社，1994：38-57.

[2] 崔彥鋒，許小榮.VB網(wǎng)絡(luò)與遠程控制編程實例教程[M].北京：北京希望電子出版社，1996：34-65.

[3] 卞志強.Visual Basic網(wǎng)絡(luò)程序設(shè)計[M].北京：人民郵電出版社，1993：48-93.