Sessões e reconexão

Um servidor remoto pode atender muitos clientes ao mesmo tempo. Para manter cada conversa organizada, ele precisa de uma forma de lembrar quem é quem: isso é uma sessão. 🧠

Uma sessão começa durante a negociação de initialize. O servidor cumprimenta o novo cliente e configura o estado que acompanhará essa conexão.

Para identificar uma sessão, o servidor retorna um cabeçalho exclusivo Mcp-Session-Id na resposta de inicialização. Pense nele como a senha de retirada do cliente.

Em cada solicitação posterior, o cliente inclui esse mesmo id nos cabeçalhos. O servidor o lê e sabe exatamente a qual sessão essa chamada pertence.

Tudo o que o servidor deve lembrar entre chamadas, como um usuário conectado ou um cursor, fica associado à sessão. Clientes diferentes nunca veem os dados uns dos outros.

Nem todo servidor precisa de memória. Um servidor sem estado trata cada solicitação de forma independente e não emite um ID de sessão, o que simplifica muito a escalabilidade.

Na internet, as conexões falham: um fluxo pode morrer no meio da resposta. Um bom transporte precisa lidar com uma conexão interrompida sem perder toda a sessão. 📡

Lembra dos IDs de evento SSE? O cliente se reconecta e envia o Last-Event-ID que recebeu, pedindo ao servidor para reenviar apenas o que veio depois.

Como cada evento recebeu um número, a repetição é precisa. O cliente não perde nada nem vê algo duas vezes, portanto uma falha momentânea nunca corrompe o resultado.

Quando termina, um cliente pode enviar um HTTP DELETE ao endpoint com o ID da sessão. O servidor libera o estado e mantém a memória organizada.

Juntas, as sessões e a reconexão fazem um servidor remoto parecer confiável: ele lembra seu contexto e sobrevive a redes instáveis com elegância. ✨

Um ID de sessão, definido na inicialização e enviado de volta, associa cada cliente ao seu estado. Os eventos SSE numerados permitem retomar de forma limpa um fluxo interrompido, sem lacunas. 🎉