├── .gitignore ├── LICENSE └── README.md /.gitignore: -------------------------------------------------------------------------------- 1 | README.html 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright [yyyy] [name of copyright owner] 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # WebSocketStream Explained 2 | 3 | 4 | ## Introduction 5 | 6 | The [WebSocket API](https://html.spec.whatwg.org/multipage/web-sockets.html) 7 | provides a JavaScript interface to the 8 | [RFC6455](https://tools.ietf.org/html/rfc6455) WebSocket protocol. While it has 9 | served well, it is awkward from an ergonomics perspective and is missing the 10 | important feature of 11 | [backpressure](https://streams.spec.whatwg.org/#backpressure). In particular, 12 | 13 | * The 14 | [onmessage](https://html.spec.whatwg.org/multipage/web-sockets.html#handler-websocket-onmessage) 15 | event will keep firing until the page becomes completely unresponsive. The 16 | user agent will buffer incoming messages until it runs out of memory and 17 | crashes. 18 | * The only way to determine when the network or remote server can’t keep up 19 | with your sent messages is to test the 20 | [bufferedAmount](https://html.spec.whatwg.org/multipage/web-sockets.html#dom-websocket-bufferedamount) 21 | attribute. To find out when it is safe to start sending messages again, it is 22 | necessary to poll bufferedAmount. 23 | 24 | WebSocketStream aims to solve these deficiencies with a new API. 25 | 26 | Here’s a basic example of usage of the new API: 27 | 28 | ```javascript 29 | const wss = new WebSocketStream(url); 30 | const { readable } = await wss.opened; 31 | const reader = readable.getReader(); 32 | while (true) { 33 | const { value, done } = await reader.read(); 34 | if (done) 35 | break; 36 | await process(value); 37 | } 38 | done(); 39 | ``` 40 | 41 | This is the roughly equivalent code with the old API: 42 | 43 | ```javascript 44 | const ws = new WebSocket(url); 45 | ws.onmessage = evt => process(evt.data); 46 | ws.onclose = evt => evt.wasClean ? done() : signalErrorSomehow(); 47 | ``` 48 | 49 | The major difference is that the second example won’t wait for asynchronous 50 | activity in `process()` to complete before calling it again; it will keep 51 | hammering it as long as messages keep arriving. 52 | 53 | Also note that because the old API was designed before Promises were added to 54 | the language, error-handling is awkward. 55 | 56 | Writing also uses the backpressure facilities of the Streams API: 57 | 58 | ```javascript 59 | const wss = new WebSocketStream(url); 60 | const { writable } = await wss.opened; 61 | const writer = writable.getWriter(); 62 | for await (const message of messages) { 63 | await writer.write(message); 64 | } 65 | ``` 66 | 67 | The second argument to WebSocketStream is an option bag to allow for future 68 | extension. One option is “protocols”, which behaves the same as the second 69 | argument to the WebSocket constructor: 70 | 71 | ```javascript 72 | const wss = new WebSocketStream(url, {protocols: ['chat', 'chatv2']}); 73 | const { protocol } = await wss.opened; 74 | ``` 75 | 76 | The selected protocol is part of the dictionary available via the 77 | `wss.opened` promise, along with “extensions”. All the information about 78 | the live connection is provided by this promise, since it is not relevant if the 79 | connection failed. 80 | 81 | ```javascript 82 | const { readable, writable, protocol, extensions } = await wss.opened; 83 | ``` 84 | 85 | The information that was available from the onclose and onerror events in the 86 | old API is now available via the “closed” Promise. This rejects in the event 87 | of an unclean close, otherwise it resolves to the code and reason sent by the 88 | server. 89 | 90 | ```javascript 91 | const { closeCode, reason } = await wss.closed; 92 | ``` 93 | 94 | An AbortSignal passed to the constructor makes it simple to abort the handshake. 95 | 96 | ```javascript 97 | const wss = new WebSocketStream(url, { signal: AbortSignal.timeout(1000) }); 98 | ``` 99 | 100 | The close method can also be used to abort the handshake, but its main purpose 101 | is to permit specifying the code and reason which is sent to the server. 102 | 103 | ```javascript 104 | wss.close({closeCode: 4000, reason: 'Game over'}); 105 | ``` 106 | 107 | 108 | ## Mapping to the protocol 109 | 110 | There is a 1:1 mapping between WebSocket messages and stream chunks. 111 | 112 | Each call to `read()` returns one WebSocket message. If a message is split into 113 | multiple frames on the wire, it won't be returned by `read()` until the final 114 | frame (the one with the FIN flag set) arrives. 115 | 116 | When `read()` is not called, the browser and operating system will still buffer 117 | data to some extent, so backpressure will not be detected immediately by the 118 | server. 119 | 120 | Text messages appear in JavaScript as strings. Binary messages appear as 121 | Uint8Array objects. 122 | 123 | A clean close will result in `read()` returning an object with `done` set to 124 | true. An unclean close will result in a rejected promise. 125 | 126 | Each call to `write()` (or chunk that is piped into the `writable`) will be 127 | converted to one message. The browser may split the message into multiple 128 | frames. BufferSource (ArrayBuffer or TypedArray) objects will be sent as binary 129 | WebSocket messages. Any other type will be converted to a string and sent as a 130 | text message. 131 | 132 | The promise returned by `write()` will resolve when the message has been 133 | buffered (either by the browser or operating system). The size of the buffer is 134 | finite but unspecified. It is not a signal that the message has been delivered 135 | to the WebSocket server (the browser does not have this information). 136 | 137 | The promise returned by `write()` will reject if the connection is closed or 138 | errored. 139 | 140 | 141 | ## Goals 142 | 143 | * Provide a WebSocket API that supports backpressure 144 | * Provide a modern, ergonomic, easy-to-use WebSocket API 145 | * Allow for future extension 146 | 147 | 148 | ## Non-goals 149 | 150 | * Support Blob chunks. The old WebSocket API defaults to receiving messages as 151 | Blobs; however, creating and reading Blobs is more costly than creating and 152 | reading ArrayBuffers. In practice, even though it requires explicitly setting 153 | binaryType, 97% of messages are received as ArrayBuffers. On the send side, 154 | sending Blobs adds considerable complexity to the implementation because the 155 | contents are not available synchronously. Since less than 4% of sent messages 156 | are Blobs it is better to avoid this complexity where we can. 157 | * Changing, replacing or extending the underlying network protocol. 158 | [WebTransport](https://developer.mozilla.org/en-US/docs/Web/API/WebTransport) 159 | has many advanced features that are not supported by the WebSocket protocol, 160 | such as datagram support over UDP. It should be preferred when advanced 161 | networking features are required. 162 | * Allowing user JavaScript to select [WebSocket 163 | extensions](https://tools.ietf.org/html/rfc6455#page-48). Since the server 164 | already negotiates the extensions to use, adding additional controls to client 165 | JavaScript seems redundant. The existing JavaScript API has never supported 166 | this, although some non-browser implementations have added options to the 167 | constructor for it. 168 | 169 | 170 | ## Non-goals in the first version 171 | 172 | * Bring-your-own-buffer reading 173 | * Reading or writing individual messages as streams (for example, to handle 174 | messages larger than memory) 175 | * Exposing WebSocket [pings and 176 | pongs](https://tools.ietf.org/html/rfc6455#page-37) to JavaScript. 177 | 178 | 179 | ## Use cases 180 | 181 | * High-bandwidth WebSocket applications that need to retain interactivity, in 182 | particular video and screen-sharing. 183 | * Similarly, video capture and other applications that generate a lot of data in 184 | the browser that needs to be uploaded to the server. With backpressure, the 185 | client can stop producing data rather than accumulating data in memory. 186 | 187 | 188 | ## End-user benefits 189 | 190 | Applications written with the new API will automatically be more responsive due 191 | to respecting backpressure. High throughput applications will adapt to the 192 | capabilities of the client, providing everyone with a smooth experience. 193 | 194 | 195 | ## Alternatives 196 | 197 | It’s possible to implement backpressure at the application level, but it’s 198 | complex and difficult to achieve peak throughput. For example, client JavaScript 199 | could send an application-level confirmation message to the server every time it 200 | finishes processing a message. The server could keep track of how many messages 201 | it has sent that have not yet been confirmed, and stop sending if the number 202 | gets above a certain threshhold. 203 | 204 | Aside from backpressure, the rest of the API can be emulated by wrapping the 205 | existing WebSocket API, but this will not permit future extensions. 206 | 207 | Adding new attributes to the existing WebSocket API was considered but not 208 | adopted because having two APIs on one object would be confusing and create odd 209 | semantics. 210 | 211 | [WebTransport](https://github.com/WICG/web-transport/blob/master/explainer.md) 212 | also provides backpressure, and may replace WebSocket for many purposes. In the 213 | near future the WebSocket protocol has the advantage that it works on networks 214 | that block QUIC, and has much existing deployed infrastructure. 215 | 216 | An older version of this explainer had the readable stream producing ArrayBuffer 217 | chunks. This was changed to Uint8Array chunks to align better with WebTransport 218 | and modern practice. 219 | 220 | Previously the `closeCode` attribute was called `code`, but this conflicted with 221 | the `code` attribute of `DOMException`. 222 | 223 | 224 | ## Future work 225 | 226 | * Adding bring-your-own-buffer reading is a natural extension with the potential 227 | to improve performance. 228 | * Customisable buffer sizes to allow developers to make the trade-off between 229 | throughput and response to backpressure explicitly. 230 | 231 | 232 | ## See also 233 | 234 | * [WebSocketStream design 235 | notes](https://docs.google.com/document/d/1La1ehXw76HP6n1uUeks-WJGFgAnpX2tCjKts7QFJ57Y/edit) 236 | for definition of the new API and technical details. 237 | --------------------------------------------------------------------------------