You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/websockets-backpressure.md
+102-4Lines changed: 102 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,6 +3,52 @@ WebSocket "routes" are registered similarly, but not identically.
3
3
4
4
Every websocket route has the same pattern and pattern matching as for Http, but instead of one single callback you have a whole set of them, here's an example:
5
5
6
+
Configuration details, notes:
7
+
-*idle_timeout*: number of seconds of inactivity before client is disconnected. If set to 0, no policy is enforced (connections can be stale).
8
+
-*open*: callback function for websocket connection being open
9
+
```python
10
+
defon_open(ws : WebSocket):
11
+
"""
12
+
ws: WebSocket - websocket connection
13
+
"""
14
+
...
15
+
```
16
+
-*close*: callback function for websocket connection closed
"subscription": lambdaws, topic, subscriptions, subscriptions_before: print(f'subscription/unsubscription on topic {topic}{subscriptions}{subscriptions_before}'),
19
66
},
20
67
)
@@ -24,6 +71,57 @@ You should use the provided user data feature to store and attach any per-socket
24
71
25
72
If you want to create something more elaborate you could have the user data hold a pointer to some dynamically allocated memory block that keeps a boolean whether the WebSocket is still valid ornot. Sky is the limit here.
26
73
74
+
In order to do so, use the `upgrade` callback configuration in the `app.ws` settings.
0 commit comments