SessionRegistry

Documentation for Redweb 0.13.2. Install that exact version when following these examples.

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

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 should I use it?

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

Follow the example

This API pattern illustrates the named surface; it may require application-owned classes, credentials, or assets. Start from a complete recipe for a runnable application.

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.

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.

What should I watch for?

Session IDs are credentials: issue them securely, never trust client-selected identity, limit stored data, and persist important state outside this in-memory registry.