Advanced - Timing

"Timing" is advanced configuration that controls the timing behavior of Section Control segments, including re-request intervals, timeout, and Alive Notice settings, optimizing system performance and user experience.

Overview

Advanced Timing settings for Section Control segments manage four key timing aspects:

1. Re-request Interval: Controls how frequently visitors in the waiting room check for entry permission
2. Alive Notice Re-request Interval: Controls how frequently the system sends "I'm still active" signals while users are within the protected section
3. Alive Notice Expiration: Sets the maximum duration users can remain within the protected section
4. Timeout: Automatically releases resources if no activity or completion signal is received

These settings help balance between server performance and user experience by configuring when and how frequently the system processes status checks and maintains active user state throughout the multi-step section.

How the timing options work together:

Key Interactions

• Re-request Interval: Only active while users are in the waiting room
• Alive Notice Interval: Periodically resets Timeout countdown while user is active
• Alive Notice Expiration: Sets maximum duration for Alive Notice transmission (300s default)
• Timeout: Only triggers if no Alive Notices arrive for the timeout duration (20s default)

The relationship: Alive Notice Interval < Timeout < Alive Notice Expiration

Re-request Interval

What it does: Controls the dynamic timing between requests that waiting visitors send to check entry availability. The system intelligently adjusts this interval based on each visitor's position in the queue.

Think of it like a coworking space reservation queue: people at the front of the line check the front desk frequently ("Is a desk available now?"), while those further back check less often. NetFUNNEL applies the same logic—visitors near entry check every 1-2 seconds, while those far back check every 8-10 seconds. This prevents overwhelming the reservation system while ensuring people at the front don't miss their desk when one becomes available.

How it works:

1. Periodic status checks: Visitors' waiting room logic repeatedly contacts NetFUNNEL servers to check entry permission
2. Server response: Each request receives either PASS (proceed to entry) or WAIT (continue waiting)
3. TTL (Time To Live): WAIT responses include a TTL value that tells the client exactly how long to wait before the next check
4. Dynamic calculation: TTL is calculated based on each visitor's queue position

Why configure a range, not a fixed value:

Different visitors need different check frequencies that change as they move through the queue. You configure a range (e.g., 1-10 seconds) rather than a single fixed interval.

• Visitors near front: Receive shorter TTL values → more frequent checks → faster entry when resources become available
• Visitors at back: Receive longer TTL values → less frequent checks → reduce unnecessary server requests
• As they progress: TTL values automatically shrink, ensuring priority-appropriate checking frequency throughout their wait

This balances server load (fewer unnecessary requests) with user experience (immediate entry when available).

Visual Example (Range: 1-10 seconds):

Queue Position     TTL Value    Check Frequency
─────────────────────────────────────────────────
    Front     →    1-2 sec    →  Very frequent
   Mid-high   →    3-5 sec    →  Moderate
    Mid-low   →    6-8 sec    →  Less frequent
      Back    →    9-10 sec   →  Least frequent

    Visitor 1  (Front of queue)
    ↓ More frequent checks as they approach entry
    ↓
    Visitor 100 (Mid-queue) 
    ↓ Gradual TTL decrease as they progress
    ↓
    Visitor 500 (Back of queue)

This gradient ensures visitors at the front get rapid entry when resources become available, while those at the back don't overwhelm your server with unnecessary requests.

Default value: 1 second minimum, 10 seconds maximum

Configurable range: 1-60 seconds for both minimum and maximum values

How to configure:

1. Navigate to your segment's Advanced Settings
2. Set the minimum value (1 second is recommended)
3. Set the maximum value (10 seconds is recommended)
4. The system automatically adjusts each visitor's interval within this range based on their queue position

Recommendation: Use default values (1-10 seconds). These are optimized for NetFUNNEL server specifications. Changing them usually isn't necessary—the default balance already accounts for system capacity. Only adjust if you have specific requirements from performance monitoring.

Alive Notice Re-request Interval

What it does: Controls how frequently NetFUNNEL Agent sends Alive Notice (opcode 5003) signals to the server while users are active within the protected section. This signal tells the server "I'm still here and using resources" to prevent automatic key return due to timeout.

Why it's needed: In Section Control, users occupy resources throughout a multi-step section (e.g., selecting a concert, choosing time slots). The key return timeout would automatically release the resource if no activity is detected, but users need to maintain their active status while navigating through multiple pages.

How it works:

1. Automatic periodic transmission: When a user enters the protected section, the NetFUNNEL Agent automatically starts sending Alive Notice requests at the configured interval
2. Server response: Each Alive Notice resets the key return timeout timer on the server
3. Continuous loop: The Agent continues sending these signals while the user remains within the section (up to the Alive Notice expiration duration)
4. Resource protection: As long as Alive Notices keep arriving, the server maintains the user's resource occupancy and keeps them as an active user

Default value: 5 seconds

Configurable range: 1-60 seconds

Why this interval matters:

• Too short (e.g., 1-2 seconds): Excessive server requests when many users are active, potentially overwhelming the server
• Too long (e.g., 10+ seconds): If the interval exceeds the key return timeout threshold, the server might think the user has left and automatically release resources before the next Alive Notice arrives
• Critical constraint: The Alive Notice re-request interval must be shorter than the Timeout minimum value to prevent premature resource release

Recommendation: Use the default value (5 seconds). This ensures frequent enough check-ins to prevent timeout-based releases while keeping server load manageable. Only adjust if you have specific requirements based on performance monitoring.

Visual example:

Timeout Reset Mechanism

Each Alive Notice resets the server's timeout countdown back to 0. This means as long as users are actively navigating pages (every 5 seconds), the timeout never triggers. Only when the user stops sending Alive Notices (e.g., closes browser) does the timeout countdown complete.

Alive Notice Expiration

What it does: Sets the maximum total duration that users can remain in an active state within the protected section before the system stops sending Alive Notices. This is the upper limit for how long a user can occupy resources before being automatically released.

Why it's needed: Without an Alive Notice Expiration limit, a user who gets stuck or intentionally stays in the section indefinitely would occupy resources forever, preventing other queued users from entering. The Alive Notice Expiration ensures that even if a user never reaches the completion point, their resource slot will eventually be released.

How it works:

1. Global timer: The expiration timer starts when the user first enters the protected section
2. Continuous tracking: This timer persists across all pages within the section (it's not reset when moving between pages)
3. Alive Notice transmission limit: As long as time remains on the expiration timer, the Agent continues sending Alive Notices
4. Automatic stop: When the expiration duration is reached, the Agent stops sending Alive Notices
5. Resource release: Once Alive Notices stop, the standard timeout mechanism will release the resource after the configured timeout period

For example, if Alive Notice Expiration is set to 300 seconds (5 minutes), and timeout is 20 seconds:

• User enters section → Expiration timer starts (300s countdown)
• Agent sends Alive Notices every 5 seconds for up to 300 seconds
• At 300 seconds, Agent stops sending Alive Notices
• 20 seconds later (320s total), timeout releases the resource

Visual example:

Alive Notice Expiration vs Timeout

• Alive Notice Expiration: Maximum time Agent sends Alive Notices (e.g., 300 seconds). When reached, Agent stops all Alive Notice transmission.
• Timeout: Time server waits after last activity before auto-releasing (e.g., 20 seconds). This starts counting after the last Alive Notice is received.

In the example above: 300s (Alive Notice Expiration) + 20s (timeout) = 320s total resource occupation before release.

Default value: 300 seconds (5 minutes)

Configurable range: 60-3600 seconds

Why this duration matters:

Setting it correctly:

• Target: Average user journey time through the entire section + safety buffer (typically 20-30 seconds)
• Example calculation: If average checkout takes 120 seconds → Set Alive Notice Expiration to 150-180 seconds
• Too short: Normal users get cut off mid-process, losing their spot prematurely and potentially blocking others unnecessarily
• Too long: Users who actually abandoned or encountered errors occupy resources indefinitely, creating bottlenecks

Guidelines:

• Measure your actual average section journey time
• Add 20-30 seconds as a safety buffer for slower users
• For checkouts/registrations: Typically 2-5 minutes (120-300 seconds)
• For longer processes: Adjust based on actual user behavior
• Critical: Alive Notice Expiration should always be longer than your longest expected legitimate use case

Recommendation: Monitor your actual user journey times and set Alive Notice Expiration to average time + 30 seconds. Start conservative and adjust based on metrics.

Timeout

What it does: Automatically releases a visitor's entry slot if they don't properly complete their service session, ensuring resources remain available for others waiting in line.

When a visitor enters your service, NetFUNNEL tracks resource usage. After the visitor finishes (completing a purchase, viewing content, or any service interaction), NetFUNNEL expects a completion notification to free the slot for the next queued visitor.

Sometimes this doesn't happen: the visitor might close their browser, navigate away, or encounter an error. Without a timeout, the slot would remain occupied indefinitely, blocking all queued visitors.

The key return timeout (referred to as "timeout") is the maximum duration the server waits after the last activity (Alive Notice or key return request) before automatically releasing the resource. This prevents resource slots from being held indefinitely by abandoned or stuck users.

Think of it this way: you're at your reserved desk, and the system has been getting periodic check-ins every 5 seconds: "Still here? Yes." Then suddenly, these check-ins stop arriving—maybe you got an urgent call and left without checking out, your session crashed, or you closed the browser. The system notices: "Haven't received a check-in for 20 seconds. They might have left." After 20 seconds of no check-ins, the system automatically releases your desk reservation and marks it available for the next person waiting. This is the safety mechanism: even if someone disappears without properly checking out (nfStopSection), their desk doesn't stay "reserved" forever, blocking others from working.

How it works:

1. Timeout countdown: Starts when entry is granted (0 seconds)
2. Alive Notice resets timeout: Each Alive Notice received resets the timeout countdown back to 0
3. Completion detection:
   • Code-Based Integration (CBI): Completion is signaled when your service calls nfStopSection()
4. Normal flow: If proper completion is received, the slot is released normally
5. Timeout scenario: If no Alive Notices arrive for the timeout duration (6-20 seconds by default), NetFUNNEL automatically releases the slot

How Timeout interacts with Alive Notice:

Timeout triggers when Alive Notices stop arriving:

Default value: 6-20 seconds range (typically 20 seconds default)

Configurable range: 6-60 seconds for both minimum and maximum values

Why it's a range:

NetFUNNEL dynamically adjusts the timeout based on completion rate—the ratio of keys returned/collected versus keys issued for entry. A 100% completion rate means all keys are being properly returned, while a lower rate indicates keys are not being returned (requiring timeout-based auto-release).

• Low completion rate (keys not being returned properly) → Timeout shifts toward minimum (6s) to help release stalled resources faster
• High completion rate (keys being returned properly, close to 100%) → Timeout shifts toward maximum (20s) to give visitors adequate time to complete

Why 6-20 seconds:

The default range balances service integrity with preventing resource locks:

• Service operations: API responses (milliseconds), page loads (1-2 seconds typically)
• 20 seconds: Provides enough time for visitors to complete operations
• Too low (e.g., 1-2 seconds): Could cause premature release before services finish

Critical Relationship: Alive Notice Re-request Interval < Timeout

The Alive Notice re-request interval must be shorter than the Timeout minimum value to prevent premature resource release.

For example, if timeout minimum is 6 seconds, the Alive Notice interval should be 5 seconds or less. Otherwise, the timeout might trigger before the next Alive Notice arrives, causing legitimate active users to lose their resources.

Best Practices

Step 1: Focus on Alive Notice Expiration

Adjust only the critical settings.

The following three can use default values:

• Re-request Interval (1-10 seconds): Waiting room queue checks - optimized for NetFUNNEL server performance
• Alive Notice Re-request Interval (5 seconds): Active status check frequency - balanced server load and responsiveness
• Timeout (6-20 seconds range): Auto-return time - with default values, the key is automatically returned after the maximum timeout following the last Alive Notice

However, Alive Notice Expiration requires careful consideration.

Why is it important?

It's the upper limit to prevent over-entry.

After entry is granted, users occupy resources throughout their service journey, and no other users can enter during this time. If the Alive Notice Expiration hasn't passed, that slot remains "occupied."

⚠️ Too short → Normal users get forced out

Example: If Alive Notice Expiration is set to 100 seconds but actual average journey time is 150 seconds:

• Alive Notices stop mid-process and the server thinks "this user has left"
• An active user gets their resource taken away, and the server lets the next user enter
• → Over-entry occurs → Server overload → System failure

⚠️ Too long → Delayed resource release

• Users who actually abandoned or left continue sending Alive Notice signals
• Resources are unnecessarily occupied for extended periods
• → Queue bottleneck → Poor UX

How to configure

Alive Notice Expiration = Average journey time + safety buffer (20-30 seconds)

Concrete examples:

• If average journey time in the section is 150 seconds → Set expiration to 160-180 seconds
• If average journey time in the section is 120 seconds → Set expiration to 150-180 seconds

Step 2: Consider Timeout as well

Timeout defines how long to wait for users who send neither Alive Notice signals nor key return signals.

Why is it complex?

Even when users are completing normally, the server doesn't know.

When a user clicks "Complete Reservation":

1. UI processing
2. Network communication
3. Server response
4. nfStopSection() call

During these steps, the server must assume "service is not yet complete."

How to configure

Time from "Complete" button click → nfStopSection() call

Include a safety buffer considering API processing delays and browser rendering time.

Example: If it takes 3 seconds on average → Set timeout to 5-6 seconds

⚠️ Too short? → Resources released before proper return

User clicked the completion button, but timeout is 2 seconds while return takes 3 seconds:

• Server releases resources before the return request arrives
• → Server decreases resource usage and lets more users enter → Duplicate resource occupation → Over-entry

⚠️ Too long? → Delayed resource release for abandoned users

• User actually closed the browser or disconnected, but server doesn't know until 10+ seconds later
• → Delayed resource release → Bottleneck

💡 Recommendation: Timeout should be "slightly longer than normal return flow" for optimal performance.

Step 3: Adjust other values only if necessary, then test

These settings can usually stay at default, but can be adjusted if needed:

• Re-request Interval: Decrease if queue is too responsive, increase if server load is high
• Alive Notice Re-request Interval: Usually keep at default. Must be shorter than Timeout minimum
• Alive Notice Expiration: Must be adjusted - measure actual journey times first
• Timeout: Increase if completion signals are missed, decrease if resources are held too long

Important notes:

• After adjusting, test with real traffic to verify expected behavior
• Gradually adjust based on monitoring metrics for safety

Configuration Checklist

Before deploying with Section Control timing:

• Measure average user journey time through your multi-step section
• Set Alive Notice Expiration = average time + 20-30 seconds
• Verify Alive Notice Re-request Interval < Timeout minimum
• Test timeout scenarios (browser close, network disconnect)
• Monitor for premature resource releases or stuck resources

For related configuration options, see Queue Position Retention and Entry Key Invalidation documentation.