CN101754127A - Message acquiring and processing method, client, server and communication system - Google Patents
Message acquiring and processing method, client, server and communication system Download PDFInfo
- Publication number
- CN101754127A CN101754127A CN200910243454A CN200910243454A CN101754127A CN 101754127 A CN101754127 A CN 101754127A CN 200910243454 A CN200910243454 A CN 200910243454A CN 200910243454 A CN200910243454 A CN 200910243454A CN 101754127 A CN101754127 A CN 101754127A
- Authority
- CN
- China
- Prior art keywords
- request
- client
- server
- reason
- failure information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/12—Messaging; Mailboxes; Announcements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention discloses a message acquiring and processing method, a client, a server and a communication system, wherein the message acquiring method comprises the steps that the client receives a first request from a user, the client sends a second request to the server, failure reason request information is carried in the second request, and the failure reason request information is used for requesting the server to send the reason for returning the failure information to the client under the condition that the return result of the server responding to the second request is failure. With the invention, the client can make a request for returning the failure information when sending the second request to the server according to the first request, so the server can send the reason for returning the failure information when returning the failure information corresponding to the second request, so the client can acquire the detailed failure situation, the user can be facilitated to know the failure reason to make optimization and to manage the client, and simultaneously, the authentication process is more humanized.
Description
Technical field
The present invention relates to the communications field, relate in particular to a kind of message and obtain and processing method, client, server and communication system.
Background technology
Authentication, mandate, charging (the Authentication AuthorizationandAccounting of present widespread usage, abbreviate AAA as) in the client and server pattern, by the mutual realization communication of message, below the message interaction process between client and server is simply described between the client and server.
The user sends the request of access to client, and client sends the AAA request according to user's access request to server; Server is handled according to the content in the AAA request, if and active is successfully to the session control packet server that the client transmission contains control command to AAA processing of request result, server can return success information to client, if server is failure to AAA processing of request result, server can return failure information to client.
Because the information that server returns is too simple, therefore client can not be known concrete failure cause, therefore can not send the request of AAA and be optimized, and client also can't further judge whether failure information is returned to incoming end, can not carry out maintenance and management to client effectively simultaneously.
At in the correlation technique because the information that server returns after AAA request is handled too simply makes client can not know that thereby failure cause influences the problem of client-side management and maintenance, effective solution is not proposed at present as yet.
Summary of the invention
At making client can not know that thereby failure cause influences the problem of client-side management and maintenance owing to server only returns failure information after AAA request is handled in the correlation technique, the present invention proposes a kind of message acquisition method, make client can know the concrete condition of failure, be optimized thereby be convenient to the problem that the user understands failure.
At making client can not know that thereby failure cause influences the problem of client-side management and maintenance owing to server only returns failure information after AAA request is handled in the correlation technique, the present invention also proposes a kind of client, make client can know the concrete condition of failure, be optimized thereby be convenient to the problem that the user understands failure.
At making client can not know that thereby failure cause influences the problem of client-side management and maintenance owing to server only returns failure information after AAA request is handled in the correlation technique, the present invention also proposes a kind of communication system, make client can know the concrete condition of failure, be optimized thereby be convenient to the problem that the user understands failure.
Technical scheme of the present invention is achieved in that
A kind of message acquisition method comprises:
Client receives first request from the user, and to server transmission second request, wherein, carry the failure cause solicited message in described second request, described failure cause solicited message is used for returning under the situation of failure information in response to described second request at described server, and the reason of asking described server will return described failure information sends to described client.
Wherein, described user end to server sends second requested operation and is:
Described client sends described second request according to described first request to server; Perhaps,
Described client sends corresponding to described second of described first request to described server and asks.
Preferably, ask before server sends second request, also to comprise according to described first in described client:
Described client is according to described first request, whether the access style of judging described user is predetermined access style, under described user's the situation of access style for predetermined access style, described client is carried at described failure cause solicited message in described second request.
Further, said method also comprises:
The reason that client will be returned described failure information sends to described user.
Wherein, described first request is for one of following: the user inserts request, user's logging request, described second ask to comprise one of following: authentication request, authorization requests, charging request.
A kind of message treatment method comprises:
Server receives the request from client;
Described server returns failure information in response to described request, and the reason that will return described failure information sends to described client.
Wherein, carry the failure cause solicited message in the described request, described failure cause solicited message is used for returning under the situation of failure information in response to described request at described server, and the reason of asking described server will return described failure information sends to described client.
Wherein, carry the sign of described client in the described request;
Then the processing that sends to described client of the server reason that will return described failure information comprises:
Described server sends to described client with the reason of returning described failure information under the legal situation of the sign of described client.
Wherein, also carry described user's sign in described second request;
Then the processing that sends to described client of the server reason that will return described failure information comprises:
Described server sends to described client with the reason of returning described failure information under the legal situation of described user's sign.
A kind of client comprises:
Receiver module is used to receive first request from the user;
Processing module, be used for sending second request to server, wherein, carry the failure cause solicited message in described second request, described failure cause solicited message is used for returning under the situation of failure information in response to described second request at described server, and the reason of asking described server will return described failure information sends to described client.
Further, above-mentioned client also comprises:
Memory module, be used to store reason from the described failure information of described server, and taken or occupied memory space reaches under the situation of predetermined threshold at the memory space of described memory module, deletion is satisfied memory time length and is reached the reason of default thresholding.
A kind of server comprises:
Receiver module is used to receive the request from client;
Processing module is used for returning failure information in response to described request, and the reason that will return described failure information sends to described client.
Wherein, carry the failure cause solicited message in the described request, described failure cause solicited message is used for returning under the situation of failure information in response to described request at described server, and the reason of asking described server will return described failure information sends to described client.
A kind of communication system is characterized in that, comprises client and server, wherein,
Described client, be used to receive first request from the user, and to server transmission second request, wherein, carry the failure cause solicited message in described second request, described failure cause solicited message is used for returning under the situation of failure information in response to described second request at described server, and the reason of asking described server will return described failure information sends to described client;
Described server, the reason that is used for returning described failure information sends to described client.
By means of technique scheme of the present invention, send second request and ask to return failure information to server according to first request by client, make server when returning, to send the reason of returning failure information corresponding to the failure information of second request, make client can know the concrete condition of failure, be optimized thereby be convenient to the problem that the user understands failure, and help client is managed.
Description of drawings
Fig. 1 is the flow chart according to the message acquisition method of the embodiment of the invention;
Fig. 2 is the detailed process flow chart that the AAA client of the embodiment of the invention is created the server info request strategy;
Fig. 3 is the detailed process flow chart that the transmission authentication request packet is judged and encapsulated to the AAA client of the embodiment of the invention;
Fig. 4 is the detailed process flow chart of the AAA client configuration local management strategy of the embodiment of the invention;
Fig. 5 is the detailed process flow chart of the AAA client configuration failure cause information distributing policy of the embodiment of the invention;
Fig. 6 is the detailed process flow chart according to the AAA client configuration information distributing policy of the embodiment of the invention;
Fig. 7 is according to the aaa server judgement of the embodiment of the invention and encapsulates the process chart that returns response message;
Fig. 8 is the process chart according to the aaa server configuration details distributing policy of the embodiment of the invention;
Fig. 9 is the composition structure chart according to the client of the embodiment of the invention;
Figure 10 is the composition structure chart according to the server of the embodiment of the invention;
Figure 11 is the composition structure chart according to the communication system of the embodiment of the invention;
Figure 12 is a mutual logical relation schematic diagram between client and server according to the embodiment of the invention.
Embodiment
At present, in the reciprocal process of client and server, server can carry out ACTIVE CONTROL to client.And, in actual applications, the unaccepted reason of request that causes user end to server to send is a lot, for example, the user name password does not match, does not meet address filtering strategy, NAS validity checking failure etc., if client is not known the reason of serviced device refusal, just be difficult to client is managed and safeguards.Based on this, the invention provides a kind of acquisition methods of message, wherein, initiatively obtaining AAA to server requests asks unaccepted reason by client, so that according to failure cause unaccepted request is optimized processing, conveniently client is managed.
Fig. 1 is the flow chart of steps of the message acquisition method of the embodiment of the invention, as shown in Figure 1, comprises following processing:
Step S101, client receives first request from the user, and wherein, this first request can be for one of following: the user inserts request, user's logging request.
Step S102, user end to server sends second request, wherein, carry the failure cause solicited message in second request, the failure cause solicited message is used for returning under the situation of failure information (promptly in response to second request at server, the failure cause solicited message is used under return results the situation for failure of server in response to second request), the reason that request server will return failure information sends to client, afterwards, server can send to client with the reason of returning failure information, so that client is carried out maintenance and management, alternatively, client can send to the user with the reason of returning failure information; Wherein, second request that user end to server sends can be authentication request, authorization requests or the request of chargeing, it also can be the request of neotectonics, can only comprise the failure cause solicited message in the request of this neotectonics, like this, client is when sending the request of this neotectonics to server, and first request that the request with this neotectonics can be had corresponding relation also sends to server, so that server is known the pairing user of the request of this neotectonics.
By above-mentioned processing, can make client return failure information according to first request request when server sends second request, so that server can send the reason of returning failure information when returning corresponding to the failure information of second request, make client can know the concrete condition of failure, thereby being convenient to the reason that the user understands failure is optimized, and help client is managed, can make that verification process is more humane simultaneously.
In the specific implementation process, asked before server sends second request according to first in client, client can be according to first request from the user, whether the access style of judging the user is predetermined access style, under user's the situation of access style for predetermined access style, client is carried at the failure cause solicited message in second request.Certainly, client can not judged user's access style yet, directly the failure cause solicited message is carried in second request, promptly, no matter which kind of access style the user is, client all is carried at the failure cause solicited message in second request and sends to server.
And, the reason of returning failure information can be sent in the processing procedure of client at server, server can be carried out this operation according to following mode:
Mode 1: the reason that server directly will return failure information sends to client.
Mode 2: also carry the sign of client in above-mentioned second request, this moment, server can be under the legal situation of the sign of client, and the reason that second request is failed sends to client.
Mode 3: also carry user's sign in above-mentioned second request, at this moment, server can be under the legal situation of user's sign, and the reason that second request is failed sends to client.
The reason of returning failure information can be sent in the processing procedure of client at server, above-mentioned three kinds of modes can be combined, perhaps adopt wherein a kind of mode to carry out.For example, server pass-through mode 2 at first carries out legitimate verification to the sign of client, if the sign of client verifies that in the sign to the user if user's sign is legal, the reason with the second request failure sends to client again.
For better the present invention will be described, be that example describes with the communication between AAA client and the aaa server below, those skilled in the art as can be known, for the client and server of other type, the present invention can realize equally.
Need configured strategy and flow chart to describe below in conjunction with accompanying drawing to client and server among the present invention.
One, AAA client configuration server info request strategy.
This strategy is used for the AAA client and judges whether the AAA client obtains server returns reason from failure information to the AAA client to server requests when the user of different access styles sends request.Particularly, when the AAA client is created the server info request strategy, need in this strategy, whether allow to the server requests details for all possible user access type definition.Access style commonly used at present comprises: dot1x inserts client, ssh client, telnet client and serial ports.Corresponding every kind of access style has " permission " or " not allowing " two kinds of policy configurations, is defaulted as " not allowing ".For example, for access style is the client of ssh and telnet, can be " permission " with policy configurations, promptly, client can be according to first request from the user, whether the access style of judging the user is ssh or telnet, is under the situation of ssh or telnet at user's access style, and client is carried at the failure cause solicited message in second request.
Fig. 2 is the detailed process flow chart that the AAA client of the embodiment of the invention is created the server info request strategy, as shown in Figure 2, may further comprise the steps:
Step S201, flow process begins.
Step S202, construction strategy.
Step S203, the processing mode of configuration dot1x access style under strategy, " permission " or do not allow, this step can be skipped the arbitrary steps of back, the default treatment mode of skipping is " not allowing ", preferably, can be that the user of dot1x is configured to " not allowing " with access style.
Step S204, the processing mode of configuration ssh access style under strategy, " permission " or do not allow.This step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is " not allowing ", preferably, can be that the user of ssh is configured to " permission " with access style.
Step S205, the processing mode of configuration telnet access style under strategy, " permission " or do not allow.This step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is " not allowing ", preferably, can be that the user of telnet is configured to " permission " with access style.
Step S206, generation strategy.
Step S207, operation is finished.
Two, the AAA client is filled in " request details " field in authentication request packet.
Be used for the AAA client and fill in " request details " field, and be sent to server with authentication request packet to corresponding A AA agreement.Particularly, the AAA client is filled in " request details " field in authentication request packet (corresponding to above-mentioned second request).When the AAA client is received the access request, at first search the server info request strategy of local configuration according to access style, if should insert the request type corresponding strategy is " permission ", then in authentication request packet, fill in " request details " field, if be " not allowing ", then do not fill in this field.The AAA client mails to server end with packaged authentication request packet then, returns the reason of failure information according to authentication request packet by this field acquisition request server.
Fig. 3 is the detailed process flow chart that the transmission authentication request packet is judged and encapsulated to the AAA client of the embodiment of the invention, as shown in Figure 3, may further comprise the steps:
Step S301, the AAA client receives the access request message from the user;
Step S302, this access way clients corresponding server info request strategy of AAA client query;
Step S303, the AAA client judges whether to fill in " request details field " according to preset strategy in sending to the AAA request message of server, if judged result enters step S304 for being, otherwise enter step S305;
Step S304, the AAA client is filled in " request details field " (that is, mentioned above the reason of returning failure information);
Step S305, encapsulated message;
Step S306 sends message;
Step S307, operation is finished.
Three, AAA client configuration local management strategy.
This strategy is used for how these failure causes being managed after the failure cause that the AAA client receives that server returns.
Fig. 4 is the detailed process flow chart of the AAA client configuration local management strategy of the embodiment of the invention, as shown in Figure 4, may further comprise the steps:
Step S401, flow process begins.
Step S402, construction strategy.
Step S403, whether configuration allows the local server detail of preserving under strategy, and this step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is " not allowing ".
Step S404, the local maximum entry number that allows the server detail of preservation of configuration under strategy, this step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is an entry number 1.
Step S405, the local ageing time of preserving the server info clauses and subclauses of configuration under strategy, this step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is ageing time 24 hours.
Step S406, generation strategy.
Step S407, operation is finished.
Four, the AAA client issues failure cause information.
After this strategy was used for the AAA client and receives the authentication result details that server returns, at different access users, how the information of carrying out issued.
Fig. 5 is the detailed process flow chart of the AAA client configuration failure cause information distributing policy of the embodiment of the invention, as shown in Figure 5, may further comprise the steps:
Step S501, the AAA client receives the authentication response message;
Step S502 resolves " details " field, that is, and and the reason of the failure information that resolution server returns;
Step S503 judges whether this field is meaningful, if meaningful, execution in step S504, otherwise execution in step S510;
Step S504, querying server information management strategy;
Step S505 judges whether the server info management strategy allows preservation information, if allow, and execution in step S506 then, otherwise execution in step S507;
Step S506 selects according to the branch among the S505, then preserves server info;
Step S507, querying server information distributing policy;
Step S508 judges whether to allow distributing policy, if allow execution in step S509, otherwise execution in step S510;
Step S509 inserts the details (that is, returning the reason of failure information) that server returns;
Step S510 is to incoming end return authentication result;
Step S511, operation is finished.
Five, AAA client configuration failure cause information distributing policy.
This strategy be used for the AAA client judge receive the details (that is, returning the reason of failure information) that server returns after, how these information are handled.Particularly, during AAA client configuration server info distributing policy, need in this strategy, how to issue the reason of returning failure information for all possible user access type definition.Access style commonly used at present comprises: dot1x inserts client, ssh client, telnet client and serial ports.Corresponding every kind of access style can dispose three kinds of policy configurations of " pressure issues " or " request issues " or " not issuing ", is defaulted as " not issuing ".
Fig. 6 is according to the detailed process flow chart of the AAA client configuration information distributing policy of the embodiment of the invention, as shown in Figure 6, may further comprise the steps:
Step S601, flow process begins.
Step S602, construction strategy.
Step S603, the server info of configuration dot1x access style issues mode under strategy, and for example, select a kind of in following three kinds of modes: 1. force to issue, 2. request issues, and does not 3. issue.This step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is " not issuing ".
Step S604, the server info of configuration ssh access style issues mode under strategy, and for example, select a kind of in following three kinds of modes: 1. force to issue, 2. request issues, and does not 3. issue.This step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is " not issuing ".
Step S605, the server info of configuration telnet access style issues mode under strategy, and for example, select a kind of in following three kinds of modes: 1. force to issue, 2. request issues, and does not 3. issue.This step can be skipped the arbitrary steps of back, and the default treatment mode of skipping is " not issuing ".Wherein, 2. request issues, and can send to the above-mentioned three kinds of modes that relate in the processing procedure of client according to the reason that server above will return failure information and be configured.
Step S606, generation strategy.
Step S607, operation is finished.
Six, aaa server is resolved " request details " field that client sends.
This strategy is used for the aaa server end after receiving the authentication request packet that client sends, from message, correctly parse the content and the record of " request details " field, be used for when client is returned response message, judging whether needs return authentication details simultaneously.
Aaa server is resolved " request details " field that client sends.After aaa server is received and is inserted request message, when analytic message, need judge whether to carry " request details " field (, judge whether to carry failure request message), if have, then determine whether returning details (promptly to this incoming end according to the server local policy, server returns the reason of failure information), if not then do not return details.
Seven, aaa server is filled in the reason of returning failure information in the authentication response message.
Server is when client return authentication response message, according to whether having " request details " in the request message field (promptly, whether carry failure request message) and the server configured strategy determine whether in response message, filling in the reason of returning failure information, aaa server is filled in the reason of returning failure information in the response message that meets corresponding strategies, and sends to the AAA client.
Aaa server judgement and encapsulation return authentication response message flow process below in conjunction with 7 pairs of technical solution of the present invention of accompanying drawing are further described:
Step S701, aaa server receives authentication request packet;
Step S702, inquiry is based on user's information distributing policy;
Step S703 judges whether to allow to fill in the reason of returning failure information in the distributing policy in step S702, if judged result then enters step S708 for being, otherwise enters step S704;
Step S704 inquires about client-based information distributing policy, and execution in step S705;
Step S705 judges whether to allow to fill in the reason of returning failure information in the distributing policy in step S704, if judged result then enters step S708 for being, otherwise enters step S705;
Step S706 inquires about overall distributing policy, and execution in step S707;
Step S707 judges whether to allow to fill in the reason of returning failure information in the distributing policy in step S706, if judged result then enters step S708 for being, otherwise enters step S709;
Step S708 fills in " details " field (that is, filling in the reason that server returns failure information) in response message;
Step S709, the encapsulation response message;
Step S710 sends response message;
Step S711, operation is finished.
Eight, aaa server configuration information distributing policy.
This strategy is used for the aaa server end after receiving the authentication request packet that client sends, and judging whether should be to these client return authentication details, and returns which kind of information.Particularly, aaa server configuration details distributing policy has three kinds of policy deployment methods at different objects:
(1) based on the policy configurations that inserts the user, this strategy be for each user on the server or user's group respectively configuration whether allow to obtain server info, this strategy priority is the highest.
(2) based on the policy configurations of AAA client, this strategy is that each the AAA client (perhaps NAS) on the access server disposes whether allow to obtain server info respectively, and this strategy priority is only second to the policy configurations based on the user.
(3) based on the global policies configuration of book server, this strategy has book server overall situation uniqueness, and priority is minimum.
If above three kinds of strategies all do not have configuration, the acquiescence book server does not allow to issue Task Details.
Aaa server configuration details distributing policy flow process below in conjunction with 8 pairs of technical solution of the present invention of accompanying drawing is further described:
Step S801, flow process begins.
Step 802, aaa server is created the information distributing policy based on the user, disposes " permission " or " not allowing " information at this user and issues.
Step 803, aaa server are created client-based information distributing policy, bring in configuration " permission " or " not allowing " information issues at this AAA client.
Step S804, aaa server is created the global information distributing policy, is configured in interior " permission " or " the not allowing " information of book server scope and issues.
Step S805, operation is finished.
Above-mentioned steps is an example with common access style, but not as restriction of the present invention.Other access styles are also in range of application of the present invention.
In addition, all right configuration server information management strategy on the AAA client, thereby the reason of server being returned failure information is stored and is managed, specifically can dispose and whether preserve the reason that server returns failure information at client terminal local, the maximum entry number (reason that server returns at each second request can be used as a cause information) of preserving of configuration server information (server returns the reason of failure information), and/or the ageing time of the information of configuration preservation, thereby taken in the client stores district, or occupancy reaches predetermined value or ratio, perhaps the data entries number of buffer memory reaches predetermined value, perhaps some data entries is expired (satisfies aging requirement, be to surpass the ageing time threshold value holding time) situation under, the data entries that deletion is aging.
Fig. 9 is the composition structure chart according to the client of the embodiment of the invention, and as shown in Figure 9, this client comprises:
Preferably, above-mentioned client also comprises: memory module, be used to store the reason from the failure information of server, and taken or occupied memory space reaches under the situation of predetermined threshold at the memory space of memory module, deletion is satisfied memory time length and is reached the reason of default thresholding.
In method according to present embodiment, by the above-mentioned configuration of carrying out in server or client, can the part or all of user/client of flexible configuration obtain the reason that server returns failure information, be convenient to obtaining the user that reason returns or client is selected or the authority configuration, have better flexibility and configurability, and can avoid carrying out returning of a large amount of cause informations in the short time, make the entire process process more reasonable.
Figure 10 is the composition structure chart according to the server of the embodiment of the invention, and as shown in figure 10, this server comprises:
Figure 11 is the composition structure chart according to the communication system of the embodiment of the invention, and as shown in figure 11, this communication system comprises client and server, wherein,
Figure 12 is a mutual logical relation schematic diagram between client and server according to the embodiment of the invention, and the present invention is described in detail below in conjunction with 1102 mutual logical relation schematic diagrames between client shown in Figure 11 1101 and server.
Incoming end sends to client 1101 and inserts request message, client 1101 receives this and inserts request message, and (specific strategy is above existing to be described to inquire about pre-configured request strategy, here repeat no more), the package request message, request message after server 1102 sends encapsulation, carry the failure cause solicited message in this request message, the failure cause solicited message is used for returning under the situation of failure information in response to second request at server 1102, and the reason that request server 1102 will return failure information sends to client 1101; Server 1102 receives and the analysis request message, according to pre-configured distributing policy, and the encapsulation response message, and response message returned to client 1101, wherein, if this response message is a failure response, then carry the reason of returning failure response in the response message; Client 1101 receives and the resolution response message, according to pre-configured management strategy, preserve the reason of returning failure response, and according to pre-configured distributing policy, return the request results message to incoming end, carry the reason of returning failure response in this request results message.
By means of above-mentioned client and the system that forms by this client and server, client can send second request and ask to return failure information to server according to first request, so that server sends the reason of returning failure information when returning corresponding to the failure information of second request, make client can know the concrete condition of failure, thereby being convenient to the problem that the user understands failure is optimized, and help client is managed, can make that verification process is more humane simultaneously.
In sum, by means of technical scheme of the present invention, can make client return failure information according to first request request when server sends second request, so that server can send the reason of returning failure information when returning corresponding to the failure information of second request, make client can know the concrete condition of failure, be optimized thereby be convenient to the reason that the user understands failure, and help client is managed, can make that verification process is more humane simultaneously; And return the multiple of failure information reason by configuration server and obtain and distributing policy, can make the client/user that satisfies certain authority know the reason that failure information returns, have better flexibility and configurability with reasonable manner more.
Fig. 9, Figure 10 and Figure 11 are device and the systems corresponding with previous methods, and the course of work of device and system and operation principle are described in detail in the method part, do not repeat them here, and the description of appropriate section gets final product in the reference method.
The above only is preferred embodiment of the present invention, and is in order to restriction the present invention, within the spirit and principles in the present invention not all, any modification of being done, is equal to replacement, improvement etc., all should be included within protection scope of the present invention.
Claims (14)
1. a message acquisition method is characterized in that, comprising:
Client receives first request from the user, and to server transmission second request, wherein, carry the failure cause solicited message in described second request, described failure cause solicited message is used for returning under the situation of failure information in response to described second request at described server, and the reason of asking described server will return described failure information sends to described client.
2. method according to claim 1 is characterized in that, described user end to server sends second requested operation and is:
Described client sends described second request according to described first request to server; Perhaps,
Described client sends corresponding to described second of described first request to described server and asks.
3. method according to claim 1 is characterized in that, asks also to comprise before server sends second request according to described first in described client:
Described client is according to described first request, whether the access style of judging described user is predetermined access style, under described user's the situation of access style for predetermined access style, described client is carried at described failure cause solicited message in described second request.
4. method according to claim 1 is characterized in that, also comprises:
The reason that client will be returned described failure information sends to described user.
5. according to each described method in the claim 1 to 4, it is characterized in that described first request is for one of following: the user inserts request, user's logging request, described second ask to comprise one of following: authentication request, authorization requests, charging request.
6. a message treatment method is characterized in that, comprising:
Server receives the request from client;
Described server returns failure information in response to described request, and the reason that will return described failure information sends to described client.
7. method according to claim 6, it is characterized in that, carry the failure cause solicited message in the described request, described failure cause solicited message is used for returning under the situation of failure information in response to described request at described server, and the reason of asking described server will return described failure information sends to described client.
8. method according to claim 6 is characterized in that, carries the sign of described client in the described request;
Then the processing that sends to described client of the server reason that will return described failure information comprises:
Described server sends to described client with the reason of returning described failure information under the legal situation of the sign of described client.
9. method according to claim 6 is characterized in that, also carries described user's sign in the described request;
Then the processing that sends to described client of the server reason that will return described failure information comprises:
Described server sends to described client with the reason of returning described failure information under the legal situation of described user's sign.
10. a client is characterized in that, comprising:
Receiver module is used to receive first request from the user;
Processing module, be used for sending second request to server according to described first request, wherein, carry the failure cause solicited message in described second request, described failure cause solicited message is used for returning under the situation of failure information in response to described second request at described server, and the reason of asking described server will return described failure information sends to described client.
11. client according to claim 10 is characterized in that, also comprises:
Memory module, be used to store reason from the described failure information of described server, and taken or occupied memory space reaches under the situation of predetermined threshold at the memory space of described memory module, deletion is satisfied memory time length and is reached the reason of default thresholding.
12. a server is characterized in that, comprising:
Receiver module is used to receive the request from client;
Processing module is used for returning failure information in response to described request, and the reason that will return described failure information sends to described client.
13. server according to claim 12, it is characterized in that, carry the failure cause solicited message in the described request, described failure cause solicited message is used for returning under the situation of failure information in response to described request at described server, and the reason of asking described server will return described failure information sends to described client.
14. a communication system is characterized in that, comprises client and server, wherein,
Described client, be used to receive first request from the user, and to server transmission second request, wherein, carry the failure cause solicited message in described second request, described failure cause solicited message is used for returning under the situation of failure information in response to described second request at described server, and the reason of asking described server will return described failure information sends to described client;
Described server, the reason that is used for returning described failure information sends to described client.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910243454A CN101754127A (en) | 2009-12-22 | 2009-12-22 | Message acquiring and processing method, client, server and communication system |
| PCT/CN2010/070874 WO2010148664A1 (en) | 2009-12-22 | 2010-03-04 | Method, client, server and communication system for message obtaining and processing |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN200910243454A CN101754127A (en) | 2009-12-22 | 2009-12-22 | Message acquiring and processing method, client, server and communication system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN101754127A true CN101754127A (en) | 2010-06-23 |
Family
ID=42480358
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN200910243454A Pending CN101754127A (en) | 2009-12-22 | 2009-12-22 | Message acquiring and processing method, client, server and communication system |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN101754127A (en) |
| WO (1) | WO2010148664A1 (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102540983A (en) * | 2010-12-10 | 2012-07-04 | 北京北方微电子基地设备工艺研究中心有限责任公司 | Acquiring method and acquiring device for process data and equipment control system |
| CN106339316A (en) * | 2016-08-24 | 2017-01-18 | 上海爱企网络科技有限公司 | Method and device for diagnosing code segment in e-commerce platform |
| CN109117609A (en) * | 2018-08-31 | 2019-01-01 | 中国农业银行股份有限公司 | A kind of request hold-up interception method and device |
| CN111988387A (en) * | 2020-08-11 | 2020-11-24 | 北京达佳互联信息技术有限公司 | Interface request processing method, device, server, equipment and storage medium |
| CN112671822A (en) * | 2020-10-20 | 2021-04-16 | 北京字跳网络技术有限公司 | Service request processing method, device, storage medium, server and system |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1277393C (en) * | 2003-12-12 | 2006-09-27 | 华为技术有限公司 | Method of selecting gateway of data packets by users in wireless local area network |
| CN1885770B (en) * | 2005-06-24 | 2010-07-28 | 华为技术有限公司 | Authentication method |
| CN1968094A (en) * | 2006-11-23 | 2007-05-23 | 华为技术有限公司 | Method, system and server for prompting the cause for user terminal authentication failure |
| CN101051910B (en) * | 2007-05-21 | 2010-06-23 | 中兴通讯股份有限公司 | Method and device for certifying authorized charging server to identify client-side software |
-
2009
- 2009-12-22 CN CN200910243454A patent/CN101754127A/en active Pending
-
2010
- 2010-03-04 WO PCT/CN2010/070874 patent/WO2010148664A1/en active Application Filing
Cited By (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN102540983A (en) * | 2010-12-10 | 2012-07-04 | 北京北方微电子基地设备工艺研究中心有限责任公司 | Acquiring method and acquiring device for process data and equipment control system |
| CN102540983B (en) * | 2010-12-10 | 2014-05-28 | 北京北方微电子基地设备工艺研究中心有限责任公司 | Acquiring method and acquiring device for process data and equipment control system |
| CN106339316A (en) * | 2016-08-24 | 2017-01-18 | 上海爱企网络科技有限公司 | Method and device for diagnosing code segment in e-commerce platform |
| CN106339316B (en) * | 2016-08-24 | 2019-01-11 | 上海爱企网络科技有限公司 | A kind of method and device that code segment is diagnosed in e-commerce platform |
| CN109117609A (en) * | 2018-08-31 | 2019-01-01 | 中国农业银行股份有限公司 | A kind of request hold-up interception method and device |
| CN109117609B (en) * | 2018-08-31 | 2021-01-29 | 中国农业银行股份有限公司 | Request intercepting method and device |
| CN111988387A (en) * | 2020-08-11 | 2020-11-24 | 北京达佳互联信息技术有限公司 | Interface request processing method, device, server, equipment and storage medium |
| CN112671822A (en) * | 2020-10-20 | 2021-04-16 | 北京字跳网络技术有限公司 | Service request processing method, device, storage medium, server and system |
| CN112671822B (en) * | 2020-10-20 | 2022-06-17 | 北京字跳网络技术有限公司 | Service request processing method, device, storage medium, server and system |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010148664A1 (en) | 2010-12-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101610156B (en) | Dual protocol stack user authentication method, device and system | |
| US20130281061A1 (en) | Telecommunications Network and Method for Time-Based Network Access | |
| CN102695167B (en) | Mobile subscriber identity management method and apparatus thereof | |
| CA2789495C (en) | Seamless mobile subscriber identification | |
| CN106412680B (en) | Multi-screen control method and device | |
| CN101754127A (en) | Message acquiring and processing method, client, server and communication system | |
| WO2016165505A1 (en) | Connection control method and apparatus | |
| CN105981345A (en) | Lawful interception in a wi-fi / packet core network access | |
| CN108418907B (en) | IP address allocation method and device | |
| WO2005048034A2 (en) | On demand session provisioning of ip flows | |
| US20230421569A1 (en) | Relay method, relay apparatus, and relay system | |
| CN105592180A (en) | Portal authentication method and device | |
| CN102984261B (en) | Network service login method, equipment and system based on mobile telephone terminal | |
| CN103607410A (en) | Content access method and equipment | |
| CN112492592A (en) | Authorization method under multiple NRF scenes | |
| JP6768942B2 (en) | Network access control methods, devices, and devices | |
| CN110913351B (en) | Multicast control method, device, network equipment and storage medium | |
| CN102215597A (en) | Access policy management method and device | |
| CN109120738B (en) | DHCP server and method for managing network internal equipment | |
| US11523444B2 (en) | UE handling in RAN | |
| CN105376096A (en) | Method and system for analyzing domain name, evaluating and feeding back data quality and optimizing data | |
| CN113993129B (en) | PDU session establishment method, terminal and computer readable storage medium | |
| CN106572077B (en) | A kind of gate verification method and device | |
| CN114125025A (en) | Data transmission method and device under multi-target network | |
| CN109040040B (en) | Information sending method and device, storage medium and electronic device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C12 | Rejection of a patent application after its publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20100623 |