Websocket server » History » Version 1
Tom Clegg, 06/16/2016 08:13 PM
| 1 | 1 | Tom Clegg | h1. Websocket server |
|---|---|---|---|
| 2 | |||
| 3 | (early draft) |
||
| 4 | |||
| 5 | {{toc}} |
||
| 6 | |||
| 7 | h2. Background |
||
| 8 | |||
| 9 | The Rails API server can function as a websocket server. Clients (notably Workbench, arv-mount, arv-ws) use it to listen for events without polling. |
||
| 10 | |||
| 11 | Problems with current implementation: |
||
| 12 | * Unreliable |
||
| 13 | * Resource-heavy (one postgres connection per connected client, uses lots of memory) |
||
| 14 | * Logging is not very good |
||
| 15 | * Updates look like database records instead of API responses (e.g., computed fields are missing, collection manifest_text has no signatures) |
||
| 16 | * Offers an API for catching up on missed events after disconnecting/reconnecting, but this API (let alone the code) isn't enough to offer a "don't miss any events, don't send any events twice" guarantee. |
||
| 17 | |||
| 18 | h2. Design sketch |
||
| 19 | |||
| 20 | New server, written in Go. |
||
| 21 | |||
| 22 | One goroutine per connected client. |
||
| 23 | |||
| 24 | One database connection receiving notifications about new logs. (Possibly still N database connections serving "catch-up" messages to N clients.) |