Project

General

Profile

Websocket server » History » Version 3

Tom Clegg, 06/17/2016 04:26 AM

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 3 Tom Clegg
* Unreliable. See #9427, #8277
13 1 Tom Clegg
* 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 3 Tom Clegg
* 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. See #9388
17 1 Tom Clegg
18 3 Tom Clegg
#8460
19
20
h2. Desired features
21
22
Monotonically increasing event IDs, so clients can (meaningfully) request "all matching events since X"
23
24 1 Tom Clegg
h2. Design sketch
25
26
New server, written in Go.
27
28
One goroutine per connected client.
29
30
One database connection receiving notifications about new logs. (Possibly still N database connections serving "catch-up" messages to N clients.)
31 2 Tom Clegg
32
h2. Libraries
33
34
Websocket:
35
* https://godoc.org/golang.org/x/net/websocket
36
37
PostgreSQL:
38 1 Tom Clegg
* https://godoc.org/github.com/lib/pq via https://godoc.org/database/sql
39
* https://godoc.org/github.com/lib/pq#hdr-Notifications and https://godoc.org/github.com/lib/pq/listen_example
40 3 Tom Clegg
41
h2. Obstacles
42
43
#8565, #8566