本發(fā)明涉及通信領(lǐng)域，具體而言，涉及一種文件的發(fā)送方法及裝置。

背景技術(shù)：

在基于IP多媒體子系統(tǒng)(IP Multimedia Subsystem，簡稱為IMS)網(wǎng)絡(luò)的富通信套件(Rich Communication Suite，簡稱為RCS)業(yè)務(wù)中，文件傳輸采用會話初始協(xié)議(Session Initialization Protocol，簡稱為SIP)和消息會話中繼協(xié)議(Message Session Relay Protocol，簡稱為MSRP)相結(jié)合的方法來實現(xiàn)，通過SIP進行信令協(xié)商，通過MSRP進行文件數(shù)據(jù)傳輸。協(xié)議規(guī)定MSRP發(fā)送消息可以不用等到收到響應(yīng)才發(fā)送下一個MSRP消息，因為服務(wù)器的性能要好于終端，所以終端連續(xù)發(fā)送不會對應(yīng)用服務(wù)器(Application Server，簡稱為AS)造成影響，但當AS向接收終端發(fā)送消息時，就不得不考慮接收終端的接收性能。對于小文件來說，MSRP一個分包或者很少的分包就可以傳送完成，不會影響接收終端，但當文件很大時，MSRP需要傳輸成百上千個消息才能完成傳輸，如果AS持續(xù)的發(fā)送這么多消息，會讓接收終端來不及接收導(dǎo)致傳輸失敗。

針對相關(guān)技術(shù)中在文件很大時，AS持續(xù)的發(fā)送文件，會讓接收終端來不及接收導(dǎo)致傳輸失敗的問題，目前尚未提出有效的解決方案。

技術(shù)實現(xiàn)要素：

本發(fā)明的主要目的在于提供種一種文件的發(fā)送方法及裝置，以至少解決相關(guān)技術(shù)中在文件很大時，AS持續(xù)的發(fā)送文件，會讓接收終端來不及接收導(dǎo)致傳輸失敗的問題。

根據(jù)本發(fā)明的一個方面，提供了一種文件的發(fā)送方法，包括；將待發(fā)送的目標文件拆分為多個子目標文件；在將所述多個子目標文件依次發(fā)送給終端時，比較已發(fā)送而未被所述終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；在比較結(jié)果為是時，在所述終端處理未被處理的子目標文件預(yù)設(shè)時間后，再比較已發(fā)送而未被所述終端處理處理的子目標文件數(shù)是否大于或等于所述預(yù)設(shè)閾值；在比較結(jié)果為否時，繼續(xù)發(fā)送所述子目標文件。

進一步地，比較已發(fā)送而為被所述終端處理的子目標文件樹是否大于或等于預(yù)設(shè)閾值包括：獲取已發(fā)送的所述子目標文件數(shù)與接收到的所述終端響應(yīng)消息數(shù)；依據(jù)所述已發(fā)送的所述子目標文件數(shù)與所述響應(yīng)消息數(shù)的差值確定已發(fā)送而未 被所述終端處理的子目標文件數(shù)，其中，所述響應(yīng)消息是指所述終端每處理完一個子目標文件發(fā)送的消息；判斷已發(fā)送而未被所述終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值。

進一步地，所述預(yù)設(shè)閾值小于或等于所述終端在指定時間內(nèi)能處理所述子目標文件的最大值。

進一步地，在將待發(fā)送的目標文件拆分為多個子目標文件之前，所述方法還包括：判斷當前待發(fā)的目標文件容量是否大于或等于第一容量；在判斷結(jié)果為是時，將待發(fā)送的目標文件拆分為多個子目標文件，在判斷結(jié)果為否時，直接向所述終端發(fā)送所述目標文件。

進一步地，所述目標文件采用基于消息會話中繼協(xié)議MSRP的方式進行傳輸。

根據(jù)本發(fā)明的另一個方面，提供了一種文件的發(fā)送裝置，包括；拆分模塊，用于將待發(fā)送的目標文件拆分為多個子目標文件；第一比較模塊，用于在將所述多個子目標文件依次發(fā)送給終端時，比較已發(fā)送而未被所述終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；第二比較模塊，用于在比較結(jié)果為是時，在所述終端處理未被處理的子目標文件預(yù)設(shè)時間后，再判斷未處理的子目標文件數(shù)是否大于或等于所述預(yù)設(shè)閾值；第一發(fā)送模塊，用于在判斷結(jié)果為否時，繼續(xù)發(fā)送所述子目標文件。

進一步地，所述第一比較模塊包括：獲取單元，用于獲取已發(fā)送的所述子目標文件數(shù)與接收到的所述終端響應(yīng)消息數(shù)；確定單元，用于依據(jù)所述已發(fā)送的所述子目標文件數(shù)與所述響應(yīng)消息數(shù)的差值確定已發(fā)送而未被所述終端處理的子目標文件數(shù)，其中，所述響應(yīng)消息用于指示所述終端每處理完一個子目標文件發(fā)送的消息；判斷單元，用于判斷已發(fā)送而未被所述終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值。

進一步地，所述預(yù)設(shè)閾值小于或等于所述終端在指定時間內(nèi)能處理所述子目標文件的最大值。

進一步地，在將待發(fā)送的目標文件拆分為多個子目標文件之前，所述裝置還包括：第一判斷模塊，用于判斷當前待發(fā)的目標文件容量是否大于或等于第一容量；第二發(fā)送模塊，用于在判斷結(jié)果為是時，將待發(fā)送的目標文件拆分為多個子目標文件，在判斷結(jié)果為否時，直接向所述終端發(fā)送所述目標文件。

進一步地，所述目標文件采用基于消息會話中繼協(xié)議MSRP的方式進行傳輸。

在本發(fā)明中，采用將待發(fā)送的目標文件拆分為多個子目標文件，而在將多個 子目標文件依次發(fā)送給終端時，判斷已發(fā)送而未被終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值，在比較結(jié)果為是時，在終端處理未被處理的子目標文件預(yù)設(shè)時間后，再比較已發(fā)送而未被終端處理處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；在比較判斷結(jié)果為否時，繼續(xù)發(fā)送子目標文件的方式，使得已發(fā)送而未被終端處理的子目標文件數(shù)始終小于預(yù)設(shè)閾值，保證了終端不會再短時間內(nèi)收到大量的文件，即終端能夠及時處理收到的文件，解決了相關(guān)技術(shù)中在文件很大時，AS持續(xù)的發(fā)送文件，會讓接收終端來不及接收導(dǎo)致傳輸失敗的問題。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構(gòu)成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構(gòu)成對本發(fā)明的不當限定。在附圖中：

圖1是根據(jù)本發(fā)明實施例的風扇的文件的發(fā)送方法的流程圖；

圖2是根據(jù)本發(fā)明實施例的文件的發(fā)送裝置結(jié)構(gòu)框圖；

圖3是根據(jù)本發(fā)明實施例的文件的發(fā)送裝置可選結(jié)構(gòu)框圖一；

圖4是根據(jù)本發(fā)明實施例的文件的發(fā)送裝置可選結(jié)構(gòu)框圖二；

圖5是根據(jù)本可選實施例的大文件傳輸?shù)南到y(tǒng)交互圖；

圖6是根據(jù)本可選實施例的媒體傳輸MSRP模塊的結(jié)構(gòu)圖；

圖7是根據(jù)本發(fā)明可選實施例的AS向UE發(fā)送大文件的方法流程圖。

具體實施方式

需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。下面將參考附圖并結(jié)合實施例來詳細說明本發(fā)明。

本實施例提供了一種文件的發(fā)送方法，圖1是根據(jù)本發(fā)明實施例的風扇的文件的發(fā)送方法的流程圖，如圖1所示，該方法的步驟包括：

步驟S102：將待發(fā)送的目標文件拆分為多個子目標文件；

步驟S104：在將多個子目標文件依次發(fā)送給終端時，比較已發(fā)送而未被終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；

步驟S106：在比較判斷結(jié)果為是時，在等待終端處理未被處理的子目標文件預(yù)設(shè)時間后，再比較已發(fā)送而未被終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；

步驟S108：在比較結(jié)果為否時，繼續(xù)發(fā)送子目標文件。

在本發(fā)明實施例的步驟S102至步驟S106中，采用將待發(fā)送的目標文件拆分為多個子目標文件，而在將多個子目標文件依次發(fā)送給終端時，比較已發(fā)送而未被終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值，在比較結(jié)果為是時，在等待終端處理未被處理的子目標文件預(yù)設(shè)時間后，再判斷未處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值依次發(fā)送子目標文件；在比較判斷結(jié)果為否時，繼續(xù)發(fā)送子目標文件的方式，使得已發(fā)送而未被終端處理的子目標文件數(shù)始終小于預(yù)設(shè)閾值，保證了終端不會再短時間內(nèi)收到大量的文件，即終端能夠及時處理收到的文件，解決了相關(guān)技術(shù)中在文件很大時，AS持續(xù)的發(fā)送文件，會讓接收終端來不及接收導(dǎo)致傳輸失敗的問題。

對于本實施例中涉及到的步驟S104，比較已發(fā)送而為被終端處理的子目標文件樹是否大于或等于預(yù)設(shè)閾值的方式，在本實施例的一個可選實施方式中，可以通過如下方式來實現(xiàn)：

步驟S11：獲取已發(fā)送的子目標文件數(shù)與接收到的終端響應(yīng)消息數(shù)，

步驟S12：依據(jù)已發(fā)送的子目標文件數(shù)與響應(yīng)消息數(shù)的差值確定已發(fā)送而未被終端處理的子目標文件數(shù)，其中，響應(yīng)消息用于指示終端每處理完一個子目標文件發(fā)送的消息；

步驟S13：判斷已發(fā)送而未被終端處理的子目標文件樹是否大于或等于預(yù)設(shè)閾值。

需要說明的是，該預(yù)設(shè)閾值小于或等于終端在指定時間內(nèi)能處理子目標文件的最大值。也就是說，通過上述步驟S11至步驟S13，可以知道當前終端已經(jīng)處理的子目標文件數(shù)，通過已發(fā)送與已處理的文件數(shù)的差值就能知道當前沒有處理的子目標文件數(shù)，進而可以使得當前未被處理的文件數(shù)維持在一個相對穩(wěn)定的數(shù)量，換言之是在終端能夠處理的一個范圍內(nèi)。

在本實施例的另一個可選實施方式中，在將待發(fā)送的目標文件拆分為多個子目標文件之前，本實施例的方法還可以包括：

步驟S21：判斷當前待發(fā)的目標文件容量是否大于或等于第一容量；

步驟S22：在判斷結(jié)果為是時，將待發(fā)送的目標文件拆分為多個子目標文件，在判斷結(jié)果為否時，直接向終端發(fā)送目標文件。

需要說明的是，本實施例涉及到的目標文件可選的采用基于消息會話中繼協(xié)議MSRP的方式進行傳輸。

在本實施例中還提供了一種文件的發(fā)送裝置，該裝置用于實現(xiàn)上述實施例及 可選實施方式，已經(jīng)進行過說明的不再贅述。如以下所使用的，術(shù)語“模塊”可以實現(xiàn)預(yù)定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現(xiàn)，但是硬件，或者軟件和硬件的組合的實現(xiàn)也是可能并被構(gòu)想的。

圖2是根據(jù)本發(fā)明實施例的文件的發(fā)送裝置結(jié)構(gòu)框圖，如圖2所示，該裝置包括；拆分模塊22，用于將待發(fā)送的目標文件拆分為多個子目標文件；第一比較模塊24，與拆分模塊22耦合連接，用于在將多個子目標文件依次發(fā)送給終端時，比較已發(fā)送而未被終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；第二比較模塊26，與第一比較模塊24耦合連接，用于在比較結(jié)果為是時，在終端處理未被處理的子目標文件預(yù)設(shè)時間后，再比較已發(fā)送而未被終端處理的子目標文件數(shù)是否大于或等于預(yù)設(shè)閾值；第一發(fā)送模塊28，與第一比較模塊24和第二比較模塊26耦合連接，用于在判斷結(jié)果為否時，繼續(xù)發(fā)送子目標文件。

圖3是根據(jù)本發(fā)明實施例的文件的發(fā)送裝置可選結(jié)構(gòu)框圖一，如圖3所示，該第一比較模24塊包括：獲取單元32，用于獲取已發(fā)送的子目標文件數(shù)與接收到的終端響應(yīng)消息數(shù)；確定單元34，與獲取單元32耦合連接，用于依據(jù)已發(fā)送的子目標文件數(shù)與響應(yīng)消息數(shù)的差值確定已發(fā)送而未被終端處理的子目標文件數(shù)，其中，響應(yīng)消息用于指示終端每處理完一個子目標文件發(fā)送的消息；判斷單元36，與確定單元34耦合連接，用于判斷已發(fā)送而未被終端處理的子目標文件樹是否大于或等于預(yù)設(shè)閾值。

可選地，本實施例中涉及的預(yù)設(shè)閾值小于或等于終端在指定時間內(nèi)能處理子目標文件的最大值。

圖4是根據(jù)本發(fā)明實施例的文件的發(fā)送裝置可選結(jié)構(gòu)框圖二，如圖4所示，在將待發(fā)送的目標文件拆分為多個子目標文件之前，裝置還包括：第一判斷模塊42，與第二發(fā)送模塊44耦合連接，用于判斷當前待發(fā)的目標文件容量是否大于或等于第一容量；第二發(fā)送模塊44，與拆分模塊22耦合連接，用于在判斷結(jié)果為是時，將待發(fā)送的目標文件拆分為多個子目標文件，在判斷結(jié)果為否時，直接向終端發(fā)送目標文件。

可選地，目標文件采用基于消息會話中繼協(xié)議MSRP的方式進行傳輸。

下面結(jié)合本發(fā)明的可選實施例對本發(fā)明進行詳細說明；

本可選實施例提供了一種基于MSRP協(xié)議的大文件傳輸?shù)姆椒?，該方法包括：接收終端發(fā)來的大文件，收一包消息，存儲一包消息，或者減小IO的壓力，收多包消息，待達到足夠的消息量再存儲，或者超時存儲；將大文件拆分，每個MSRP消息發(fā)送一塊，循環(huán)發(fā)送，直至發(fā)送完成。為了適應(yīng)不同終端不同性能，或者網(wǎng)絡(luò)狀況，在循環(huán)發(fā)送消息時，提出一種發(fā)送指定數(shù)量的消息方法。AS發(fā)送指定數(shù)量的MSRP消息，待接收終端處理完成且AS收到接收終端的處理完成 響應(yīng)，才繼續(xù)發(fā)送后面的消息，保持到接收終端的TCP鏈路上有等量的消息個數(shù)在發(fā)送。的等量可以根據(jù)當前狀態(tài)自適應(yīng)的進行調(diào)整大小，以便適應(yīng)不斷變化的網(wǎng)絡(luò)環(huán)境。

此外，本可選實施例提供了一種基于MSRP協(xié)議的大文件傳輸?shù)南到y(tǒng)，能夠有效緩解接收終端的接收壓力，該系統(tǒng)包括第一終端UE1、第一應(yīng)用服務(wù)器AS1、第二應(yīng)用服務(wù)器AS2和第二終端UE2。所有終端和服務(wù)器都設(shè)有SIP模塊和MSRP模塊；UE1和AS1通過SIP模塊協(xié)商和MSRP模塊數(shù)據(jù)傳輸；該AS1和該AS2通過SIP模塊進行協(xié)商，不進行數(shù)據(jù)的傳輸；AS2和UE2通過SIP模塊協(xié)商和MSRP模塊數(shù)據(jù)傳輸。

其中，MSRP模塊包括：接收模塊，用于接收來自發(fā)送終端的消息；發(fā)送模塊，用于發(fā)送消息到接收終端。

接收模塊包括：接收單元，用于接收終端的MSRP消息；解碼模塊，用于解析MSRP消息；存儲模塊，將解碼后的消息內(nèi)容發(fā)送到云存儲模塊進行存儲；云存儲(可用所有的其它存儲替代)，用來在云端存儲消息進行不同AS之間進行數(shù)據(jù)共享。

發(fā)送模塊包括：云存儲；讀入單元，用于到云存儲中讀取數(shù)據(jù)；編碼單元，用于將讀取的內(nèi)容編碼到MSRP消息中；控制單元，用于自適應(yīng)的控制向接收端發(fā)送的速率；發(fā)送模塊，用于將MSRP消息發(fā)送到接收終端。

相對于相關(guān)技術(shù)中的系統(tǒng)模塊組成，本可選實施例增加了控制單元，該控制模塊用來控制AS服務(wù)器向終端發(fā)送大文件消息的速度。具體控制方法：統(tǒng)計發(fā)送MSRP請求消息數(shù)、接收MSRP響應(yīng)消息數(shù)，計算當前可發(fā)送消息數(shù)，判斷當前已發(fā)送消息是否大于發(fā)送窗口；如果大于則停止發(fā)送，繼續(xù)等待響應(yīng)，直到當前已發(fā)送消息小于等于發(fā)送窗口；如果小于等于則繼續(xù)發(fā)送。當前可發(fā)送消息數(shù)：請求消息數(shù)-響應(yīng)消息數(shù)-發(fā)送窗口的差值。其中，發(fā)送窗口＝計算發(fā)出請求到接收到響應(yīng)的時間差的平均值(計算方法包括但不只限于任何反應(yīng)網(wǎng)絡(luò)或者終端性能的計算方法)，自適應(yīng)調(diào)整發(fā)送窗口，值小給予大的窗口，值大給予小的窗口。

通過本可選實施例，解決了相關(guān)技術(shù)中對基于MSRP協(xié)議的大文件傳輸，能夠自適應(yīng)調(diào)整AS服務(wù)器向接收終端的發(fā)送速率，讓AS服務(wù)器和接收終端有相同的傳輸性能。即能對不同性能的終端給予的不同的發(fā)送速率；能有效利用網(wǎng)絡(luò)帶寬，自適應(yīng)的改變發(fā)送速率；能有效提高大文件的發(fā)送成功率，增強用戶體驗性。

下面結(jié)合附圖對本發(fā)明可選實施例對本可選實施例進行詳細說明；

圖5是根據(jù)本可選實施例的大文件傳輸?shù)南到y(tǒng)交互圖，如圖5所示，UE1、UE2可以是PC、PDA或者手機等終端等設(shè)備，用來發(fā)送和接收文件；AS1和AS2是部署在云上的服務(wù)器，用來存儲轉(zhuǎn)發(fā)文件，將文件存儲在云上，實現(xiàn)不同AS之間的數(shù)據(jù)共享，需要說明的是，圖5中的虛線表示信令交互，藍色表示媒體交互。

UE1和AS1先進行信令交互，完成媒體協(xié)商后，進行數(shù)據(jù)交互，AS1將收到的媒體數(shù)據(jù)存儲在云上。AS1和AS2進行信令交互，因為AS1和AS2共享數(shù)據(jù)，所以就不在進行媒體交互，減少媒體傳輸。AS2和UE2也是先進行信令交互，然后在進行數(shù)據(jù)的傳輸。由此完成UE1到UE2的消息傳輸。

圖6是根據(jù)本可選實施例的媒體傳輸MSRP模塊的結(jié)構(gòu)圖，如圖6所示，該模塊包括：發(fā)送模塊和接收模塊；

其中，接收模塊包括：接收單元、解碼單元、存儲單元、云存儲。

接收單元，用來接收IP網(wǎng)絡(luò)上的TCP消息，將收到的TCP消息發(fā)到到解碼單元。解碼單元將收到的TCP數(shù)據(jù)進行組包，解析出一個完整的MSRP消息，將解碼信息發(fā)送到存儲單元。存儲單元將解碼后的數(shù)據(jù)進行存儲，這里采用緩存策略，將收到的數(shù)據(jù)進行緩存，當達到指定的大小或者超時后，才會將數(shù)據(jù)發(fā)送到云存儲單元。云存儲是一種分布式存儲方式，能實現(xiàn)數(shù)據(jù)共享。

發(fā)送模塊包括：發(fā)送單元、控制單元、編碼單元、讀入單元、云儲存。

讀入單元用于去云存儲中讀取數(shù)據(jù)，讀取指定大小的數(shù)據(jù)放在內(nèi)存緩沖中。編碼單元，用于在緩沖中獲取一定大小的數(shù)據(jù)，組成MSRP消息包，當緩沖中數(shù)據(jù)小于指定大小且云存儲中還有數(shù)據(jù)時，再次讓讀入模塊再次讀取指定大小的數(shù)據(jù)?？刂茊卧糜谟嬎惆l(fā)出請求到收到響應(yīng)的平均值，獲取當前系統(tǒng)的會話占用數(shù)，用它們來計算發(fā)送窗口的大小，用來控制是否繼續(xù)發(fā)送MSRP消息。發(fā)送模塊用來將MSRP發(fā)送到TCP鏈路中。

圖7是根據(jù)本發(fā)明可選實施例的AS向UE發(fā)送大文件的方法流程圖，如圖7所示，該方法步驟包括：

步驟S702：開始下發(fā)大文件。

步驟S704：將大文件拆分成N個MSRP消息，同時設(shè)置TCP鏈路上可以同時存在MSRP消息的數(shù)M個。將N個MSRP消息一個一個的發(fā)送出去。

步驟S706：發(fā)送第C個MSRP消息；

步驟S708：判斷C是否等于N，若C不等于N轉(zhuǎn)到步驟S714；

步驟S710：判斷C是否等于R；若等于R，則轉(zhuǎn)到步驟S716，若不等于R 則執(zhí)行步驟S712；

其中，R表示發(fā)送的C個MSRP消息之后收到的響應(yīng)數(shù)；

步驟S712：繼續(xù)接收響應(yīng)，計算收到的響應(yīng)數(shù)R，轉(zhuǎn)到步驟S708；

步驟S714：判斷C-R是否小于等于M，若是則轉(zhuǎn)到步驟S706，若否則轉(zhuǎn)到步驟S712；

步驟S716：下發(fā)大文件成功，流程結(jié)束。

在另外一個實施例中，還提供了一種軟件，該軟件用于執(zhí)行上述實施例及可選實施方式中描述的技術(shù)方案。

在另外一個實施例中，還提供了一種存儲介質(zhì)，該存儲介質(zhì)中存儲有上述軟件，該存儲介質(zhì)包括但不限于：光盤、軟盤、硬盤、可擦寫存儲器等。

顯然，本領(lǐng)域的技術(shù)人員應(yīng)該明白，上述本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現(xiàn)，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網(wǎng)絡(luò)上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現(xiàn)，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現(xiàn)。這樣，本發(fā)明不限制于任何特定的硬件和軟件結(jié)合。

上述僅為本發(fā)明的可選實施例而已，并不用于限制本發(fā)明，對于本領(lǐng)域的技術(shù)人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等，均應(yīng)包含在本發(fā)明的保護范圍之內(nèi)。