消息推送方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及計(jì)算機(jī)領(lǐng)域，特別涉及一種消息推送方法及裝置。
【背景技術(shù)】
[0002]在服務(wù)器向客戶端推送消息時(shí)，為了實(shí)現(xiàn)服務(wù)器與客戶端之間的實(shí)時(shí)通訊，開發(fā)人員常用的推送方法為輪詢(Polling)推送。
[0003]輪詢推送方法包括:客戶端每隔預(yù)定時(shí)間間隔向服務(wù)器端發(fā)出獲取請求，服務(wù)器端在存在推送消息時(shí)，向客戶端反饋推送消息；在不存在推送消息，向客戶端反饋代表空的消息。
[0004]在實(shí)現(xiàn)本發(fā)明實(shí)施例的過程中，發(fā)明人發(fā)現(xiàn)現(xiàn)有技術(shù)至少存在以下問題:
[0005]輪詢推送方法是以頻繁請求的方式來保持客戶端和服務(wù)器端的同步，這就使得每個(gè)客戶端在與服務(wù)器進(jìn)行實(shí)時(shí)通訊的過程中，占用大量的服務(wù)器資源。

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

[0006]為了解決現(xiàn)有技術(shù)的問題，本發(fā)明實(shí)施例提供了一種虛擬禮品贈(zèng)送方法及裝置。所述技術(shù)方案如下:
[0007]第一方面，提供了一種消息推送方法，所述方法包括:
[0008]檢測客戶端是否兼容網(wǎng)絡(luò)套接字Websocket協(xié)議；
[0009]若所述客戶端兼容所述Websocket協(xié)議，則基于Websocket協(xié)議進(jìn)行消息推送；
[0010]若所述客戶端不兼容所述Websocket協(xié)議，則基于長輪詢方式進(jìn)行消息推送。
[0011]在第一方面的第一種可能的實(shí)施方式中，所述檢測客戶端是否兼容網(wǎng)絡(luò)套接字Websocket協(xié)議，包括:
[0012]通過預(yù)定函數(shù)檢測所述客戶端是否兼容網(wǎng)絡(luò)套接字Websocket協(xié)議；
[0013]其中，所述預(yù)定函數(shù)是所述Websocket協(xié)議所提供的函數(shù)。
[0014]在第二種可能的實(shí)施方式中，所述基于長輪詢方式進(jìn)行消息推送，包括:
[0015]接收所述客戶端發(fā)送的第i輪詢請求；
[0016]在不存在待推送的消息時(shí)，忽略所述第i輪詢請求且保持與所述客戶端之間的網(wǎng)絡(luò)連接；
[0017]接收所述客戶端發(fā)送的第i+Ι輪詢請求；所述第i+Ι輪詢請求是所述網(wǎng)絡(luò)連接超時(shí)或斷開時(shí)所述客戶端重新發(fā)送的輪詢請求，其中i為正整數(shù)。
[0018]在第三種可能的實(shí)施方式中，所述接收所述客戶端發(fā)送的第i輪詢請求之后，還包括:
[0019]在存在所述待推送的消息時(shí)，向所述客戶端發(fā)送所述待推送的消息。
[0020]結(jié)合第一方面、第一方面的第一種可能的實(shí)施方式、第一方面的第二種可能的實(shí)施方式或者第一方面的第三種可能的實(shí)施方式，在第四種可能的實(shí)施方式中，所述若所述客戶端兼容所述Websocket協(xié)議，則基于Websocket協(xié)議進(jìn)行消息推送之后，還包括:
[0021]檢測與所述客戶端之間的網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的中斷次數(shù)是否超過預(yù)設(shè)閾值；
[0022]若所述網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的中斷次數(shù)超過所述預(yù)設(shè)閾值，則基于所述長輪詢方式進(jìn)行消息推送。
[0023]第二方面，提供了一種消息推送裝置，所述裝置包括:
[0024]檢測模塊，用于檢測客戶端是否兼容網(wǎng)絡(luò)套接字Websocket協(xié)議；
[0025]第一推送模塊，用于在所述檢測模塊檢測結(jié)果為所述客戶端兼容所述Websocket協(xié)議時(shí)，基于Websocket協(xié)議進(jìn)行消息推送；
[0026]第二推送模塊，用于在所述檢測模塊檢測結(jié)果為所述客戶端不兼容所述Websocket協(xié)議時(shí)，基于長輪詢方式進(jìn)行消息推送。
[0027]在第二方面的第一種可能的實(shí)施方式中，所述檢測模塊，還用于，通過預(yù)定函數(shù)檢測所述客戶端是否兼容網(wǎng)絡(luò)套接字Websocket協(xié)議，其中，所述預(yù)定函數(shù)是所述Websocket協(xié)議所提供的函數(shù)。
[0028]在第二種可能的實(shí)施方式中，所述第二推送模塊，包括:
[0029]第一接收單元，用于接收所述客戶端發(fā)送的第i輪詢請求；
[0030]連接保持單元，用于在不存在待推送的消息時(shí)，忽略所述第一接受單元接收的所述第i輪詢請求且保持與所述客戶端之間的網(wǎng)絡(luò)連接；
[0031]第二接收單元，用于接收所述客戶端發(fā)送的第i+Ι輪詢請求；所述第i+Ι輪詢請求是所述網(wǎng)絡(luò)連接超時(shí)或斷開時(shí)所述客戶端重新發(fā)送的輪詢請求，其中i為正整數(shù)。
[0032]在第三種可能的實(shí)施方式中，所述第二推送模塊，還包括:
[0033]消息發(fā)送單元，用于所述第一接收單元接收所述客戶端發(fā)送的第i輪詢請求之后，在存在所述待推送的消息時(shí)，向所述客戶端發(fā)送所述待推送的消息。
[0034]結(jié)合第二方面、第二方面的第一種可能的實(shí)施方式、第二方面的第二種可能的實(shí)施方式或者第二方面的第三種可能的實(shí)施方式，在第四種可能的實(shí)施方式中，所述第一推送模塊，包括:
[0035]檢測單元，用于檢測與所述客戶端之間的網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的中斷次數(shù)是否超過預(yù)設(shè)閾值；
[0036]切換單元，用于在所述檢測單元檢測結(jié)果為所述網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的中斷次數(shù)超過所述預(yù)設(shè)閾值時(shí)，切換至第一推送模塊。
[0037]本發(fā)明實(shí)施例提供的技術(shù)方案帶來的有益效果是:
[0038]通過檢測客戶端是否兼容網(wǎng)絡(luò)套接字Websocket協(xié)議；通過檢測客戶端是否兼容Websocket協(xié)議；若客戶端兼容Websocket協(xié)議，則基于Websocket協(xié)議進(jìn)行消息推送；若客戶端不兼容Websocket協(xié)議，則基于長輪詢方式進(jìn)行消息推送，使得客戶端不必頻繁地向服務(wù)器發(fā)出資源請求，就可以保持客戶端和服務(wù)器端的同步，解決了當(dāng)客戶端以頻繁請求的方式來保持客戶端和服務(wù)器之間的同步時(shí)，占用大量服務(wù)器資源的問題，達(dá)到了根據(jù)客戶端的實(shí)際情況選擇使用更為合理的消息推送方式，降低服務(wù)器端CPU的利用率的效果Ο
[0039]此外，本發(fā)明實(shí)施例提供的消息推送方法，在基于Websocket協(xié)議進(jìn)行消息推送時(shí)，通過檢測與客戶端之間的網(wǎng)絡(luò)連接在預(yù)設(shè)時(shí)間內(nèi)的中斷次數(shù)是否超過預(yù)設(shè)閾值；若超過預(yù)設(shè)閾值，則基于長輪詢方式進(jìn)行消息推送，使得在客戶端和服務(wù)器之間的網(wǎng)絡(luò)連接環(huán)境較差時(shí)，客戶端仍可以在盡量短的時(shí)間內(nèi)接收到服務(wù)器的推送消息，達(dá)到了在客戶端和服務(wù)器之間的網(wǎng)絡(luò)連接環(huán)境較差時(shí)，提高客戶端接收服務(wù)器的推送消息的實(shí)時(shí)性的效果。
[0040]進(jìn)一步地，本發(fā)明實(shí)施例提供的消息推送方法，在基于長輪詢方式進(jìn)行消息推送時(shí)，客戶端發(fā)送第i輪詢請求后，通過服務(wù)器檢測是否存在待推送的消息；在不存在待推送的消息時(shí)，忽略第i輪詢請求且保持與客戶端之間的網(wǎng)絡(luò)連接；在存在待推送的消息時(shí)，向客戶端發(fā)送待推送的消息；接收客戶端發(fā)送的第i+Ι輪詢請求，使得服務(wù)器在基于長輪詢方式進(jìn)行消息推送時(shí)，若服務(wù)器中沒有待推送的消息，則不向客戶端推送消息，解決了基于輪詢方式進(jìn)行消息推送時(shí)，若服務(wù)器中沒有待推送的消息，重復(fù)向客戶端發(fā)送舊的待推送消息的問題，達(dá)到了減少網(wǎng)絡(luò)寬帶的利用率，提高消息推送的準(zhǔn)確性的效果。
【附圖說明】
[0041]為了更清楚地說明本發(fā)明實(shí)施例中的技術(shù)方案，下面將對實(shí)施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實(shí)施例，對于本領(lǐng)域普通技術(shù)人員來講，在不付出創(chuàng)造性勞動(dòng)的前提下，還可以根據(jù)這些附圖獲得其他的附圖。
[0042]圖1是根據(jù)一個(gè)示例性實(shí)施例示出的一種消息推送方法流程圖；
[0043]圖2是根據(jù)一個(gè)示例性實(shí)施例示出的基于Websocket協(xié)議進(jìn)行消息推送時(shí)網(wǎng)絡(luò)連接建立過程的交互圖；
[0044]圖3是根據(jù)另一個(gè)示例性實(shí)施例示出的一種消息推送方法流程圖；
[0045]圖4是根據(jù)一個(gè)示例性實(shí)施例示出的一種消息推送裝置的框圖；
[0046]圖5是根據(jù)另一個(gè)示例性實(shí)施例示出的一種消息推送裝置的框圖。
【具體實(shí)施方式】
[0047]這里將詳細(xì)地對示例性實(shí)施例進(jìn)行說明，其示例表示在附圖中。下面的描述涉及附圖時(shí)，除非另有表示，不同附圖中的相同數(shù)字表示相同或相似的要素。以下示例性實(shí)施例中所描述的實(shí)施方式并不代表與本發(fā)明相一致的所有實(shí)施方式。相反，它們僅是與如所附權(quán)利要求書中所詳述的、本發(fā)明的一些方面相一致的裝置和方法的例子。
[0048]HTTP (HyperText Transfer Protocol，超文本傳輸協(xié)議)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。HTTP協(xié)議是一種單向的網(wǎng)絡(luò)協(xié)議。在建立連接后，只有當(dāng)客戶端向服務(wù)器發(fā)出資源請求后，服務(wù)器才能返回相應(yīng)的數(shù)據(jù)。而服務(wù)器不