專利名稱：消息獲取和處理方法、客戶端、服務(wù)器和通信系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，尤其涉及一種消息獲取和處理方法、客戶端、服務(wù)器和通信
系統(tǒng)。
背景技術(shù)：
目前普遍應(yīng)用的認(rèn)證、授權(quán)、計(jì)費(fèi)(Authentication AuthorizationandAccounting，簡(jiǎn)稱為AAA)客戶端和服務(wù)器模式中，客戶端和服務(wù)器之間 通過(guò)消息的交互實(shí)現(xiàn)通信，下面對(duì)客戶端與服務(wù)器間的消息交互過(guò)程進(jìn)行簡(jiǎn)單的描述。
用戶向客戶端發(fā)送接入請(qǐng)求，客戶端根據(jù)用戶的接入請(qǐng)求向服務(wù)器發(fā)送AAA請(qǐng) 求；服務(wù)器根據(jù)AAA請(qǐng)求中的內(nèi)容進(jìn)行處理，并主動(dòng)向客戶端發(fā)送含有控制命令的會(huì)話控 制報(bào)文如果服務(wù)器對(duì)AAA請(qǐng)求的處理結(jié)果為成功，服務(wù)器會(huì)向客戶端返回成功信息，如果 服務(wù)器對(duì)AAA請(qǐng)求的處理結(jié)果為失敗，服務(wù)器會(huì)向客戶端返回失敗信息。
由于服務(wù)器返回的信息過(guò)于簡(jiǎn)單，因此客戶端不能夠獲知具體的失敗原因，因此 不能夠?qū)AA的請(qǐng)求發(fā)送進(jìn)行優(yōu)化，并且客戶端也無(wú)法進(jìn)一步判斷是否將失敗信息返回給 接入端，同時(shí)也不能夠有效地對(duì)客戶端進(jìn)行維護(hù)和管理。 針對(duì)相關(guān)技術(shù)中由于服務(wù)器對(duì)AAA請(qǐng)求處理后返回的信息過(guò)于簡(jiǎn)單使得客戶端 不能獲知失敗原因從而影響客戶端管理和維護(hù)的問(wèn)題，目前尚未提出有效的解決方案。

發(fā)明內(nèi)容
針對(duì)相關(guān)技術(shù)中由于服務(wù)器對(duì)AAA請(qǐng)求處理后僅返回失敗信息而使得客戶端不
能獲知失敗原因從而影響客戶端管理和維護(hù)的問(wèn)題，本發(fā)明提出一種消息獲取方法，使客
戶端能夠獲知失敗的具體情況，便于用戶了解失敗的問(wèn)題從而進(jìn)行優(yōu)化。 針對(duì)相關(guān)技術(shù)中由于服務(wù)器對(duì)AAA請(qǐng)求處理后僅返回失敗信息而使得客戶端不
能獲知失敗原因從而影響客戶端管理和維護(hù)的問(wèn)題，本發(fā)明還提出一種客戶端，使客戶端
能夠獲知失敗的具體情況，便于用戶了解失敗的問(wèn)題從而進(jìn)行優(yōu)化。 針對(duì)相關(guān)技術(shù)中由于服務(wù)器對(duì)AAA請(qǐng)求處理后僅返回失敗信息而使得客戶端不 能獲知失敗原因從而影響客戶端管理和維護(hù)的問(wèn)題，本發(fā)明還提出一種通信系統(tǒng)，使客戶 端能夠獲知失敗的具體情況，便于用戶了解失敗的問(wèn)題從而進(jìn)行優(yōu)化。
本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的
—種消息獲取方法，包括 客戶端接收來(lái)自用戶的第一請(qǐng)求，并向服務(wù)器發(fā)送第二請(qǐng)求，其中，所述第二請(qǐng)求 中攜帶有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述第二請(qǐng) 求返回失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶
丄山順。 其中，所述客戶端向服務(wù)器發(fā)送第二請(qǐng)求的操作為 所述客戶端根據(jù)所述第一請(qǐng)求向服務(wù)器發(fā)送所述第二請(qǐng)求；或者，
4
所述客戶端向所述服務(wù)器發(fā)送對(duì)應(yīng)于所述第一請(qǐng)求的所述第二請(qǐng)求。 優(yōu)選地，在所述客戶端根據(jù)所述第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求之前，還包括 所述客戶端根據(jù)所述第一請(qǐng)求，判斷所述用戶的接入類型是否為預(yù)定接入類型，
在所述用戶的接入類型為預(yù)定接入類型的情況下，所述客戶端將所述失敗原因請(qǐng)求信息攜
帶在所述第二請(qǐng)求中。
進(jìn)一步地，上述方法還包括 客戶端將返回所述失敗信息的原因發(fā)送給所述用戶。
其中，所述第一請(qǐng)求為以下之一 用戶接入請(qǐng)求、用戶登錄請(qǐng)求，所述第二請(qǐng)求包 括以下之一 認(rèn)證請(qǐng)求、授權(quán)請(qǐng)求、計(jì)費(fèi)請(qǐng)求。
—種消息處理方法，包括
服務(wù)器接收來(lái)自客戶端的請(qǐng)求； 所述服務(wù)器響應(yīng)于所述請(qǐng)求返回失敗信息，并將返回所述失敗信息的原因發(fā)送給 所述客戶端。 其中，所述請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述 服務(wù)器響應(yīng)于所述請(qǐng)求返回失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原 因發(fā)送給所述客戶端。 其中，所述請(qǐng)求中攜帶有所述客戶端的標(biāo)識(shí)； 則服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端的處理包括 所述服務(wù)器在所述客戶端的標(biāo)識(shí)合法的情況下，將返回所述失敗信息的原因發(fā)送
給所述客戶端。 其中，所述第二請(qǐng)求中還攜帶有所述用戶的標(biāo)識(shí)； 則服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端的處理包括 所述服務(wù)器在所述用戶的標(biāo)識(shí)合法的情況下，將返回所述失敗信息的原因發(fā)送給
所述客戶端。 —種客戶端，包括 接收模塊，用于接收來(lái)自用戶的第一請(qǐng)求； 處理模塊，用于向服務(wù)器發(fā)送第二請(qǐng)求，其中，所述第二請(qǐng)求中攜帶有失敗原因請(qǐng) 求信息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述第二請(qǐng)求返回失敗信息的情 況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端。
進(jìn)一步地，上述客戶端還包括 存儲(chǔ)模塊，用于存儲(chǔ)來(lái)自所述服務(wù)器的所述失敗信息的原因，并且在所述存儲(chǔ)模 塊的存儲(chǔ)空間被占滿或被占用的存儲(chǔ)空間達(dá)到預(yù)定門(mén)限的情況下，刪除滿足存儲(chǔ)時(shí)間長(zhǎng)度 達(dá)到預(yù)設(shè)門(mén)限的原因。
—種服務(wù)器，包括 接收模塊，用于接收來(lái)自客戶端的請(qǐng)求； 處理模塊，用于響應(yīng)于所述請(qǐng)求返回失敗信息，并將返回所述失敗信息的原因發(fā) 送給所述客戶端。 其中，所述請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述 服務(wù)器響應(yīng)于所述請(qǐng)求返回失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端。 —種通信系統(tǒng)，其特征在于，包括客戶端和服務(wù)器，其中， 所述客戶端，用于接收來(lái)自用戶的第一請(qǐng)求，并向服務(wù)器發(fā)送第二請(qǐng)求，其中，所 述第二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于 所述第二請(qǐng)求返回失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給 所述客戶端； 所述服務(wù)器，用于將返回所述失敗信息的原因發(fā)送給所述客戶端。 借助于本發(fā)明的上述技術(shù)方案，通過(guò)客戶端根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求
并請(qǐng)求返回失敗信息，使得服務(wù)器能夠在返回對(duì)應(yīng)于第二請(qǐng)求的失敗信息的同時(shí)發(fā)送返回
失敗信息的原因，使客戶端能夠獲知失敗的具體情況，便于用戶了解失敗的問(wèn)題從而進(jìn)行
優(yōu)化，并且有助于對(duì)客戶端進(jìn)行管理。


圖1是根據(jù)本發(fā)明實(shí)施例的消息獲取方法的流程圖； 圖2是本發(fā)明實(shí)施例的AAA客戶端創(chuàng)建服務(wù)器信息請(qǐng)求策略的詳細(xì)處理流程圖； 圖3是本發(fā)明實(shí)施例的AAA客戶端判斷并封裝發(fā)送認(rèn)證請(qǐng)求報(bào)文的詳細(xì)處理流程 圖； 圖4是本發(fā)明實(shí)施例的AAA客戶端配置本地管理策略的詳細(xì)處理流程圖； 圖5是本發(fā)明實(shí)施例的AAA客戶端配置失敗原因信息下發(fā)策略的詳細(xì)處理流程
圖； 圖6是根據(jù)本發(fā)明實(shí)施例的AAA客戶端配置信息下發(fā)策略的詳細(xì)處理流程圖； 圖7是根據(jù)本發(fā)明實(shí)施例的AAA服務(wù)器判斷并封裝返回響應(yīng)報(bào)文的處理流程圖； 圖8是根據(jù)本發(fā)明實(shí)施例的AAA服務(wù)器配置詳細(xì)信息下發(fā)策略的處理流程圖； 圖9是根據(jù)本發(fā)明實(shí)施例的客戶端的組成結(jié)構(gòu)圖； 圖10是根據(jù)本發(fā)明實(shí)施例的服務(wù)器的組成結(jié)構(gòu)圖； 圖11是根據(jù)本發(fā)明實(shí)施例的通信系統(tǒng)的組成結(jié)構(gòu)圖； 圖12是根據(jù)本發(fā)明實(shí)施例的客戶端和服務(wù)器間交互的邏輯關(guān)系示意圖。
具體實(shí)施例方式
目前，客戶端與服務(wù)器的交互過(guò)程中，服務(wù)器會(huì)對(duì)客戶端進(jìn)行主動(dòng)控制。并且，在 實(shí)際應(yīng)用中，導(dǎo)致客戶端向服務(wù)器發(fā)送的請(qǐng)求被拒絕的原因很多，例如，用戶名密碼不匹 配、不符合地址過(guò)濾策略、NAS合法性檢查失敗等，如果客戶端不知道被服務(wù)器拒絕的原因， 就難以對(duì)客戶端進(jìn)行管理和維護(hù)?；诖?，本發(fā)明提供一種消息的獲取方法，其中，由客戶 端主動(dòng)向服務(wù)器請(qǐng)求獲取AAA請(qǐng)求被拒絕的原因，以便根據(jù)失敗原因?qū)Ρ痪芙^的請(qǐng)求進(jìn)行 優(yōu)化處理，方便對(duì)客戶端進(jìn)行管理。 圖1是本發(fā)明實(shí)施例的消息獲取方法的步驟流程圖，如圖1所示，包括以下處理
步驟SlOl，客戶端接收來(lái)自用戶的第一請(qǐng)求，其中，該第一請(qǐng)求可以為以下之一 用戶接入請(qǐng)求、用戶登錄請(qǐng)求。 步驟S102，客戶端向服務(wù)器發(fā)送第二請(qǐng)求，其中，第二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，失敗原因請(qǐng)求信息用于在服務(wù)器響應(yīng)于第二請(qǐng)求返回失敗信息的情況下(即，失敗 原因請(qǐng)求信息用于在服務(wù)器響應(yīng)于第二請(qǐng)求的返回結(jié)果為失敗的情況下)，請(qǐng)求服務(wù)器將 返回失敗信息的原因發(fā)送給客戶端，之后，服務(wù)器會(huì)將返回失敗信息的原因發(fā)送給客戶端， 以對(duì)客戶端進(jìn)行維護(hù)和管理，可選地，客戶端可以將返回失敗信息的原因發(fā)送給用戶；其 中，客戶端向服務(wù)器發(fā)送的第二請(qǐng)求可以是認(rèn)證請(qǐng)求、授權(quán)請(qǐng)求、或計(jì)費(fèi)請(qǐng)求，也可以是新 構(gòu)造的請(qǐng)求，該新構(gòu)造的請(qǐng)求中可以僅包括失敗原因請(qǐng)求信息，這樣，客戶端在向服務(wù)器發(fā) 送該新構(gòu)造的請(qǐng)求時(shí)，會(huì)將與該新構(gòu)造的請(qǐng)求具有對(duì)應(yīng)關(guān)系的第一請(qǐng)求也發(fā)送給服務(wù)器， 以使服務(wù)器獲知該新構(gòu)造的請(qǐng)求所對(duì)應(yīng)的用戶。 通過(guò)上述處理，能夠使客戶端根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求時(shí)請(qǐng)求返回失 敗信息，以便服務(wù)器能夠在返回對(duì)應(yīng)于第二請(qǐng)求的失敗信息的同時(shí)發(fā)送返回失敗信息的原 因，使客戶端能夠獲知失敗的具體情況，便于用戶了解失敗的原因從而進(jìn)行優(yōu)化，并且有助 于對(duì)客戶端進(jìn)行管理，同時(shí)能夠使得認(rèn)證過(guò)程更人性化。 在具體實(shí)現(xiàn)過(guò)程中，在客戶端根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求之前，客戶端 可以根據(jù)來(lái)自用戶的第一請(qǐng)求，判斷用戶的接入類型是否為預(yù)定接入類型，在用戶的接入 類型為預(yù)定接入類型的情況下，客戶端將失敗原因請(qǐng)求信息攜帶在第二請(qǐng)求中。當(dāng)然，客戶 端也可以不對(duì)用戶的接入類型進(jìn)行判斷，直接將失敗原因請(qǐng)求信息攜帶在第二請(qǐng)求中，即， 無(wú)論用戶為何種接入類型，客戶端均將失敗原因請(qǐng)求信息攜帶在第二請(qǐng)求中發(fā)送給服務(wù) 器。 并且，在服務(wù)器會(huì)將返回失敗信息的原因發(fā)送給客戶端的處理過(guò)程中，服務(wù)器可 以根據(jù)以下方式執(zhí)行該操作 方式1 :服務(wù)器直接將返回失敗信息的原因發(fā)送給客戶端。 方式2 :上述第二請(qǐng)求中還攜帶有客戶端的標(biāo)識(shí)，此時(shí)服務(wù)器會(huì)在客戶端的標(biāo)識(shí) 合法的情況下，將第二請(qǐng)求失敗的原因發(fā)送給客戶端。 方式3 :上述第二請(qǐng)求中還攜帶有用戶的標(biāo)識(shí)，此時(shí)，服務(wù)器會(huì)在用戶的標(biāo)識(shí)合法 的情況下，將第二請(qǐng)求失敗的原因發(fā)送給客戶端。 在服務(wù)器會(huì)將返回失敗信息的原因發(fā)送給客戶端的處理過(guò)程中，可以將上述三種 方式相結(jié)合，或者采用其中一種方式來(lái)執(zhí)行。例如，服務(wù)器通過(guò)方式2，首先對(duì)客戶端的標(biāo)識(shí) 進(jìn)行合法性驗(yàn)證，如果客戶端的標(biāo)識(shí)，在對(duì)用戶的標(biāo)識(shí)進(jìn)行驗(yàn)證，如果用戶的標(biāo)識(shí)合法，再 將第二請(qǐng)求失敗的原因發(fā)送給客戶端。 為了更好的對(duì)本發(fā)明進(jìn)行說(shuō)明，下面以AAA客戶端和AAA服務(wù)器之間的通信為例 進(jìn)行說(shuō)明，本領(lǐng)域技術(shù)人員可知，對(duì)于其它類型的客戶端和服務(wù)器，本發(fā)明同樣是可以實(shí)現(xiàn) 的。 下面結(jié)合附圖對(duì)本發(fā)明中客戶端和服務(wù)器需要配置的策略以及流程圖進(jìn)行說(shuō)明。
—、 AAA客戶端配置服務(wù)器信息請(qǐng)求策略。 該策略用于AAA客戶端判斷當(dāng)不同接入類型的用戶發(fā)送請(qǐng)求時(shí)，AAA客戶端是否 向服務(wù)器請(qǐng)求獲取服務(wù)器向AAA客戶端返回失敗信息的原因。具體地，AAA客戶端創(chuàng)建服 務(wù)器信息請(qǐng)求策略時(shí)，需要在該策略中為所有可能的用戶接入類型定義是否允許向服務(wù)器 請(qǐng)求詳細(xì)信息。目前常用的接入類型包括dotlx接入客戶端、ssh客戶端、telnet客戶端 和串口。對(duì)應(yīng)每種接入類型，有"允許"或者"不允許"兩種策略配置，默認(rèn)為"不允許"。例如，對(duì)于接入類型為ssh和telnet的客戶端，可以將策略配置為"允許"，即，客戶端可以根
據(jù)來(lái)自用戶的第一請(qǐng)求，判斷用戶的接入類型是否為ssh或telnet,在用戶的接入類型為
ssh或telnet的情況下，客戶端將失敗原因請(qǐng)求信息攜帶在第二請(qǐng)求中。 圖2是本發(fā)明實(shí)施例的AAA客戶端創(chuàng)建服務(wù)器信息請(qǐng)求策略的詳細(xì)處理流程圖，
如圖2所示，包括以下步驟 步驟S201，流程開(kāi)始。 步驟S202，創(chuàng)建策略。 步驟S203，在策略下配置dotlx接入類型的處理方式，"允許"或者不允許，此步驟 可以跳過(guò)到后面的任意步驟，跳過(guò)的默認(rèn)處理方式為"不允許"，優(yōu)選地，可以將接入類型為 dotlx的用戶配置為"不允許"。 步驟S204，在策略下配置ssh接入類型的處理方式，"允許"或者不允許。此步驟 可以跳過(guò)到后面的任意步驟，跳過(guò)的默認(rèn)處理方式為"不允許"，優(yōu)選地，可以將接入類型為 ssh的用戶配置為"允許"。 步驟S205，在策略下配置telnet接入類型的處理方式，"允許"或者不允許。此步 驟可以跳過(guò)到后面的任意步驟，跳過(guò)的默認(rèn)處理方式為"不允許"，優(yōu)選地，可以將接入類型 為telnet的用戶配置為"允許"。
步驟S206，生成策略。
步驟S207，操作完成。 二、AAA客戶端向認(rèn)證請(qǐng)求報(bào)文中填寫(xiě)"請(qǐng)求詳細(xì)信息"字段。
用于AAA客戶端向?qū)?yīng)AAA協(xié)議中填寫(xiě)"請(qǐng)求詳細(xì)信息"字段，并隨認(rèn)證請(qǐng)求報(bào)文 發(fā)送至服務(wù)器。具體地，AAA客戶端向認(rèn)證請(qǐng)求報(bào)文(對(duì)應(yīng)于上述第二請(qǐng)求)中填寫(xiě)"請(qǐng)求 詳細(xì)信息"字段。當(dāng)AAA客戶端收到接入請(qǐng)求時(shí)，首先根據(jù)接入類型查找本地配置的服務(wù)器 信息請(qǐng)求策略，如果該接入請(qǐng)求類型對(duì)應(yīng)的策略為"允許"，則向認(rèn)證請(qǐng)求報(bào)文中填寫(xiě)"請(qǐng)求 詳細(xì)信息"字段，如果為"不允許"，則不填寫(xiě)該字段。然后AAA客戶端將封裝好的認(rèn)證請(qǐng)求 報(bào)文發(fā)往服務(wù)器端，通過(guò)該字段請(qǐng)求獲取服務(wù)器根據(jù)認(rèn)證請(qǐng)求報(bào)文返回失敗信息的原因。
圖3是本發(fā)明實(shí)施例的AAA客戶端判斷并封裝發(fā)送認(rèn)證請(qǐng)求報(bào)文的詳細(xì)處理流程 圖，如圖3所示，包括以下步驟 步驟S301， AAA客戶端接收到來(lái)自用戶的接入請(qǐng)求報(bào)文；
步驟S302， AAA客戶端查詢?cè)摻尤敕绞綄?duì)應(yīng)的客戶端服務(wù)器信息請(qǐng)求策略；
步驟S303， AAA客戶端根據(jù)預(yù)設(shè)策略判斷是否在發(fā)送給服務(wù)器的AAA請(qǐng)求報(bào)文中 填寫(xiě)"請(qǐng)求詳細(xì)信息字段"，如果判斷結(jié)果為是，進(jìn)入步驟S304，否則進(jìn)入步驟S305 ;
步驟S304，AAA客戶端填寫(xiě)"請(qǐng)求詳細(xì)信息字段"(即，上文所述的返回失敗信息的 原因)； 步驟S305，封裝報(bào)文；
步驟S306，發(fā)送報(bào)文；
步驟S307，操作完成。
三、AAA客戶端配置本地管理策略。 該策略用于AAA客戶端收到服務(wù)器返回的失敗原因之后，如何對(duì)這些失敗原因進(jìn)
行管理。
8
圖4是本發(fā)明實(shí)施例的AAA客戶端配置本地管理策略的詳細(xì)處理流程圖，如圖4
所示，包括以下步驟 步驟S401，流程開(kāi)始。 步驟S402，創(chuàng)建策略。 步驟S403，在策略下配置是否允許本地保存服務(wù)器詳細(xì)信息，此步驟可以跳過(guò)到 后面的任意步驟，跳過(guò)的默認(rèn)處理方式為"不允許"。 步驟S404，在策略下配置本地允許保存的服務(wù)器詳細(xì)信息的最大條目數(shù)，此步驟 可以跳過(guò)到后面的任意步驟，跳過(guò)的默認(rèn)處理方式為條目數(shù)1。 步驟S405，在策略下配置本地保存服務(wù)器信息條目的老化時(shí)間，此步驟可以跳過(guò)
到后面的任意步驟，跳過(guò)的默認(rèn)處理方式為老化時(shí)間24小時(shí)。 步驟S406，生成策略。 步驟S407，操作完成。 四、AAA客戶端下發(fā)失敗原因信息。 該策略用于AAA客戶端接收到服務(wù)器返回的認(rèn)證結(jié)果詳細(xì)信息后，針對(duì)不同的接 入用戶，如何進(jìn)行信息下發(fā)。 圖5是本發(fā)明實(shí)施例的AAA客戶端配置失敗原因信息下發(fā)策略的詳細(xì)處理流程 圖，如圖5所示，包括以下步驟 步驟S501， AAA客戶端接收到認(rèn)證響應(yīng)報(bào)文； 步驟S502，解析"詳細(xì)信息"字段，即，解析服務(wù)器返回的失敗信息的原因；
步驟S503，判斷該字段是否有內(nèi)容，如果有內(nèi)容，執(zhí)行步驟S504，否則執(zhí)行步驟 S510 ; 步驟S504，查詢服務(wù)器信息管理策略； 步驟S505，判斷服務(wù)器信息管理策略是否允許保存信息，如果允許，則執(zhí)行步驟 S506，否則執(zhí)行步驟S507 ; 步驟S506，根據(jù)S505中的分支選擇，則保存服務(wù)器信息；
步驟S507，查詢服務(wù)器信息下發(fā)策略； 步驟S508 ，判斷是否允許下發(fā)策略，如果允許，執(zhí)行步驟S509 ，否則執(zhí)行步驟 S510 ; 步驟S509，填入服務(wù)器返回的詳細(xì)信息(g卩，返回失敗信息的原因)；
步驟S510，向接入端返回認(rèn)證結(jié)果；
步驟S511，操作完成。 五、AAA客戶端配置失敗原因信息下發(fā)策略。 該策略用于AAA客戶端判斷收到服務(wù)器返回的詳細(xì)信息(S卩，返回失敗信息的原 因)后，如何對(duì)這些信息進(jìn)行處理。具體地，AAA客戶端配置服務(wù)器信息下發(fā)策略時(shí)，需要 在該策略中為所有可能的用戶接入類型定義如何下發(fā)返回失敗信息的原因。目前常用的接 入類型包括dotlx接入客戶端、ssh客戶端、telnet客戶端和串口。對(duì)應(yīng)每種接入類型，可 以配置"強(qiáng)制下發(fā)"或者"請(qǐng)求下發(fā)"或者"不下發(fā)"三種策略配置，默認(rèn)為"不下發(fā)"。
圖6是根據(jù)本發(fā)明實(shí)施例的AAA客戶端配置信息下發(fā)策略的詳細(xì)處理流程圖，如 圖6所示，包括以下步驟
步驟S601，流程開(kāi)始。
步驟S602，創(chuàng)建策略。 步驟S603，在策略下配置dotlx接入類型的服務(wù)器信息下發(fā)方式，例如，選擇下列 三種方式中的一種l.強(qiáng)制下發(fā)，2.請(qǐng)求下發(fā)，3.不下發(fā)。此步驟可以跳過(guò)到后面的任意 步驟，跳過(guò)的默認(rèn)處理方式為"不下發(fā)"。 步驟S604，在策略下配置ssh接入類型的服務(wù)器信息下發(fā)方式，例如，選擇下列三 種方式中的一種l.強(qiáng)制下發(fā)，2.請(qǐng)求下發(fā)，3.不下發(fā)。此步驟可以跳過(guò)到后面的任意步 驟，跳過(guò)的默認(rèn)處理方式為"不下發(fā)"。 步驟S605，在策略下配置telnet接入類型的服務(wù)器信息下發(fā)方式，例如，選擇下 列三種方式中的一種l.強(qiáng)制下發(fā)，2.請(qǐng)求下發(fā)，3.不下發(fā)。此步驟可以跳過(guò)到后面的任 意步驟，跳過(guò)的默認(rèn)處理方式為"不下發(fā)"。其中，2.請(qǐng)求下發(fā)中，可以按照上文中服務(wù)器將 返回失敗信息的原因發(fā)送給客戶端的處理過(guò)程中涉及的上述三種方式進(jìn)行配置。
步驟S606，生成策略。
步驟S607，操作完成。 六、AAA服務(wù)器解析客戶端發(fā)送的"請(qǐng)求詳細(xì)信息"字段。 該策略用于AAA服務(wù)器端在收到客戶端發(fā)送的認(rèn)證請(qǐng)求報(bào)文后，從報(bào)文中正確解 析出"請(qǐng)求詳細(xì)信息"字段的內(nèi)容并記錄，用于向客戶端返回響應(yīng)報(bào)文時(shí)判斷是否需要同時(shí) 返回認(rèn)證詳細(xì)信息。 AAA服務(wù)器解析客戶端發(fā)送的"請(qǐng)求詳細(xì)信息"字段。AAA服務(wù)器收到接入請(qǐng)求報(bào) 文后，在解析報(bào)文時(shí)需要判斷是否攜帶"請(qǐng)求詳細(xì)信息"字段(即，判斷是否攜帶失敗請(qǐng)求 消息)，如果有，則根據(jù)服務(wù)器本地策略來(lái)決定是否向該接入端返回詳細(xì)信息(即，服務(wù)器 返回失敗信息的原因)，如果沒(méi)有則不返回詳細(xì)信息。
七、AAA服務(wù)器在認(rèn)證響應(yīng)報(bào)文中填寫(xiě)返回失敗信息的原因。 服務(wù)器向客戶端返回認(rèn)證響應(yīng)報(bào)文時(shí)，根據(jù)請(qǐng)求報(bào)文中是否帶有"請(qǐng)求詳細(xì)信息" 字段(即，是否攜帶失敗請(qǐng)求消息)以及服務(wù)器配置的策略來(lái)決定是否向響應(yīng)報(bào)文中填寫(xiě) 返回失敗信息的原因，AAA服務(wù)器向符合相關(guān)策略的響應(yīng)報(bào)文中填寫(xiě)返回失敗信息的原因， 并發(fā)送給AAA客戶端。 下面結(jié)合附圖7對(duì)本發(fā)明技術(shù)方案的AAA服務(wù)器判斷并封裝返回認(rèn)證響應(yīng)報(bào)文流 程作進(jìn)一步描述 步驟S701， AAA服務(wù)器接收到認(rèn)證請(qǐng)求報(bào)文；
步驟S702，查詢基于用戶的信息下發(fā)策略； 步驟S703，判斷是否允許在步驟S702中的下發(fā)策略中填寫(xiě)返回失敗信息的原因，
如果判斷結(jié)果為是，則進(jìn)入步驟S708，否則進(jìn)入步驟S704 ; 步驟S704，查詢基于客戶端的信息下發(fā)策略，并執(zhí)行步驟S705 ; 步驟S705，判斷是否允許在步驟S704中的下發(fā)策略中填寫(xiě)返回失敗信息的原因，
如果判斷結(jié)果為是，則進(jìn)入步驟S708，否則進(jìn)入步驟S705 ; 步驟S706，查詢?nèi)窒掳l(fā)策略，并執(zhí)行步驟S707 ; 步驟S707，判斷是否允許在步驟S706中的下發(fā)策略中填寫(xiě)返回失敗信息的原因， 如果判斷結(jié)果為是，則進(jìn)入步驟S708，否則進(jìn)入步驟S709 ;
步驟S708，在響應(yīng)報(bào)文中填寫(xiě)"詳細(xì)信息"字段(即，填寫(xiě)服務(wù)器返回失敗信息的原因)； 步驟S709，封裝響應(yīng)報(bào)文；
步驟S710，發(fā)送響應(yīng)報(bào)文；
步驟S711，操作完成。
八、AAA服務(wù)器配置信息下發(fā)策略。 該策略用于AAA服務(wù)器端在收到客戶端發(fā)送的認(rèn)證請(qǐng)求報(bào)文后，判斷是否應(yīng)該向該客戶端返回認(rèn)證詳細(xì)信息，以及返回何種信息。具體地，AAA服務(wù)器配置詳細(xì)信息下發(fā)策略，針對(duì)不同的對(duì)象有三種策略部署方法 (1)基于接入用戶的策略配置，該策略是為服務(wù)器上的每個(gè)用戶或者用戶組分別配置是否允許獲取服務(wù)器信息，該策略優(yōu)先級(jí)最高。 (2)基于AAA客戶端的策略配置，該策略是接入服務(wù)器上的每個(gè)AAA客戶端(或者NAS)分別配置是否允許獲取服務(wù)器信息，該策略優(yōu)先級(jí)僅次于基于用戶的策略配置。
(3)基于本服務(wù)器的全局策略配置，該策略具有本服務(wù)器全局唯一性，優(yōu)先級(jí)最低。 如果以上三種策略都沒(méi)有配置，默認(rèn)本服務(wù)器不允許下發(fā)任務(wù)詳細(xì)信息。 下面結(jié)合附圖8對(duì)本發(fā)明技術(shù)方案的AAA服務(wù)器配置詳細(xì)信息下發(fā)策略流程作進(jìn)
一步描述 步驟S801，流程開(kāi)始。 步驟802，AAA服務(wù)器創(chuàng)建基于用戶的信息下發(fā)策略，針對(duì)該用戶來(lái)配置"允許"或者"不允許"信息下發(fā)。 步驟803， AAA服務(wù)器創(chuàng)建基于客戶端的信息下發(fā)策略，針對(duì)該AAA客戶端來(lái)配置"允許"或者"不允許"信息下發(fā)。 步驟S804， AAA服務(wù)器創(chuàng)建全局信息下發(fā)策略，配置在本服務(wù)器范圍內(nèi)"允許"或
者"不允許"信息下發(fā)。 步驟S805，操作完成。 上述步驟以常見(jiàn)的接入類型為例，但并不作為本發(fā)明的限制。其他接入類型也在本發(fā)明的應(yīng)用范圍內(nèi)。 此外，在AAA客戶端上還可以配置服務(wù)器信息管理策略，從而對(duì)服務(wù)器返回失敗信息的原因進(jìn)行存儲(chǔ)和管理，具體可以配置是否在客戶端本地保存服務(wù)器返回失敗信息的原因、配置服務(wù)器信息(服務(wù)器返回失敗信息的原因)最大保存條目數(shù)(服務(wù)器針對(duì)每次第二請(qǐng)求返回的原因可以作為一條原因信息)、和/或配置保存的信息的老化時(shí)間，從而在客戶端存儲(chǔ)區(qū)被占滿、或占用量達(dá)到預(yù)定值或比例、或者緩存的信息條目數(shù)達(dá)到預(yù)定值、或者某些信息條目過(guò)期(滿足老化要求，即保存時(shí)間超過(guò)老化時(shí)間閾值)的情況下，刪除老化的信息條目。 圖9是根據(jù)本發(fā)明實(shí)施例的客戶端的組成結(jié)構(gòu)圖，如圖9所示，該客戶端包括
接收模塊91 ，用于接收來(lái)自用戶的第一請(qǐng)求； 處理模塊92，用于根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求，其中，第二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，失敗原因請(qǐng)求信息用于在服務(wù)器響應(yīng)于第二請(qǐng)求返回失敗信息的情況
11下，請(qǐng)求服務(wù)器將返回失敗信息的原因發(fā)送給客戶端。 優(yōu)選地，上述客戶端還包括存儲(chǔ)模塊，用于存儲(chǔ)來(lái)自服務(wù)器的失敗信息的原因，并且在存儲(chǔ)模塊的存儲(chǔ)空間被占滿或被占用的存儲(chǔ)空間達(dá)到預(yù)定門(mén)限的情況下，刪除滿足存儲(chǔ)時(shí)間長(zhǎng)度達(dá)到預(yù)設(shè)門(mén)限的原因。 在根據(jù)本實(shí)施例的方法中，通過(guò)在服務(wù)器或客戶端進(jìn)行的上述配置，能夠靈活配置部分或全部用戶/客戶端獲取服務(wù)器返回失敗信息的原因，便于對(duì)獲取原因返回的用戶或客戶端進(jìn)行選擇或權(quán)限配置，具有較好的靈活性和可配置性，并且能夠避免短時(shí)間內(nèi)進(jìn)行大量的原因信息的返回，使整個(gè)處理過(guò)程更加合理。 圖10是根據(jù)本發(fā)明實(shí)施例的服務(wù)器的組成結(jié)構(gòu)圖，如圖10所示，該服務(wù)器包括
接收模塊1001，用于接收來(lái)自客戶端的請(qǐng)求，其中，請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，失敗原因請(qǐng)求信息用于在服務(wù)器響應(yīng)于請(qǐng)求返回失敗信息的情況下，請(qǐng)求服務(wù)器將返回失敗信息的原因發(fā)送給客戶端； 處理模塊1002，用于響應(yīng)于請(qǐng)求返回失敗信息，并將返回失敗信息的原因發(fā)送給客戶端。 圖ll是根據(jù)本發(fā)明實(shí)施例的通信系統(tǒng)的組成結(jié)構(gòu)圖，如圖ll所示，該通信系統(tǒng)包括客戶端和服務(wù)器，其中， 客戶端1101，用于接收來(lái)自用戶的第一請(qǐng)求，并根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求，其中，第二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，失敗原因請(qǐng)求信息用于在服務(wù)器響應(yīng)于第二請(qǐng)求返回失敗信息的情況下，請(qǐng)求服務(wù)器將返回失敗信息的原因發(fā)送給客戶端；
服務(wù)器1102，用于將返回失敗信息的原因發(fā)送給客戶端。 圖12是根據(jù)本發(fā)明實(shí)施例的客戶端和服務(wù)器間交互的邏輯關(guān)系示意圖，下面結(jié)合圖11所示的客戶端1101和服務(wù)器間1102交互的邏輯關(guān)系示意圖對(duì)本發(fā)明進(jìn)行詳細(xì)說(shuō)明。 接入端向客戶端1101發(fā)送接入請(qǐng)求報(bào)文，客戶端1101接收該接入請(qǐng)求報(bào)文，并查詢預(yù)先配置的請(qǐng)求策略(具體策略上文中已有描述，這里不再贅述)，封裝請(qǐng)求報(bào)文，向服務(wù)器1102發(fā)送封裝后的請(qǐng)求報(bào)文，該請(qǐng)求報(bào)文中攜帶有失敗原因請(qǐng)求信息，失敗原因請(qǐng)求信息用于在服務(wù)器1102響應(yīng)于第二請(qǐng)求返回失敗信息的情況下，請(qǐng)求服務(wù)器1102將返回失敗信息的原因發(fā)送給客戶端1101 ;服務(wù)器1102接收并解析請(qǐng)求報(bào)文，根據(jù)預(yù)先配置的下發(fā)策略，封裝響應(yīng)報(bào)文，并將響應(yīng)報(bào)文返回給客戶端iioi，其中，如果該響應(yīng)報(bào)文為失敗響應(yīng)，則響應(yīng)報(bào)文中攜帶有返回失敗響應(yīng)的原因；客戶端1101接收并解析響應(yīng)報(bào)文，根據(jù)預(yù)先配置的管理策略，保存返回失敗響應(yīng)的原因，并根據(jù)預(yù)先配置的下發(fā)策略，向接入端返回請(qǐng)求結(jié)果報(bào)文，該請(qǐng)求結(jié)果報(bào)文中攜帶有返回失敗響應(yīng)的原因。 借助于上述客戶端以及由該客戶端和服務(wù)器組成的系統(tǒng)，客戶端可以根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求并請(qǐng)求返回失敗信息，以便服務(wù)器在返回對(duì)應(yīng)于第二請(qǐng)求的失敗信息的同時(shí)發(fā)送返回失敗信息的原因，使客戶端能夠獲知失敗的具體情況，便于用戶了解失敗的問(wèn)題從而進(jìn)行優(yōu)化，并且有助于對(duì)客戶端進(jìn)行管理，同時(shí)能夠使得認(rèn)證過(guò)程更人性化。 綜上所述，借助于本發(fā)明的技術(shù)方案，能夠使客戶端根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求時(shí)請(qǐng)求返回失敗信息，以便服務(wù)器能夠在返回對(duì)應(yīng)于第二請(qǐng)求的失敗信息的同時(shí)發(fā)送返回失敗信息的原因，使客戶端能夠獲知失敗的具體情況，便于用戶了解失敗的原因
從而進(jìn)行優(yōu)化，并且有助于對(duì)客戶端進(jìn)行管理，同時(shí)能夠使得認(rèn)證過(guò)程更人性化；并且通過(guò)
配置服務(wù)器返回失敗信息原因的多種獲取及下發(fā)策略，能夠以更加合理的方式使?jié)M足一定
權(quán)限的客戶端/用戶獲知失敗信息返回的原因，具有較好的靈活性和可配置性。 圖9、圖10和圖11是與前面方法對(duì)應(yīng)的裝置和系統(tǒng)，裝置和系統(tǒng)的工作過(guò)程以及
工作原理在方法部分已經(jīng)進(jìn)行了詳細(xì)描述，在此不再贅述，參照方法中相應(yīng)部分的描述即可。 以上所述僅為本發(fā)明的較佳實(shí)施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進(jìn)等，均應(yīng)包含在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
一種消息獲取方法，其特征在于，包括客戶端接收來(lái)自用戶的第一請(qǐng)求，并向服務(wù)器發(fā)送第二請(qǐng)求，其中，所述第二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述第二請(qǐng)求返回失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述客戶端向服務(wù)器發(fā)送第二請(qǐng)求的操 作為所述客戶端根據(jù)所述第一請(qǐng)求向服務(wù)器發(fā)送所述第二請(qǐng)求；或者， 所述客戶端向所述服務(wù)器發(fā)送對(duì)應(yīng)于所述第一請(qǐng)求的所述第二請(qǐng)求。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，在所述客戶端根據(jù)所述第一請(qǐng)求向服務(wù) 器發(fā)送第二請(qǐng)求之前，還包括所述客戶端根據(jù)所述第一請(qǐng)求，判斷所述用戶的接入類型是否為預(yù)定接入類型，在所 述用戶的接入類型為預(yù)定接入類型的情況下，所述客戶端將所述失敗原因請(qǐng)求信息攜帶在 所述第二請(qǐng)求中。
4. 根據(jù)權(quán)利要求1所述的方法，其特征在于，還包括 客戶端將返回所述失敗信息的原因發(fā)送給所述用戶。
5. 根據(jù)權(quán)利要求1至4中任一項(xiàng)所述的方法，其特征在于，所述第一請(qǐng)求為以下之一 用戶接入請(qǐng)求、用戶登錄請(qǐng)求，所述第二請(qǐng)求包括以下之一 認(rèn)證請(qǐng)求、授權(quán)請(qǐng)求、計(jì)費(fèi)請(qǐng) 求。
6. —種消息處理方法，其特征在于，包括 服務(wù)器接收來(lái)自客戶端的請(qǐng)求；所述服務(wù)器響應(yīng)于所述請(qǐng)求返回失敗信息，并將返回所述失敗信息的原因發(fā)送給所述 客戶端。
7. 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，所 述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述請(qǐng)求返回失敗信息的情況下，請(qǐng)求所述 服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端。
8. 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述請(qǐng)求中攜帶有所述客戶端的標(biāo)識(shí)；則服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端的處理包括所述服務(wù)器在所述客戶端的標(biāo)識(shí)合法的情況下，將返回所述失敗信息的原因發(fā)送給所 述客戶端。
9. 根據(jù)權(quán)利要求6所述的方法，其特征在于，所述請(qǐng)求中還攜帶有所述用戶的標(biāo)識(shí)； 則服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端的處理包括所述服務(wù)器在所述用戶的標(biāo)識(shí)合法的情況下，將返回所述失敗信息的原因發(fā)送給所述 客戶端。
10. —種客戶端，其特征在于，包括 接收模塊，用于接收來(lái)自用戶的第一請(qǐng)求；處理模塊，用于根據(jù)所述第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求，其中，所述第二請(qǐng)求中攜帶 有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述第二請(qǐng)求返回 失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端。
11. 根據(jù)權(quán)利要求10所述的客戶端，其特征在于，還包括存儲(chǔ)模塊，用于存儲(chǔ)來(lái)自所述服務(wù)器的所述失敗信息的原因，并且在所述存儲(chǔ)模塊的 存儲(chǔ)空間被占滿或被占用的存儲(chǔ)空間達(dá)到預(yù)定門(mén)限的情況下，刪除滿足存儲(chǔ)時(shí)間長(zhǎng)度達(dá)到 預(yù)設(shè)門(mén)限的原因。
12. —種服務(wù)器，其特征在于，包括 接收模塊，用于接收來(lái)自客戶端的請(qǐng)求；處理模塊，用于響應(yīng)于所述請(qǐng)求返回失敗信息，并將返回所述失敗信息的原因發(fā)送給 所述客戶端。
13. 根據(jù)權(quán)利要求12所述的服務(wù)器，其特征在于，所述請(qǐng)求中攜帶有失敗原因請(qǐng)求信 息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述請(qǐng)求返回失敗信息的情況下，請(qǐng) 求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述客戶端。
14. 一種通信系統(tǒng)，其特征在于，包括客戶端和服務(wù)器，其中，所述客戶端，用于接收來(lái)自用戶的第一請(qǐng)求，并向服務(wù)器發(fā)送第二請(qǐng)求，其中，所述第 二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，所述失敗原因請(qǐng)求信息用于在所述服務(wù)器響應(yīng)于所述 第二請(qǐng)求返回失敗信息的情況下，請(qǐng)求所述服務(wù)器將返回所述失敗信息的原因發(fā)送給所述 客戶端；所述服務(wù)器，用于將返回所述失敗信息的原因發(fā)送給所述客戶端。
全文摘要
本發(fā)明公開(kāi)了一種消息獲取和處理方法、客戶端、服務(wù)器和通信系統(tǒng)，其中，該消息獲取方法包括客戶端接收來(lái)自用戶的第一請(qǐng)求，客戶端向服務(wù)器發(fā)送第二請(qǐng)求，其中，第二請(qǐng)求中攜帶有失敗原因請(qǐng)求信息，該失敗原因請(qǐng)求信息用于在服務(wù)器響應(yīng)于第二請(qǐng)求的返回結(jié)果為失敗的情況下，請(qǐng)求服務(wù)器將返回失敗信息的原因發(fā)送給客戶端。通過(guò)本發(fā)明，能夠使客戶端根據(jù)第一請(qǐng)求向服務(wù)器發(fā)送第二請(qǐng)求時(shí)請(qǐng)求返回失敗信息，以便服務(wù)器能夠在返回對(duì)應(yīng)于第二請(qǐng)求的失敗信息的同時(shí)發(fā)送返回失敗信息的原因，使客戶端能夠獲知失敗的具體情況，便于用戶了解失敗的原因從而進(jìn)行優(yōu)化，并且有助于對(duì)客戶端進(jìn)行管理，同時(shí)能夠使得認(rèn)證過(guò)程更人性化。
文檔編號(hào)H04W4/12GK101754127SQ20091024345
公開(kāi)日2010年6月23日 申請(qǐng)日期2009年12月22日 優(yōu)先權(quán)日2009年12月22日
發(fā)明者楊洋 申請(qǐng)人:中興通訊股份有限公司