Support for websockets

[pbiggar]

Dark users should be able to trivially make use of websockets. This is about how to provide that.

One option is for us to use something like Pusher.com. However, that would require our users to use the pusher client library, which would lock us in to that.

Asp.net has built-in websockets so we could do this ourselves.

How should it work:

• a canvas should be able to receive websocket requests. This could be done by WEBSOCKET handler, similar to a HTTP handler. It would receive websockets requests and potentially reply to them. This would not fundamentally be different to HTTP requests, just over websockets.

TODO: what does the product equivalent of "channels" look like. Devs want to be able to send data to their users, and so we need a thing for users to subscribe to so that they can receive arbitrary pushes that can be authenticated.

Technology wise, pushes will be able to come from anywhere, not just the machine that the user is connected to. So pushes should be delivered via pubsub, and when the user is connected to a WS server, the server subscribes the appropriate pubsub channel for that canvas(?) so that we can send them the pushes if it is appropriate for the user to receive them.

One complication is that users may switch servers due to a redeploy, and need to miss anything or run the same event twice:

• to not miss anything, reach back in time to get old events
• to not do things twice, give the developer guidance on how to send idempotency tokens (that is, push event IDs) from the server and to ignore them on the client. Perhaps offer a simple JS client/library to support this.

[StachuDotNet]

If this would result in fewer/no get_unlocked_dbs calls+logs (which I think it could), that'd be a nice win.

[pbiggar]

If this would result in fewer/no get_unlocked_dbs calls+logs (which I think it could), that'd be a nice win.

I don't think this will.

The primary reason for get_unlocked_db is that there are very few people logged in at any given time, but there are very many writes to the DB going on at once. So it's much much cheaper to make the get_unlocked_db call than it is to do something on each DB write.

[StachuDotNet]

merged into #5262