Why does Anycast need extra thought for an online poker room?

Anycast steers each packet to the nearest announcing site, and routes can change during a session. A web page tolerates that because each request is independent. A poker client keeps a long-lived connection to a table server, so a route change can land an existing session on a site that has never seen it. The design has to decide what happens to that player mid-hand.

Should table state live at every Anycast site?

Usually not. The game server that holds a hand in progress is the authority and typically sits in one place. Anycast sites more often terminate the connection, absorb attack traffic and forward clean traffic to the game server. Decide explicitly which layer holds session state, and write down how a client re-attaches if its entry site changes.

What should happen to a player when their entry site changes mid-hand?

The hand should resolve by game rules, not by network luck. The client reconnects, the game server recognises the seat, and the player sees the current state. If the design cannot do that, the operator needs a documented rule for timeouts, auto-actions and disputed hands, agreed with game operations and compliance.

Does a private Anycast network replace DDoS protection for a poker room?

No. It gives you your own announced prefixes and routing control, which makes steering and absorbing attack traffic more flexible. Capacity, scrubbing and the response procedure still need to be specified and tested. Treat it as the routing layer on which mitigation sits.

How should we test the design before a major tournament?

Run an authorised, scoped test in a quiet window that drains a site, moves traffic and withdraws a prefix while test players are seated, with written abort signals. Observe reconnect behaviour, timers and the support queue. Do not run unauthorised load against production or a provider's shared network.

Private Anycast for an Online Poker Room: Live Sessions

The short answer

A poker client keeps a long-lived connection to a table server, so an Anycast route change can strand a player mid-hand. A private Anycast design for a poker room must say where session state lives, how a client re-attaches after its entry site changes, how timers behave during that gap, and who may withdraw a site during a tournament. Write those answers down before choosing a provider.

Who this is for

This is for a CTO, head of infrastructure or network lead at a poker operator, or at a casino or sportsbook running a poker product, who is deciding whether to run a private Anycast network. The general buyer question of who holds the ASN, the address blocks and the exit terms is covered in private Anycast network provider: who holds the ASN, IP blocks and exit terms. The cut-over mechanics for a casino are in Anycast cut-over runbook for an online casino. This article covers what a poker room adds: a connection that is expected to survive.

Why a stateless Anycast mental model breaks

Anycast announces the same address from several sites and lets routing send each client to a nearby one. For a website that serves independent requests, that is close to free: if the route shifts between two requests, the second request is simply answered elsewhere. A poker room does not behave like that. The client opens a connection and keeps it for the whole session, and the table server holds the state of hands in progress for several players at once.

Two consequences follow. First, a route change in the middle of a session can send the player's next packets to a different site than the one that terminated the connection. Depending on how your sites are built, that connection is reset, stalls or is quietly proxied. Second, the moment at which this is most likely to matter is also the moment players care most about: a tournament with a published schedule and prize pool, when many players are connected and a stalled hand has consequences.

A tournament desk with a row of seat cards, one card turned over and glowing lime-green beside a phone handset and a closed logbook — The question Anycast raises for poker is asked at the tournament desk: what happens to the player whose seat card just turned over.

Where does the session live?

Before touching routing, decide which layer owns which state. A workable split has three layers.

Edge sites announce your prefixes, terminate the connection, absorb unwanted traffic and forward what remains. They should hold as little game state as possible.
A session layer that can recognise a returning client and attach it to the seat it already holds.
The game server, which is the authority for table state and tournament progress and typically sits in one place.

If the edge sites keep game state, a route change becomes a state-transfer problem. If they hold none, it becomes a reconnect problem, which is far easier to reason about and to test. Either way, write which layer is authoritative for each item: seat, stack, timer, pending action, tournament clock.

The route-change decision table

Use this as a working matrix to fill in with your own architecture. It is a structure, not a performance claim.

Event	What the player experiences	Design question	Owner
Routing shifts a client to another site mid-hand	Stall or disconnect, then reconnect	How does the client re-attach to the same seat?	Platform engineering
A site is drained for maintenance	Connections move or reset	Is draining allowed while a tournament is running?	Infrastructure with game operations
A site is withdrawn during an attack	Some players reconnect through other sites	Who may withdraw, and what does the player see?	Security with game operations
A prefix is withdrawn entirely	Players cannot reach the room	What is the published state of the tournament clock?	Game operations with compliance
The provider reroutes upstream	Latency or path changes	Do you get notice, and can you refuse during events?	Infrastructure and provider
Return to normal after an event	Connections drift back	Is there a rule against flapping while hands are live?	Network lead

The last column is the useful one. In most real delays the technical fix is not what costs time; it is people debating who is allowed to withdraw a site while a tournament is running.

Timers and the gap

Poker has action timers: a player who does not act in time is folded or checked automatically. A reconnect gap interacts with that timer in ways a web team will not expect. Decide, with game operations, what the room does while a player's connection is re-attaching: whether a timer bank or grace period applies, whether an automatic action is allowed during a known routing event, and how a hand that was affected is documented for a dispute. These are rules the operator owns, and they should be agreed before the network design is finalised, not discovered during the first tournament after cut-over.

What the provider should state in writing

A provider that can announce your prefixes is not automatically one that understands long-lived sessions. Ask for these in the contract or design document, and compare the answers with the questions in the buyer guide.

Who controls the announcements, and whether you can withdraw or prepend without a ticket during an event.
How draining works: whether existing connections are allowed to finish, are reset, or are proxied to another site.
Notice and freeze windows: advance notice of upstream or site changes, and a way to declare your tournament calendar as a no-change period.
Attack handling: what is absorbed at the edge, what is forwarded, and what the provider does with a flood that threatens a site. The wider attack-side view is in private Anycast and shared DDoS protection for a crypto exchange, which shares the shared-tenancy concern.
Observability: per-site connection counts, reset rates and the ability to see which site a given client reached, with log retention you can use after an incident.
Exit terms: what happens to your prefixes and your routing if you leave, so the room is not locked into a layer it cannot replace mid-season.

Prove it with a controlled drill

A diagram cannot show how a reconnect feels at the table. The most useful single exercise is a scoped, authorised drill in a quiet window: seat test players, drain a site, move traffic, withdraw a prefix and bring it back, while recording what each test client sees. Agree written abort signals and the people who can call a stop. Include game operations so that timers, auto-actions and the support queue are part of the observation. This is the same discipline as an authorised DDoS stress test, and the poker-specific continuity questions are in DDoS stress testing an online poker room's tournaments. Never run unauthorised load against production or against a provider's shared network.

Where Anycast does not help

Anycast changes where traffic enters your network; it does not change what happens inside it. It does nothing about a compromised administrator account, a flaw in table logic or a log gap. Those are covered in penetration testing an online poker room and managed SOC for an online poker room. Nor does it settle fairness: this article does not cover collusion or bot detection, and nothing here certifies the shuffle or the random-number generator, which is accredited laboratory work. For the mitigation policy that sits on top of this routing layer, see DDoS protection for an online poker room.

Limitations

This article is not legal or regulatory advice. It does not state what any licensing authority or testing laboratory requires of a poker operator regarding availability, session handling or disputed hands; check your licence terms and local rules. It uses no external statistics, latency figures or incident case studies. The decision table is a starting position and needs adjusting to your architecture, provider and tournament calendar. How much of this you control depends on whether you self-host or run on a network operator's platform, and you can only act on systems you own or have written permission to touch.

Decision and next step

If you can say where a poker session lives, how a client re-attaches after a route change, and who may withdraw a site during a tournament, you are ready to specify a private Anycast design. If not, those answers are the first deliverable. Request a private Anycast quote and we will turn your tournament calendar and architecture into a design brief and a drill plan.

Sources and review

General Anycast and connection behaviour follows public references: Cloudflare Learning Center on Anycast and RFC 4786, Operation of Anycast Services, read 2026-11-06; check the current versions. AnySec prepared the poker-specific decision table from the public structure of poker operations; no AnySec-original statistics are used. Author: AnySec Engineering. Published 2026-11-06; last reviewed 2026-11-06.

Frequently asked questions

Why does Anycast need extra thought for an online poker room?: Anycast steers each packet to the nearest announcing site, and routes can change during a session. A web page tolerates that because each request is independent. A poker client keeps a long-lived connection to a table server, so a route change can land an existing session on a site that has never seen it. The design has to decide what happens to that player mid-hand.
Should table state live at every Anycast site?: Usually not. The game server that holds a hand in progress is the authority and typically sits in one place. Anycast sites more often terminate the connection, absorb attack traffic and forward clean traffic to the game server. Decide explicitly which layer holds session state, and write down how a client re-attaches if its entry site changes.
What should happen to a player when their entry site changes mid-hand?: The hand should resolve by game rules, not by network luck. The client reconnects, the game server recognises the seat, and the player sees the current state. If the design cannot do that, the operator needs a documented rule for timeouts, auto-actions and disputed hands, agreed with game operations and compliance.
Does a private Anycast network replace DDoS protection for a poker room?: No. It gives you your own announced prefixes and routing control, which makes steering and absorbing attack traffic more flexible. Capacity, scrubbing and the response procedure still need to be specified and tested. Treat it as the routing layer on which mitigation sits.
How should we test the design before a major tournament?: Run an authorised, scoped test in a quiet window that drains a site, moves traffic and withdraws a prefix while test players are seated, with written abort signals. Observe reconnect behaviour, timers and the support queue. Do not run unauthorised load against production or a provider's shared network.