Skip to content

GameDispo

Security & DDoS protected transit

How GameDispo places Minecraft and FiveM traffic behind protected transit and an in-house edge filter — the same layered model many providers describe as “scrub first, then filter locally.”

The idea (industry framing)

Serious game-hosting and network operators rarely rely on a single box firewall. The common pattern is two layers:

  1. Protected / scrubbed transit — announce or deliver prefixes through a mitigation-capable transit or scrubbing network so large volumetric floods are absorbed or reduced before they saturate the last mile into the game node.
  2. Local high-performance filtering — keep your own logic at the edge (often XDP / eBPF on the NIC) so remaining junk, protocol abuse, and application-shaped floods can be dropped at line rate without paying full kernel networking cost for every packet.

That split exists because upstream scrubbing is built for scale, while game UDP/TCP sessions need tighter, stateful, application-aware decisions that generic volumetric filters alone often miss. Providers and network engineers describe this as clean traffic delivery into a customer or host edge that still runs its own filter stack.

What GameDispo runs

We implement that model as DDoS protected transit on every standard Minecraft and FiveM plan:

  1. Upstream scrubbing via CosmicGuard (AS215703) — inbound game traffic is scrubbed on CosmicGuard’s mitigation-capable transit path. Large volumetric floods are reduced upstream so they are less likely to overwhelm the path into our Virginia edge.
  2. Inline native XDP (in-house) — on our NIC we run our own native XDP program inline, before the normal receive path. Unwanted packets can be dropped early (XDP_DROP); allowed flows continue (XDP_PASS). This is the same class of early-driver filtering operators mean when they talk about XDP/eBPF at line rate.
  3. Stateful / punched session handling — the XDP path keeps flow state and punched allowances for legitimate game sessions, so real players are not treated like anonymous flood sources after they have established a valid session.
  4. Application-specific filtering — on top of volumetric scrubbing, we apply game-oriented checks (ports, protocol shape, rates, and related state) aimed at traffic that bypasses or survives upstream filtering. The goal is to handle that remainder on the edge at line rate instead of letting it land on your game process.

Packet path

  1. Player / internet traffic is destined for your service
  2. Traffic reaches CosmicGuard upstream scrubbing on AS215703
  3. Scrubbed (cleaner) traffic is delivered toward our game edge
  4. Frames hit the NIC driver on the game node
  5. Our native XDP program runs — stateful / punched + application-specific filters
  6. XDP_DROP or XDP_PASS into the normal stack and, if passed, your game process

In short: CosmicGuard handles the transit-scale scrub; our XDP layer is the local, game-aware filter for what still arrives. We do not publish unverified packet-per-second, “Tbps,” or nanosecond marketing numbers.

Why both layers

Upstream scrubbing alone can still leave protocol-aware or lower-rate abuse that looks enough like game traffic to pass a volumetric filter. Local XDP alone cannot absorb multi-gigabit floods that fill the uplink before packets ever reach the NIC. Combining protected transit with an inline native filter is how many modern stacks address both problems — capacity upstream, precision at the edge.

Limits

Mitigation reduces risk; it does not promise every attack leaves you online, and it is not a challenge or “unbootable” guarantee. Coverage and credits are defined in the SLA. Using protection to bait or advertise attacks is prohibited under the AUP.

DDoS protected transit is included on standard Minecraft and FiveM plans — not a separate upsell SKU.

Get a server Back to home