Utility Classes

Timers

Timers in the Mobius Diameter Stack manage time-bound tasks across various operations, ensuring that the protocol operates efficiently and within expected timeframes. These timers serve to monitor different states and activities of the Diameter protocol sessions, links, and transactions, preventing stalled processes, managing session lifecycles, and ensuring timely communication between Diameter peers. 

Time-Based Task Execution

At their core, timers are designed to perform specific actions after a designated period or upon detecting certain conditions. This behavior is critical in the asynchronous, event-driven nature of Diameter protocol operations, where communication between peers is managed over potentially unreliable networks.
Each timer implements the Timer interface, which standardizes the behavior of timers with methods for starting, stopping, and executing tasks based on time constraints. The core methods in the Timer interface are:

Session and Link Monitoring

Timers play a key role in managing the lifecycle of Diameter sessions and Diameter links by monitoring their activity, inactivity, and connection states:
Idle and Inactivity Monitoring: Classes like IdleCheckTimer and InactivityTimer monitor the activity of Diameter sessions and links. They ensure that if a session or link becomes inactive for too long, corrective actions such as sending Device-Watchdog-Requests (DWR) or terminating idle sessions are triggered. This prevents stale or inactive resources from persisting in the system.
Request and Response Monitoring: Timers such as the SendTimer monitor the request-sending process to ensure that requests are processed within the expected time. If a request is not sent or acknowledged in time, the system can handle the timeout, preventing long delays in Diameter transactions.

Resource Cleanup

Timers are also responsible for ensuring the efficient use of resources within the stack. LocalIncomingCleanupTimer handles periodic cleanup of stale or expired Diameter responses stored in internal data structures. This timer helps maintain the stack's performance by freeing up memory and other resources when they are no longer needed. Without this, outdated responses could accumulate, leading to potential memory leaks or performance degradation.
Connection and Reconnection Management
Timers like ReconnectTimer manage the process of reconnecting to a peer in case of a lost connection or failed session. They periodically check the state of the connection and trigger reconnection attempts by sending Capability Exchange Requests (CERs) when the peer enters an IDLE or CER_SENT state. This ensures continuous connectivity and resilience in the Diameter network.
Asynchronous and Non-Blocking Execution
The use of timers within the Mobius Diameter Stack allows for non-blocking, asynchronous execution. Timers handle background tasks while the main process continues without waiting for these timers to complete. This ensures that long-running tasks, such as waiting for peer responses or monitoring for session inactivity, do not block the main execution flow of the stack.
Flexibility and Dynamic Timeouts
Timers in the stack are highly configurable, allowing dynamic adjustments to the timeout periods and task logic. Many of the timer classes, such as SendTimer and InactivityTimer, allow for their timeouts to be restarted or reset dynamically based on current conditions. This flexibility ensures that the system can adapt to real-time changes, such as adjusting the inactivity timeout based on network latency or other environmental factors.
Centralized Timer Management
The timers in the Mobius Diameter Stack are often integrated into a centralized management system, such as the PeriodicQueue, where timers can be stored and executed at the appropriate intervals. This centralized management ensures that timers are efficiently handled, and system resources are properly allocated to time-bound tasks.

Timers Classes

DisconnectTimer

The DisconnectTimer is a timer utility that helps manage and monitor the state of the connection between peers in a Diameter session. It specifically tracks the disconnection process and triggers appropriate callbacks based on the connection state of the DiameterLink. This class ensures that the disconnection event is handled smoothly and accurately within a given time frame.

Workflow and Logic
The DisconnectTimer is primarily responsible for handling peer disconnection based on the peer state (DPR_SENT). Once the timer is started, it monitors the state of the DiameterLink to ensure that if the DPR_SENT (Disconnect-Peer-Request) state is detected, the timer stops itself. It uses an AsyncCallback to notify the system about the completion of the timer's execution. If the peer state transitions as expected, it executes a callback, which can be further used to trigger follow-up actions.

IdleCheckTimer 

The IdleCheckTimer class is used to monitor the activity within a DiameterSession and trigger a timeout when the session becomes idle for a predefined period. This class helps ensure that sessions are terminated or managed appropriately when there is no activity, preventing potential resource leaks and ensuring efficient resource management.

Workflow and Logic
The IdleCheckTimer is initialized with a DiameterSession and a timeout period. It periodically checks whether the session has been idle beyond the defined timeout period. If the session remains idle, it logs the event and triggers the session's onIdleTimeout() method to handle the session's inactivity.
The class can also be restarted with a new timeout value or the default timeout value, giving flexibility in resetting the idle monitoring.

InactivityTimer

The InactivityTimer is used to monitor the activity on a DiameterLink and ensure that the link stays active by periodically checking for inactivity. If the link becomes inactive or does not receive a response within a set timeframe, the InactivityTimer triggers actions such as sending Device-Watchdog-Request (DWR) messages to maintain the connection or change the peer's state to handle inactivity appropriately.

Workflow and Logic
The InactivityTimer monitors both inactivity and response timeout conditions. The timer tracks the last activity on the DiameterLink and ensures that if no activity occurs for a configured timeout (inactivityTimeout), it sends a Device-Watchdog-Request (DWR) to the peer. If no Device-Watchdog-Answer (DWA) is received in a timely manner (responseTimeout), the peer's state is changed to IDLE, and a new Capability Exchange Request (CER) is initiated to restore the connection.
The class interacts with key Diameter components such as:

• DiameterLink: The link being monitored for activity.
• PeerStateEnum: Represents the state of the peer (e.g., OPEN, IDLE).
• AtomicLong lastActivity: Keeps track of the last activity timestamp.
• AtomicBoolean waitingForDWA: Indicates whether the timer is currently waiting for a Device-Watchdog-Answer (DWA) from the peer.

Behavior
DWR Sending: If no activity is detected within the inactivityTimeout, a DWR is sent to the peer to confirm the connection is still active.
DWA Waiting: If the timer is waiting for a DWA and the response is not received within the responseTimeout, the peer's state is changed to IDLE, and a new CER request is initiated.
Peer State Monitoring: The peer's state (PeerStateEnum) is constantly monitored to decide what action should be taken, whether to send DWR or change the state to IDLE.

LocalIncomingCleanupTimer

The LocalIncomingCleanupTimer is responsible for periodically cleaning up expired Diameter answer data. It checks for expired entries within a ConcurrentHashMap that stores incoming Diameter responses and removes them based on a configured duplicates timeout. This timer helps manage memory by preventing stale or unnecessary Diameter answers from occupying system resources.

Workflow and Logic
The LocalIncomingCleanupTimer is initialized with a DiameterStack and a map of Diameter responses. It periodically traverses the map and removes entries that have exceeded a certain timeout, based on the DuplicatesTimeout value defined in the DiameterStack. The class works in conjunction with the PeriodicQueue, which ensures that the timer is rescheduled based on the DuplicatesCheckPeriod configuration.

Behavior
Cleanup Process: The timer regularly checks the map containing Diameter responses and removes expired entries, ensuring efficient resource management.
Dynamic Scheduling: The timer is rescheduled after each execution, based on the stack's configuration (DuplicatesCheckPeriod), allowing for flexible periodic cleanup.
Interaction with PeriodicQueue: After each cleanup execution, the timer is stored in the PeriodicQueue for further execution in the future.

ReconnectTimer

The ReconnectTimer is used to manage reconnection attempts between Diameter peers. When a DiameterLink transitions into an inactive state, this timer ensures that the system initiates a reconnection process by sending a Capability Exchange Request (CER) to re-establish communication with the peer. It periodically checks the peer's state and triggers reconnection attempts based on the current timeout.

Workflow and Logic
The ReconnectTimer monitors the state of the DiameterLink. If the link enters an IDLE or CER_SENT state, it sends a CER message to initiate the reconnection. The timer can be configured with a custom timeout, after which the next reconnection attempt will be made. If a reconnection is successful, the AsyncCallback associated with the timer is executed to notify the system of success.

Behavior
Reconnection Attempts: The ReconnectTimer checks the state of the DiameterLink periodically. If the peer is in IDLE or CER_SENT, a CER is sent to initiate reconnection.
Callback Execution: If a callback is provided, it is executed after each reconnection attempt to indicate success or completion of the operation.
Dynamic Timeout: The timer can be dynamically reset with different timeout values, making it flexible for different reconnection scenarios.

SendTimer

The SendTimer is used to monitor the sending process of requests within a DiameterSession. Its primary responsibility is to ensure that requests sent by the session are completed within a given timeout period. If a request takes too long, the timer triggers a timeout event, allowing the system to handle the failure appropriately.

Workflow and Logic
The SendTimer monitors the time taken for a request to be sent from a DiameterSession. It tracks the time elapsed since the request was initiated, and if the request is not sent successfully within the configured timeout period, the session is notified, and appropriate actions can be taken (e.g., triggering a retry or logging an error). This class helps prevent stalled or delayed requests from impacting the system's performance.

Behavior
Timeout Handling: The timer checks if the request has been successfully sent within the allowed time. If not, it logs an error and triggers the session's onTimeout() method.
Restart Capability: The timer can be restarted, allowing it to reset the timeout window if the system wants to attempt sending the request again.
Session Monitoring: By monitoring the sending process, the SendTimer ensures that stalled requests are detected and handled properly.

Message Processing

The MessageProcessingTask is designed to handle the processing of Diameter protocol messages that are received over a DiameterLink. It integrates with the DiameterStack and processes various types of messages such as CapabilitiesExchangeRequest, DeviceWatchdogRequest, DisconnectPeerRequest, and others, ensuring that messages are properly routed, validated, and responded to within the Diameter protocol framework. This class is typically used as a background task in a Diameter node, being instantiated and executed when a message is received over a DiameterLink. It ensures that the peer’s state is correctly managed and that all Diameter protocol-related operations, such as session validation and application ID matching, are handled efficiently.

Key Functions

Message Routing and Processing: Handles Diameter messages based on their type, ensuring that messages are processed according to the current state of the peer (such as OPEN, IDLE, etc.).
Session and State Management: Manages the state of the DiameterLink and performs session handling tasks, such as checking for duplicates, resetting inactivity timers, and validating application support.
Error Handling: Provides robust error detection and response mechanisms by sending error messages when invalid or unsupported messages are received.
Provider Interaction: Routes messages to the appropriate DiameterProvider if applicable, allowing the provider to handle the message or respond appropriately.
Listener Notification: Notifies any registered NetworkListener instances when a message is received for further external handling.

Attributes

Constructor

Initializes a MessageProcessingTask instance with the necessary attributes for processing a message.

Parameters

Methods