Multiplayer · In depth

SessionRegistry

Bounded, expiring ownership records for application-issued opaque session IDs. Redweb handles takeover and expiry; the application owns credential issuance and payload validation.

Explain it like I’m five

The simple mental model

SessionRegistry is a numbered coat-check ticket. A reconnecting player presents the ticket and safely takes ownership of the stored session from an older connection.

When it fits

When should I use it?

Use it for short reconnect windows, controlled connection takeover, and small pieces of application-issued resumable state.

A practical API pattern

Follow the example

This pattern explains the named API. Application classes, credentials, and assets may need to be supplied; use a complete recipe for a runnable starting point.

Read this article as Markdown

JavaScript

class MatchRoute extends SocketRoute {
  constructor() {
    super({
      path: '/match',
      handlers: [JoinMatchHandler, MoveMatchHandler, ResumeMatchHandler],
      sessions: { ttlMs: 30000, maxSessions: 10000 },
    })
  }
}

1
The application creates an opaque session ID and stores bounded state against the connected socket.
2
After a disconnect, the record remains available for the configured TTL.
3
Resume atomically transfers ownership and closes the former owner if it is still connected.

Surface area

Methods and members

socket.createSession(sessionId, data)

Creates a bounded application-issued session owned by the current connection.

socket.resumeSession(sessionId)

Atomically transfers ownership, closes the former owner, and returns stored data.

stop()

Stops the one route-level sweep timer and clears every retained record.