#include <diameter_api.h>
Inheritance diagram for AAASession:
Public Types | |
| enum | EVENT { EVENT_AUTH_REQUEST = 0, EVENT_AUTH_SUCCESS, EVENT_AUTH_CONTINUE, EVENT_AUTH_FAILED, EVENT_ACCT_SUCCESS, EVENT_NO_SERVICE, EVENT_PROC_ERROR } |
Public Member Functions | |
| AAASession (AAAApplicationCore &appCore, diameter_unsigned32_t appId) | |
| virtual | ~AAASession () |
| virtual AAAReturnCode | SetTimeout (time_t timeout) |
| virtual AAAReturnCode | RegisterMessageHandler (AAASessionMessageHandler *handler) |
| virtual AAAReturnCode | RemoveMessageHandler (AAASessionMessageHandler *handler) |
| virtual AAAReturnCode | Update (AAASession::EVENT event)=0 |
| const AAASessionHandle | GetSessionHandle () |
| diameter_unsigned32_t | GetApplicationId () |
| void | GetSessionId (diameter_octetstring_t &id) |
Protected Attributes | |
| AAASessionHandle | handle |
| diameter_unsigned32_t | id |
The class definitions in this section allow the client to open, close, and manipulate sessions and servers to accept or reject a session request. As with the event notification class, an instance of the application core is required. The session management model has two (2) parts, client and server. Creating a session instance is the responsibility of both the client and server. The client is the active entity and can start and end a session. The server can either accept or reject (via abort) a session request. The server accepts or rejects a session from incomming messages received from the event notification subscription.
A base class is provided to encapsulates the session specific information and would not typically be used directly by an application. The client and server derived class provides the functionality required by the application to act either as a client or server.
This class inherits from AAAEventHandler which provides it the functionality of handling session events. The HandleDisconnect(), HandleTimeout() and HandleAbort() method of AAAEventHandler is invoked on the a specified session events. Applications wishing to capture these event MUST override any of these methods. The derived class MAY also declare application specific data members in the derived class thereby allowing the implementation of the handler methods access to those data once they are invoked.
For incomming session specific messages, the HandleMessage() method of AAAEventHandler is invoked for any message associated with this session but does NOT match any message handlers. Messages not matching command code handlers are considered un-handled. If the application wishes to capture known and valid messages for this session then message handlers needs to be assigned.
The path of incomming messages from the transport layers is as follows:
a) After being received by the transport, message is parsed completely
b) The application id of the message is checked to see if it matches application ids supported by this core. If no match is found the message is silently discarded in the case that the application functions as a client. If it is a server, an error message is transmitted.
c) If the application id is supported, a search for an existing session (using the session id of the message) to which the message belongs to is made. If a session match is found, the list of handlers is searched next. If session match fails, the message is silently discared if the application functions as a client, else an error message is transmitted. If a session match is found as well as a handler match then the HandleMessage() method of the handler is invoked. If the handler match fails then the HandleMessage() method of the session object itself is invoked.
If the session id is not found but there exists a AAAServerSession- Factory for this id then the CreateInstance() method of the factory is invoked an a new AAAServerSession is created. This only occurs when the application functions as a server.
More information about AAAServerSessionFactory can be found in it's comments. Note that there are no factories for client sessions. Client applications MUST create a session since the diameter model dictates that a client instantiates a authentication session. A server, on the other hand, receives multiple client session request and hence a factory model is implemented.
|
|
||||||||||||
|
constructor
|
|
|
destructor |
|
|
Accesss method for application id Returns the assigned application id |
|
|
Access method for session handle. Returns the current session handle. |
|
|
Returns the internally generated session ID in octet string format. |
|
|
Assigns a handler object to handler for incomming message matching the command code specified in the handler object. The HandleMessage() method of the handler object will be invoked once a match is found. Note that registration is unique, i.e. the same handler object cannot be registered more than once.
|
|
|
Removes a handler currently registered
|
|
|
This function sets the timeout, in seconds, for this session
|
|
|
This functions allows an applications to impose a state transition whether serving as a diameter client or server.
Implemented in AAAClientSession, AAAServerSession, and AAAAccountingSession. |
|
|
Internal data representation uniquely identifying this session. This tag is stored in the session database and remembered persistently by the library even across reboots. |
|
|
Application ID for this session |
1.3.5