Can we expose an interface for session in StreamableHttpHandler for self-implement?

[MrJiang724]

Currently, the session in StreamableHttpHandler is ConcurrentDictionary. It stores session information in the machine memory, which makes SSE and stateful streamable HTTP unable to support multiple instances.

Can we create an interface for it and default implement is ConcurrentDictionary? So that we can use shared storage to override it and run these protocols in multi-instance mode.

[halter73]

It stores session information in the machine memory, which makes SSE and stateful streamable HTTP unable to support multiple instances.

Out of curiosity, why not use the stateless mode which does not have this limitation?

Can we create an interface for it and default implement is ConcurrentDictionary? So that we can use shared storage to override it and run these protocols in multi-instance mode.

The ConcurrentDictionary currently stores a reference to the SseResponseStreamTransport or SseResponseStreamTransport among other things, and these are not serializable. So even if you could override it, it wouldn't be possible to support multiple server instances without some inter-server RPC mechanism which I doubt you had in mind. Can you provide an example of an C# interface that would allow you to do what you want?

I've considered adding the ability to give you some control over the mcp-session-id header in stateless mode which would allow it to serve as a poor man's session cookie. However, it seems like most clients support real cookies, so maybe we're better off telling people to use cookies instead.

This seems somewhat similar to #425, so I'm curious what @AArnott and @eiriktsarpalis think about this.

@eiriktsarpalis has #466 open, which will make the session ID easier to access. You could use that to key into a distributed cache or something like that. And if you want to get the session ID today, you should be able to use HttpContext.Response.Headers["mcp-session-id"].

[MrJiang724]

Thank you very much for your reply.

Out of curiosity, why not use the stateless mode which does not have this limitation?

We hope that the client's series of requests have continuity and prevent the client from tampering with the records by modifying the cookie locally. At the same time, as a robust online service, only multiple nodes can ensure its high availability.

The ConcurrentDictionary currently stores a reference to the SseResponseStreamTransport or SseResponseStreamTransport among other things, and these are not serializable. So even if you could override it, it wouldn't be possible to support multiple server instances without some inter-server RPC mechanism which I doubt you had in mind. Can you provide an example of an C# interface that would allow you to do what you want?

Is it possible to work around the inter-server RPC mechanism? We can define a task class to store the status and related data. For the running task in the previous instance, we can upload the task status and result to this shared session object. For the task which need to be executed in previous instance, we can generate task with input and execute it in other instances.

Let me consider more about how to support this shared session.

Maybe we can use some client info as key and store client info in the database to let stateless mode service have similar ability.