Skip to content

Latest commit

 

History

History
14 lines (10 loc) · 1.6 KB

Resuming_a_connection.md

File metadata and controls

14 lines (10 loc) · 1.6 KB

Resuming a connection

There are two circumstances under which resuming a connection is necessary. The first is if a disconnection happens. The second is if the client is instructed to migrate to a new endpoint via a migrate message. Both situations can be handled the same way.

When initially connecting to a Ribbon, the Ribbon will send a hello message to the client containing two critical pieces of information—the socket id (id) and the resume token (resume). These should be stored for use in the event that resuming is necessary.

After reconnecting to a Ribbon, whether via a new endpoint or with the same one, the client must send a resume message with the socket id (socketid) and resume token (resumetoken). After this, the client should send a hello message with the most recent id'd messages sent to the Ribbon so it can handle the ones it hasn't seen because the client was disconnected at the time. This is to ensure sync. After this, the server will send a hello message back with the its own most-recent id'd messages for the client to sort through. The official TETR.IO client sends approximately enough messages to cover the last 30 seconds, clamped between 100 and 2000. The pseudocode that calculates this every time a new messages is sent is shown below.

if (lastSentId is evenly divisible by 100) {
    let messagesPerSecond = 1000 / (seconds since last recalculation) / 100;
    let cacheSize = max(100, min(30 * messagesPerSecond, 2000));
}