PERL模拟飞鸽传书文件传输总结
生活随笔
收集整理的這篇文章主要介紹了
PERL模拟飞鸽传书文件传输总结
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
經(jīng)過半個月對 FreeEIM 飛鴿傳書的學(xué)習(xí)實踐，對于網(wǎng)絡(luò)SOCKET連接、文件傳輸?shù)膶崿F(xiàn)原理與具體實現(xiàn)的重點難點已經(jīng)有了一定的了解。
飛鴿傳書唯一官網(wǎng)
文件傳輸需要建立一個文件發(fā)送端，一個文件接收端，并通過自己指定的傳輸協(xié)議，對文件數(shù)據(jù)進行傳輸。在文件傳輸過程中，我們由于許多原因，要對數(shù)據(jù)進行處理，這樣，就需要文件發(fā)送與接收雙方進行通信，對傳輸文件的一些特性進行互相通告，以方便對傳輸數(shù)據(jù)的處理。文件傳輸?shù)囊笤谟谖募?shù)據(jù)的傳輸速度，CPU的占用率，以及網(wǎng)絡(luò)資源的使用率。下面對這三方面進行分析：
1.文件數(shù)據(jù)的傳輸速率
純正意義上的文件傳輸速度是指文件的實際內(nèi)容開始發(fā)送到文件內(nèi)容全部傳輸完畢所用的時間來除文件的大小得出的值。這個值由發(fā)送數(shù)據(jù)包的大小決定，這個大小值要保證一次傳輸數(shù)據(jù)要盡可能的多的同時發(fā)送數(shù)據(jù)包的速度也要快，也就是說網(wǎng)絡(luò)占用率與傳輸速度相互關(guān)聯(lián)。但在程序?qū)嶋H傳輸文件中，發(fā)送方讀文件內(nèi)容到內(nèi)存、接收方從內(nèi)存向文件寫數(shù)據(jù)、發(fā)送文件前的通信以及傳輸數(shù)據(jù)的壓縮與解壓縮都會消耗時間，所以我們算速率的時候通常把這些時間也算進去了，因為要評估程序的性能，就要把實際消耗的時間都算上。那么影響傳輸速率的其他因素還有：
發(fā)送端讀文件時間；
接收端寫文件的時間；
數(shù)據(jù)的壓縮、解壓縮時間；
傳輸通訊時間。
我們需要解決的是，一次發(fā)送接收多少數(shù)據(jù)，如何發(fā)送，數(shù)據(jù)一次壓縮或解壓縮多少，還有就是通信的方式，如何發(fā)送接收發(fā)送前的通信，才能使其耗時最短。
2.CPU的占用率
CPU的占用率就是指程序運行后，文件傳輸時CPU的使用情況。CPU主要工作在文件數(shù)據(jù)的讀寫，文件數(shù)據(jù)的壓縮與解壓縮。文件數(shù)據(jù)連續(xù)的進行寫入內(nèi)存，或者從內(nèi)存寫入文件都會占用很多的CPU使用，壓縮解壓縮數(shù)據(jù)時，對于很大的數(shù)據(jù)進行壓縮或解壓縮也會占用很大的CPU使用。
想要降低CPU占用率，就要使文件發(fā)送與接收有層次，將大的數(shù)據(jù)分開成若干的較大的數(shù)據(jù)包，然后再將這些數(shù)據(jù)包分別按小包發(fā)送。如何控制分割的大數(shù)據(jù)包的大小，和每次發(fā)送數(shù)據(jù)包的大小，與接收端接收了多少數(shù)據(jù)再寫入文件都是關(guān)鍵,；如果要對傳輸?shù)臄?shù)據(jù)進行壓縮，何時進行壓縮和解壓縮，一次壓縮和解壓多少數(shù)據(jù)，壓縮次數(shù)是關(guān)鍵，由于邏輯結(jié)構(gòu)的因素，何時進行壓縮就制約了數(shù)據(jù)壓縮大小，在文件分割前壓縮，壓縮的數(shù)據(jù)就會很大，如果把文件分割成大的數(shù)據(jù)包后進行壓縮，這個數(shù)據(jù)包的大小就決定壓縮的效率，如果在每次SOCKET發(fā)送數(shù)據(jù)包的時候進行壓縮，就會使壓縮的次數(shù)巨增，也制約了壓縮效率。
3.網(wǎng)絡(luò)資源的使用率
網(wǎng)絡(luò)資源的利用率是指在文件傳輸過程中，對網(wǎng)絡(luò)資源的利用情況，SOCKET在傳輸數(shù)據(jù)包的時候有一個最大傳輸字節(jié)，可以用SND_BUF、RCV_BUF分別取出發(fā)送端與接收端的最大值。每次發(fā)送數(shù)據(jù)包時候最大利用了SND_BUF、RCV_BUF的大小，就可以使傳輸效率大大提高，網(wǎng)絡(luò)利用率也就很高。網(wǎng)絡(luò)資源的使用率也影響文件數(shù)據(jù)的傳輸速率。為了保證每次發(fā)包與收包的數(shù)據(jù)大小的一致性，我們就要保證SND_BUF、RCV_BUF的一致，所以接收端的RCV_BUF要與發(fā)送端的SND_BUF相等，這就要求我們在發(fā)送文件之前的通信中要把發(fā)送端的SND_BUF告訴接收端，接收端對自己的RCV_BUF進行處理。
文件傳輸過程中還有一些問題：
1．文件傳輸結(jié)束標(biāo)志，文件什么時候傳輸完畢，我們退出SOCKET，不再進行數(shù)據(jù)的收發(fā)，我們可以在傳輸前通信前的通信中把文件大小告訴接收方，當(dāng)接收方寫入文件數(shù)據(jù)到了該大小后傳輸結(jié)束。
2.文件傳輸過程中出現(xiàn)發(fā)送方與接收方單方中斷傳輸時候，要通知對方結(jié)束程序，并對沒有寫完的文件進行刪除，著塊要根據(jù)傳輸方式跟邏輯結(jié)構(gòu)的不同采取不同的方法實現(xiàn)。
3.文件內(nèi)容的壓縮與不壓縮一定程度上影響了文件傳輸?shù)倪壿嫿Y(jié)構(gòu)，采取不同的壓縮方式，在不同的階段進行壓縮，文件傳輸?shù)倪壿嫿Y(jié)構(gòu)應(yīng)該不同，這樣才能保證傳輸數(shù)據(jù)的正確性和傳輸?shù)母咝浴?/span>
4.在文件傳輸過程中是否會有丟包的現(xiàn)象呢？采取TCP方式，由于它是可靠的連接，三次握手機制保證了傳輸數(shù)據(jù)的正確性。而采取UDP方式就不行了。另外接收端在采用sysread從SOCKET中讀數(shù)據(jù)時候，如果是外網(wǎng)文件傳輸，sysread會出現(xiàn)讀到的數(shù)據(jù)小于我們指定的長度，這樣就要采取邏輯上的補救，限制讀夠了該長度后才讀下一數(shù)據(jù)。
5.文件接收端在往緩存變量寫數(shù)據(jù)時候，如果一次寫入的數(shù)據(jù)比較大，那么，第一次寫數(shù)據(jù)時候?qū)⑾拇罅康臅r間，這里要采用先把緩存擴大到數(shù)據(jù)長度的空間大小，然后清空緩存變量，再進行數(shù)據(jù)的寫入。
6.數(shù)據(jù)壓縮后發(fā)送給接收端，接收端如何知道何時解壓縮得到的數(shù)據(jù)是原始正確的數(shù)據(jù)呢，壓縮后的數(shù)據(jù)分開后或者取出部分后解壓縮后得到的值肯定不等于原始數(shù)據(jù)，接收端依次讀取SOCKET數(shù)據(jù)包，累加寫入變量，當(dāng)變量的值等于發(fā)送端發(fā)送的壓縮數(shù)據(jù)時，對其解壓縮得到的值才是原始數(shù)據(jù)。判斷這個變量等于壓縮的數(shù)據(jù)就要用到壓縮數(shù)據(jù)的大小，發(fā)送端壓縮后先與接收端進行通信，將壓縮數(shù)據(jù)大小告訴接收端，接收端反饋一個收到的信息后，發(fā)送端開始發(fā)送壓縮數(shù)據(jù)，接收端根據(jù)收到的壓縮數(shù)據(jù)的大小來判斷接收數(shù)據(jù)是否到達了壓縮數(shù)據(jù)包的大小，如果大小一樣了，就說明壓縮包全部接收到了，現(xiàn)在就可以進行解壓縮處理了。
總結(jié)，一個基本的文件傳輸結(jié)構(gòu)已經(jīng)出來了，再加上簡單的處理，比如，對發(fā)送文件的選擇，接收文件的重命名，傳輸方的IP選擇等等，文件傳輸程序就基本實現(xiàn)了，程序還有很多不太合理的地方，CPU，網(wǎng)絡(luò)，跟傳輸速率還有提升的空間，希望大家批評指正。
文件傳輸需要建立一個文件發(fā)送端，一個文件接收端，并通過自己指定的傳輸協(xié)議，對文件數(shù)據(jù)進行傳輸。在文件傳輸過程中，我們由于許多原因，要對數(shù)據(jù)進行處理，這樣，就需要文件發(fā)送與接收雙方進行通信，對傳輸文件的一些特性進行互相通告，以方便對傳輸數(shù)據(jù)的處理。文件傳輸?shù)囊笤谟谖募?shù)據(jù)的傳輸速度，CPU的占用率，以及網(wǎng)絡(luò)資源的使用率。下面對這三方面進行分析：
1.文件數(shù)據(jù)的傳輸速率
純正意義上的文件傳輸速度是指文件的實際內(nèi)容開始發(fā)送到文件內(nèi)容全部傳輸完畢所用的時間來除文件的大小得出的值。這個值由發(fā)送數(shù)據(jù)包的大小決定，這個大小值要保證一次傳輸數(shù)據(jù)要盡可能的多的同時發(fā)送數(shù)據(jù)包的速度也要快，也就是說網(wǎng)絡(luò)占用率與傳輸速度相互關(guān)聯(lián)。但在程序?qū)嶋H傳輸文件中，發(fā)送方讀文件內(nèi)容到內(nèi)存、接收方從內(nèi)存向文件寫數(shù)據(jù)、發(fā)送文件前的通信以及傳輸數(shù)據(jù)的壓縮與解壓縮都會消耗時間，所以我們算速率的時候通常把這些時間也算進去了，因為要評估程序的性能，就要把實際消耗的時間都算上。那么影響傳輸速率的其他因素還有：
發(fā)送端讀文件時間；
接收端寫文件的時間；
數(shù)據(jù)的壓縮、解壓縮時間；
傳輸通訊時間。
我們需要解決的是，一次發(fā)送接收多少數(shù)據(jù)，如何發(fā)送，數(shù)據(jù)一次壓縮或解壓縮多少，還有就是通信的方式，如何發(fā)送接收發(fā)送前的通信，才能使其耗時最短。
2.CPU的占用率
CPU的占用率就是指程序運行后，文件傳輸時CPU的使用情況。CPU主要工作在文件數(shù)據(jù)的讀寫，文件數(shù)據(jù)的壓縮與解壓縮。文件數(shù)據(jù)連續(xù)的進行寫入內(nèi)存，或者從內(nèi)存寫入文件都會占用很多的CPU使用，壓縮解壓縮數(shù)據(jù)時，對于很大的數(shù)據(jù)進行壓縮或解壓縮也會占用很大的CPU使用。
想要降低CPU占用率，就要使文件發(fā)送與接收有層次，將大的數(shù)據(jù)分開成若干的較大的數(shù)據(jù)包，然后再將這些數(shù)據(jù)包分別按小包發(fā)送。如何控制分割的大數(shù)據(jù)包的大小，和每次發(fā)送數(shù)據(jù)包的大小，與接收端接收了多少數(shù)據(jù)再寫入文件都是關(guān)鍵,；如果要對傳輸?shù)臄?shù)據(jù)進行壓縮，何時進行壓縮和解壓縮，一次壓縮和解壓多少數(shù)據(jù)，壓縮次數(shù)是關(guān)鍵，由于邏輯結(jié)構(gòu)的因素，何時進行壓縮就制約了數(shù)據(jù)壓縮大小，在文件分割前壓縮，壓縮的數(shù)據(jù)就會很大，如果把文件分割成大的數(shù)據(jù)包后進行壓縮，這個數(shù)據(jù)包的大小就決定壓縮的效率，如果在每次SOCKET發(fā)送數(shù)據(jù)包的時候進行壓縮，就會使壓縮的次數(shù)巨增，也制約了壓縮效率。
3.網(wǎng)絡(luò)資源的使用率
網(wǎng)絡(luò)資源的利用率是指在文件傳輸過程中，對網(wǎng)絡(luò)資源的利用情況，SOCKET在傳輸數(shù)據(jù)包的時候有一個最大傳輸字節(jié)，可以用SND_BUF、RCV_BUF分別取出發(fā)送端與接收端的最大值。每次發(fā)送數(shù)據(jù)包時候最大利用了SND_BUF、RCV_BUF的大小，就可以使傳輸效率大大提高，網(wǎng)絡(luò)利用率也就很高。網(wǎng)絡(luò)資源的使用率也影響文件數(shù)據(jù)的傳輸速率。為了保證每次發(fā)包與收包的數(shù)據(jù)大小的一致性，我們就要保證SND_BUF、RCV_BUF的一致，所以接收端的RCV_BUF要與發(fā)送端的SND_BUF相等，這就要求我們在發(fā)送文件之前的通信中要把發(fā)送端的SND_BUF告訴接收端，接收端對自己的RCV_BUF進行處理。
文件傳輸過程中還有一些問題：
1．文件傳輸結(jié)束標(biāo)志，文件什么時候傳輸完畢，我們退出SOCKET，不再進行數(shù)據(jù)的收發(fā)，我們可以在傳輸前通信前的通信中把文件大小告訴接收方，當(dāng)接收方寫入文件數(shù)據(jù)到了該大小后傳輸結(jié)束。
2.文件傳輸過程中出現(xiàn)發(fā)送方與接收方單方中斷傳輸時候，要通知對方結(jié)束程序，并對沒有寫完的文件進行刪除，著塊要根據(jù)傳輸方式跟邏輯結(jié)構(gòu)的不同采取不同的方法實現(xiàn)。
3.文件內(nèi)容的壓縮與不壓縮一定程度上影響了文件傳輸?shù)倪壿嫿Y(jié)構(gòu)，采取不同的壓縮方式，在不同的階段進行壓縮，文件傳輸?shù)倪壿嫿Y(jié)構(gòu)應(yīng)該不同，這樣才能保證傳輸數(shù)據(jù)的正確性和傳輸?shù)母咝浴?/span>
4.在文件傳輸過程中是否會有丟包的現(xiàn)象呢？采取TCP方式，由于它是可靠的連接，三次握手機制保證了傳輸數(shù)據(jù)的正確性。而采取UDP方式就不行了。另外接收端在采用sysread從SOCKET中讀數(shù)據(jù)時候，如果是外網(wǎng)文件傳輸，sysread會出現(xiàn)讀到的數(shù)據(jù)小于我們指定的長度，這樣就要采取邏輯上的補救，限制讀夠了該長度后才讀下一數(shù)據(jù)。
5.文件接收端在往緩存變量寫數(shù)據(jù)時候，如果一次寫入的數(shù)據(jù)比較大，那么，第一次寫數(shù)據(jù)時候?qū)⑾拇罅康臅r間，這里要采用先把緩存擴大到數(shù)據(jù)長度的空間大小，然后清空緩存變量，再進行數(shù)據(jù)的寫入。
6.數(shù)據(jù)壓縮后發(fā)送給接收端，接收端如何知道何時解壓縮得到的數(shù)據(jù)是原始正確的數(shù)據(jù)呢，壓縮后的數(shù)據(jù)分開后或者取出部分后解壓縮后得到的值肯定不等于原始數(shù)據(jù)，接收端依次讀取SOCKET數(shù)據(jù)包，累加寫入變量，當(dāng)變量的值等于發(fā)送端發(fā)送的壓縮數(shù)據(jù)時，對其解壓縮得到的值才是原始數(shù)據(jù)。判斷這個變量等于壓縮的數(shù)據(jù)就要用到壓縮數(shù)據(jù)的大小，發(fā)送端壓縮后先與接收端進行通信，將壓縮數(shù)據(jù)大小告訴接收端，接收端反饋一個收到的信息后，發(fā)送端開始發(fā)送壓縮數(shù)據(jù)，接收端根據(jù)收到的壓縮數(shù)據(jù)的大小來判斷接收數(shù)據(jù)是否到達了壓縮數(shù)據(jù)包的大小，如果大小一樣了，就說明壓縮包全部接收到了，現(xiàn)在就可以進行解壓縮處理了。
總結(jié)，一個基本的文件傳輸結(jié)構(gòu)已經(jīng)出來了，再加上簡單的處理，比如，對發(fā)送文件的選擇，接收文件的重命名，傳輸方的IP選擇等等，文件傳輸程序就基本實現(xiàn)了，程序還有很多不太合理的地方，CPU，網(wǎng)絡(luò)，跟傳輸速率還有提升的空間，希望大家批評指正。
總結(jié)
以上是生活随笔為你收集整理的PERL模拟飞鸽传书文件传输总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 程序园冬天好冷怎么办？
- 下一篇： 构思新巧的173dmba飞鸽