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