Segment

📄️ Interface Guide

Learn how to view, create, edit, and delete segments in the NetFUNNEL console interface.

🗃️ Basic Control Segment

13 items

🗃️ Section Control Segment

10 items

Overview

Segments are the core components of NetFUNNEL traffic control, serving as work units that manage the scope and policies for traffic control. Each segment has a unique segment key and can be configured with different control methods depending on your traffic management needs.

What are Segments?

A Segment is a work unit that manages the scope to which traffic control is applied. Traffic control policies are executed for access requests within the specified scope. Segments allow you to:

• Define Control Scope: Specify which URLs or sections should be controlled
• Set Traffic Policies: Configure entry status, limited inflow, and waiting room behavior
• Monitor Performance: Track traffic patterns and system performance
• Manage Resources: Control concurrent user limits and system capacity

Segment Types Comparison

NetFUNNEL provides two segment types, each optimized for different traffic control scenarios:

Aspect	Basic Control	Section Control
Primary Purpose	Controls entry speed for specific actions/URLs	Maintains fixed concurrent capacity in multi-step processes
Key Management	Key returned quickly after action completes	Key held until entire section/process completes
Best For	Button clicks, API calls, page loads, specific URLs	Multi-step processes, checkout flows, registration
Integration Methods	URL-Triggered Integration (UTI) + Code-Based Integration (CBI)	Code-Based Integration (CBI) only
Inflow Types	Fixed Type + Variable Type	Fixed Type only
Trigger Rules	Supported (for UTI)	Not supported
Entry Pass	Supported	Not supported
Advanced Timing	Re-request Interval, Timeout	Re-request Interval, Alive Notice Re-request Interval, Alive Notice Expiration, Timeout
Pre/Post Waiting Room	Supported	Not supported

Basic Control Segments

Basic Control controls traffic for specific actions or URLs. This method is ideal when you have:

• Specific surge URLs: Known high-traffic pages or endpoints
• Targeted control: Need to control specific user actions
• URL-based protection: Want automatic protection based on URL patterns (UTI)
• Quick response: Need immediate key return after actions complete
• Variable Type: Want automatic adjustment of limited inflow based on measured processing time

Key Characteristics:

• Key returned quickly after action completes
• Controls entry speed (how fast users can enter)
• Supports both UTI and CBI integration methods
• Supports Variable Type for automatic adjustment of limited inflow based on measured processing time
• Perfect for: Single actions, API throttling, page protection, targeted surge points

User Journey:

Action → Wait in queue (if active users exceed limited inflow) → Enter immediately → Key returned quickly → Next user can enter

Use Cases:

• /checkout page load protection
• /payment endpoint throttling
• /signup button click control
• High-traffic event page protection

Section Control Segments

Section Control is used when you need to control entire multi-step processes or application sections. This method is suitable for:

• Multi-step processes: Checkout flows, registration processes, multi-page forms
• Fixed capacity management: Need to maintain a fixed number of concurrent users in a section
• Process-wide control: Want to control entire process flows, not just individual pages
• Long-running sections: Processes where users navigate through multiple pages/steps

Key Characteristics:

• Key held until entire section/process completes
• Maintains fixed concurrent capacity (fixed number of users in section)
• Supports CBI integration method only
• Supports Fixed Type only (constant limited inflow)
• Perfect for: Multi-step processes, checkout flows, maintaining fixed capacity

User Journey:

Start → Wait in queue (if active users exceed limited inflow) → Enter section → Multiple steps → Complete entire process → Key returned → Next user can enter

Use Cases:

• E-commerce checkout process (cart → shipping → payment → confirmation)
• User registration flow (form → verification → confirmation)
• Booking/reservation process
• Multi-step payment processing

Common Concepts

Both Basic Control and Section Control share several fundamental concepts:

Segment Creation and Identity

Segment Name: Human-readable identifier for easy management

• Used for identification in segment lists
• Best practice: Use descriptive names (e.g., "E-commerce Checkout", "User Registration")
• Can include environment indicators (e.g., "Production", "Staging")

Segment Key: Unique identifier used by NetFUNNEL agents

• Automatically generated (format: segKey_XXXX)
• Can be customized during creation
• Cannot be changed after creation (immutable)
• Used in API calls: nfStart(segmentKey) or nfStartSection(segmentKey)

Entry Status

Entry Status determines how users are handled when attempting to access controlled resources:

• Waiting Status: Users wait in queue and enter when limited inflow becomes available

  • Shows waiting room UI
  • Users enter sequentially as limited inflow becomes available

• Block Status: Users are prevented from entering

  • Shows block room UI
  • All access requests are blocked (useful for maintenance or emergency situations)

Note: Setting Limited Inflow to 0 moves all users to waiting room (useful for testing).

Limited Inflow

Limited Inflow is the core traffic control mechanism that determines how many users can access your service simultaneously.

Core Concept:

• Sets maximum limited inflow for concurrent users
• Users only wait when active users exceed limited inflow
• If limit is 100 and current active users is 50, next 50 users proceed immediately
• User #101 and beyond wait until limited inflow becomes available

Fixed Type (Available in both):

• Constant limited inflow (e.g., always 100 users)
• Simple and predictable
• Recommended starting point

Variable Type (Basic Control only):

• Automatically adjusts limited inflow based on measured processing time
• Requires configuration of processing time range and limited inflow range
• Not available in Section Control (because processing time = user residency time, not server load)

Waiting Room Application

Both segment types use Waiting Room Application to configure the UI users see:

Waiting Room: Template shown to queued users while waiting

• Customizable templates
• Can include Live Messages (real-time text updates, max 20 characters)
• Basic Control: Displays "Estimated Wait Time"
• Section Control: Does not display "Estimated Wait Time" (due to variable user residency times)

Block Room: Template shown to blocked users

• Displayed when Entry Status is set to Block
• Customizable templates

Advanced Features

Queue Position Retention (Both):

• Restore queue position after disconnection (1 second to 2 hours)
• Helps users maintain their position if browser closes or network disconnects

Entry Key Invalidation (Both):

• Force re-queuing for specific conditions
• Basic Control: URL-based or Timer-based invalidation
• Section Control: Timer-based invalidation only

Advanced Timing (Both):

• Basic Control: Re-request Interval, Timeout
• Section Control: Re-request Interval, Alive Notice Re-request Interval, Alive Notice Expiration, Timeout

Assign Person in Charge (Both):

• Assign responsible Operators for segment management
• Restrict segment modification to assigned Operators

Key Differences Explained

1. Key Management Philosophy

The fundamental difference between Basic Control and Section Control is how and when entry keys are returned:

Basic Control - Quick Return:

• Key is returned immediately after the action completes (e.g., page loads, API call finishes)
• Focus: Control entry speed - how fast users can enter
• Next user can enter quickly after previous user completes action
• Example: After /checkout page loads, key is returned → user can proceed → next user can access immediately

Section Control - Hold Until Complete:

• Key is held throughout the entire multi-step process
• Focus: Maintain fixed concurrent capacity - fixed number of users in section at same time
• Key only returned when entire section completes (e.g., checkout finished, registration completed)
• Example: User enters checkout → key held during cart → shipping → payment → confirmation → key returned when all steps complete

2. Integration Methods

Basic Control - Two Methods:

• URL-Triggered Integration (UTI): Automatic protection based on URL patterns

  • No code changes required
  • Configure trigger rules to match URLs
  • Automatic waiting room display for matching requests

• Code-Based Integration (CBI): Manual control using nfStart() and nfStop()

  • Precise control over when waiting rooms appear
  • Use for button clicks, API calls, specific code paths

Section Control - One Method:

• Code-Based Integration (CBI) only: Manual control using nfStartSection() and nfStopSection()
  • Must manually define section boundaries
  • Call nfStartSection() when section begins
  • Call nfStopSection() when section completes
  • URL-Triggered Integration not supported (sections are multi-step, can't be triggered by single URL)

3. Inflow Type Availability

Basic Control - Two Types:

• Fixed Type: Constant limited inflow
• Variable Type: Automatically adjusts limited inflow based on measured processing time
  • Monitors processing time (server response time)
  • Adjusts limited inflow based on measured processing time
  • Requires configuration of processing time range and limited inflow range

Section Control - One Type:

• Fixed Type only: Constant limited inflow
• Variable Type not available: Processing time in Section Control represents user residency time (how long users stay in multi-step process), not server load
  • User behavior varies significantly (some users take 2 minutes, others take 10 minutes in checkout)
  • Cannot reliably use this as server load indicator
  • Therefore, automatic adjustment mechanism not suitable

4. Advanced Features Availability

Basic Control Exclusive:

• Trigger Rules: URL-based conditions for automatic protection (UTI)
• Entry Pass: Allow immediate re-entry without re-waiting (1 minute to 24 hours)
• Pre/Post Waiting Room Reservation: Schedule waiting rooms before and after main events
• Variable Type Inflow: Automatic adjustment of limited inflow based on processing time
• Estimated Wait Time: Displayed in waiting rooms

Section Control Exclusive:

• Alive Notice Re-request Interval: How often the Agent sends "I'm still active" signals
• Alive Notice Expiration: Maximum duration users can remain active in section

Both Support:

• Queue Position Retention
• Entry Key Invalidation (methods differ)
• Advanced Timing (options differ)
• Assign Person in Charge

Which Segment Type Should I Use?

Choose Basic Control if:

• ✅ You need to protect specific URLs or pages
• ✅ You want to use URL-Triggered Integration (UTI) for automatic protection
• ✅ You need quick key return after single actions complete
• ✅ You want Variable Type for automatic adjustment of limited inflow based on processing time
• ✅ You have targeted surge points (specific pages/endpoints)
• ✅ You need Entry Pass for immediate re-entry
• ✅ You need Trigger Rules for URL-based conditional control

Best for: Single-page actions, API throttling, page protection, URL-based traffic control

Choose Section Control if:

• ✅ You have multi-step processes (checkout, registration, multi-page flows)
• ✅ You need to maintain fixed concurrent capacity in a section
• ✅ You want to control entire process flows, not just individual pages
• ✅ You have processes where users navigate through multiple pages/steps
• ✅ You're using Code-Based Integration (CBI) only
• ✅ You need fixed capacity management (Variable Type not needed)

Best for: Multi-step checkout flows, registration processes, booking flows, processes requiring fixed concurrent user limits

Decision Flow

Do you need to protect multi-step processes?
  ├─ YES → Section Control
  │        (Checkout flows, registration, booking)
  │
  └─ NO → Do you need URL-based automatic protection?
         ├─ YES → Basic Control (UTI)
         │        (Specific pages, trigger rules)
         │
         └─ NO → Basic Control (CBI)
                (Button clicks, API calls, code-level control)

Segment Configuration Overview

Basic Setup Process

1. Create Segment: Click the '+' button in the segment list
2. Choose Control Type: Select Basic Control or Section Control
3. Configure Settings:
   • Basic Settings (Name, Key)
   • Entry Status (Waiting/Block)
   • Limited Inflow (limited inflow limit)
   • Waiting Room Application (templates)
4. Integration Setup:
   • Basic Control: Choose UTI (Trigger Rules) or CBI (code implementation)
   • Section Control: Implement CBI (nfStartSection/nfStopSection)
5. Test Configuration: Verify settings and monitor real-time metrics

Essential Configuration Elements

All segments require these core settings:

• Segment Name: Easy-to-distinguish identifier
• Segment Key: Unique key for API calls (auto-generated, modifiable until creation)
• Entry Status: Waiting (sequential entry) or Block (entry restriction)
• Limited Inflow: Number of users who can access simultaneously
• Waiting Room: Template selection and customization

Basic Control Additional:

• Trigger Rules: URL-based conditions (for UTI only)

Best Practices

Segment Planning

• Identify Control Scope: Determine which URLs or sections need control
• Choose Control Type:
  • Basic Control for specific URLs/pages/actions
  • Section Control for multi-step processes
• Plan Capacity: Set Limited Inflow to ~50% of maximum server capacity
• Design Waiting Experience: Create meaningful waiting room experiences
• Consider Integration Method: UTI for automatic protection, CBI for precise control

Performance Optimization

• Monitor Usage: Track segment performance and user experience
• Adjust Limits: Modify Limited Inflow based on actual capacity
• Start with Fixed Type: Use Fixed Type first, consider Variable Type (Basic Control) after monitoring
• Test Thoroughly: Verify settings with trigger rule tests (Basic Control UTI) or code testing (CBI)

Configuration Tips

• Segment Naming: Use descriptive names indicating purpose and environment
• Key Customization: Customize segment keys during creation for better code readability
• Entry Status: Use Waiting for normal operation, Block for maintenance/emergencies
• Testing: Set Limited Inflow to 0 for testing (all users go to waiting room)