Polling - Controlled Access: Coordinated Medium Access Control | OneNoughtOne

Computer NetworksControlled Access

Controlled Access: Coordinated Medium Access Control

LevelIntermediate

Duration60 mins

TopicControlled Access

1 / 5

Polling

The Order of Controlled Chaos

Imagine a classroom where every student shouts out answers simultaneously—chaos ensues, nobody is heard, and learning grinds to a halt. Now imagine the teacher systematically calling on each student in turn: "Alice, do you have something to say? No? Bob, how about you?" This orderly approach is precisely what polling achieves in computer networks.

Unlike contention-based protocols (ALOHA, CSMA/CD) where stations compete for the channel and collisions are inevitable, controlled access protocols eliminate collisions entirely by coordinating which station may transmit at any given moment. Polling represents the centralized approach to this coordination—a primary station (controller) sequentially queries secondary stations, granting each an exclusive opportunity to transmit.

This seemingly simple concept has profound implications for network determinism, fairness, and real-time guarantees that contention-based systems simply cannot provide.

What You Will Learn

By the end of this page, you will understand the complete mechanics of polling protocols—how primary stations coordinate channel access, the poll/select protocol structure, round-robin versus priority-based polling strategies, overhead analysis, and why polling remains essential for industrial control systems, satellite networks, and real-time applications where predictable latency matters more than raw throughput.

The Fundamental Problem with Contention

Before we dive into polling, we must understand why contention-based protocols—despite their simplicity and widespread use—fail catastrophically in certain applications.

The Contention Paradigm:

In protocols like CSMA/CD (Ethernet), stations compete for the shared medium:

Listen before transmitting (carrier sense)
Transmit if channel is idle
If collision occurs, back off and retry

This works remarkably well for bursty, best-effort traffic. But it has fundamental limitations:

Contention Protocol Limitations
Limitation	Consequence	Impact on Applications
Non-deterministic access	Unbounded worst-case latency	Fatal for real-time control systems
Collision overhead	Wasted bandwidth during contention	Throughput degrades under heavy load
Unfairness possible	Some stations may dominate	Starvation of low-priority traffic
Hidden terminal problem	Collision detection fails in wireless	Severe degradation in WLANs
Load-dependent performance	Efficiency drops as load increases	Unpredictable behavior at scale

When Contention Fails

Consider a factory floor with 100 sensors reporting to a central controller. If each sensor uses CSMA/CD and a critical alarm sensor needs to transmit during peak load, it might wait indefinitely while collisions resolve. In industrial control, this delay could mean equipment damage or safety hazards. Controlled access becomes mandatory.

The Controlled Access Solution:

Controlled access protocols eliminate these problems through coordination:

Property	Contention (CSMA/CD)	Controlled Access (Polling)
Collisions	Occur and must be resolved	Never occur
Access delay	Variable, unbounded	Bounded, deterministic
Fairness	Statistical, best-effort	Guaranteed by design
Overhead type	Collisions, backoff	Polling messages
Complexity	Distributed, simple	Centralized, moderate

Polling achieves these guarantees through a master-slave architecture where one station controls all medium access.

Polling Architecture

Polling is a centralized controlled access protocol where a designated primary station (also called the controller, master, or poller) systematically queries secondary stations (also called slaves or polled stations) for data.

Key Architectural Components:

Primary Station (Controller)
- Maintains the polling list (ordered list of secondary stations)
- Initiates all data transfers
- Sends poll messages to secondaries
- Receives data from polled stations
- May send data to secondaries using select messages
Secondary Stations (Slaves)
- Wait passively for poll messages
- Transmit data only when polled
- Cannot initiate communication
- Buffer outgoing data until polled
Polling List
- Ordered sequence of secondary station addresses
- Determines polling order and frequency
- May be static or dynamically adjusted

Converting Mermaid diagram...

The Poll/Select Protocol:

Polling systems typically implement two complementary operations:

Poll Operation (Secondary → Primary):

Primary sends POLL message to secondary
Secondary responds with DATA if it has something to send
Secondary responds with NAK (negative acknowledgment) if no data
Primary waits for response before polling next station

Select Operation (Primary → Secondary):

Primary sends SELECT message indicating intent to send data
Secondary responds with ACK if ready to receive
Primary transmits DATA frame
Secondary acknowledges successful receipt

This bidirectional capability allows the controller to both collect data from sensors and send commands to actuators—essential for industrial control systems.

Primary Station as Traffic Cop

Think of the primary station as a traffic officer at an intersection without traffic lights. Instead of letting cars (stations) compete and potentially collide, the officer explicitly directs each car when to go. No collisions occur, but every movement requires the officer's explicit permission.

Polling Message Formats

The efficiency of polling depends critically on the overhead of poll and response messages. Let's examine the typical message formats used in polling protocols.

Poll Message Structure:

+----------+-------------+----------+--------+
|  Header  |   Address   |   Type   |  FCS   |
| (1 byte) |  (1-2 bytes)|  (1 byte)| (2 bytes)|
+----------+-------------+----------+--------+

Type field values:
  0x01 = POLL (request data from secondary)
  0x02 = SELECT (prepare to receive data)
  0x03 = EOT (end of transmission, release line)

Response Message Structure:

+----------+-------------+----------+----------+--------+
|  Header  |   Address   |   Type   |   Data   |  FCS   |
| (1 byte) |  (1-2 bytes)|  (1 byte)| (0-N bytes)| (2 bytes)|
+----------+-------------+----------+----------+--------+

Type field values:
  0x10 = DATA (contains data payload)
  0x11 = NAK (no data to send)
  0x12 = ACK (ready to receive / received OK)

polling_protocol.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# Polling Protocol Message Types
class MessageType:
    POLL = 0x01      # Primary -> Secondary: "Do you have data?"
    SELECT = 0x02    # Primary -> Secondary: "I have data for you"
    EOT = 0x03       # End of transmission
    
    DATA = 0x10      # Secondary -> Primary: "Here is my data"
    NAK = 0x11       # Secondary -> Primary: "Nothing to send"
    ACK = 0x12       # Acknowledgment
 
class PollMessage:
    """Poll message from primary to secondary."""
    def __init__(self, address: int):
        self.header = 0x7E  # Flag byte
        self.address = address
        self.msg_type = MessageType.POLL
        self.fcs = self.compute_fcs()
    
    def to_bytes(self) -> bytes:
        return bytes([
            self.header,
            self.address >> 8,    # High byte of address
            self.address & 0xFF,  # Low byte of address
            self.msg_type,
            self.fcs >> 8,
            self.fcs & 0xFF
        ])
    
    def size(self) -> int:
        return 6  # bytes (poll message overhead)
 
class DataResponse:
    """Data response from secondary to primary."""
    def __init__(self, address: int, data: bytes):
        self.header = 0x7E
        self.address = address
        self.msg_type = MessageType.DATA
        self.data = data
        self.fcs = self.compute_fcs()
    
    def overhead(self) -> int:
        return 6  # Header + Address + Type + FCS
    
    def total_size(self) -> int:
        return self.overhead() + len(self.data)

Polling Overhead Analysis:

For each station polled, the overhead includes:

Poll message: ~5-8 bytes from primary
Propagation delay: Round-trip time for poll/response
Response message: ~5-8 bytes (NAK) or larger (DATA + header)
Processing delay: Time for secondary to process poll

For a network with N stations where only fraction f have data:

Per-cycle overhead = N × (poll_size + response_overhead) + N × RTT
Useful data = f × N × avg_data_size
Efficiency = Useful data / (Useful data + Per-cycle overhead)

This overhead becomes significant when:

Many stations exist (large N)
Few stations have data (small f)
Propagation delays are high (large RTT)
Data bursts are small relative to poll overhead

The Empty Poll Problem

If a secondary has no data, it still must respond with NAK, consuming channel time. In networks where most stations rarely have data (sparse traffic), polling efficiency drops dramatically. This is why polling works best when stations consistently have data to send or when deterministic timing matters more than efficiency.

Round-Robin Polling

The simplest and most common polling strategy is round-robin polling, where the primary station cycles through all secondary stations in a fixed, repeating sequence.

Algorithm:

current_station = 0
while True:
    send_poll(station_list[current_station])
    response = wait_for_response(timeout)
    
    if response.type == DATA:
        process_data(response.data)
    elif response == TIMEOUT:
        mark_station_unresponsive(current_station)
    
    current_station = (current_station + 1) % num_stations

Properties of Round-Robin Polling:

Property	Characteristic
Fairness	Perfect - each station gets equal opportunity
Maximum wait	Bounded: (N-1) × poll_cycle_time
Complexity	O(1) per poll decision
Adaptability	None - static scheduling
Overhead	Proportional to N (all stations polled)

Converting Mermaid diagram...

Calculating Polling Cycle Time:

For N stations with:

Poll message size: P bytes
NAK response size: R bytes
Average data response size: D bytes
Fraction of stations with data: f
Channel data rate: C bps
One-way propagation delay: τ seconds

Cycle time formula:

T_cycle = N × [T_poll + T_response + 2τ]

where:
  T_poll = P × 8 / C (poll transmission time)
  T_response = f × (D × 8 / C) + (1-f) × (R × 8 / C)

Example Calculation:

Given:

N = 20 stations
P = 6 bytes, R = 6 bytes, D = 100 bytes average
C = 1 Mbps
τ = 0.1 ms (local network)
f = 0.3 (30% have data)

T_poll = 6 × 8 / 1,000,000 = 48 μs
T_response_avg = 0.3 × (100 × 8 / 1,000,000) + 0.7 × (6 × 8 / 1,000,000)
               = 0.3 × 800 μs + 0.7 × 48 μs
               = 240 μs + 33.6 μs = 273.6 μs

Per-station time = 48 + 273.6 + 200 = 521.6 μs
T_cycle = 20 × 521.6 μs = 10.43 ms

Maximum latency for any station = T_cycle ≈ 10.43 ms

Bounded Latency Guarantee

The critical insight is that maximum latency is BOUNDED and PREDICTABLE. Unlike CSMA/CD where a station might wait indefinitely during heavy collisions, a polled station knows it will be served within at most one polling cycle time. This determinism is invaluable for real-time systems.

Priority and Weighted Polling

Round-robin polling treats all stations equally, but many applications require differentiated service. Priority polling and weighted polling address this need.

Priority Polling:

Stations are assigned priority levels. Higher-priority stations are polled more frequently or before lower-priority stations.

Strategy 1: Priority Classes with Multiple Rounds

Polling sequence per cycle:
  [High priority x 4]: A, B
  [Medium priority x 2]: C, D, E
  [Low priority x 1]: F, G, H, I

Resulting pattern: A, B, A, B, A, B, A, B, C, D, E, C, D, E, F, G, H, I

Strategy 2: Priority Ordering

Polling sequence:
  All high-priority stations first
  Then medium-priority
  Then low-priority

Pattern: A, B, C, D, E, F, G, H, I (where A,B are high; C,D,E medium; F,G,H,I low)

priority_polling.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
from dataclasses import dataclass
from enum import IntEnum
from typing import List
 
class Priority(IntEnum):
    HIGH = 3
    MEDIUM = 2
    LOW = 1
 
@dataclass
class Station:
    address: int
    priority: Priority
    weight: int = 1  # For weighted polling
 
class WeightedPriorityPoller:
    """Implements weighted priority polling."""
    
    def __init__(self, stations: List[Station]):
        self.stations = sorted(stations, 
                              key=lambda s: (-s.priority, s.address))
        self.polling_list = self._build_weighted_list()
        self.current_index = 0
    
    def _build_weighted_list(self) -> List[Station]:
        """Build polling list with priority-based repetition."""
        poll_list = []
        
        for station in self.stations:
            # Higher priority = more polls per cycle
            repetitions = station.priority * station.weight
            poll_list.extend([station] * repetitions)
        
        return poll_list
    
    def next_station(self) -> Station:
        """Get next station to poll."""
        station = self.polling_list[self.current_index]
        self.current_index = (self.current_index + 1) % len(self.polling_list)
        return station
    
    def get_poll_ratio(self, station: Station) -> float:
        """Calculate what fraction of polls go to this station."""
        station_polls = self.polling_list.count(station)
        return station_polls / len(self.polling_list)
 
# Example usage
stations = [
    Station(address=1, priority=Priority.HIGH, weight=2),    # Critical sensor
    Station(address=2, priority=Priority.HIGH, weight=1),    # Safety sensor
    Station(address=3, priority=Priority.MEDIUM, weight=1),  # Process sensor
    Station(address=4, priority=Priority.LOW, weight=1),     # Status sensor
]
 
poller = WeightedPriorityPoller(stations)
 
# Station 1 gets: 3 (HIGH) × 2 (weight) = 6 polls per cycle
# Station 2 gets: 3 (HIGH) × 1 (weight) = 3 polls per cycle
# Station 3 gets: 2 (MEDIUM) × 1 (weight) = 2 polls per cycle
# Station 4 gets: 1 (LOW) × 1 (weight) = 1 poll per cycle

Service Guarantees with Priority Polling:

Priority Level	Poll Frequency	Max Latency	Use Case
High (weight 3)	3× per cycle	T_cycle / 3	Safety alarms, emergency stops
Medium (weight 2)	2× per cycle	T_cycle / 2	Process control, feedback loops
Low (weight 1)	1× per cycle	T_cycle	Status monitoring, logging

Trade-offs of Priority Polling:

Advantage: Critical stations get faster service
Advantage: Latency bounds can be tightened for high-priority traffic
Disadvantage: Low-priority stations may see significantly increased latency
Disadvantage: If many high-priority stations exist, cycle time increases

Priority Inversion Risk

If a high-priority station has large amounts of data and transmits for a long time when polled, lower-priority stations are delayed even further. Some systems implement transmission limits (maximum bytes per poll) to prevent high-priority stations from monopolizing the channel.

Hub Polling (Roll-Call Polling)

A variant of centralized polling is Hub Polling (also called Roll-Call Polling), commonly used in multipoint networks where the primary station is at the center of a star or tree topology.

Hub Polling Characteristics:

Centralized topology — Primary station connects to all secondaries via hub
Sequential roll-call — Primary addresses each secondary in turn
Timeout handling — If a secondary doesn't respond, primary moves to next
Recovery mechanisms — Failed stations can be re-polled or marked offline

Hub Polling Sequence:

Primary: POLL Station_1
         Wait for response (with timeout)
         If DATA → accept and acknowledge
         If NAK → note nothing to send
         If TIMEOUT → mark station as failed
         
Primary: POLL Station_2
         ... (repeat sequence)

Converting Mermaid diagram...

Hub Polling in Mainframe Environments:

Historically, hub polling was extensively used in IBM mainframe networks (SNA - Systems Network Architecture):

Cluster Controller (Primary)
    ↓ Poll
3270 Terminal (Secondary)
    ↓ Response
Cluster Controller
    ↓ Poll
Printer (Secondary)
    ↓ NAK (nothing to print)
Cluster Controller
    ↓ Poll
3270 Terminal (next)
    ...

Efficiency Considerations for Hub Polling:

Factor	Impact on Efficiency
Number of terminals	Linear increase in cycle time
Terminal response time	Adds to per-poll overhead
Propagation delay	Multiplied by 2N (poll + response for each)
Failed terminals	Timeout delays add significant overhead

Historical Context

Hub polling was the dominant paradigm for mainframe-terminal communication from the 1970s through the 1990s. IBM's SDLC (Synchronous Data Link Control) and its ISO standardization as HDLC (High-level Data Link Control) include comprehensive polling support. These protocols influenced practically all subsequent WAN protocols.

Advantages and Disadvantages of Polling

Polling offers a fundamentally different set of trade-offs compared to contention-based protocols. Understanding these trade-offs is essential for selecting the appropriate protocol for a given application.

Advantages

•No collisions — Channel time is never wasted on collision resolution
•Deterministic latency — Maximum wait time is bounded and predictable
•Guaranteed fairness — Every station is polled according to schedule
•Priority support — Easy to implement differentiated service levels
•Centralized control — Simple network management and troubleshooting
•Works with any topology — Star, tree, bus, or multipoint
•No hidden terminal problem — Primary controls all access

Disadvantages

•Polling overhead — Every station polled consumes channel time, even with nothing to send
•Single point of failure — Primary station failure halts entire network
•Latency increases with stations — More stations = longer cycle time
•Inefficient for sparse traffic — Most polls may return NAK
•Bandwidth waste — Poll/NAK exchanges use channel without carrying useful data
•Scalability limits — Cycle time grows linearly with N
•Response time depends on position — Station polled first gets faster service than last

When to Use Polling vs. Contention
Criterion	Favor Polling	Favor Contention (CSMA)
Traffic pattern	Continuous, regular	Bursty, irregular
Latency requirements	Bounded, guaranteed	Best-effort acceptable
Number of stations	Moderate (< 50)	Large (100+)
Data availability	Most stations have data	Few stations active at once
Failure tolerance	Single point OK	Distributed resilience needed
Network management	Centralized preferred	Autonomous stations preferred
Real-time constraints	Hard real-time	Soft or no real-time

Real-World Applications of Polling

Despite being considered "old-fashioned" compared to modern switched networks, polling remains critically important in several domains where its deterministic properties are essential.

Critical Polling Applications

•Industrial Control Systems (SCADA) — Supervisory Control and Data Acquisition systems poll PLCs (Programmable Logic Controllers) and RTUs (Remote Terminal Units) for sensor data. Protocols like Modbus and DNP3 use polling extensively for deterministic data collection.
•Satellite Communication — Ground stations poll satellite terminals in VSAT networks. The long propagation delay (250ms+ round-trip) makes contention impractical; polling provides orderly access to the expensive satellite bandwidth.
•Avionics Networks — Aircraft data buses like ARINC 429 and MIL-STD-1553 use polling for safety-critical communication between flight computers, sensors, and actuators. Deterministic timing is mandatory for flight control.
•Building Automation — BACnet (Building Automation and Control Networks) supports polling for HVAC, lighting, and access control systems where reliable, scheduled data collection matters more than throughput.
•Point-of-Sale Terminals — Retail networks poll POS terminals for transaction data. The centralized controller aggregates sales data and pushes price updates to terminals.
•Medical Devices — Patient monitoring systems poll bedside monitors for vital signs. Guaranteed latency ensures critical alarms are never delayed by network contention.

Case Study: Modbus Polling in Industrial Control

Modbus Master (SCADA Server)
    ↓ Query (Read Holding Registers)
Modbus Slave (PLC, Address 01)
    ↓ Response (Register values: temperature, pressure)
Modbus Master
    ↓ Query (Read Input Status)
Modbus Slave (RTU, Address 02)
    ↓ Response (Digital inputs: switch states)
    
Typical polling cycle: 100ms - 1000ms
Maximum slaves per network: 247 (Modbus limit)

Modbus remains one of the most widely deployed industrial protocols, and its polling-based architecture ensures that every sensor is read at predictable intervals—essential for process control where a missed reading could mean unsafe operating conditions.

Enduring Relevance

While Ethernet and IP have taken over most general networking, polling persists wherever deterministic behavior trumps raw throughput. Modern industrial Ethernet protocols (PROFINET, EtherNet/IP, EtherCAT) often layer deterministic mechanisms on top of Ethernet to achieve polling-like guarantees.

Summary: Polling Fundamentals

We've explored polling as a fundamental controlled access protocol. Let's consolidate the key concepts:

Key Takeaways

•Centralized coordination — A primary station explicitly grants transmission permission to secondary stations, eliminating collisions entirely.
•Poll/Select protocol — Poll operations retrieve data from secondaries; Select operations send data to secondaries. Both require explicit handshaking.
•Deterministic latency — Maximum access delay is bounded by the polling cycle time, making polling ideal for real-time systems.
•Round-robin fairness — Basic polling treats all stations equally; priority polling provides differentiated service.
•Overhead trade-off — The price of determinism is polling overhead—every station must be polled even if it has nothing to send.
•Single point of failure — The primary station is critical; its failure halts the network.
•Enduring applications — Industrial control, avionics, satellite communication rely on polling for guaranteed access timing.

What's Next:

In the next page, we'll explore Token Passing—a distributed controlled access protocol that eliminates the single point of failure inherent in polling while maintaining collision-free operation. We'll see how stations pass a special token to coordinate access without requiring a central controller.

Page Complete

You now understand polling as a controlled access protocol—its centralized architecture, message formats, round-robin and priority scheduling, efficiency trade-offs, and real-world applications. Next, we'll discover how token passing achieves similar determinism in a fully distributed manner.

1 / 5

Loading learning content...

Computer NetworksControlled Access

Controlled Access: Coordinated Medium Access Control

LevelIntermediate

Duration60 mins

TopicControlled Access

1 / 5

Polling

The Order of Controlled Chaos

This seemingly simple concept has profound implications for network determinism, fairness, and real-time guarantees that contention-based systems simply cannot provide.

What You Will Learn

The Fundamental Problem with Contention

Before we dive into polling, we must understand why contention-based protocols—despite their simplicity and widespread use—fail catastrophically in certain applications.

The Contention Paradigm:

In protocols like CSMA/CD (Ethernet), stations compete for the shared medium:

Listen before transmitting (carrier sense)
Transmit if channel is idle
If collision occurs, back off and retry

This works remarkably well for bursty, best-effort traffic. But it has fundamental limitations:

Contention Protocol Limitations
Limitation	Consequence	Impact on Applications
Non-deterministic access	Unbounded worst-case latency	Fatal for real-time control systems
Collision overhead	Wasted bandwidth during contention	Throughput degrades under heavy load
Unfairness possible	Some stations may dominate	Starvation of low-priority traffic
Hidden terminal problem	Collision detection fails in wireless	Severe degradation in WLANs
Load-dependent performance	Efficiency drops as load increases	Unpredictable behavior at scale

When Contention Fails

The Controlled Access Solution:

Controlled access protocols eliminate these problems through coordination:

Property	Contention (CSMA/CD)	Controlled Access (Polling)
Collisions	Occur and must be resolved	Never occur
Access delay	Variable, unbounded	Bounded, deterministic
Fairness	Statistical, best-effort	Guaranteed by design
Overhead type	Collisions, backoff	Polling messages
Complexity	Distributed, simple	Centralized, moderate

Polling achieves these guarantees through a master-slave architecture where one station controls all medium access.

Polling Architecture

Key Architectural Components:

Primary Station (Controller)
- Maintains the polling list (ordered list of secondary stations)
- Initiates all data transfers
- Sends poll messages to secondaries
- Receives data from polled stations
- May send data to secondaries using select messages
Secondary Stations (Slaves)
- Wait passively for poll messages
- Transmit data only when polled
- Cannot initiate communication
- Buffer outgoing data until polled
Polling List
- Ordered sequence of secondary station addresses
- Determines polling order and frequency
- May be static or dynamically adjusted

Converting Mermaid diagram...

The Poll/Select Protocol:

Polling systems typically implement two complementary operations:

Poll Operation (Secondary → Primary):

Primary sends POLL message to secondary
Secondary responds with DATA if it has something to send
Secondary responds with NAK (negative acknowledgment) if no data
Primary waits for response before polling next station

Select Operation (Primary → Secondary):

Primary sends SELECT message indicating intent to send data
Secondary responds with ACK if ready to receive
Primary transmits DATA frame
Secondary acknowledges successful receipt

This bidirectional capability allows the controller to both collect data from sensors and send commands to actuators—essential for industrial control systems.

Primary Station as Traffic Cop

Polling Message Formats

The efficiency of polling depends critically on the overhead of poll and response messages. Let's examine the typical message formats used in polling protocols.

Poll Message Structure:

+----------+-------------+----------+--------+
|  Header  |   Address   |   Type   |  FCS   |
| (1 byte) |  (1-2 bytes)|  (1 byte)| (2 bytes)|
+----------+-------------+----------+--------+

Type field values:
  0x01 = POLL (request data from secondary)
  0x02 = SELECT (prepare to receive data)
  0x03 = EOT (end of transmission, release line)

Response Message Structure:

+----------+-------------+----------+----------+--------+
|  Header  |   Address   |   Type   |   Data   |  FCS   |
| (1 byte) |  (1-2 bytes)|  (1 byte)| (0-N bytes)| (2 bytes)|
+----------+-------------+----------+----------+--------+

Type field values:
  0x10 = DATA (contains data payload)
  0x11 = NAK (no data to send)
  0x12 = ACK (ready to receive / received OK)

polling_protocol.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# Polling Protocol Message Types
class MessageType:
    POLL = 0x01      # Primary -> Secondary: "Do you have data?"
    SELECT = 0x02    # Primary -> Secondary: "I have data for you"
    EOT = 0x03       # End of transmission
    
    DATA = 0x10      # Secondary -> Primary: "Here is my data"
    NAK = 0x11       # Secondary -> Primary: "Nothing to send"
    ACK = 0x12       # Acknowledgment
 
class PollMessage:
    """Poll message from primary to secondary."""
    def __init__(self, address: int):
        self.header = 0x7E  # Flag byte
        self.address = address
        self.msg_type = MessageType.POLL
        self.fcs = self.compute_fcs()
    
    def to_bytes(self) -> bytes:
        return bytes([
            self.header,
            self.address >> 8,    # High byte of address
            self.address & 0xFF,  # Low byte of address
            self.msg_type,
            self.fcs >> 8,
            self.fcs & 0xFF
        ])
    
    def size(self) -> int:
        return 6  # bytes (poll message overhead)
 
class DataResponse:
    """Data response from secondary to primary."""
    def __init__(self, address: int, data: bytes):
        self.header = 0x7E
        self.address = address
        self.msg_type = MessageType.DATA
        self.data = data
        self.fcs = self.compute_fcs()
    
    def overhead(self) -> int:
        return 6  # Header + Address + Type + FCS
    
    def total_size(self) -> int:
        return self.overhead() + len(self.data)

Polling Overhead Analysis:

For each station polled, the overhead includes:

Poll message: ~5-8 bytes from primary
Propagation delay: Round-trip time for poll/response
Response message: ~5-8 bytes (NAK) or larger (DATA + header)
Processing delay: Time for secondary to process poll

For a network with N stations where only fraction f have data:

Per-cycle overhead = N × (poll_size + response_overhead) + N × RTT
Useful data = f × N × avg_data_size
Efficiency = Useful data / (Useful data + Per-cycle overhead)

This overhead becomes significant when:

Many stations exist (large N)
Few stations have data (small f)
Propagation delays are high (large RTT)
Data bursts are small relative to poll overhead

The Empty Poll Problem

Round-Robin Polling

The simplest and most common polling strategy is round-robin polling, where the primary station cycles through all secondary stations in a fixed, repeating sequence.

Algorithm:

current_station = 0
while True:
    send_poll(station_list[current_station])
    response = wait_for_response(timeout)
    
    if response.type == DATA:
        process_data(response.data)
    elif response == TIMEOUT:
        mark_station_unresponsive(current_station)
    
    current_station = (current_station + 1) % num_stations

Properties of Round-Robin Polling:

Property	Characteristic
Fairness	Perfect - each station gets equal opportunity
Maximum wait	Bounded: (N-1) × poll_cycle_time
Complexity	O(1) per poll decision
Adaptability	None - static scheduling
Overhead	Proportional to N (all stations polled)

Converting Mermaid diagram...

Calculating Polling Cycle Time:

For N stations with:

Poll message size: P bytes
NAK response size: R bytes
Average data response size: D bytes
Fraction of stations with data: f
Channel data rate: C bps
One-way propagation delay: τ seconds

Cycle time formula:

T_cycle = N × [T_poll + T_response + 2τ]

where:
  T_poll = P × 8 / C (poll transmission time)
  T_response = f × (D × 8 / C) + (1-f) × (R × 8 / C)

Example Calculation:

Given:

N = 20 stations
P = 6 bytes, R = 6 bytes, D = 100 bytes average
C = 1 Mbps
τ = 0.1 ms (local network)
f = 0.3 (30% have data)

T_poll = 6 × 8 / 1,000,000 = 48 μs
T_response_avg = 0.3 × (100 × 8 / 1,000,000) + 0.7 × (6 × 8 / 1,000,000)
               = 0.3 × 800 μs + 0.7 × 48 μs
               = 240 μs + 33.6 μs = 273.6 μs

Per-station time = 48 + 273.6 + 200 = 521.6 μs
T_cycle = 20 × 521.6 μs = 10.43 ms

Maximum latency for any station = T_cycle ≈ 10.43 ms

Bounded Latency Guarantee

Priority and Weighted Polling

Round-robin polling treats all stations equally, but many applications require differentiated service. Priority polling and weighted polling address this need.

Priority Polling:

Stations are assigned priority levels. Higher-priority stations are polled more frequently or before lower-priority stations.

Strategy 1: Priority Classes with Multiple Rounds

Polling sequence per cycle:
  [High priority x 4]: A, B
  [Medium priority x 2]: C, D, E
  [Low priority x 1]: F, G, H, I

Resulting pattern: A, B, A, B, A, B, A, B, C, D, E, C, D, E, F, G, H, I

Strategy 2: Priority Ordering

Polling sequence:
  All high-priority stations first
  Then medium-priority
  Then low-priority

Pattern: A, B, C, D, E, F, G, H, I (where A,B are high; C,D,E medium; F,G,H,I low)

priority_polling.py
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
from dataclasses import dataclass
from enum import IntEnum
from typing import List
 
class Priority(IntEnum):
    HIGH = 3
    MEDIUM = 2
    LOW = 1
 
@dataclass
class Station:
    address: int
    priority: Priority
    weight: int = 1  # For weighted polling
 
class WeightedPriorityPoller:
    """Implements weighted priority polling."""
    
    def __init__(self, stations: List[Station]):
        self.stations = sorted(stations, 
                              key=lambda s: (-s.priority, s.address))
        self.polling_list = self._build_weighted_list()
        self.current_index = 0
    
    def _build_weighted_list(self) -> List[Station]:
        """Build polling list with priority-based repetition."""
        poll_list = []
        
        for station in self.stations:
            # Higher priority = more polls per cycle
            repetitions = station.priority * station.weight
            poll_list.extend([station] * repetitions)
        
        return poll_list
    
    def next_station(self) -> Station:
        """Get next station to poll."""
        station = self.polling_list[self.current_index]
        self.current_index = (self.current_index + 1) % len(self.polling_list)
        return station
    
    def get_poll_ratio(self, station: Station) -> float:
        """Calculate what fraction of polls go to this station."""
        station_polls = self.polling_list.count(station)
        return station_polls / len(self.polling_list)
 
# Example usage
stations = [
    Station(address=1, priority=Priority.HIGH, weight=2),    # Critical sensor
    Station(address=2, priority=Priority.HIGH, weight=1),    # Safety sensor
    Station(address=3, priority=Priority.MEDIUM, weight=1),  # Process sensor
    Station(address=4, priority=Priority.LOW, weight=1),     # Status sensor
]
 
poller = WeightedPriorityPoller(stations)
 
# Station 1 gets: 3 (HIGH) × 2 (weight) = 6 polls per cycle
# Station 2 gets: 3 (HIGH) × 1 (weight) = 3 polls per cycle
# Station 3 gets: 2 (MEDIUM) × 1 (weight) = 2 polls per cycle
# Station 4 gets: 1 (LOW) × 1 (weight) = 1 poll per cycle

Service Guarantees with Priority Polling:

Priority Level	Poll Frequency	Max Latency	Use Case
High (weight 3)	3× per cycle	T_cycle / 3	Safety alarms, emergency stops
Medium (weight 2)	2× per cycle	T_cycle / 2	Process control, feedback loops
Low (weight 1)	1× per cycle	T_cycle	Status monitoring, logging

Trade-offs of Priority Polling:

Advantage: Critical stations get faster service
Advantage: Latency bounds can be tightened for high-priority traffic
Disadvantage: Low-priority stations may see significantly increased latency
Disadvantage: If many high-priority stations exist, cycle time increases

Priority Inversion Risk

Hub Polling (Roll-Call Polling)

A variant of centralized polling is Hub Polling (also called Roll-Call Polling), commonly used in multipoint networks where the primary station is at the center of a star or tree topology.

Hub Polling Characteristics:

Centralized topology — Primary station connects to all secondaries via hub
Sequential roll-call — Primary addresses each secondary in turn
Timeout handling — If a secondary doesn't respond, primary moves to next
Recovery mechanisms — Failed stations can be re-polled or marked offline

Hub Polling Sequence:

Primary: POLL Station_1
         Wait for response (with timeout)
         If DATA → accept and acknowledge
         If NAK → note nothing to send
         If TIMEOUT → mark station as failed
         
Primary: POLL Station_2
         ... (repeat sequence)

Converting Mermaid diagram...

Hub Polling in Mainframe Environments:

Historically, hub polling was extensively used in IBM mainframe networks (SNA - Systems Network Architecture):

Cluster Controller (Primary)
    ↓ Poll
3270 Terminal (Secondary)
    ↓ Response
Cluster Controller
    ↓ Poll
Printer (Secondary)
    ↓ NAK (nothing to print)
Cluster Controller
    ↓ Poll
3270 Terminal (next)
    ...

Efficiency Considerations for Hub Polling:

Factor	Impact on Efficiency
Number of terminals	Linear increase in cycle time
Terminal response time	Adds to per-poll overhead
Propagation delay	Multiplied by 2N (poll + response for each)
Failed terminals	Timeout delays add significant overhead

Historical Context

Advantages and Disadvantages of Polling

Advantages

•No collisions — Channel time is never wasted on collision resolution
•Deterministic latency — Maximum wait time is bounded and predictable
•Guaranteed fairness — Every station is polled according to schedule
•Priority support — Easy to implement differentiated service levels
•Centralized control — Simple network management and troubleshooting
•Works with any topology — Star, tree, bus, or multipoint
•No hidden terminal problem — Primary controls all access

Disadvantages

•Polling overhead — Every station polled consumes channel time, even with nothing to send
•Single point of failure — Primary station failure halts entire network
•Latency increases with stations — More stations = longer cycle time
•Inefficient for sparse traffic — Most polls may return NAK
•Bandwidth waste — Poll/NAK exchanges use channel without carrying useful data
•Scalability limits — Cycle time grows linearly with N
•Response time depends on position — Station polled first gets faster service than last

When to Use Polling vs. Contention
Criterion	Favor Polling	Favor Contention (CSMA)
Traffic pattern	Continuous, regular	Bursty, irregular
Latency requirements	Bounded, guaranteed	Best-effort acceptable
Number of stations	Moderate (< 50)	Large (100+)
Data availability	Most stations have data	Few stations active at once
Failure tolerance	Single point OK	Distributed resilience needed
Network management	Centralized preferred	Autonomous stations preferred
Real-time constraints	Hard real-time	Soft or no real-time

Real-World Applications of Polling

Despite being considered "old-fashioned" compared to modern switched networks, polling remains critically important in several domains where its deterministic properties are essential.

Critical Polling Applications

•Industrial Control Systems (SCADA) — Supervisory Control and Data Acquisition systems poll PLCs (Programmable Logic Controllers) and RTUs (Remote Terminal Units) for sensor data. Protocols like Modbus and DNP3 use polling extensively for deterministic data collection.
•Satellite Communication — Ground stations poll satellite terminals in VSAT networks. The long propagation delay (250ms+ round-trip) makes contention impractical; polling provides orderly access to the expensive satellite bandwidth.
•Avionics Networks — Aircraft data buses like ARINC 429 and MIL-STD-1553 use polling for safety-critical communication between flight computers, sensors, and actuators. Deterministic timing is mandatory for flight control.
•Building Automation — BACnet (Building Automation and Control Networks) supports polling for HVAC, lighting, and access control systems where reliable, scheduled data collection matters more than throughput.
•Point-of-Sale Terminals — Retail networks poll POS terminals for transaction data. The centralized controller aggregates sales data and pushes price updates to terminals.
•Medical Devices — Patient monitoring systems poll bedside monitors for vital signs. Guaranteed latency ensures critical alarms are never delayed by network contention.

Case Study: Modbus Polling in Industrial Control

Modbus Master (SCADA Server)
    ↓ Query (Read Holding Registers)
Modbus Slave (PLC, Address 01)
    ↓ Response (Register values: temperature, pressure)
Modbus Master
    ↓ Query (Read Input Status)
Modbus Slave (RTU, Address 02)
    ↓ Response (Digital inputs: switch states)
    
Typical polling cycle: 100ms - 1000ms
Maximum slaves per network: 247 (Modbus limit)

Enduring Relevance

Summary: Polling Fundamentals

We've explored polling as a fundamental controlled access protocol. Let's consolidate the key concepts:

Key Takeaways

•Centralized coordination — A primary station explicitly grants transmission permission to secondary stations, eliminating collisions entirely.
•Poll/Select protocol — Poll operations retrieve data from secondaries; Select operations send data to secondaries. Both require explicit handshaking.
•Deterministic latency — Maximum access delay is bounded by the polling cycle time, making polling ideal for real-time systems.
•Round-robin fairness — Basic polling treats all stations equally; priority polling provides differentiated service.
•Overhead trade-off — The price of determinism is polling overhead—every station must be polled even if it has nothing to send.
•Single point of failure — The primary station is critical; its failure halts the network.
•Enduring applications — Industrial control, avionics, satellite communication rely on polling for guaranteed access timing.

What's Next:

Page Complete

1 / 5