This is a theorical question, since I have a bare idea about the concept, and have not any code yet.
Suppose I use Websockets with Tornado and, in a bridged fashion, a django project which would handle regular connections. This means: the actual server is Tornado, which receives every request and, if the request has NOT a path of /socket (say), the django wsgi handler would handle it (via a fallback container). On the other side, requests to /socket path must have ws or wss protocols and are treated as websockets by Tornado.
When the connection starts, the first request before the Upgrade will have the cookies, and I can grab the session id from the cookies and use the session manager to get the session object by ID. For the lapse of that connection, which since it's a websocket connection it'll be a long-term one, I will have the same value for the session id cookie (since I cannot get agin the cookie headers, because the websocket connection doesn't send headers anymore - the idea is to reduce the overhead, and passing cookies with the message can have a huge overhead).
It's ok until now: Websockets connect, send the cookie only once, the server-side bound for that socket can have that cookie value (the session id) and play with it until the connection is closed.
My Question: How can I detect, in real time, that a session is not available anymore? (possible reasons: 1. user issued a resource which involves closing the current session, althought it's done via AJAX and the websocket is not closed; 2. session expired due to idleness; 3. somehow by use of django api the session is closed, althought that doesn't imply the current execution context for that is the request being closed - I don't ever know if such scenario is possible).
Notes: detecting when a specific session was closed could help me to determine whether the corresponding websockets must be closed as well.