MCP Protokolünde Oturum Durumu: Sticky, Redis ve Continuation Kıyaslaması

Model Context Protocol'ün Temmuz 2026 güncellemesi, sunucu tarafında tutulan oturumları (Mcp-Session-Id) kaldırıp yerine MRTR (Multi Round-Trip Requests) desenini getirdi: sunucu bir girdi istediğinde durum, opak bir requestState alanına gömülüp istemciye geri veriliyor. Protokol bu alanın içeriğine karışmıyor — seçim artık geliştiricide.

Rust tabanlı rmcp v3 SDK'sı üzerine kurulu bir deney, bu üç olası yaklaşımı tek bir trait arkasında uygulayıp aynı makinede, aynı kodekle karşılaştırdı: replika belleğinde tutulan 'sticky' oturum, Redis destekli oturum deposu ve HMAC ile imzalanmış, tamamen payload içinde taşınan 'sealed continuation'. Referans olarak farklı transport ve kodek kullanan bir gRPC held-stream de eklendi. 74.550 örnekle yapılan ölçümler, küçük veri boyutlarında tel üzerinde durum taşımanın pratikte ölçülemez bir maliyeti olduğunu, ancak durum büyüdükçe (250→923 bayt) tur başına yaklaşık 120 mikrosaniye eklendiğini gösterdi.

Redis deposu dört çağrılık bir diyalogda dokuz ayrı Redis gidişi gerektirip yakın mesafede 1.4 ms, 1 ms gecikmeli depoda 4.84 ms/tur maliyete yol açtı; ayrıca Redis çöktüğünde tüm diyalog başarısız oldu. Sticky bellek modeli, terk edilen 100 diyalogun 100'ünü de süreç sonlanana kadar bellekte tuttu. En çarpıcı bulgu: eski bir requestState'in yeniden sunulması, bir diyalogu geçerli iki farklı rezervasyona (1.388,80 ve 804,00) çatallayabildi — protokoldeki tüm korumalar 'SHOULD' seviyesinde, yalnızca 'at-most-once' garantisi 'MUST' ama bu da sunucu tarafı durum gerektiriyor. Yazı, Rust'ın async fn'i CPS closure'ları canlı tutmak yerine sabit boyutlu bir durum makinesine derlemesiyle paralellik kuruyor.