Sesje i ponowne połączenia

Zdalny serwer może jednocześnie obsługiwać wielu klientów. Aby prawidłowo rozdzielać rozmowy, musi pamiętać, kto jest kim — do tego służy sesja. 🧠

Sesja rozpoczyna się podczas uzgadniania initialize. Serwer wita nowego klienta i konfiguruje stan, który będzie śledził to połączenie.

Aby oznaczyć sesję, serwer zwraca unikalny nagłówek Mcp-Session-Id w odpowiedzi na initialize. Można myśleć o nim jak o bilecie klienta.

W każdym kolejnym żądaniu klient umieszcza ten sam id w nagłówkach. Serwer odczytuje go i dokładnie wie, do której sesji należy dane wywołanie.

Wszystko, co serwer powinien pamiętać między wywołaniami, na przykład zalogowanego użytkownika lub kursor, jest powiązane z sesją. Różni klienci nigdy nie widzą swoich danych.

Nie każdy serwer potrzebuje pamięci. Serwer bezstanowy traktuje każde żądanie niezależnie i nie wydaje identyfikatora sesji, co znacznie upraszcza skalowanie.

W internecie połączenia mogą się zrywać: strumień może zakończyć się w połowie odpowiedzi. Dobry transport musi obsłużyć zerwane połączenie bez utraty całej sesji. 📡

Pamiętają Państwo identyfikatory zdarzeń SSE? Klient łączy się ponownie i wysyła znany sobie nagłówek Last-Event-ID, prosząc serwer o odtworzenie tylko tych zdarzeń, które nastąpiły później.

Ponieważ każde zdarzenie miało numer, odtwarzanie jest precyzyjne. Klient niczego nie pomija i nie otrzymuje niczego dwukrotnie, więc chwilowa awaria nie uszkadza wyniku.

Gdy klient zakończy pracę, może wysłać żądanie HTTP DELETE do endpointu wraz z identyfikatorem sesji. Serwer zwalnia stan i utrzymuje porządek w pamięci.

Sesje i ponowne łączenie razem sprawiają, że zdalny serwer wydaje się niezawodny: pamięta kontekst i sprawnie radzi sobie z niestabilnymi sieciami. ✨

Identyfikator sesji, ustawiony podczas inicjalizacji i odsyłany w kolejnych żądaniach, wiąże każdego klienta z jego stanem. Numerowane zdarzenia SSE pozwalają płynnie wznowić przerwany strumień bez luk. 🎉