專利名稱：一種多媒體數(shù)據(jù)傳輸系統(tǒng)及其應(yīng)用方法
技術(shù)領(lǐng)域：
本發(fā)明屬于多媒體數(shù)據(jù)傳輸領(lǐng)域，具體涉及一種多媒體數(shù)據(jù)傳輸系統(tǒng)及其應(yīng)用方法。
背景技術(shù)：
目前，RTSP/RTP 協(xié)議是當(dāng)前應(yīng)用比較廣泛一種多媒體傳輸控制方法，其為應(yīng)用提供端到端的實(shí)時(shí)網(wǎng)絡(luò)傳輸。該方法的弊端是每個(gè)流媒體傳輸要使用3個(gè)連接信道一個(gè) RTSP協(xié)議信道，一個(gè)RTCP信道，一個(gè)RTP信道，占用了較多的有限的系統(tǒng)端口(當(dāng)前操作系統(tǒng)最大只支持65535個(gè)端口)，信道建立的握手交互較多，不太適應(yīng)以實(shí)時(shí)性要求高的連接頻繁的場(chǎng)合。另外，TCP/UDP協(xié)議屬于網(wǎng)絡(luò)傳輸層協(xié)議，其中TCP提供IP環(huán)境下的數(shù)據(jù)可靠傳輸，它提供的服務(wù)包括數(shù)據(jù)流傳送、可靠性、有效流控、全雙工操作和多路復(fù)用，通過面向連接、端到端和可靠的數(shù)據(jù)包發(fā)送。通俗說(shuō)，它是事先為所發(fā)送的數(shù)據(jù)開辟出連接好的通道， 然后再進(jìn)行數(shù)據(jù)發(fā)送；而UDP則不為IP提供可靠性、流控或差錯(cuò)恢復(fù)功能。一般來(lái)說(shuō)，TCP 對(duì)應(yīng)的是可靠性要求高的應(yīng)用，而UDP對(duì)應(yīng)的則是可靠性要求低、傳輸經(jīng)濟(jì)的應(yīng)用，本發(fā)明是基于TCP/UDP協(xié)議實(shí)現(xiàn)的系統(tǒng)和方法。

發(fā)明內(nèi)容
針對(duì)現(xiàn)有技術(shù)的缺點(diǎn)，本發(fā)明的目的是提供一種通過使用單通道進(jìn)行多媒體數(shù)據(jù)傳輸和控制提高單個(gè)服務(wù)器能夠管理的鏈接數(shù)據(jù)，提高傳輸握手的鏈接速度的多媒體數(shù)據(jù)傳輸系統(tǒng)及其應(yīng)用方法。為實(shí)現(xiàn)上述目的，本發(fā)明的一種多媒體數(shù)據(jù)傳輸系統(tǒng)包括 流媒體協(xié)議，用于規(guī)定通信消息格式封裝和通信流程；
安裝有流媒體協(xié)議的服務(wù)器，用于接受客戶端連接和連接的管理，接收、解析并響應(yīng)客戶端的請(qǐng)求，以及把多媒體數(shù)據(jù)按流媒體協(xié)議發(fā)送到客戶端；
安裝有流媒體協(xié)議的客戶端，用于建立與服務(wù)器的連接和對(duì)連接進(jìn)行維護(hù)，并將請(qǐng)求按流媒體協(xié)議發(fā)送給服務(wù)器以及對(duì)接收到的響應(yīng)消息進(jìn)行解析返回給應(yīng)用者。作為一種優(yōu)選方案，流媒體協(xié)議的結(jié)構(gòu)包括依次排列的包頭數(shù)據(jù)、負(fù)載數(shù)據(jù)和CRC 校驗(yàn)數(shù)據(jù)。作為進(jìn)一步的優(yōu)選方案，包頭數(shù)據(jù)的長(zhǎng)度為80比特，負(fù)載數(shù)據(jù)的長(zhǎng)度隨實(shí)際傳輸?shù)亩嗝襟w數(shù)據(jù)長(zhǎng)度變化而變化。作為進(jìn)一步的優(yōu)選方案，包頭數(shù)據(jù)的結(jié)構(gòu)包括依次排列的當(dāng)前包長(zhǎng)度、協(xié)議版本、 包類型、校驗(yàn)方式、分包末尾包標(biāo)識(shí)、包序號(hào)、包內(nèi)分包序號(hào)、會(huì)話子通道號(hào)、附加值。作為進(jìn)一步的優(yōu)選方案，當(dāng)前包長(zhǎng)度、協(xié)議版本、包類型、校驗(yàn)方式、分包末尾包標(biāo)識(shí)、包序號(hào)、包內(nèi)分包序號(hào)、會(huì)話子通道號(hào)、附加值長(zhǎng)度分別為M比特、3比特、1比特、3比特、1比特、16比特、16比特、8比特、8比特。
為了實(shí)現(xiàn)第二個(gè)發(fā)明目的，采用如下技術(shù)方案
本發(fā)明提供了一種多媒體數(shù)據(jù)傳輸?shù)膽?yīng)用方法，采用權(quán)利要求1所述系統(tǒng)實(shí)現(xiàn)，包括如下步驟
A.客戶端建立會(huì)話通道客戶端向服務(wù)器發(fā)送連接請(qǐng)求；
B.服務(wù)器接收到連接請(qǐng)求后對(duì)連接請(qǐng)求進(jìn)行解析，建立與客戶端的會(huì)話通道；此時(shí)客戶端等待服務(wù)器的連接請(qǐng)求響應(yīng)，服務(wù)器建立會(huì)話通道后向客戶端返回連接請(qǐng)求結(jié)果；
C.會(huì)話通道建立后，服務(wù)器等待客戶端的心跳或者命令；
D.客戶端向服務(wù)器發(fā)送開始播放命令，請(qǐng)求進(jìn)行多媒體數(shù)據(jù)的傳輸；
E.服務(wù)器接收到開始播放命令后向客戶端傳輸多媒體數(shù)據(jù)；
F.客戶端向服務(wù)器發(fā)送結(jié)束命令并等待服務(wù)器的響應(yīng)；
G.服務(wù)器接收到結(jié)束命令后返回結(jié)束響應(yīng)結(jié)果，停止傳輸多媒體數(shù)據(jù)并拆除與客戶端的會(huì)話通道，會(huì)話結(jié)束；
H.客戶端接收到結(jié)束響應(yīng)結(jié)果后拆除與服務(wù)器的會(huì)話通道。作為一種優(yōu)選方案，客戶端和服務(wù)器中安裝有流媒體協(xié)議，所述流媒體協(xié)議的結(jié)構(gòu)包括依次排列的包頭數(shù)據(jù)、負(fù)載數(shù)據(jù)和CRC校驗(yàn)數(shù)據(jù)。作為進(jìn)一步的優(yōu)選方案，包頭數(shù)據(jù)的長(zhǎng)度為80比特，負(fù)載數(shù)據(jù)的長(zhǎng)度隨實(shí)際傳輸?shù)亩嗝襟w數(shù)據(jù)長(zhǎng)度變化而變化。作為進(jìn)一步的優(yōu)選方案，包頭數(shù)據(jù)的結(jié)構(gòu)包括依次排列的M比特的當(dāng)前包長(zhǎng)度、 3比特的協(xié)議版本、1比特的包類型、3比特的校驗(yàn)方式、1比特的分包末尾包標(biāo)識(shí)、16比特的包序號(hào)、16比特的包內(nèi)分包序號(hào)、8比特的會(huì)話子通道號(hào)、8比特的附加值。作為另一種優(yōu)選方案，客戶端中設(shè)置有存活定時(shí)器keepalive，在進(jìn)行流媒體數(shù)據(jù)傳輸過程中，還進(jìn)行如下步驟
el.客戶端向服務(wù)器發(fā)送keepalive命令，探測(cè)流媒體數(shù)據(jù)傳輸是否發(fā)生擁塞；此時(shí)客戶端還向服務(wù)器發(fā)送控制命令；
e2.客戶端等待服務(wù)器的ke印alive響應(yīng)；
e3.服務(wù)器返回ke印alive響應(yīng)，如果ke印alive響應(yīng)為擁塞，則客戶端向服務(wù)器發(fā)送重傳命令。本發(fā)明的有益效果是
本發(fā)明基于TCP/UDP協(xié)議，通過單個(gè)網(wǎng)絡(luò)連接上進(jìn)行多媒體數(shù)據(jù)和監(jiān)控命令的傳輸， 降低了對(duì)系統(tǒng)端口資源的占用和簡(jiǎn)化了交互流程，大大提高了傳輸握手的鏈接速度，能夠做到毫秒級(jí)的響應(yīng)，而且支持海量連接，比使用RTSP+RTP的方式提高2倍的鏈接數(shù)量，更好適應(yīng)以實(shí)時(shí)媒體傳輸。


圖1 是本發(fā)明一種多媒體數(shù)據(jù)傳輸系統(tǒng)的結(jié)構(gòu)示意圖； 圖2 是本發(fā)明流媒體協(xié)議結(jié)構(gòu)示意圖3 是本發(fā)明一種多媒體數(shù)據(jù)傳輸?shù)膽?yīng)用方法的流程圖。
具體實(shí)施方式
下面結(jié)合實(shí)施例及附圖，對(duì)本發(fā)明作進(jìn)一步地詳細(xì)說(shuō)明，但本發(fā)明的實(shí)施方式不限于此。本發(fā)明如圖1所示，本發(fā)明的一種多媒體數(shù)據(jù)傳輸系統(tǒng)包括流媒體協(xié)議，客戶端和服務(wù)器。如圖2所示，流媒體協(xié)議分別安裝在客戶端和服務(wù)器中，用于規(guī)定通信消息格式封裝和通信流程；其結(jié)構(gòu)包括依次排列的包頭數(shù)據(jù)、負(fù)載數(shù)據(jù)和CRC校驗(yàn)數(shù)據(jù)，包頭數(shù)據(jù)的長(zhǎng)度為80比特，負(fù)載數(shù)據(jù)的長(zhǎng)度隨實(shí)際傳輸?shù)亩嗝襟w數(shù)據(jù)長(zhǎng)度變化而變化。包頭數(shù)據(jù)的結(jié)構(gòu)包括依次排列的M比特的當(dāng)前包長(zhǎng)度、3比特的協(xié)議版本、1比特的包類型、3比特的校驗(yàn)方式、1比特的分包末尾包標(biāo)識(shí)、16比特的包序號(hào)、16比特的包內(nèi)分包序號(hào)、8比特的會(huì)話子通道號(hào)、8比特的附加值。服務(wù)器，用于接受客戶端連接和連接的管理，接收、解析并響應(yīng)客戶端的請(qǐng)求，以及把多媒體數(shù)據(jù)按流媒體協(xié)議發(fā)送到客戶端；
客戶端，用于建立與服務(wù)器的連接和對(duì)連接進(jìn)行維護(hù)，并將請(qǐng)求按流媒體協(xié)議發(fā)送給服務(wù)器以及對(duì)接收到的響應(yīng)消息進(jìn)行解析返回給應(yīng)用者。如圖3所示，采用權(quán)利要求1所述系統(tǒng)實(shí)現(xiàn)的一種多媒體數(shù)據(jù)傳輸?shù)膽?yīng)用方法，客戶端中還設(shè)置有存活定時(shí)器ke印alive，該方法包括如下步驟
A.客戶端建立會(huì)話通道客戶端向服務(wù)器發(fā)送連接請(qǐng)求；
B.服務(wù)器接收到連接請(qǐng)求后對(duì)連接請(qǐng)求進(jìn)行解析，建立與客戶端的會(huì)話通道；此時(shí)客戶端等待服務(wù)器的連接請(qǐng)求響應(yīng)，服務(wù)器建立會(huì)話通道后向客戶端返回連接請(qǐng)求結(jié)果；
C.會(huì)話通道建立后，服務(wù)器等待客戶端的心跳或者命令；
D.客戶端向服務(wù)器發(fā)送開始播放命令，請(qǐng)求進(jìn)行多媒體數(shù)據(jù)的傳輸；
E.服務(wù)器接收到開始播放命令后向客戶端傳輸多媒體數(shù)據(jù)；
el.客戶端向服務(wù)器發(fā)送keepalive命令，探測(cè)流媒體數(shù)據(jù)傳輸是否發(fā)生擁塞；此時(shí)客戶端還向服務(wù)器發(fā)送控制命令；
e2.客戶端等待服務(wù)器的ke印alive響應(yīng)；
e3.服務(wù)器返回ke印alive響應(yīng)，如果ke印alive響應(yīng)為擁塞，則客戶端向服務(wù)器發(fā)送重傳命令；
F.客戶端向服務(wù)器發(fā)送結(jié)束命令并等待服務(wù)器的響應(yīng)；
G.服務(wù)器接收到結(jié)束命令后返回結(jié)束響應(yīng)結(jié)果，停止傳輸多媒體數(shù)據(jù)并拆除與客戶端的會(huì)話通道，會(huì)話結(jié)束；
H.客戶端接收到結(jié)束響應(yīng)結(jié)果后拆除與服務(wù)器的會(huì)話通道。
權(quán)利要求
1.一種多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，包括流媒體協(xié)議，用于規(guī)定通信消息格式封裝和通信流程；安裝有流媒體協(xié)議的服務(wù)器，用于接受客戶端連接和連接的管理，接收、解析并響應(yīng)客戶端的請(qǐng)求，以及把多媒體數(shù)據(jù)按流媒體協(xié)議發(fā)送到客戶端；安裝有流媒體協(xié)議的客戶端，用于建立與服務(wù)器的連接和對(duì)連接進(jìn)行維護(hù)，并將請(qǐng)求按流媒體協(xié)議發(fā)送給服務(wù)器以及對(duì)接收到的響應(yīng)消息進(jìn)行解析返回給應(yīng)用者。
2.根據(jù)權(quán)利要求1所述的多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，流媒體協(xié)議的結(jié)構(gòu)包括依次排列的包頭數(shù)據(jù)、負(fù)載數(shù)據(jù)和CRC校驗(yàn)數(shù)據(jù)。
3.根據(jù)權(quán)利要求2所述的多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，包頭數(shù)據(jù)的長(zhǎng)度為80比特，負(fù)載數(shù)據(jù)的長(zhǎng)度隨實(shí)際傳輸?shù)亩嗝襟w數(shù)據(jù)長(zhǎng)度變化而變化。
4.根據(jù)權(quán)利要求3所述的多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，包頭數(shù)據(jù)的結(jié)構(gòu)包括依次排列的當(dāng)前包長(zhǎng)度、協(xié)議版本、包類型、校驗(yàn)方式、分包末尾包標(biāo)識(shí)、包序號(hào)、包內(nèi)分包序號(hào)、會(huì)話子通道號(hào)、附加值。
5.根據(jù)權(quán)利要求4所述的多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，當(dāng)前包長(zhǎng)度、協(xié)議版本、 包類型、校驗(yàn)方式、分包末尾包標(biāo)識(shí)、包序號(hào)、包內(nèi)分包序號(hào)、會(huì)話子通道號(hào)、附加值長(zhǎng)度分別為24比特、3比特、1比特、3比特、1比特、16比特、16比特、8比特、8比特。
6.一種多媒體數(shù)據(jù)傳輸?shù)膽?yīng)用方法，采用權(quán)利要求1所述系統(tǒng)實(shí)現(xiàn)，其特征在于，包括如下步驟A.客戶端建立會(huì)話通道客戶端向服務(wù)器發(fā)送連接請(qǐng)求；B.服務(wù)器接收到連接請(qǐng)求后對(duì)連接請(qǐng)求進(jìn)行解析，建立與客戶端的會(huì)話通道；此時(shí)客戶端等待服務(wù)器的連接請(qǐng)求響應(yīng)，服務(wù)器建立會(huì)話通道后向客戶端返回連接請(qǐng)求結(jié)果；C.會(huì)話通道建立后，服務(wù)器等待客戶端的心跳或者命令；D.客戶端向服務(wù)器發(fā)送開始播放命令，請(qǐng)求進(jìn)行多媒體數(shù)據(jù)的傳輸；E.服務(wù)器接收到開始播放命令后向客戶端傳輸多媒體數(shù)據(jù)；F.客戶端向服務(wù)器發(fā)送結(jié)束命令并等待服務(wù)器的響應(yīng)；G.服務(wù)器接收到結(jié)束命令后返回結(jié)束響應(yīng)結(jié)果，停止傳輸多媒體數(shù)據(jù)并拆除與客戶端的會(huì)話通道，會(huì)話結(jié)束；H.客戶端接收到結(jié)束響應(yīng)結(jié)果后拆除與服務(wù)器的會(huì)話通道。
7.根據(jù)權(quán)利要求6所述多媒體數(shù)據(jù)傳輸?shù)膽?yīng)用方法，其特征在于，客戶端和服務(wù)器中安裝有流媒體協(xié)議，所述流媒體協(xié)議的結(jié)構(gòu)包括依次排列的包頭數(shù)據(jù)、負(fù)載數(shù)據(jù)和CRC校驗(yàn)數(shù)據(jù)。
8.根據(jù)權(quán)利要求7所述的多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，包頭數(shù)據(jù)的長(zhǎng)度為80比特，負(fù)載數(shù)據(jù)的長(zhǎng)度隨實(shí)際傳輸?shù)亩嗝襟w數(shù)據(jù)長(zhǎng)度變化而變化。
9.根據(jù)權(quán)利要求8所述的多媒體數(shù)據(jù)傳輸系統(tǒng)，其特征在于，包頭數(shù)據(jù)的結(jié)構(gòu)包括依次排列的M比特的當(dāng)前包長(zhǎng)度、3比特的協(xié)議版本、1比特的包類型、3比特的校驗(yàn)方式、 1比特的分包末尾包標(biāo)識(shí)、16比特的包序號(hào)、16比特的包內(nèi)分包序號(hào)、8比特的會(huì)話子通道號(hào)、8比特的附加值。
10.根據(jù)權(quán)利要求7所述多媒體數(shù)據(jù)傳輸?shù)膽?yīng)用方法，其特征在于，客戶端中設(shè)置有存活定時(shí)器keepalive，在進(jìn)行流媒體數(shù)據(jù)傳輸過程中，還進(jìn)行如下步驟el.客戶端向服務(wù)器發(fā)送ke印alive命令，探測(cè)流媒體數(shù)據(jù)傳輸是否發(fā)生擁塞；此時(shí)客戶端還向服務(wù)器發(fā)送控制命令；e2.客戶端等待服務(wù)器的ke印alive響應(yīng)；e3.服務(wù)器返回ke印alive響應(yīng)，如果ke印alive響應(yīng)為擁塞，則客戶端向服務(wù)器發(fā)送重傳命令。
全文摘要
本發(fā)明屬于多媒體數(shù)據(jù)傳輸領(lǐng)域，具體涉及一種多媒體數(shù)據(jù)傳輸系統(tǒng)及其應(yīng)用方法。所述系統(tǒng)包括流媒體協(xié)議，用于規(guī)定通信消息格式封裝和通信流程；安裝有流媒體協(xié)議的服務(wù)器，用于接受客戶端連接和連接的管理，接收、解析并響應(yīng)客戶端的請(qǐng)求，以及把多媒體數(shù)據(jù)按流媒體協(xié)議發(fā)送到客戶端；安裝有流媒體協(xié)議的客戶端，用于建立與服務(wù)器的連接和對(duì)連接進(jìn)行維護(hù)，并將請(qǐng)求按流媒體協(xié)議發(fā)送給服務(wù)器以及對(duì)接收到的響應(yīng)消息進(jìn)行解析返回給應(yīng)用者。本發(fā)明通過使用單通道進(jìn)行多媒體數(shù)據(jù)傳輸和控制提高單個(gè)服務(wù)器能夠管理的鏈接數(shù)據(jù)，提高傳輸握手的鏈接速度。
文檔編號(hào)H04L29/06GK102340506SQ20111029890
公開日2012年2月1日 申請(qǐng)日期2011年9月29日 優(yōu)先權(quán)日2011年9月29日
發(fā)明者鄒陽(yáng)星 申請(qǐng)人:廣東高新興通信股份有限公司