[發(fā)明專利]數(shù)據(jù)包傳輸?shù)姆椒ā⒀b置和系統(tǒng)

有效

• 申請?zhí)枺?/td>: 200710301641.0
• 申請日: 2007-12-27
• 公開（公告）號: CN101197778A
• 公開（公告）日: 2008-06-11
• 發(fā)明（設(shè)計）人: 華有為
• 申請（專利權(quán)）人: 騰訊科技（深圳）有限公司
• 主分類號: H04L12/56
• 分類號: H04L12/56;H04L12/58
• 代理公司: 北京德琦知識產(chǎn)權(quán)代理有限公司
• 代理人: 羅正云;宋志強(qiáng)

技術(shù)領(lǐng)域

本發(fā)明涉及數(shù)據(jù)傳輸技術(shù)，特別涉及數(shù)據(jù)包傳輸?shù)姆椒ā⒀b置和系統(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ù)包的默認(rèn)容量為最大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è)備同時進(jìn)行數(shù)據(jù)下發(fā)來保證傳輸效率，無疑為運(yùn)營商增加了成本，如果考慮運(yùn)營商成本仍使用相同數(shù)量的服務(wù)器設(shè)備進(jìn)行數(shù)據(jù)下發(fā)，則會導(dǎo)致數(shù)據(jù)傳輸效率大大降低，降低了用戶體驗(yàn)。

發(fā)明內(nèi)容

本發(fā)明提供一種數(shù)據(jù)包傳輸?shù)姆椒ǎ摲椒軌蚴褂玫统杀緦?shí)現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。

本發(fā)明提供一種服務(wù)器，該服務(wù)器能夠使用低成本實(shí)現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。

本發(fā)明提供一種客戶端，該客戶端能夠使用低成本實(shí)現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。

本發(fā)明提供一種數(shù)據(jù)包傳輸?shù)南到y(tǒng)，該系統(tǒng)能夠使用低成本實(shí)現(xiàn)大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。

本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的：

一種數(shù)據(jù)包傳輸?shù)姆椒ǎ摲椒òǎ?/p>

服務(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ù)姆椒ā⒀b置和系統(tǒng)，服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求，并在允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)，因此通過客戶端主動探測服務(wù)器可接受的下發(fā)數(shù)據(jù)包容量，在服務(wù)器允許的情況下，發(fā)送大于默認(rèn)容量的數(shù)據(jù)包，從而實(shí)現(xiàn)不增加服務(wù)器設(shè)備的情況下，花費(fèi)更少的時間完成大數(shù)據(jù)量數(shù)據(jù)的傳輸，即使用低成本實(shí)現(xiàn)了大數(shù)據(jù)量數(shù)據(jù)的高效率傳輸。

附圖說明

圖1為現(xiàn)有技術(shù)中客戶端與服務(wù)器之間數(shù)據(jù)傳輸?shù)牧鞒虉D；

圖2為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ牧鞒虉D；

圖3為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ膶?shí)施例流程圖；

圖4為本發(fā)明提供的服務(wù)器的結(jié)構(gòu)示意圖；

圖5為本發(fā)明提供的客戶端的結(jié)構(gòu)示意圖；

圖6為本發(fā)明數(shù)據(jù)包傳輸?shù)南到y(tǒng)結(jié)構(gòu)示意圖。

具體實(shí)施方式

為使本發(fā)明的目的和優(yōu)點(diǎn)更加清楚，下面結(jié)合附圖和實(shí)施例對本發(fā)明做進(jìn)一步的詳細(xì)說明。

首先介紹本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ā?/p>

圖2為本發(fā)明數(shù)據(jù)包傳輸?shù)姆椒ǖ牧鞒虉D，該流程包括：

步驟201：服務(wù)器接收客戶端增加下發(fā)數(shù)據(jù)包容量的請求。

步驟202：服務(wù)器允許客戶端請求的下發(fā)數(shù)據(jù)包容量時，按照客戶端請求的下發(fā)數(shù)據(jù)包容量向客戶端下發(fā)數(shù)據(jù)。