Best Practices

Follow these recommendations to get the most reliable, lowest-latency shred delivery from ShredStream.com.

---

UDP Buffer Sizing

The single most impactful configuration change is increasing your UDP receive buffer. ShredStream.com can deliver thousands of shreds per second, and the default OS buffer is far too small.

Set a minimum of 25 MB:

# Apply immediately (Linux)
sudo sysctl -w net.core.rmem_max=26214400
sudo sysctl -w net.core.rmem_default=26214400

# Persist across reboots — add to /etc/sysctl.conf
net.core.rmem_max=26214400
net.core.rmem_default=26214400

Then request the buffer size in your application code:

Python

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 25 * 1024 * 1024)
sock.bind(("0.0.0.0", 9000))

Rust

C

Note on Linux buffer doubling: Linux internally doubles the buffer value you pass to setsockopt(). When you request 25 MB, the kernel allocates 50 MB (half for data, half for kernel bookkeeping). The rmem_max sysctl must be at least 25 MB for the request to succeed.

---

Monitoring

Active monitoring helps you detect issues before they affect your application.

Key Metrics to Track

Metric	Healthy Range	How to Check
Shred rate	500 -- 5,000/sec	Count packets per second in your receiver
Kernel drops	0	ss -u -a -n or netstat -su
Slot gap vs RPC	< 2 slots	Compare latest shred slot to getSlot on an RPC node
CPU usage	< 70% on receive core	htop, top, or your monitoring stack
Memory usage	Stable, no growth	Watch for buffer leaks over time

Monitoring Example

Check kernel-level UDP drops in real time:

# Watch UDP receive errors (Linux)
watch -n 1 'cat /proc/net/snmp | grep Udp:'

A simple Python monitoring wrapper:

import socket
import time

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 25 * 1024 * 1024)
sock.bind(("0.0.0.0", 9000))

count = 0
last_report = time.time()

while True:
    data, addr = sock.recvfrom(2048)
    count += 1

    now = time.time()
    if now - last_report >= 10:
        rate = count / (now - last_report)
        print(f"Shred rate: {rate:.0f}/sec")
        count = 0
        last_report = now

---

Redundancy and Failover

For production systems where uptime is critical, plan for redundancy.

• Multi-region streams -- Create streams in two or more regions. If one region experiences an issue, the other continues delivering. Deduplicate incoming shreds by their signature to avoid processing the same data twice.

• Hot standby servers -- Run a second receiver on a different machine. Both can listen simultaneously; your processing pipeline deduplicates downstream.

• IP failover -- Use a floating IP or Elastic IP that can be reassigned quickly. Update the stream destination from the dashboard when you move traffic to a standby server.

With a Pro or Ultra plan, you have multiple connections available -- use them across regions for built-in redundancy.

---

Error Handling

Not every UDP packet will be a valid shred. Build defensive checks into your receiver.

1. Validate packet size -- Every ShredStream.com shred is exactly 1,203 bytes. Discard packets of any other length immediately:

   data, addr = sock.recvfrom(2048)
   if len(data) != 1203:
       continue  # not a valid shred

2. Validate the variant byte -- The byte at offset 0x40 (64) of a valid shred is 0xA5. Reject anything else:

   if data[0x40] != 0xA5:
       continue  # invalid variant

3. Skip invalid packets silently -- Do not log every invalid packet at a high verbosity level. During normal operation, occasional stray packets are expected. Log a counter or periodic summary instead.

---

Reconnection Strategies

UDP is connectionless, so there is no "disconnect" event. You need to detect data loss proactively.

• Idle timeout detection -- If no shreds arrive for 30 seconds, something is likely wrong. Trigger an alert or begin diagnostics automatically.

• Health checks via the dashboard -- Poll the ShredStream.com API or check the dashboard to confirm your stream status is still active.

• Exponential backoff for retries -- If you need to restart your listener or re-query the API, use exponential backoff (1s, 2s, 4s, 8s, up to 60s max) to avoid overwhelming your system or the API.

---

Performance Tips

When every microsecond matters, these optimizations help you process shreds as fast as possible.

• CPU pinning -- Lock your receive thread to a specific core using taskset to avoid context switches:

  taskset -c 0 ./your_receiver

• Dedicated NIC queue (RSS) -- Configure Receive Side Scaling to steer UDP traffic for your port to a single CPU core, reducing lock contention.

• Avoid allocations in the hot path -- Pre-allocate your receive buffers. Do not create new objects or allocate memory on every recvfrom() call.

• Separate receive and processing threads -- Use a dedicated thread (or async task) that does nothing but read from the socket and push packets into a lock-free queue. A second thread handles parsing, validation, and business logic.

• Consider recvmmsg() -- On Linux, recvmmsg() reads multiple UDP packets in a single system call, significantly reducing syscall overhead at high packet rates:

  // Receive up to 64 packets at once
  struct mmsghdr msgs[64];
  struct iovec iovecs[64];
  // ... initialize buffers ...
  int received = recvmmsg(sockfd, msgs, 64, MSG_WAITFORONE, NULL);

---

Summary Checklist

• UDP receive buffer set to 25 MB or higher

• Socket bound to 0.0.0.0, not 127.0.0.1

• Monitoring shred rate and kernel drops

• Packet size validated (1,203 bytes) and variant byte checked (0xA5)

• Idle timeout detection in place (30 seconds)

• Receive thread isolated from processing logic

• Redundant streams in multiple regions (for production workloads)