Skip to content

feat(transport): adopt v3 WebSocket subprotocol#124

Closed
infinia-yzl wants to merge 1 commit into
flametime:0.2from
infinia-yzl:upstream-v3-protocol
Closed

feat(transport): adopt v3 WebSocket subprotocol#124
infinia-yzl wants to merge 1 commit into
flametime:0.2from
infinia-yzl:upstream-v3-protocol

Conversation

@infinia-yzl

Copy link
Copy Markdown

Summary

Flips the WebSocket subprotocol identifier from v2.bsatn.spacetimedb to v3.bsatn.spacetimedb to opt into the v3 transport introduced in clockworklabs/SpacetimeDB 2.2.0 (PR clockworklabs/SpacetimeDB#4761).

Why this works as a one-line change

v3 is not a new message schema. It reuses the v2 ClientMessage / ServerMessage values as-is. The only on-the-wire change is that a single WebSocket payload may now contain one OR more BSATN-encoded v2 messages concatenated back to back. Senders may coalesce as they please; receivers must decode sequentially until end-of-buffer.

The existing BSATNDeserializer.process_bytes_and_extract_messages already loops decoding messages from the incoming buffer until empty, so the receive-side semantics work for free. The send side keeps sending one logical message per frame, which is still valid v3 — a future optimization is to coalesce client-side sends, deliberately not part of this PR.

Verification

Server handshake responds with 101 Switching Protocols + sec-websocket-protocol: v3.bsatn.spacetimedb:

curl -s -i -N \
  -H "Connection: Upgrade" -H "Upgrade: websocket" \
  -H "Sec-WebSocket-Version: 13" \
  -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
  -H "Sec-WebSocket-Protocol: v3.bsatn.spacetimedb" \
  -H "Authorization: Bearer <token>" \
  http://localhost:3333/v1/database/<name>/subscribe

End-to-end verified in a downstream project via integration tests against a live SpacetimeDB 2.2.0 dev DB:

Test plan

  • Existing test-server-module flows continue to pass against a 2.2 server
  • No regressions in the procedure / reducer / subscription codepaths (none expected — schema is unchanged)
  • Hand-test connect-and-subscribe in any consuming project

Notes for reviewers

  • Not adding client-side outbound batching in this PR. Server batches naturally during high-throughput periods; client-side batching is a separate optimization that's worth measuring before adding complexity.
  • The version: String = "v1" on line 10 is the HTTP path prefix (/v1/database/...), unrelated to the WebSocket subprotocol version — leaving untouched.

🤖 Generated with Claude Code

clockworklabs/SpacetimeDB 2.2.0 introduced a v3 WebSocket transport
(PR #4761) with subprotocol identifier `v3.bsatn.spacetimedb`. v3
keeps the v2 ClientMessage / ServerMessage schema intact — the only
on-the-wire change is that a single WebSocket payload may contain
one OR more BSATN-encoded v2 messages concatenated back to back.
Senders may coalesce as they please; receivers decode sequentially
until end-of-buffer.

The existing BSATNDeserializer.process_bytes_and_extract_messages
already loops decoding messages from the incoming buffer until
empty, so the receive-side semantics work for free on v3. The send
side keeps sending one logical message per frame, still valid v3.

Verified manually against a SpacetimeDB 2.2.0 server:
  curl -s -i -N \
    -H "Connection: Upgrade" -H "Upgrade: websocket" \
    -H "Sec-WebSocket-Version: 13" \
    -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
    -H "Sec-WebSocket-Protocol: v3.bsatn.spacetimedb" \
    -H "Authorization: Bearer <token>" \
    http://localhost:3333/v1/database/<name>/subscribe
returns `HTTP/1.1 101 Switching Protocols` with
`sec-websocket-protocol: v3.bsatn.spacetimedb` and proceeds with
normal message dispatch (IdentityToken delivered immediately).

Also verified end-to-end via integration tests in a downstream
project: anonymous connect + subscribe + iter() round-trip, plus an
overlapping-subscription audit (subscribe narrow, then subscribe
wide; assert on_insert fires exactly once for the new row and zero
additional times for the already-cached row — analogous to the
Unreal SDK fix in #4903).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant