專利名稱:一種實現(xiàn)網絡客戶端節(jié)能的交互方法及系統(tǒng)的制作方法
技術領域:
本發(fā)明涉及交互技術,尤其涉及一種帶有網絡交互的客戶端/服務器(c/幻系統(tǒng)中實現(xiàn)網絡客戶端節(jié)能的交互方法及系統(tǒng)。
背景技術:
C/S系統(tǒng)中現(xiàn)有的交互技術是服務器在交互的客戶端間所起的作用僅僅是透傳消息,即服務器只是將一個客戶端的請求消息轉發(fā)給另一個客戶端進行處理,服務器自身并不對客戶端的請求做處理。響應的客戶端對請求消息進行處理時,是利用客戶端自身的內部邏輯運算的,并將運算后的結果作為對請求消息的響應由服務器轉發(fā)給請求的客戶端。采用現(xiàn)有交互技術存在的缺點是由于服務器僅透傳消息,運算是基于各個客戶端自身內部邏輯進行的,因此,導致客戶端在運算時大量的資源被占用,且客戶端一直在運算會很耗電,不利于客戶端節(jié)能。
發(fā)明內容
有鑒于此,本發(fā)明的主要目的在于提供一種實現(xiàn)網絡客戶端節(jié)能的交互方法及系統(tǒng),能避免客戶端大量的資源被占用,且降低客戶端耗電量,利于客戶端節(jié)能。為達到上述目的,本發(fā)明的技術方案是這樣實現(xiàn)的一種實現(xiàn)網絡客戶端節(jié)能的交互方法,該方法包括服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入所述請求消息中發(fā)送給響應客戶端。其中,所述采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理具體包括信息預處理操作、信息完整性校驗操作和信息合法性校驗操作。其中,所述請求客戶端發(fā)送的請求消息中攜帶業(yè)務信息;所述服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理具體包括對所述業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出備選業(yè)務類型信息,根據所述業(yè)務信息從所述備選業(yè)務類型信息中匹配出與所述業(yè)務信息對應的業(yè)務類型信息。其中,所述將運算結果添加入所述請求消息中發(fā)送給響應客戶端具體包括將與所述業(yè)務信息對應的業(yè)務類型信息添加入所述請求消息中發(fā)送給響應客戶端;該方法還包括所述響應客戶端獲知所述請求客戶端的所述業(yè)務信息和對應的所述業(yè)務類型信息后,查詢出匹配的業(yè)務類型信息,并由響應方轉變成發(fā)起方發(fā)起請求。一種實現(xiàn)網絡客戶端節(jié)能的交互系統(tǒng),該系統(tǒng)包括請求客戶端、服務器、和響應客戶端;其中,所述請求客戶端,用于向所述服務器發(fā)送請求消息;所述服務器,用于采用自身內部邏輯對請求客戶端發(fā)送的所述請求消息進行運算處理后,將運算結果添加入所述請求消息中發(fā)送給響應客戶端;
所述響應客戶端,用于接收所述請求消息并響應。其中,所述請求客戶端,進一步用于在發(fā)送的所述請求消息中攜帶業(yè)務信息;所述服務器,進一步用于對所述業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出備選業(yè)務類型信息,根據所述業(yè)務信息從所述備選業(yè)務類型信息中匹配出與所述業(yè)務信息對應的業(yè)務類型信息;將與所述業(yè)務信息對應的業(yè)務類型信息添加入所述請求消息中發(fā)送給響應客戶端。其中,所述響應客戶端,進一步用于從接收的所述請求消息中獲知所述請求客戶端的所述業(yè)務信息和對應的所述業(yè)務類型信息后,查詢出匹配的業(yè)務類型信息,并由響應方轉變成發(fā)起方發(fā)起請求。本發(fā)明的服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入請求消息中發(fā)送給響應客戶端。由于本發(fā)明將原本由客戶端所進行的運算置入服務器中運算,因此,能避免客戶端大量的資源被占用,且降低客戶端耗電量, 利于客戶端節(jié)能。
圖1為現(xiàn)有聯(lián)網打牌場景下的消息交互流程圖;圖2為采用本發(fā)明方法的聯(lián)網打牌場景下的消息交互流程圖。
具體實施例方式本發(fā)明的基本思想是服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入請求消息中發(fā)送給響應客戶端。為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白,以下舉實施例并參照附圖,對本發(fā)明進一步詳細說明。以下將現(xiàn)有技術和本發(fā)明進行對比闡述,以更好地體現(xiàn)本發(fā)明相對于現(xiàn)有技術的優(yōu)點。就現(xiàn)有技術而言,如圖1所示,交互過程包括以下步驟步驟101、由客戶端A發(fā)起業(yè)務時,客戶端A向服務器發(fā)送請求消息,請求消息中攜帶客戶端A的業(yè)務信息。這里,如果以現(xiàn)有聯(lián)網打牌場景下的消息交互為例,客戶端A和客戶端B兩個終端在玩牌,則業(yè)務信息可以具體為出牌信息。相應的,后續(xù)步驟中的業(yè)務類型信息可以具體為牌型信息,業(yè)務數量可以具體為出牌數量。以下不作贅述。步驟102、服務器檢查客戶端A的業(yè)務信息的正確性后,返回響應消息給客戶端A。步驟103、服務器轉發(fā)請求消息給客戶端B,請求消息中攜帶客戶端A的業(yè)務信息。步驟104、客戶端B收到請求消息后,從請求消息中獲知客戶端A的業(yè)務信息,運算出客戶端A的業(yè)務類型信息,查詢出匹配的業(yè)務類型信息以便客戶端B發(fā)起業(yè)務。這里,針對本步驟舉例,業(yè)務信息是AAAB,其對應的業(yè)務類型信息是三帶一;業(yè)務信息是AABBCC,其對應的業(yè)務類型信息是連對;業(yè)務信息是AB⑶EF...,其對應的業(yè)務類型信息是順子;業(yè)務信息是AAAA,其對應的業(yè)務類型信息是炸彈等。運算業(yè)務類型信息時,是根據獲知的業(yè)務數量運算出可能的幾種業(yè)務類型信息。然后,根據業(yè)務信息從可能的這幾
4種業(yè)務類型信息中匹配出對應的業(yè)務類型信息,以便客戶端B發(fā)起業(yè)務。步驟105、由客戶端B發(fā)起業(yè)務時,客戶端B向服務器發(fā)送請求消息,請求消息中攜帶客戶端B的業(yè)務信息。步驟106、服務器檢查客戶端B的業(yè)務信息的正確性后,返回響應消息給客戶端B。步驟107、服務器轉發(fā)請求消息給客戶端A,請求消息中攜帶客戶端B的業(yè)務信息。步驟108、客戶端A收到請求消息后,從請求消息中獲知客戶端B的業(yè)務信息,運算出客戶端B的業(yè)務類型信息,查詢出匹配的業(yè)務類型信息以便接續(xù)由客戶端A發(fā)起業(yè)務。綜上所述,可以看到現(xiàn)有技術中兩個客戶端進行消息交互時存在很明顯的缺點, 即為兩個客戶端中的任意一個客戶端每次收到對端客戶端的業(yè)務信息,都必須運算對端客戶端所發(fā)起業(yè)務的業(yè)務類型信息,再從自己的業(yè)務信息中查詢出相匹配的業(yè)務類型信息,這個運算對端客戶端所發(fā)起業(yè)務的業(yè)務類型信息是多余的運算,因為從客戶端節(jié)能的角度考慮,客戶端只執(zhí)行自身相關的操作就好了,比如從自己的業(yè)務信息中查詢出相匹配的業(yè)務類型信息。由于上述多余的運算勢必占用客戶端資源,一直處于運算的客戶端很耗電,不利于客戶端節(jié)能。而本發(fā)明設計C/S交互協(xié)議時充分考慮和利用公共運算部分,盡可能地將運算放在服務器側而不是在客戶端側,以便盡可能的減少交互中的重復運算。這種方式尤其適合于運算能力弱的客戶端,比如手機,機頂盒等設備等。本發(fā)明通過將客戶端的公共運算后置到服務器側,減少了客戶端側的運算,從而實現(xiàn)了終端節(jié)能。而且服務器作為客戶端的管理方能獲知所有客戶端提交的信息,也便于利用這些信息進行運算。如果是客戶端進行運算, 通常只保存自身相關的信息,不會涉及到其他客戶端的信息,當遇到自身不知曉的信息時還需要向服務器進行查詢,勢必增加額外的消息交互。因此,本發(fā)明由服務器進行運算能很好地達到客戶端節(jié)能的效果。需要指出的是本發(fā)明的業(yè)務不局限于聯(lián)網打牌場景的具體應用,適用于所有的聯(lián)網休閑游戲場景,如斗地主、象棋、或麻將等。所謂聯(lián)網休閑游戲場景指兩個或兩個以上的用戶登錄客戶端一起聯(lián)網玩,并且需要登錄的客戶端實時與服務器交互游戲數據的場景。以下對本發(fā)明進行具體闡述。一種實現(xiàn)網絡客戶端節(jié)能的交互方法,該方法主要包括以下內容服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入請求消息中發(fā)送給響應客戶端。這里,在聯(lián)網打牌場景下,請求客戶端發(fā)送的所述請求消息中可以攜帶業(yè)務信息。 那么所述服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理具體包括 對業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出可能的幾種備選業(yè)務類型信息,然后,根據業(yè)務信息從可能的這幾種備選業(yè)務類型信息中匹配出對應的業(yè)務類型信息,以獲得與業(yè)務信息對應的業(yè)務類型信息。所謂業(yè)務類型信息屬于業(yè)務信息的特性,比如業(yè)務信息是3334,這個業(yè)務信息對應的業(yè)務類型信息是“三帶一”。這里,所述將運算結果添加入所述請求消息中發(fā)送給響應客戶端具體包括將與業(yè)務信息對應的業(yè)務類型信息添加入所述請求消息中發(fā)送給響應客戶端。該方法還包括響應客戶端獲知所述請求客戶端的業(yè)務信息和對應的業(yè)務類型信息后,查詢出匹配的業(yè)務類型信息以便于后續(xù)由響應客戶端發(fā)起業(yè)務,響應客戶端發(fā)起業(yè)務時由響應方轉變成發(fā)起方發(fā)起請求。這里需要指出的是,服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理具體包括信息預處理操作、信息完整性校驗操作和信息合法性校驗操作。其中,所述信息預處理操作,即為上述服務器根據獲知的業(yè)務數量運算出可能的幾種備選業(yè)務類型信息,然后,根據業(yè)務信息從可能的這幾種備選業(yè)務類型信息中匹配出對應的業(yè)務類型信息,以獲得與業(yè)務信息對應的業(yè)務類型信息的操作。所述信息完整性校驗操作,即為檢查數據包是不是完整的操作。所述信息合法性校驗操作,即為服務器要判別本次出的業(yè)務類型信息是否與前次業(yè)務類型信息相匹配,在匹配的基礎上當本次業(yè)務信息大于前次業(yè)務信息時合法性校驗通過。方法實施例如圖2所示,交互過程包括以下步驟步驟201、由客戶端A發(fā)起業(yè)務時,客戶端A向服務器發(fā)送請求消息,請求消息中攜帶客戶端A的業(yè)務信息。這里,為了針對以上現(xiàn)有技術的例子對比方便描述,仍然以聯(lián)網打牌場景下的消息交互為例,客戶端A和客戶端B兩個終端在玩牌,則業(yè)務信息可以具體為出牌信息。相應的,后續(xù)步驟中的業(yè)務類型信息可以具體為牌型信息,業(yè)務數量可以具體為出牌數 量。以下不作贅述。步驟202、服務器檢查客戶端A的業(yè)務信息的正確性后,返回響應消息給客戶端A。步驟203、服務器對客戶端A的業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出可能的幾種備選業(yè)務類型信息,然后,根據客戶端A的業(yè)務信息從可能的這幾種備選業(yè)務類型信息中匹配出對應的業(yè)務類型信息,以獲得與客戶端A的業(yè)務信息對應的客戶端A的業(yè)務類型信息。步驟204、服務器將獲得的客戶端A的業(yè)務類型信息添加入請求消息,將攜帶客戶端A的業(yè)務信息和客戶端A的業(yè)務類型信息的請求消息發(fā)送給客戶端B。步驟205、客戶端B收到請求消息后,從請求消息中獲知客戶端A的業(yè)務信息和客戶端A的業(yè)務類型信息,查詢出匹配的業(yè)務類型信息以便客戶端B發(fā)起業(yè)務。步驟206、由客戶端B發(fā)起業(yè)務時,客戶端B向服務器發(fā)送請求消息,請求消息中攜帶客戶端B的業(yè)務信息。步驟207、服務器檢查客戶端B的業(yè)務信息的正確性后,返回響應消息給客戶端B。步驟208、服務器對客戶端B的業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出可能的幾種備選業(yè)務類型信息,然后,根據客戶端B的業(yè)務信息從可能的這幾種備選業(yè)務類型信息中匹配出對應的業(yè)務類型信息,以獲得與客戶端B的業(yè)務信息對應的客戶端B的業(yè)務類型信息。步驟209、服務器將獲得的客戶端B的業(yè)務類型信息添加入請求消息,將攜帶客戶端B的業(yè)務信息和客戶端B的業(yè)務類型信息的請求消息發(fā)送給客戶端A。步驟210、客戶端A收到請求消息后,從請求消息中獲知客戶端B的業(yè)務信息和客戶端B的業(yè)務類型信息,查詢出匹配的業(yè)務類型信息以便客戶端A發(fā)起業(yè)務。通過以上方法實施例與現(xiàn)有聯(lián)網打牌場景下例子的對比可知通過在請求消息中增加業(yè)務類型信息,客戶端省略了運算對端客戶端業(yè)務類型信息的過程。在聯(lián)網休閑游戲場景中,類似的例子還有很多,比如斗地主游戲中,一個玩家出了雙王,服務器運算后在請求消息中通知其它兩家手中沒有大過本家出的牌的結果,以減少其它兩家客戶端的運算; 又如象棋游戲中,對家下的棋是否對本家造成“將軍”,如果采用現(xiàn)有技術,每次客戶端都要運算,而采用本發(fā)明,完全可以由服務器運算后在請求消息中增加是否“將軍”即可。一種實現(xiàn)網絡客戶端節(jié)能的交互系統(tǒng),該系統(tǒng)包括請求客戶端、服務器、和響應客戶端。其中,請求客戶端用于向服務器發(fā)送請求消息。服務器用于采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入請求消息中發(fā)送給響應客戶端。響應客戶端用于接收請求消息并響應。這里,請求客戶端進一步用于在聯(lián)網打牌場景下,在發(fā)送的請求消息中攜帶業(yè)務信息。服務器進一步用于對業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出備選業(yè)務類型信息,根據業(yè)務信息從備選業(yè)務類型信息中匹配出與業(yè)務信息對應的業(yè)務類型信息;將與業(yè)務信息對應的業(yè)務類型信息添加入請求消息中發(fā)送給響應客戶端。這里,響應客戶端進一步用于從接收的請求消息中獲知請求客戶端的業(yè)務信息和對應的業(yè)務類型信息后,查詢出匹配的業(yè)務類型信息,并由響應方轉變成發(fā)起方發(fā)起請求。以上所述,僅為本發(fā)明的較佳實施例而已,并非用于限定本發(fā)明的保護范圍。
權利要求
1.一種實現(xiàn)網絡客戶端節(jié)能的交互方法,其特征在于,該方法包括服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入所述請求消息中發(fā)送給響應客戶端。
2.根據權利要求1所述的方法,其特征在于,所述采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理具體包括信息預處理操作、信息完整性校驗操作和信息合法性校驗操作。
3.根據權利要求1所述的方法,其特征在于,所述請求客戶端發(fā)送的請求消息中攜帶業(yè)務信息;所述服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理具體包括 對所述業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出備選業(yè)務類型信息, 根據所述業(yè)務信息從所述備選業(yè)務類型信息中匹配出與所述業(yè)務信息對應的業(yè)務類型信肩、ο
4.根據權利要求3所述的方法,其特征在于,所述將運算結果添加入所述請求消息中發(fā)送給響應客戶端具體包括將與所述業(yè)務信息對應的業(yè)務類型信息添加入所述請求消息中發(fā)送給響應客戶端;該方法還包括所述響應客戶端獲知所述請求客戶端的所述業(yè)務信息和對應的所述業(yè)務類型信息后,查詢出匹配的業(yè)務類型信息,并由響應方轉變成發(fā)起方發(fā)起請求。
5.一種實現(xiàn)網絡客戶端節(jié)能的交互系統(tǒng),其特征在于,該系統(tǒng)包括請求客戶端、服務器、和響應客戶端;其中,所述請求客戶端,用于向所述服務器發(fā)送請求消息;所述服務器,用于采用自身內部邏輯對請求客戶端發(fā)送的所述請求消息進行運算處理后,將運算結果添加入所述請求消息中發(fā)送給響應客戶端;所述響應客戶端,用于接收所述請求消息并響應。
6.根據權利要求5所述的系統(tǒng),其特征在于,所述請求客戶端,進一步用于在發(fā)送的所述請求消息中攜帶業(yè)務信息;所述服務器,進一步用于對所述業(yè)務信息進行信息預處理操作時,根據獲知的業(yè)務數量運算出備選業(yè)務類型信息,根據所述業(yè)務信息從所述備選業(yè)務類型信息中匹配出與所述業(yè)務信息對應的業(yè)務類型信息;將與所述業(yè)務信息對應的業(yè)務類型信息添加入所述請求消息中發(fā)送給響應客戶端。
7.根據權利要求6所述的系統(tǒng),其特征在于,所述響應客戶端,進一步用于從接收的所述請求消息中獲知所述請求客戶端的所述業(yè)務信息和對應的所述業(yè)務類型信息后,查詢出匹配的業(yè)務類型信息,并由響應方轉變成發(fā)起方發(fā)起請求。
全文摘要
本發(fā)明公開了一種實現(xiàn)網絡客戶端節(jié)能的交互方法,該方法包括服務器采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入所述請求消息中發(fā)送給響應客戶端。本發(fā)明還公開了一種實現(xiàn)網絡客戶端節(jié)能的交互系統(tǒng),系統(tǒng)中的服務器用于采用自身內部邏輯對請求客戶端發(fā)送的請求消息進行運算處理后,將運算結果添加入請求消息中發(fā)送給響應客戶端。采用本發(fā)明的方法及系統(tǒng),能避免客戶端大量的資源被占用,且降低客戶端耗電量,利于客戶端節(jié)能。
文檔編號H04L29/06GK102546539SQ20101059325
公開日2012年7月4日 申請日期2010年12月7日 優(yōu)先權日2010年12月7日
發(fā)明者俞烜, 李偉, 王雪暉 申請人:騰訊科技(深圳)有限公司