DEV Community

Lemon Tern
Lemon Tern

Posted on • Originally published at cardsharing.site

Optimizing Cardsharing Latency: TCP vs UDP in DVB Satellite Systems

#dvb #networking #latency #protocols

Optimizing Cardsharing Latency: TCP vs UDP in DVB Satellite Systems

Your card sharing setup works perfectly until it doesn't. Random black screens, channel switch delays, picture breakup during live events — these aren't bandwidth problems, they're latency issues. If you're managing CCcam/OScam servers or building DVB applications, understanding the protocol differences between TCP and UDP can dramatically improve your users' viewing experience.

Why Latency Dominates Bandwidth in Card Sharing

Here's what most developers miss: an ECM (Entitlement Control Message) request is only ~200 bytes. You could theoretically run card sharing over a 56k modem. The killer isn't throughput — it's round-trip time.

Every encrypted channel follows this cycle:

  1. Client sends ECM to server (~160-220 bytes)
  2. Server feeds ECM to physical smart card
  3. Card returns Control Word (CW) (~8 bytes)
  4. Client receives CW before decoder's timeout

The entire cycle must complete before the CW expires (typically 5-10 seconds for DVB encryption). Your decoder has roughly one CW period of buffer, so response latency directly impacts video stability.

Acceptable Latency Thresholds

Response Time Viewing Quality Channel Zapping
<300ms Perfect Near-instant
300-500ms Good Slight delay
500-800ms Acceptable Noticeable delay
>800ms Freezes/Black screens Unacceptable

TCP vs UDP: The Technical Breakdown

TCP (Transmission Control Protocol)

Pros:

  • Guaranteed packet delivery
  • Automatic retransmission on packet loss
  • Connection persistence reduces handshake overhead
  • Better for unreliable networks

Cons:

  • Higher latency due to connection establishment (3-way handshake)
  • Cumulative retransmission delays on packet loss
  • More overhead per packet 
TCP handshake overhead:
Client -> Server: SYN (20ms)
Server -> Client: SYN-ACK (20ms)
Client -> Server: ACK (20ms)
Total before data transmission: ~60ms
Enter fullscreen mode Exit fullscreen mode

UDP (User Datagram Protocol)

Pros:

  • Minimal protocol overhead
  • No connection setup delay
  • Lower latency for single request-response cycles
  • Better for time-sensitive applications

Cons:

  • No guaranteed delivery
  • Application must handle retransmissions
  • Packets can arrive out of order
  • Vulnerable to packet loss on congested networks 
UDP transmission:
Client -> Server: ECM (5ms)
Server -> Client: CW (5ms)
Total: ~10ms (no handshake)
Enter fullscreen mode Exit fullscreen mode

Practical Configuration Recommendations

When to Use TCP

Use TCP for:

  • High-latency satellite connections (>150ms baseline)
  • Unstable/congested networks (>2% packet loss)
  • Server-to-smart-card communication (reliability critical)
  • Geographic redundancy scenarios

OScam TCP Configuration:

[server]
http_port = 8080
listenip = 0.0.0.0
port = 10001  ; TCP port for cardsharing
Enter fullscreen mode Exit fullscreen mode

When to Use UDP

Use UDP for:

  • Low-latency terrestrial networks (<50ms baseline)
  • Stable connections with <1% packet loss
  • High-volume client connections (scalability)
  • Real-time streaming applications

CCcam UDP-Optimized Setup:

NETWORK_SOCKET = UDP
ECM_TIMEOUT = 3000
CW_WAIT = 2000
MAX_RETRIES = 2
Enter fullscreen mode Exit fullscreen mode

Diagnostic Steps

  1. Measure baseline latency: 
   ping -c 10 <cardsharing-server>
Enter fullscreen mode Exit fullscreen mode

Look for packet loss percentage and standard deviation

  1. Monitor ECM response times:
    Enable debug logging in OScam/CCcam to track actual response times

  2. Test both protocols:
    Run parallel TCP and UDP instances, monitor freeze frequency

  3. Check receiver logs:
    Most DVB receivers log ECM failures — correlate with protocol switches

Key Takeaways

  • Latency matters more than bandwidth for card sharing stability
  • UDP shines on stable, low-latency connections (terrestrial, local networks)
  • TCP wins on unreliable links (satellite, congested WAN)
  • Hybrid approaches (UDP with smart retry logic) offer best of both worlds
  • Test empirically — your specific network conditions will determine the optimal choice

The best protocol choice depends on your network topology, not on theory. Measure, test, and optimize based on real metrics.

Want the complete technical guide with advanced tuning parameters, packet analysis, and server benchmarks? Check out the full cardsharing latency optimization guide.

Top comments (0)