search

clockworklabs / SpacetimeDB

Multiplayer at the speed of light
https://spacetimedb.com
Other
4.15k stars 100 forks source link

Make client timeout delay adjustable #327

Open SteveBoytsun opened 8 months ago

SteveBoytsun commented 8 months ago

Right now all clients timeout after a hard-coded time interval (I believe it's somewhere around 15 seconds). This makes it more difficult to debug projects that require constant connection without making sure auto-reconnecting is handled properly (which is non-trivial and can often change state mid-debugging). Making timeout adjustable (or adding an option to disable it altogether) would make debugging much easier. The value either be server-wide or configurable per database.

kim commented 8 months ago

By client, do you mean subscribed SDK clients, or calling certain HTTP endpoints (e.g. spacetime publish)?

If it’s the former, it seems more like a bug. If it’s the latter then yes, you beat me to it.

cloutiertyler commented 7 months ago

I would echo what @kim is asking, @SteveBoytsun

kim commented 7 months ago

I believe @SteveBoytsun is referring to the WebSocket timeout, which closes the connection after 60s of inactivity (ie. not even PONG frames received).

I would consider it a bit hairy to allow clients to prolong this period, as WebSockets consume resources even if idle. The connection is also tied to the connect/disconnect reducers, so it would become difficult for a module to assume anything about the liveness of connected clients.

We could certainly make the timeout much larger for standalone, but not sure if that'd help. If the timeout in fact occurs at 15s instead of 60, we should investigate.

SteveBoytsun commented 7 months ago

Yes, I'm referring to WebSocket timeout. I know it can create problems if everyone uses large timeouts, but it's very useful for development (ex. hitting a breakpoint, inspecting data structures for a while (maybe a few minutes), and getting back into the game to see how state changes). Perhaps this is something that can be exposed only for self-hosted instances?

After digging into it, 15s timeout seems to be something on our side, so please disregard that number. The actual request still stands though.

kim commented 7 months ago

Turns out to be more invasive than anticipated, because all the relevant bits are in client-api and thus all implementations would need to support it. We will probably want to formulate it as some generic, extensible configuration object.