請求消息的處理、發(fā)送方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明設(shè)及通信領(lǐng)域，具體而言，設(shè)及一種請求消息的處理、發(fā)送方法及裝置。
【背景技術(shù)】
[0002] 用戶數(shù)據(jù)報(bào)協(xié)議化ser化化gram Protocol,簡稱為UDP)，是傳輸層中一個(gè)簡單的 面向數(shù)據(jù)報(bào)的不可靠協(xié)議。相比于傳輸控制協(xié)議(Transmission Control Protocol，簡稱 為TCP), UDP的數(shù)據(jù)傳輸更加高效、快速。特別是對于網(wǎng)絡(luò)游戲、音頻、視頻等傳輸場景中，更 加注重的是傳輸性能而并非傳輸?shù)耐暾?，所W采用UDP則是更優(yōu)的選擇。然而，大多數(shù)UDP 服務(wù)器程序是迭代運(yùn)行的，服務(wù)器首先需要等待一個(gè)客戶請求，其次讀取該客戶請求，然后 處理該客戶請求，最后返回與該客戶請求對應(yīng)的客戶應(yīng)答，并接著等待下一個(gè)到來的客戶 請求。在其中一個(gè)客戶請求的處理過程需要耗用過長時(shí)間的情況下，就會嚴(yán)重阻礙對后續(xù) 到來的客戶請求進(jìn)行處理，因而，在目前的研究過程中，期望UDP服務(wù)器程序能夠具有特定 形式的并發(fā)性。
[0003] 在相關(guān)技術(shù)中，UDP實(shí)現(xiàn)并發(fā)按照監(jiān)聽端口的數(shù)量來劃分可W包括W下兩類：
[0004] 第一類、服務(wù)器監(jiān)聽一個(gè)端口
[0005] 在運(yùn)種方法中，服務(wù)器需要創(chuàng)建一個(gè)套接字(socket),將其綁定到一個(gè)眾所周知 的端口上，全部數(shù)據(jù)接收請求與數(shù)據(jù)發(fā)送請求都需要通過此端口來實(shí)現(xiàn)。服務(wù)器從此端口 接收到數(shù)據(jù)后，再通過特定分發(fā)策略將數(shù)據(jù)分發(fā)到應(yīng)用層程序中。常見的數(shù)據(jù)分發(fā)策略可 W包括但不限于:循環(huán)式、多線程式、環(huán)形緩存和環(huán)形隊(duì)列式。
[0006] (1)循環(huán)式:服務(wù)器在接收到來自于客戶端的請求后，處理該請求，然后將與該請 求對應(yīng)的應(yīng)答反饋至客戶端，然后再繼續(xù)處理下一個(gè)請求。
[0007] (2)多線程式:服務(wù)器在接收到來自于客戶端的請求后，創(chuàng)建一個(gè)數(shù)據(jù)處理子線程 單獨(dú)處理接收到的數(shù)據(jù)，并將處理結(jié)果反饋至客戶端，然后數(shù)據(jù)處理線程退出。
[0008] (3)環(huán)形緩存和環(huán)形隊(duì)列式:在數(shù)據(jù)接收線程中創(chuàng)建環(huán)形隊(duì)列，用于存儲待返回?cái)?shù) 據(jù)的客戶端標(biāo)識(例如:客戶端的網(wǎng)絡(luò)協(xié)議（IP)和端口），并在數(shù)據(jù)處理子線程中創(chuàng)建發(fā)送 環(huán)形緩存和接收環(huán)形緩存，用于接收數(shù)據(jù)和存儲待發(fā)送數(shù)據(jù);數(shù)據(jù)接收線程接收數(shù)據(jù)同時(shí) 查看環(huán)形隊(duì)列中是否有需要返回?cái)?shù)據(jù)的客戶端標(biāo)識，如果有，則相應(yīng)的數(shù)據(jù)處理子線程會 將環(huán)形緩存中的數(shù)據(jù)發(fā)送出去。在此種方式中的循環(huán)緩沖區(qū)可W提供對緩沖區(qū)的互斥訪 問，因而數(shù)據(jù)接收線程與數(shù)據(jù)處理子線程之間不需要增加互斥保護(hù)即可同時(shí)進(jìn)行，從而具 備良好的并發(fā)性能，循環(huán)緩沖區(qū)可W更好地利用系統(tǒng)內(nèi)存資源。
[0009] 然而，采用服務(wù)器監(jiān)聽一個(gè)端口的解決方案仍然存在W下明顯缺陷：
[0010] 所有數(shù)據(jù)均需要通過一個(gè)套接字來接收必然會設(shè)及到數(shù)據(jù)的分發(fā)。循環(huán)式是一種 串行的處理方式，其本質(zhì)上并沒有做到并發(fā)性。運(yùn)種方式對于處理占用時(shí)間長的請求，效率 就比較低下。例如:在文件傳送服務(wù)中，循環(huán)式在處理每一個(gè)請求時(shí)都需要相當(dāng)長的時(shí)間， 由此會導(dǎo)致后續(xù)的請求得不到及時(shí)地處理。多線程式中線程的創(chuàng)建和銷毀耗時(shí)較長，因?yàn)?每次創(chuàng)建一個(gè)線程都需要獲取內(nèi)存和系統(tǒng)資源，同時(shí)還需要考慮線程之間對數(shù)據(jù)的互斥訪 問，所W提高服務(wù)程序效率的一個(gè)重要技術(shù)手段就是盡可能減少創(chuàng)建和銷毀線程的次數(shù)， 目前的做法是采用線程池來管理線程。此外，環(huán)形緩存和環(huán)形隊(duì)列接收處理數(shù)據(jù)的方式雖 然能夠解決線程之間數(shù)據(jù)的互斥訪問，提高了并發(fā)性能，但實(shí)際上，環(huán)形緩存和環(huán)形隊(duì)列式 與前兩種方式只是數(shù)據(jù)分發(fā)方式不同，并不能改變通過一個(gè)套接字來收發(fā)數(shù)據(jù)的事實(shí)。如 果并發(fā)請求量巨大，整個(gè)系統(tǒng)的瓶頸就會集中在數(shù)據(jù)分發(fā)上。
[0011] 第二類、服務(wù)器監(jiān)聽多個(gè)端口
[0012] 服務(wù)器在一個(gè)眾所周知的端口上創(chuàng)建一個(gè)套接字（socket),監(jiān)聽客戶請求。當(dāng)服 務(wù)器接收到來自于客戶端的請求時(shí)，記錄其IP地址和端口，然后為該客戶請求創(chuàng)建一個(gè)子 線程，由子線程負(fù)責(zé)與該客戶端之間的通信。子線程創(chuàng)建一個(gè)新的套接字，在其上綁定 (bind)-個(gè)臨時(shí)端口，通過此套接字發(fā)送對此請求的所有應(yīng)答。
[0013] 然而，采用服務(wù)器監(jiān)聽多個(gè)端口的方式雖然能夠解決只監(jiān)聽一個(gè)端口中數(shù)據(jù)集中 分發(fā)的問題，但是，采用服務(wù)器監(jiān)聽多個(gè)端口的解決方案同樣存在W下明顯缺陷：
[0014] (1)在一般情況下，服務(wù)器端的防火墻只會允許數(shù)據(jù)通過特定的端口，而不會開放 所有的端口，W防止服務(wù)器遭受到惡意攻擊。由此會導(dǎo)致數(shù)據(jù)無法突破防火墻的限制。而且 即使沒有防火墻的限制，如果客戶端指定從服務(wù)器某一端口接收數(shù)據(jù)，也會造成客戶端接 收數(shù)據(jù)失敗。
[0015] (2)對于每一個(gè)客戶端發(fā)送的請求，服務(wù)器都需要分配一個(gè)新的端口，由于端口資 源是有限的（最多只有65535個(gè)），運(yùn)樣即使服務(wù)器性能再好，處理程序再高效，在服務(wù)器只 具有一個(gè)IP地址的情況下，并發(fā)請求的總體數(shù)量將難W突破65535的極限。
[0016] 針對上述的問題，目前尚未提出有效的解決方案。

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

[0017] 本發(fā)明實(shí)施例提供了一種請求消息的處理、發(fā)送方法及裝置，W至少解決相關(guān)技 術(shù)中缺乏一種高效的并發(fā)解決方案既能滿足數(shù)據(jù)的分發(fā)需求，同時(shí)又能突破網(wǎng)絡(luò)端口和防 火墻的限制的技術(shù)問題。
[0018] 根據(jù)本發(fā)明實(shí)施例的一個(gè)方面，提供了一種請求消息的處理方法，包括:在服務(wù)器 的預(yù)設(shè)端口上創(chuàng)建全局UDP套接字;采用全局UDP套接字監(jiān)聽客戶端發(fā)送的請求消息；為監(jiān) 聽到的請求消息創(chuàng)建臨時(shí)UDP套接字，并通過UDP臨時(shí)套接字與客戶端進(jìn)行通信。
[0019] 進(jìn)一步地，采用全局UDP套接字監(jiān)聽客戶端發(fā)送的請求消息包括:將全局UDP套接 字中的套接字選項(xiàng)設(shè)置為允許臨時(shí)UDP套接字與全局UDP套接字同時(shí)綁定至服務(wù)器的標(biāo)識 信息，并且將服務(wù)器的標(biāo)識信息與全局UDP套接字進(jìn)行綁定;采用全局UDP套接字循環(huán)監(jiān)聽 等待請求消息，并在請求消息到達(dá)服務(wù)器時(shí)，創(chuàng)建子線程或進(jìn)程處理請求消息。
[0020] 進(jìn)一步地，為請求消息創(chuàng)建臨時(shí)UDP套接字，并通過臨時(shí)套接字與客戶端進(jìn)行通信 包括:在子線程或進(jìn)程中創(chuàng)建臨時(shí)UDP套接字，并允許臨時(shí)UDP套接字對服務(wù)器的標(biāo)識信息 進(jìn)行復(fù)用；調(diào)用第一系統(tǒng)函數(shù)將服務(wù)器的標(biāo)識信息與臨時(shí)UDP套接字進(jìn)行綁定;調(diào)用第二系 統(tǒng)函數(shù)將客戶端的標(biāo)識信息與臨時(shí)UDP套接字進(jìn)行綁定;通過臨時(shí)UDP套接字向客戶端發(fā)送 數(shù)據(jù)和/或通過臨時(shí)UDP套接字讀取從客戶端接收到的數(shù)據(jù)。
[0021] 進(jìn)一步地，通過臨時(shí)UDP套接字讀取從客戶端接收到的數(shù)據(jù)包括:獲取與預(yù)設(shè)端口 相匹配的全部臨時(shí)UDP套接字，并根據(jù)服務(wù)器的標(biāo)識信息和/或客戶端的標(biāo)識信息選取匹配 程度最高的臨時(shí)UDP套接字作為臨時(shí)UDP套接字;在臨時(shí)UDP套接字產(chǎn)生讀取信號，并從與臨 時(shí)UDP套接字相關(guān)聯(lián)的接收緩沖區(qū)中讀取從客戶端接收到的數(shù)據(jù)。
[0022] 根據(jù)本發(fā)明實(shí)施例的另一方面，還提供了一種請求消息的發(fā)送方法，包括:在客戶 端上創(chuàng)建UDP套接字，并將服務(wù)器的標(biāo)識信息與UDP套接字進(jìn)行綁定;通過UDP套接字向服務(wù) 器發(fā)送請求消息。
[0023] 進(jìn)一步地，在通過UDP套接字向服務(wù)器發(fā)送請求消息之后，還包括：調(diào)用系統(tǒng)函數(shù) 從UDP套接字讀取從服務(wù)器接收到的與請求消息對應(yīng)的響應(yīng)數(shù)據(jù)。
[0024] 根據(jù)本發(fā)明實(shí)施例的又一方面，還提供了一種請求消息的處理裝置，包括:創(chuàng)建模 塊，用于在服務(wù)器的預(yù)設(shè)端口上創(chuàng)建全局UDP套接字;監(jiān)聽模塊，用于采用全局UDP套接字監(jiān) 聽客戶端發(fā)送的請求消息;通信模塊，用于為監(jiān)聽到的請求消息創(chuàng)建臨時(shí)UDP套接字，并通 過UDP臨時(shí)套接字與客戶端進(jìn)行通信。
[0025] 進(jìn)一步地，監(jiān)聽模塊包括:第一創(chuàng)建單元，用于在預(yù)設(shè)端口上創(chuàng)建全局UDP套接字， 其中，全局UDP套接字用于監(jiān)聽請求消息;第一處理單元，用于將全局UDP套接字中的套接字 選項(xiàng)設(shè)置為允許臨時(shí)UDP套接字與全局UDP套接字同時(shí)綁定至服務(wù)器的標(biāo)識信息，并且將服 務(wù)器的標(biāo)識信息與全局UDP套接字進(jìn)行綁定；監(jiān)聽單元，用于采用全局UDP套接字循環(huán)監(jiān)聽 等待請求消息，并在請求消息到達(dá)服務(wù)器時(shí)，創(chuàng)建子線程或進(jìn)程處理請求消息。
[0026] 進(jìn)一步地，通信模塊包括:第二處理單元，用于在子線程或進(jìn)程中創(chuàng)建臨時(shí)UDP套 接字，并允許臨時(shí)UDP套接字對服務(wù)器的標(biāo)識信息進(jìn)行復(fù)用;第一綁定單元，用于調(diào)用第一 系統(tǒng)函數(shù)將服務(wù)器的標(biāo)識信息與臨時(shí)UDP套接字進(jìn)行綁定;第二綁定單元，用于調(diào)用第二系 統(tǒng)函數(shù)將客戶端的標(biāo)識信息與臨時(shí)UDP套接字進(jìn)行綁定;通信單元，用于通過臨時(shí)UDP套接 字向客戶端發(fā)送數(shù)據(jù)和/或通過臨時(shí)UDP套接字讀取從客戶端接收到的數(shù)據(jù)。
[0027] 進(jìn)一步地，通信單元包括：匹配子單元，用于獲取與預(yù)設(shè)端口相匹配的全部臨時(shí) UDP套接字，并根據(jù)服務(wù)器的標(biāo)識信息和/或客戶端的標(biāo)識信息選取匹配程度最高的臨時(shí) UDP套接字作為臨時(shí)UDP套接字;讀取子單元，用于在臨時(shí)UDP套接字產(chǎn)生讀取信號，并從與 臨時(shí)UDP套接字相關(guān)聯(lián)的接收緩沖區(qū)中讀取從客戶端接收到的數(shù)據(jù)。
[0028] 根據(jù)本發(fā)明實(shí)施例的再一方面，還提供了一種請求消息的發(fā)送裝置，包括:處理模 塊，用于在客戶端上創(chuàng)建UDP套接字，并將服務(wù)器的標(biāo)識信息與UDP套接字進(jìn)行綁定;發(fā)送模 塊，用于通過UDP套接字向服務(wù)器發(fā)送請求消息。
[0029] 進(jìn)一步地，上述裝置還包括:讀取模塊，用于調(diào)用系統(tǒng)函數(shù)從UDP套接字讀取從服 務(wù)器接收到的與請求消息對應(yīng)的響應(yīng)數(shù)據(jù)。
[0030] 在本發(fā)明實(shí)施例中，采用在服務(wù)器的預(yù)設(shè)端口上創(chuàng)建的全局UDP套接字監(jiān)聽到客 戶端發(fā)送的請求消息;為請求消息創(chuàng)建臨時(shí)UDP套接字，并且將服務(wù)器的標(biāo)識信息和客戶端 的標(biāo)識信息與此UDP套接字綁定，W及通過UDP臨時(shí)套接字與客戶端進(jìn)行通信，通過使用全 局UDP套接字在預(yù)設(shè)端口上監(jiān)聽到客戶端發(fā)送的請求消息，并分別為每個(gè)客戶端發(fā)送的請 求消息分別創(chuàng)建一個(gè)臨時(shí)UDP套接