1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
//! A bidirectional `WebSocket` bridge between a host and its user interfaces.
//!
//! The shape a real station takes: an orchestrator owns the engine, one or more
//! panels connect, and the **same connection** carries progress out and requests
//! back. A panel does not poll, and does not open a second channel to ask for
//! something.
//!
//! Everything is JSON in `WebSocket` **text** frames, opcode `0x1` in RFC 6455.
//! The protocol frames each message itself, so there is no terminator to agree
//! on, unlike the line transport in `rs-teststand-bridge`, where CRLF exists precisely because a
//! raw socket has no record boundary.
//!
//! # Threads
//!
//! Two, and the split is the point:
//!
//! - **The engine thread**, whichever thread called [`WebSocketBridge::bind`]
//! and owns the engine. It publishes events and drains commands. Engine
//! wrappers are neither [`Send`] nor [`Sync`], so nothing here can take one
//! even by accident.
//! - **The server thread**, a runtime of its own, accepting panels and moving
//! bytes. It never sees the engine; what crosses between the two is
//! `MessageEvent`, `Command` and `Response` from `rs-teststand-bridge`, all
//! plain data.
//!
//! Replies go out as an `Ack`, a fixed five-field record, rather
//! than as the `Response` enum whose fields vary by variant. A client sorts the
//! two kinds of traffic on `command`: an acknowledgement always carries one and
//! an event never does.
use ;
use mpsc;
use thread;
// Four things are easy to get wrong in a tokio websocket server, and each is
// answered deliberately here rather than by accident. Changing this file means
// keeping them true.
//
// A lagging receiver. `broadcast` drops messages for a receiver that falls
// behind and reports `Lagged`. That is treated as fatal for the panel rather
// than ignored: it is disconnected, because silently missing messages is worse
// than a close it can react to. `EVENT_BACKLOG` bounds what one slow panel can
// hold open.
//
// Cancellation in `select!`. The macro drops the futures it was polling when a
// branch wins, so a branch future that had consumed something would lose it.
// Both branches here poll cancel-safe futures. The bodies are safe for a
// different reason: once a branch is chosen its body runs to completion, so the
// `send` calls inside are never cut short.
//
// Split halves. `split` produces a read and a write half that cannot be
// recombined, so both stay in this one task rather than being handed out.
//
// Locks across await points. There are none. State moves through channels.
use broadcast;
use ;
/// How many events the fan-out holds before the slowest panel misses some.
///
/// A panel that falls this far behind is disconnected rather than allowed to
/// hold the buffer open: one that stopped reading is not a reason for the
/// station to grow memory without limit.
const EVENT_BACKLOG: usize = 256;
/// Largest message a panel may send, in bytes.
///
/// Commands are small. A sequence path and a lookup string are the biggest
/// parts of one, so a megabyte is generous by a wide margin. Without a limit a
/// single frame can make the host allocate until it dies, and that needs no
/// malice: a client with a loop bug reaches the same place.
///
/// This bounds what one panel can make the host hold. `EVENT_BACKLOG` bounds
/// what a slow panel can make it keep.
const MAX_MESSAGE_BYTES: usize = 1024 * 1024;
/// Largest single frame accepted, in bytes.
///
/// Kept at the message limit. A message can arrive as several frames, so
/// capping only the message would still let one frame be assembled unbounded
/// before the total is known.
const MAX_FRAME_BYTES: usize = MAX_MESSAGE_BYTES;
/// Most panels served at once.
///
/// A host serves an orchestrator and the few panels a person has open, so this
/// is far above normal use. It exists because nothing else stops a client that
/// reconnects in a loop from opening sockets until the host runs out of them,
/// and a station that has stopped answering is worse than one that refused a
/// connection.
///
/// Refusing is deliberate rather than queueing: a panel told no can back off
/// and return, while one left waiting cannot tell a busy host from a dead one.
const MAX_CLIENTS: usize = 64;
/// What travels out to the panels: an event, or an answer to one of them.
use serve;
/// A command, with the panel that sent it.
///
/// The identity matters: a reply goes to the panel that asked, not to every
/// panel watching.
/// Accepts panels, broadcasts events to them, and collects their commands.
///
/// Built on the engine's thread and used from there; the server runs elsewhere
/// and shares nothing but data.