專利名稱：一種文件傳輸?shù)姆椒白影l(fā)送器的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計算機技術(shù)領(lǐng)域，特別涉及一種文件傳輸?shù)姆椒白影l(fā)送器。
背景技術(shù)：
隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，網(wǎng)絡(luò)即時通訊工具發(fā)展到今天，也已經(jīng)被大多數(shù)的 網(wǎng)民所接受，已經(jīng)成為用戶必不可少的軟件工具，不但在平時的休閑娛樂中，
而且在用戶的工作中得到廣泛的使用。因此用戶對IM軟件的易用性，穩(wěn)定性， 安全性等方面提出了較高的要求。在IM軟件中，人性化的服務(wù)可以為用戶提 供一種更加強烈的粘性作用，用戶在網(wǎng)絡(luò)生活中必不可少的使用IM軟件進行 著曰常的交流與溝通，IM軟件可以說是用戶桌面不可缺少的工具之一，成為 工作與生活中不可或缺的一部分。文件傳輸作為一種主要溝通方式，在IM基 礎(chǔ)服務(wù)中具有舉足輕重的低位，如何傳輸?shù)酶旄咝?，是一個需要長期研究 的問題。
現(xiàn)有技術(shù)中采用仿TCP ( Transmission Control Protocol,傳輸控制協(xié)議)滑 動窗口的UDP (User Datagram Protocol ，用戶數(shù)據(jù)報協(xié)議)文件傳輸方法，由 于方法與TCP特性相似，因此受網(wǎng)絡(luò)環(huán)境(丟包、延遲、抖動等)影響較大、 帶寬利用率較低。

發(fā)明內(nèi)容
為了提高文件傳輸?shù)乃俣群托?，本發(fā)明實施例提供了一種文件傳輸?shù)姆?法及子發(fā)送器。所述技術(shù)方案如下
一種文件傳輸?shù)姆椒?，所述方法包?br> 子發(fā)送器收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時，向協(xié)調(diào)器查 詢下一個待發(fā)送的文件塊的標號；
3接收所述協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的標號，并發(fā)送所述文件塊。
所述方法還包括
收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身無效時，停止發(fā)送。 所述方法還包括
發(fā)出第一文件塊后，若在重傳時限內(nèi)沒有收到應(yīng)答，則重新發(fā)送所述第一文 件塊。
一種子發(fā)送器，所述子發(fā)送器包括查詢模塊和第一發(fā)送模塊；
所述查詢;f莫塊，用于收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時， 向協(xié)調(diào)器查詢下一個待發(fā)送的文件塊的標號；
所述發(fā)送模塊，用于接收所述協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的標號， 并發(fā)送所述文件塊。
所述子發(fā)送器還包括確定模塊，用于收到上次發(fā)送的文件塊的應(yīng)答之后， 確定自身無效時，停止發(fā)送。
所述子發(fā)送器還包括第二發(fā)送模塊，用于發(fā)出第一文件塊后，在重傳時限 內(nèi)沒有收到應(yīng)答，則重新發(fā)送所述第一文件塊。
本發(fā)明實施例提供的技術(shù)方案的有益效果是通過多個子發(fā)送器獨立傳輸 文件塊，大大提高了 UDP文件傳輸?shù)乃俣群托省?br>

圖1是本發(fā)明實施例1提供的一種文件傳輸?shù)姆椒鞒虉D2是本發(fā)明實施例2 4是供的一種調(diào)整子發(fā)送器個數(shù)的方法流程圖3是本發(fā)明實施例3提供的子發(fā)送器結(jié)構(gòu)示意圖4是本發(fā)明實施例4提供的一種調(diào)整子發(fā)送器個數(shù)的裝置結(jié)構(gòu)示意圖5是本發(fā)明實施例4提供的另一種調(diào)整子發(fā)送器個數(shù)的裝置結(jié)構(gòu)示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明 實施方式作進一步地詳細描述。 實施例1
參見圖l，本發(fā)明實施例提供了一種文件傳輸?shù)姆椒?，該方法包?01:收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時，向協(xié)調(diào)器查詢
下一個待發(fā)送的文件塊的標號；
102:接收協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的標號，并發(fā)送具有該標號 的文件塊。
例如，上一個發(fā)送的文件塊的標號為13,則某子發(fā)送器向協(xié)調(diào)器查詢出下 一個待發(fā)送的文件塊的標號為14,則該某子發(fā)送器將發(fā)送標號為14的文件塊， 然后另一個子發(fā)送器再向協(xié)調(diào)器查詢時，下一個待發(fā)送的文件的標號為15。
其中，該方法還包4舌
收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身無效時，停止發(fā)送。
例如，當前有10個子發(fā)送器正在工作，分別為第一子發(fā)送器到第十子發(fā)送
器，協(xié)調(diào)器計算出傳輸當前文件需要的子發(fā)送器個數(shù)為9,則第十子發(fā)送器就處
于無效狀態(tài)。
其中，該方法還包4舌
發(fā)出第 一文件塊后，在RTO (Retransmission Timeout,重傳時限)內(nèi)沒有收 到應(yīng)答，則重新發(fā)送該第一文件塊。
例如，第一子發(fā)送器發(fā)出文件塊10后，該文件塊10即為第一文件塊，在 RTO內(nèi)沒有收到該文件塊10的應(yīng)答，則重新發(fā)送該文件塊10,然后在RTO內(nèi) 還是沒有收到應(yīng)答，則再次重新發(fā)送該文件塊10,以此循環(huán)，直到收到應(yīng)答， 由于所有子發(fā)送器獨立傳輸文件塊，第一子發(fā)送器之外的其他子發(fā)送器仍舊發(fā) 送其他的文件塊，第一子發(fā)送器循環(huán)發(fā)送文件塊10時，文件塊11及以后的文 件塊由其他的子發(fā)送器發(fā)送。
本實施例中，子發(fā)送器的個數(shù)可以通過實施例2提供的方法進行調(diào)整，但不 限于實施例2提供的兩種方法。在使用實施例2提供的方法調(diào)整子發(fā)送器個數(shù) 時，多發(fā)增量等可以相應(yīng)的做些變化。
本發(fā)明實施例通過多個子發(fā)送器獨立傳輸文件塊，大大提高了 UDP文件傳 輸?shù)乃俣群托省?br> 實施例2
本發(fā)明實施例提供了一種調(diào)整如實施例l提供的子發(fā)送器個數(shù)的方法，該方 法包括步驟bl:將第一預(yù)設(shè)時間段內(nèi)的實時平均速度和該預(yù)設(shè)時間段內(nèi)的實時平 均RTT (Round-Trip Time,往返時延)相乘，得到保持當前實時平均速度所需 子發(fā)送器的最少個數(shù)。
其中，設(shè)第一預(yù)設(shè)時間段為5s,則實時平均速度為5s內(nèi)發(fā)出的文件塊總數(shù) /5s，如果上次計算的5s是2到6s，則下次計算的5s可以是3到7s，即時間段 可以有重疊。
其中，該方法包^":
步驟b2:給上述計算出的保持當前實時平均速度所需子發(fā)送器的最少個數(shù) 乘以多發(fā)系數(shù)，得到多發(fā)的子發(fā)送器個數(shù)。
其中，考慮到丟包影響，子發(fā)送器數(shù)目要比保持當前實時平均速度所需子發(fā)
送器的最少個數(shù)多，多發(fā)系數(shù)為丟包率系數(shù)4RTO/實時平均RTT，丟包率系數(shù)可
以是l/(l-實時丟包率)-1,在丟包率較小時丟包率系數(shù)約等于丟包率；多發(fā)系
數(shù)還可以是丟包率系數(shù)*1^0/實時平均RTT與乘系數(shù)增量之和，乘系數(shù)增量可
以在10%-20%之間。
其中，實時丟包率與實時效率的和為1，設(shè)預(yù)設(shè)時間段為5s,實時效率則為
最近5s收到的應(yīng)答it/最近5s發(fā)出的文件塊總數(shù)，如果上次計算的5s是2到6s,
則下次計算的5s可以3到7s,即時間l史可以有重疊。
其中，參見圖2，該方法還包括
步驟b3:給多發(fā)后的子發(fā)送器個數(shù)再加上多發(fā)增量，并和保持當前實時平 均速度所需子發(fā)送器的最少個數(shù)相加，得到實際所需的子發(fā)送器個數(shù)。
其中，考慮到當網(wǎng)絡(luò)變好時速度能夠快速上去，可以加上多發(fā)增量，該多發(fā) 增量可以是l， 2或3，但不限于這三個值。
其中，用實時平均速度乘以實時平均RTT計算出保持當前實時平均速度所 需子發(fā)送器的最少個數(shù)之前，該方法還包括
步驟al:根據(jù)子發(fā)送器個數(shù)，計算第二預(yù)設(shè)時間段內(nèi)發(fā)送文件塊的實時平均 速度和實時效率；
步驟a2:根據(jù)該實時平均速度和實時效率調(diào)整子發(fā)送器個數(shù)，并執(zhí)行步驟 303,直到實時平均速度下降到預(yù)設(shè)閾值或?qū)崟r效率穩(wěn)定在預(yù)設(shè)范圍內(nèi)，執(zhí)^f亍步 驟301。
例如，第二預(yù)設(shè)時間段為5s,則實時平均速度為最近5s內(nèi)發(fā)出的文件塊總 凄t/5s，實時效率為最近5s收到的應(yīng)答凄t/最近5s發(fā)出的文件塊總數(shù)，如果上次
6計算的5s是2到6s,則下次計算的5s為7到lls。
步驟al和步驟a2可以稱為快速調(diào)節(jié)子發(fā)送器個數(shù)的階段,在快速調(diào)節(jié)階段， 計算實時平均速度和實時效率時，時間段沒有重疊。
本發(fā)明實施例提供的調(diào)整子發(fā)送器個數(shù)的方法不限于應(yīng)用在實施例1提供 的文件傳輸過程中，比如，也可以應(yīng)用在語音傳輸?shù)冗^程中，如果應(yīng)用在其他 的場景中，多發(fā)增量等可以相應(yīng)的做些變化。
本發(fā)明實施例通過計算子發(fā)送器個數(shù)，可以控制實時流量，使子發(fā)送器發(fā)送 文件的實時平均速度和實時效率處于最佳狀態(tài)；當距離目標子發(fā)送器個數(shù)比較 遠時，可以先快速調(diào)節(jié)子發(fā)送器個數(shù)，使子發(fā)送器個數(shù)盡快到達子發(fā)送器個數(shù) 最佳值附近，減少了調(diào)整的時間，然后計算子發(fā)送器個數(shù)，子發(fā)送器發(fā)送文件 的實時平均速度和實時效率也就能快速處于最佳狀態(tài)。
實施例3
參見圖3，本發(fā)明實施例提供了一種子發(fā)送器，該子發(fā)送器包括 查詢模塊201和第一發(fā)送模塊202;
查詢模塊201，用于收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時， 向協(xié)調(diào)器查詢下一個纟寺發(fā)送的文件塊的標號；
第一發(fā)送模塊202，用于接收協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的標號， 并發(fā)送具有該標號的文件塊。
例如，上一個發(fā)送的文件塊的標號為13,則某子發(fā)送器向協(xié)調(diào)器查詢出下 一個待發(fā)送的文件塊的標號為14，則該某子發(fā)送器將發(fā)送標號為14的文件塊， 然后另一個子發(fā)送器再向協(xié)調(diào)器查詢時，下一個待發(fā)送的文件的標號為15。
其中，該子發(fā)送器還包括
確定模塊，用于收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身無效時，停止 發(fā)送。
例如，當前有10個子發(fā)送器正在工作，分別為第一子發(fā)送器到第十子發(fā)送 器，協(xié)調(diào)器計算出傳輸當前文件需要的子發(fā)送器個數(shù)為9，則第十子發(fā)送器就處 于無效狀態(tài)。
其中，該子發(fā)送器還包括
第二發(fā)送模塊，用于發(fā)出第一文件塊后，在重傳時限RTO內(nèi)沒有收到應(yīng)答，則重新發(fā)送該第 一文件塊。
例如，第一子發(fā)送器發(fā)出文件塊10后，該文件塊10即為第一文件塊，在 RTO內(nèi)沒有收到該文件塊10的應(yīng)答，則重新發(fā)送該文件塊10,然后在RTO內(nèi) 還是沒有收到應(yīng)答，則再次重新發(fā)送該文件塊10,以此循環(huán)，直到收到應(yīng)答， 由于所有子發(fā)送器獨立傳輸文件塊，第一子發(fā)送器之外的其他子發(fā)送器仍舊發(fā) 送其他的文件塊，第一子發(fā)送器循環(huán)發(fā)送文件塊10時，文件塊11及以后的文 件塊由其他的子發(fā)送器發(fā)送。
本發(fā)明實施例通過多個子發(fā)送器獨立傳輸文件塊，大大提高了 UDP文件傳 輸?shù)乃俣群托省?br> 實施例4
本發(fā)明實施例提供了一種調(diào)整如實施例3提供的子發(fā)送器個數(shù)的裝置，該裝 置包括第一相乘模塊301;
第一相乘模塊301,用于將預(yù)設(shè)時間段內(nèi)的實時平均速度和該預(yù)設(shè)時間段內(nèi) 的實時平均RTT相乘，得到保持實時平均速度所需子發(fā)送器的最少個數(shù)。
其中，設(shè)預(yù)設(shè)時間段為5s,則實時平均速度為5s內(nèi)發(fā)出的文件塊總粉5s， 如果上次計算的5s是2到6s，則下次計算的5s可以是3到7s，即時間段可以 有重疊。
其中，該裝置還包括第二相乘模塊302,用于對第一相乘模塊301得到的 保持當前實時平均速度所需子發(fā)送器的最少個數(shù)乘以多發(fā)系數(shù)，得到多發(fā)的子 發(fā)送器個數(shù)。
其中，考慮到丟包影響，子發(fā)送器數(shù)目要比保持當前實時平均速度所需子發(fā)
送器的最少個數(shù)多，多發(fā)系數(shù)為丟包率系數(shù)*11丁0/實時平均1111\丟包率系數(shù)可
以是l/(l-實時丟包率)-1，在丟包率較小時丟包率系數(shù)約等于丟包率；多發(fā)系
數(shù)還可以是丟包率系數(shù)*11丁0/實時平均RTT與乘系數(shù)增量之和，乘系數(shù)增量可
以在10%-20%之間。
其中，實時丟包率與實時效率的和為1，設(shè)預(yù)設(shè)時間段為5s，實時效率則為
最近5s收到的應(yīng)答數(shù)/最近5s發(fā)出的文件塊總數(shù)，如果上次計算的5s是2到6s,
則下次計算的5s可以3到7s，即時間段可以有重疊。
其中，參見圖4，該裝置還包括相加模塊303,用于對第二相乘模塊302
8得到的多發(fā)后的子發(fā)送器個數(shù)再加上多發(fā)增量，并和保持當前實時平均速度所需子發(fā)送器的最少個數(shù)相加，得到實際所需的子發(fā)送器個數(shù)。
其中，考慮到當網(wǎng)絡(luò)變好時速度能夠快速上去，可以加上多發(fā)增量，該多發(fā)
增量可以是l, 2或3，但不限于這三個值。其中，參見圖5，該裝置還包括
計算模塊304,用于根據(jù)子發(fā)送器個數(shù)，計算第二預(yù)設(shè)時間段內(nèi)發(fā)送文件塊
的實時平均速度和實時效率；
調(diào)整模塊305，用于根據(jù)計算模塊304計算的實時平均速度和實時效率調(diào)整
子發(fā)送器個數(shù)，并通知計算模塊304，直到實時平均速度下降到預(yù)設(shè)閾值或?qū)崟r
效率穩(wěn)定在預(yù)設(shè)范圍內(nèi)，通知第 一相乘模塊301 。
例如，第二預(yù)設(shè)時間段為5s，則實時平均速度為最近5s內(nèi)發(fā)出的文件塊總
數(shù)/5s,實時效率為最近5s收到的應(yīng)答凄t/最近5s發(fā)出的文件塊總數(shù)，如果上次
計算的5s是2到6s,則下次計算的5s為7到lls。
計算模塊304和調(diào)整模塊305可以稱為快速調(diào)節(jié)子發(fā)送器個數(shù)的階段，在快速調(diào)節(jié)階段，計算實時平均速度和實時效率時，時間段沒有重疊。
本發(fā)明實施例提供的調(diào)整子發(fā)送器個數(shù)的裝置不限于應(yīng)用在實施例1提供的文件傳輸過程中，比如，也可以應(yīng)用在語音傳輸?shù)冗^程中，如果應(yīng)用在其他的場景中，多發(fā)增量等可以相應(yīng)的做些變化。
本發(fā)明實施例通過計算子發(fā)送器個數(shù)，可以控制實時流量，使子發(fā)送器發(fā)送文件的實時平均速度和實時效率處于最佳狀態(tài)；當距離目標子發(fā)送器個數(shù)比較遠時，可以先快速調(diào)節(jié)子發(fā)送器個數(shù)，使子發(fā)送器個數(shù)盡快到達子發(fā)送器個數(shù)最佳值附近，減少了調(diào)整的時間，然后計算子發(fā)送器個數(shù)，子發(fā)送器發(fā)送文件的實時平均速度和實時效率也就能快速處于最佳狀態(tài)。
以上所述僅為本發(fā)明的較佳實施例，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
9
權(quán)利要求
1.一種文件傳輸?shù)姆椒?，其特征在于，所述方法包括子發(fā)送器收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時，向協(xié)調(diào)器查詢下一個待發(fā)送的文件塊的標號；接收所述協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的標號，并發(fā)送具有所述標號的文件塊。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述方法還包括 收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身無效時，停止發(fā)送。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述方法還包括 發(fā)出第一文件塊后，若在重傳時限內(nèi)沒有收到應(yīng)答，則重新發(fā)送所述第一文件塊。
4. 一種子發(fā)送器，其特征在于，所述子發(fā)送器包括查詢模塊和第一發(fā)送 模塊；所述查詢模塊，用于收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時， 向協(xié)調(diào)器查詢下一個待發(fā)送的文件塊的標號；所述第一發(fā)送模塊，用于接收所述協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的 標號，并發(fā)送所述文件塊。
5. 根據(jù)權(quán)利要求4所述的子發(fā)送器，其特征在于，所述子發(fā)送器還包括 確定模塊，用于收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身無效時，停止發(fā) 送。
6. 根據(jù)權(quán)利要求4所述的子發(fā)送器，其特征在于，所述子發(fā)送器還包括 第二發(fā)送模塊，用于發(fā)出第一文件塊后，在重傳時限內(nèi)沒有收到應(yīng)答，則重新 發(fā)送所述第一文件塊。
全文摘要
本發(fā)明實施例公開了一種文件傳輸?shù)姆椒白影l(fā)送器，屬于計算機技術(shù)領(lǐng)域。所述方法包括子發(fā)送器收到上次發(fā)送的文件塊的應(yīng)答之后，確定自身有效時，向協(xié)調(diào)器查詢下一個待發(fā)送的文件塊的標號；接收所述協(xié)調(diào)器返回的下一個待發(fā)送的文件塊的標號，并發(fā)送所述具有所述標號的文件塊。所述子發(fā)送器包括查詢模塊和第一發(fā)送模塊。本發(fā)明實施例提供的技術(shù)方案大大提高了UDP文件傳輸?shù)乃俣群托省?br> 文檔編號H04L1/18GK101562508SQ20091008478
公開日2009年10月21日 申請日期2009年5月19日 優(yōu)先權(quán)日2009年5月19日
發(fā)明者陳家君 申請人:騰訊科技(深圳)有限公司