Tornado, Django, Websockets, and Session syncing

Question

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.

Answer 1

I'm assuming you're using the cookie system from django (using django.contrib.sessions.middleware.SessionMiddleware).

You obviously do not want to each the session cookie on each websocket request. Then it's up to the server to find out if the session is alive.

This will require accessing the session storage all the time. If you're using database-backed sessions, it will introduce a lot of overhead. If you're using cache-backed sessions, it's doable.

Reference from the django documentation: https://docs.djangoproject.com/en/1.8/topics/http/sessions/