專利名稱：數(shù)據(jù)包傳輸?shù)姆椒ā⒀b置和系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及數(shù)據(jù)傳輸技術(shù)，特別涉及數(shù)據(jù)包傳輸?shù)姆椒?、裝置和系統(tǒng)。
背景技術(shù)：
隨著通信技術(shù)的不斷發(fā)展，網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)量也在大幅增長，針對大 數(shù)據(jù)量的數(shù)據(jù)傳輸，目前存在一種分包發(fā)送的方案。
以流媒體業(yè)務(wù)為例，該業(yè)務(wù)中的大數(shù)據(jù)量數(shù)據(jù)都采用用戶數(shù)據(jù)報協(xié)議
(UDP)發(fā)送，服務(wù)器將大數(shù)據(jù)分成若干UDP數(shù)據(jù)包向客戶端發(fā)送。按照 現(xiàn)有技術(shù)中對UDP數(shù)據(jù)包發(fā)送的方案，大于1K的UDP數(shù)據(jù)包需分包發(fā)送， 也就是說服務(wù)器向客戶端發(fā)送一個UDP數(shù)據(jù)包的最大容量為1K。
圖1為現(xiàn)有技術(shù)中客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)牧鞒虉D，該流程包
括
步驟101:服務(wù)器接收客戶端發(fā)送的數(shù)據(jù)傳輸請求。
步驟102:服務(wù)器向客戶端返回響應(yīng)，告知客戶端數(shù)據(jù)傳輸過程中下發(fā) UDP數(shù)據(jù)包的默認容量為最大1K。
步驟103:服務(wù)器按照每個UDP數(shù)據(jù)包為最大1K的容量，將傳輸?shù)臄?shù) 據(jù)分成若干個UDP數(shù)據(jù)包向客戶端逐個下發(fā)。
可見，現(xiàn)有技術(shù)中采用分包發(fā)送來處理大數(shù)據(jù)量數(shù)據(jù)傳輸?shù)姆桨福捎?分包后的每個數(shù)據(jù)包容量大小為一固定值，針對大數(shù)據(jù)量數(shù)據(jù)來說，則需要 更多的服務(wù)器設(shè)備同時進行數(shù)據(jù)下發(fā)來保證傳輸效率，無疑為運營商增加了 成本，如果考慮運營商成本仍使用相同數(shù)量的服務(wù)器設(shè)備進行數(shù)據(jù)下發(fā)，則 會導(dǎo)致數(shù)據(jù)傳輸效率大大降低，降低了用戶體驗。

發(fā)明內(nèi)容
本發(fā)明提供一種數(shù)據(jù)包傳輸?shù)姆椒ǎ摲椒軌蚴褂玫统杀緦崿F(xiàn)大數(shù)據(jù) 量數(shù)據(jù)的高效率傳輸。
本發(fā)明提供一種服務(wù)器，該服務(wù)器能夠使用低成本實現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的 高效率傳輸。
本發(fā)明提供一種客戶端，該客戶端能夠使用低成本實現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的 高效率傳輸。
本發(fā)明提供一種數(shù)據(jù)包傳輸?shù)南到y(tǒng)，該系統(tǒng)能夠使用低成本實現(xiàn)大數(shù)據(jù) 量數(shù)據(jù)的高效率傳輸。
本發(fā)明的技術(shù)方案是這樣實現(xiàn)的 一種數(shù)據(jù)包傳輸?shù)姆椒ǎ摲椒ò?服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求；
服務(wù)器允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù) 據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
一種服務(wù)器，該服務(wù)器包括
請求處理模塊，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，解析出是否 允許客戶端請求的數(shù)據(jù)包容量；
數(shù)據(jù)下發(fā)模塊，用于在所述請求處理模塊解析出允許客戶端請求的數(shù)據(jù) 包容量時，按照客戶端請求的數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
一種客戶端，該客戶端包括
請求發(fā)送模塊，用于向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的請求； 數(shù)據(jù)接收模塊，用于接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)。
一種數(shù)據(jù)包傳輸?shù)南到y(tǒng)，該系統(tǒng)包括
服務(wù)器，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，在允許客戶端請求 的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)；
客戶端，用于向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的請求，接收服務(wù)器按 照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)。
可見，本發(fā)明提供的數(shù)據(jù)包傳輸?shù)姆椒?、裝置和系統(tǒng)，服務(wù)器接收客戶 端增加下發(fā)數(shù)據(jù)包容量的請求，并在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時， 按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，因此通過客戶端主動 探測服務(wù)器可接受的下發(fā)數(shù)據(jù)包容量，在服務(wù)器允許的情況下，發(fā)送大于默 認容量的數(shù)據(jù)包，從而實現(xiàn)不增加服務(wù)器設(shè)備的情況下，花費更少的時間完 成大數(shù)據(jù)量數(shù)據(jù)的傳輸，即使用低成本實現(xiàn)了大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。


圖1為現(xiàn)有技術(shù)中客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)牧鞒虉D2為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ牧鞒虉D3為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ膶嵤├鞒虉D4為本發(fā)明提供的服務(wù)器的結(jié)構(gòu)示意圖5為本發(fā)明提供的客戶端的結(jié)構(gòu)示意圖6為本發(fā)明數(shù)據(jù)包傳輸?shù)南到y(tǒng)結(jié)構(gòu)示意圖。
具體實施例方式
為使本發(fā)明的目的和優(yōu)點更加清楚，下面結(jié)合附圖和實施例對本發(fā)明做
進一步的詳細iJL明。
首先介紹本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ā?br> 圖2為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ牧鞒虉D，該流程包括
步驟201:服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求。
步驟202:服務(wù)器允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請
求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
本發(fā)明提供的數(shù)據(jù)包傳輸?shù)姆椒?，服?wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容
量的請求，并在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，因此通過客戶端主動探測服務(wù)器可接受的 下發(fā)數(shù)據(jù)包容量，在服務(wù)器允許的情況下，發(fā)送大于常規(guī)容量的數(shù)據(jù)包，從 而實現(xiàn)不增加服務(wù)器設(shè)備的情況下，花費更少的時間完成大數(shù)據(jù)量數(shù)據(jù)的傳 輸，即使用低成本實現(xiàn)了大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。
上述步驟201中，增加下發(fā)數(shù)據(jù)包容量的請求，可以是客戶端在發(fā)送數(shù) 據(jù)傳輸請求并接收到服務(wù)器返回的默認數(shù)據(jù)包容量后首次發(fā)送的請求，在這 種情況下，步驟202中可以進一步包括服務(wù)器不允許客戶端請求的下發(fā)數(shù) 據(jù)包容量時，按照下發(fā)數(shù)據(jù)包的默認容量向客戶端下發(fā)數(shù)據(jù)；上述步驟201 中，增加下發(fā)數(shù)據(jù)包容量的請求，也可以是服務(wù)器上一次允許客戶端請求的 下發(fā)數(shù)據(jù)包容量之后再次發(fā)送的請求，在這種情況下，步驟202中可以進一 步包括服務(wù)器不允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照上一次允許客 戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
上述步驟201與步驟202之間還可以進一步包括服務(wù)器向客戶端返回 允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，客戶端可以根據(jù)接收到的響應(yīng)，在服務(wù) 器允許所請求的下發(fā)數(shù)據(jù)包容量時，向服務(wù)器再次請求增加下發(fā)數(shù)據(jù)包容 量，以實現(xiàn)更高效率的數(shù)據(jù)傳輸。
利用本發(fā)明實施例提供的方法，可以構(gòu)成一種新的組網(wǎng)模式，即根據(jù)網(wǎng) 絡(luò)傳輸狀況，自動適應(yīng)數(shù)據(jù)傳輸?shù)哪Ｊ?，稱為自適應(yīng)網(wǎng)絡(luò)組網(wǎng)模式。
下面以C/S應(yīng)用中UDP公網(wǎng)中的數(shù)據(jù)傳輸為例，舉出本發(fā)明數(shù)據(jù)傳輸 的方法的一個實施例，在該實施例中，服務(wù)器下發(fā)的數(shù)據(jù)包默認容量為最大 1K。
圖3為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ膶嵤├鞒虉D，該流程包括 步驟301:服務(wù)器接收客戶端發(fā)送的數(shù)據(jù)傳輸請求。 步驟302:服務(wù)器向客戶端返回響應(yīng)，告知客戶端數(shù)據(jù)傳輸過程中下發(fā) 的每個UDP數(shù)據(jù)包為最大1K。
上述步驟301 ~步驟302為數(shù)據(jù)傳輸中的常規(guī)步驟，這里不再贅述。 步驟303:服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，在本實施例中，客戶端請求的下發(fā)數(shù)據(jù)包容量為4K。
步驟304:服務(wù)器判斷是否允許客戶端請求的下發(fā)數(shù)據(jù)包容量，如果允 許，執(zhí)行步驟305，如果不允許，執(zhí)行步驟308。
步驟305:服務(wù)器向客戶端返回允許所請求的下發(fā)數(shù)據(jù)包容量的響應(yīng)， 并接收客戶端增加下發(fā)數(shù)據(jù)包容量的再次請求，本實施例中，客戶端再次請 求的下發(fā)數(shù)據(jù)包容量為8K。
步驟306:服務(wù)器判斷是否允許客戶端再次請求的下發(fā)數(shù)據(jù)包容量，如 果允許，執(zhí)行步驟307，如果不允許，執(zhí)行步驟309。
步驟307:服務(wù)器向客戶端返回允許所請求的下發(fā)數(shù)據(jù)包容量的響應(yīng)， 并按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，結(jié)束流程。在本實 施例中，服務(wù)器是按照8K向客戶端下發(fā)數(shù)據(jù)。
步驟308:服務(wù)器向客戶端返回不允許所請求的下發(fā)數(shù)據(jù)包容量的響應(yīng)， 并按照下發(fā)數(shù)據(jù)包的默認容量向客戶端下發(fā)數(shù)據(jù)，結(jié)束流程。在本實施例中， 服務(wù)器是按照1K向客戶端下發(fā)數(shù)據(jù)。
步驟309:服務(wù)器向客戶端返回不允許所請求的下發(fā)數(shù)據(jù)包容量的響應(yīng)， 并按照上一次允許客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，結(jié)束流 程。在本實施例中，服務(wù)器是按照4K向客戶端下發(fā)數(shù)據(jù)。
圖3所示流程，是以C/S應(yīng)用中UDP公網(wǎng)中的數(shù)據(jù)傳輸為例，介紹了 客戶端可以連續(xù)兩次主動向服務(wù)器請求下發(fā)數(shù)據(jù)包容量的方法，該實施例中 客戶端所請求的具體下發(fā)數(shù)據(jù)包容量大小以及請求的次數(shù)，在實際應(yīng)用中， 都是可以改變的，并不局限與上述具體的具體數(shù)值。
其次，介紹本發(fā)明數(shù)據(jù)包傳輸?shù)难b置，包括服務(wù)器和客戶端。
圖4為本發(fā)明提供的服務(wù)器結(jié)構(gòu)示意圖，該服務(wù)器包括 請求處理4莫塊，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，解析出是否 允許客戶端請求的數(shù)據(jù)包容量。
數(shù)據(jù)下發(fā)模塊，用于在所述請求處理模塊解析出允許客戶端請求的數(shù)據(jù) 包容量時，按照客戶端請求的數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
本發(fā)明提供的數(shù)據(jù)包傳輸?shù)姆?wù)器，接收客戶端增加下發(fā)數(shù)據(jù)包容量的 請求，并在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù) 據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。因此通過客戶端主動探測服務(wù)器可接受的下發(fā) 數(shù)據(jù)包容量，在服務(wù)器允許的情況下，發(fā)送大于默認容量的數(shù)據(jù)包，從而實 現(xiàn)不增加服務(wù)器個數(shù)的情況下，花費更少的時間完成大數(shù)據(jù)量數(shù)據(jù)的傳輸， 即使用低成本實現(xiàn)了大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。
進一步地，本發(fā)明服務(wù)器的請求處理模塊，其內(nèi)部結(jié)構(gòu)可以包括 第一處理執(zhí)行單元，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，按照第
二處理執(zhí)行單元得出的解析結(jié)果，向客戶端返回是否允許所請求下發(fā)數(shù)據(jù)包容
量的響應(yīng)。
第二處理執(zhí)行單元，用于解析第一處理執(zhí)行單元接收的增加下發(fā)數(shù)據(jù)包 容量的請求，解析出是否允許客戶端請求的數(shù)據(jù)包容量。
基于上述請求處理模塊的內(nèi)部結(jié)構(gòu)，可以使服務(wù)器及時告知客戶端是否 允許所請求的下發(fā)數(shù)據(jù)包容量，以便客戶端在收到允許所請求的下發(fā)數(shù)據(jù)包 容量時，再次請求增加下發(fā)數(shù)據(jù)包容量，以實現(xiàn)更高效率的數(shù)據(jù)傳輸。
進一步地，本發(fā)明服務(wù)器中的數(shù)據(jù)下發(fā)模塊，其內(nèi)部結(jié)構(gòu)可以包括
第一數(shù)據(jù)下發(fā)單元，用于在所述請求為客戶端增加下發(fā)數(shù)據(jù)包容量的首次 請求時，如果所述請求處理沖莫塊解析出允許客戶端請求的下發(fā)數(shù)據(jù)包容量，按 照客戶端請求的數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，如果所述請求處理模塊解析出 不允許客戶端請求的數(shù)據(jù)包容量，按照下發(fā)數(shù)據(jù)包的默認容量向客戶端下發(fā)數(shù) 據(jù)。
第二數(shù)據(jù)下發(fā)單元，用于所述請求為服務(wù)器上一次允許客戶端請求的下 發(fā)數(shù)據(jù)包容量之后，所述客戶端增加下發(fā)數(shù)據(jù)包容量的再次請求時，如果所 述請求處理模塊解析出允許客戶端請求的數(shù)據(jù)包容量，按照客戶端請求的下 發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，如果所述請求處理模塊解析出不允許客戶 端請求的數(shù)據(jù)包容量，按照上一次允許客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶 端下發(fā)數(shù)據(jù)。 基于上述數(shù)據(jù)下發(fā)模塊的內(nèi)部結(jié)構(gòu)，針對客戶端增加下發(fā)數(shù)據(jù)包容量的 首次請求，服務(wù)器可以在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端 請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，而在不允許客戶端請求的下發(fā)數(shù)
據(jù)包容量時，按照默認容量向客戶端下發(fā)數(shù)據(jù)；針對客戶端增加下發(fā)數(shù)據(jù)包 容量的再次請求時，服務(wù)器可以在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按 照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，而在不允許客戶端請求 的下發(fā)數(shù)據(jù)包容量時，按照上一次允許客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶 端下發(fā)數(shù)據(jù)。服務(wù)器在處理客戶端發(fā)送的增加下發(fā)數(shù)據(jù)包容量請求時，可以 進行靈活處理。
如果本發(fā)明的服務(wù)器在C/S應(yīng)用中UDP公網(wǎng)中進行數(shù)據(jù)傳輸，服務(wù)器 下發(fā)每個UDP數(shù)據(jù)包的默認容量為最大1K,服務(wù)器基于其內(nèi)部結(jié)構(gòu)，可以 按照如下方式工作.'
第一處理執(zhí)行單元接收客戶端發(fā)送的增加下發(fā)數(shù)據(jù)包容量的首次請求， 請求大于1K的下發(fā)數(shù)據(jù)包容量，例如4K;第二處理執(zhí)行單元解析出是否允 許客戶端請求的數(shù)據(jù)包容量，如果是，則由第一處理執(zhí)行單元向客戶端返回
允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，并由第一數(shù)據(jù)下發(fā)單元按照客戶端請求
的下發(fā)數(shù)據(jù)包容量4K向客戶端下發(fā)數(shù)據(jù)，否則，由第一處理執(zhí)行單元向客
戶端返回不允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，并由第 一數(shù)據(jù)下發(fā)單元按照
下發(fā)數(shù)據(jù)包的默認容量1K向客戶端下發(fā)數(shù)據(jù)。
第一處理執(zhí)行單元接收客戶端發(fā)送的增加下發(fā)數(shù)據(jù)包容量的再次請求，
請求大于4K的數(shù)據(jù)包，例如8K;第二處理執(zhí)行單元解析出是否允許客戶端
請求的數(shù)據(jù)包容量，如果是，則由第一處理執(zhí)行單元向客戶端返回允許所請
求下發(fā)數(shù)據(jù)包容量的響應(yīng)，并由第二數(shù)據(jù)下發(fā)單元按照客戶端請求的數(shù)據(jù)包
容量向客戶端下發(fā)數(shù)據(jù)，否則，由第一處理執(zhí)行單元向客戶端返回不允許所
請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，并由第二數(shù)據(jù)下發(fā)單元按照上一次允許客戶端
請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，即按照4K向客戶端下發(fā)數(shù)據(jù)。
圖5為本發(fā)明提供的客戶端結(jié)構(gòu)示意圖，該客戶端包括
請求發(fā)送模塊，用于向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的請求。
數(shù)據(jù)接收模塊，用于接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)。
進一步地，該客戶端中可以進一步包括響應(yīng)接收模塊，用于接收服務(wù) 器返回的是否允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)。
在本發(fā)明的客戶端中進一步包括響應(yīng)接收模塊時，客戶端可以及時獲知 服務(wù)器是否允許所請求的下發(fā)數(shù)據(jù)包容量，從而在服務(wù)器允許所請求的下發(fā) 數(shù)據(jù)包容量時，再次請求增加下發(fā)數(shù)據(jù)包容量，從而進一步提高數(shù)據(jù)傳輸效 率。
進一步地，上述數(shù)據(jù)接收模塊的內(nèi)部結(jié)構(gòu)可以包括
第一數(shù)據(jù)接收單元，用于在所述請求為增加下發(fā)數(shù)據(jù)包容量的首次請求時， 如果所述響應(yīng)接收模塊接收服務(wù)器返回的允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)， 接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)，如果所述響應(yīng)接收模塊 接收服務(wù)器返回的不允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，接收服務(wù)器按照下發(fā) 數(shù)據(jù)包的默認容量下發(fā)的數(shù)據(jù)。
第二數(shù)據(jù)接收單元，用于所述請求為服務(wù)器上一次允許所請求的下發(fā)數(shù)
據(jù)包容量之后，增加下發(fā)數(shù)據(jù)包容量的再次請求時，如果所述響應(yīng)接收模塊 接收服務(wù)器返回的允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，接收服務(wù)器按照所請 求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)，如果所述響應(yīng)接收模塊接收服務(wù)器返回的 不允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，接收服務(wù)器按照上一次所允許的下發(fā) 數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)。
基于上述數(shù)據(jù)接收模塊的內(nèi)部結(jié)構(gòu)，客戶端在接收到服務(wù)器返回的允許 所請求的下發(fā)數(shù)據(jù)包容量的響應(yīng)時，可以接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù) 包容量下發(fā)的數(shù)據(jù)，在接收到服務(wù)器返回的不允許所請求的下發(fā)數(shù)據(jù)包容量 的響應(yīng)時，如果是首次請求增加下發(fā)數(shù)據(jù)包容量，則可以接收服務(wù)器按照下 發(fā)數(shù)據(jù)包的默認容量下發(fā)的數(shù)據(jù)，如果是再次請求增加下發(fā)數(shù)據(jù)包容量，則 可以接收服務(wù)器按照上一次允許的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)，使客戶端接收數(shù)據(jù)具有了更好的靈活性。
如果本發(fā)明的客戶端在C/S應(yīng)用中UDP公網(wǎng)中進行數(shù)據(jù)傳輸，服務(wù)器 下發(fā)每個UDP數(shù)據(jù)包的默認容量為最大1K，客戶端基于其內(nèi)部結(jié)構(gòu)，可以 按照如下方式工作
請求發(fā)送模塊向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的首次請求，請求大于 1K的下發(fā)數(shù)據(jù)包容量，例如4K;如果響應(yīng)接收模塊接收服務(wù)器返回的允許 所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，第一數(shù)據(jù)接收單元接收服務(wù)器按照所請求的 下發(fā)數(shù)據(jù)包容量4K下發(fā)的數(shù)據(jù)，如果響應(yīng)接收模塊接收服務(wù)器返回的不允 許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，第一數(shù)據(jù)接收單元接收服務(wù)器按照下發(fā)數(shù) 據(jù)包的默認容量1K下發(fā)的數(shù)據(jù)。
請求發(fā)送模塊向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的再次請求，請求大于 4K的下發(fā)數(shù)據(jù)包容量，例如8K;如果響應(yīng)接收模塊接收服務(wù)器返回的允許 所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，第二數(shù)據(jù)接收單元接收服務(wù)器按照所請求的 下發(fā)數(shù)據(jù)包容量8K下發(fā)的數(shù)據(jù)，如果響應(yīng)接收模塊接收服務(wù)器返回的不允 許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，第二數(shù)據(jù)接收單元接收服務(wù)器按照上一次 允許的下發(fā)數(shù)據(jù)包容量4K下發(fā)的數(shù)據(jù)。
使用本發(fā)明提供的服務(wù)器和客戶端，可以組成本發(fā)明數(shù)據(jù)傳輸?shù)南到y(tǒng)，
圖6為本發(fā)明數(shù)據(jù)傳輸?shù)南到y(tǒng)結(jié)構(gòu)示意圖，在圖6所示系統(tǒng)中，服務(wù)器和客 戶端的內(nèi)部結(jié)構(gòu)與本發(fā)明提供的服務(wù)器和客戶端的內(nèi)部結(jié)構(gòu)相同。
綜上所述，以上僅為本發(fā)明的較佳實施例而已，并非用于限定本發(fā)明的 保護范圍。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改 進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
1、一種數(shù)據(jù)包傳輸?shù)姆椒?，其特征在于，該方法包括服?wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求；服務(wù)器允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
2、 如權(quán)利要求l所述的方法，其特征在于，所述服務(wù)器接收客戶端增加下 發(fā)數(shù)據(jù)包容量的請求、與按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù) 之間，進一步包括服務(wù)器向客戶端返回允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)。
3、 如權(quán)利要求2所述的方法，其特征在于，所述請求為客戶端增加下發(fā)數(shù) 據(jù)包容量的首次請求；所述服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求之后進一 步包括 服務(wù)器不允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，向客戶端返回不允許所請 求的下發(fā)數(shù)據(jù)包容量響應(yīng)，按照下發(fā)數(shù)據(jù)包的默認容量向客戶端下發(fā)數(shù)據(jù)。
4、 如權(quán)利要求2所述的方法，其特征在于，所述請求為服務(wù)器上一次允許 客戶端請求的下發(fā)數(shù)據(jù)包容量之后，所述客戶端增加下發(fā)數(shù)據(jù)包容量的再次請 求；所述服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求之后進一步包括服務(wù)器不允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，向客戶端返回不允許所請 求的下發(fā)數(shù)據(jù)包容量響應(yīng)，按照上一次允許客戶端請求的下發(fā)數(shù)據(jù)包容量向客 戶端下發(fā)數(shù)據(jù)。
5、 一種服務(wù)器，其特征在于，該服務(wù)器包括請求處理模塊，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，解析出是否 允許客戶端請求的數(shù)據(jù)包容量；數(shù)據(jù)下發(fā)模塊，用于在所述請求處理模塊解析出允許客戶端請求的數(shù)據(jù)包 容量時，按照客戶端請求的數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
6、 如權(quán)利要求5所述的服務(wù)器，其特征在于，所述請求處理模塊包括 第一處理執(zhí)行單元，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，按照第二處理執(zhí)行單元得出的解析結(jié)果，向客戶端返回是否允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)；第二處理執(zhí)行單元，用于解析第一處理執(zhí)行單元接收的增加下發(fā)數(shù)據(jù)包容 量的請求，解析出是否允許客戶端請求的數(shù)據(jù)包容量。
7、 如權(quán)利要求5所述的服務(wù)器，其特征在于，所述數(shù)據(jù)下發(fā)模塊包括 第一數(shù)據(jù)下發(fā)單元，用于在所述請求為客戶端增加下發(fā)數(shù)據(jù)包容量的首次請求時，如果所述請求處理模塊解析出允許客戶端請求的下發(fā)數(shù)據(jù)包容量，按 照客戶端請求的數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，如果所述請求處理模塊解析出 不允許客戶端請求的數(shù)據(jù)包容量，按照下發(fā)數(shù)據(jù)包的默認容量向客戶端下發(fā)數(shù) 據(jù)；第二數(shù)據(jù)下發(fā)單元，用于所述請求為服務(wù)器上一次允許客戶端請求的下發(fā) 數(shù)據(jù)包容量之后，所述客戶端增加下發(fā)數(shù)據(jù)包容量的再次請求時，如果所述請 求處理模塊解析出允許客戶端請求的數(shù)據(jù)包容量，按照客戶端請求的下發(fā)數(shù)據(jù) 包容量向客戶端下發(fā)數(shù)據(jù)，如果所述請求處理模塊解析出不允許客戶端請求的 數(shù)據(jù)包容量，按照上一次允許客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。
8、 一種客戶端，其特征在于，該客戶端包括 請求發(fā)送模塊，用于向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的請求； 數(shù)據(jù)接收模塊，用于接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)。
9、 如權(quán)利要求8所述的客戶端，其特征在于，該客戶端中進一步包括響 應(yīng)接收模塊，用于接收服務(wù)器返回的是否允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)。
10、 如權(quán)利要求9所述的客戶端，其特征在于，所述數(shù)據(jù)接收模塊包括 第一數(shù)據(jù)接收單元，用于在所述請求為增加下發(fā)lt據(jù)包容量的首次請求時，如果所述響應(yīng)接收模塊接收服務(wù)器返回的允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)， 接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)，如果所述響應(yīng)接收^t塊 接收服務(wù)器返回的不允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，接收服務(wù)器按照下發(fā) 數(shù)據(jù)包的默認容量下發(fā)的數(shù)據(jù)；第二數(shù)據(jù)接收單元，用于所述請求為服務(wù)器上一次允許所請求的下發(fā)數(shù)據(jù)包容量之后，增加下發(fā)數(shù)據(jù)包容量的再次請求時，如果所述響應(yīng)接收模塊接收 服務(wù)器返回的允許所請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，接收服務(wù)器按照所請求的下 發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)，如果所述響應(yīng)接收模塊接收服務(wù)器返回的不允許所 請求下發(fā)數(shù)據(jù)包容量的響應(yīng)，接收服務(wù)器按照上一次所允許的下發(fā)數(shù)據(jù)包容量 下發(fā)的數(shù)據(jù)。
11、 一種數(shù)據(jù)包傳輸?shù)南到y(tǒng)，其特征在于，該系統(tǒng)包括服務(wù)器，用于接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)； 客戶端，用于向服務(wù)器發(fā)送增加下發(fā)數(shù)據(jù)包容量的請求，接收服務(wù)器按照所請求的下發(fā)數(shù)據(jù)包容量下發(fā)的數(shù)據(jù)。
全文摘要
本發(fā)明公開了一種數(shù)據(jù)包傳輸?shù)姆椒ǎ摲椒òǚ?wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求；服務(wù)器允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。本發(fā)明還公開了兩種數(shù)據(jù)包傳輸?shù)难b置和一種數(shù)據(jù)包傳輸?shù)南到y(tǒng)。應(yīng)用本發(fā)明，能夠使用低成本實現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。
文檔編號H04L12/56GK101197778SQ20071030164
公開日2008年6月11日 申請日期2007年12月27日 優(yōu)先權(quán)日2007年12月27日
發(fā)明者華有為 申請人:騰訊科技(深圳)有限公司