Skip to content

Commit 0dfc514

Browse files
committed
docs: update README.md
1 parent 1273638 commit 0dfc514

File tree

2 files changed

+90
-50
lines changed

2 files changed

+90
-50
lines changed

README.md

Lines changed: 29 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ npm install --save @matrixai/quic
1616

1717
## Usage
1818

19-
See the example executables in `/src/bin`.
19+
See the example usage in [tests](tests).
2020

2121
## Development
2222

@@ -39,6 +39,27 @@ npm run lint
3939
npm run lintfix
4040
```
4141

42+
### Docs Generation
43+
44+
```sh
45+
npm run docs
46+
```
47+
48+
See the docs at: https://matrixai.github.io/js-quic/
49+
50+
### Publishing
51+
52+
```sh
53+
# npm login
54+
npm version patch # major/minor/patch
55+
npm run build
56+
npm publish --access public
57+
git push
58+
git push --tags
59+
```
60+
61+
## How it works
62+
4263
### Quiche
4364

4465
To understand how to develop this, it is important to understand how quiche works.
@@ -113,23 +134,23 @@ When using the encapsulated way, the `QUICSocket` is separated between client an
113134

114135
When using the injected way, the `QUICSocket` is shared between client and server.
115136

116-
![](/images/quic_structure_encapsulated.svg)
137+
![image](/images/quic_structure_encapsulated.svg)
117138

118139
If you are building a peer to peer network, you must use the injected way. This is the only way to ensure that hole-punching works because both the client and server for any given peer must share the same UDP socket and thus share the `QUICSocket`. When done in this way, the `QUICSocket` lifecycle is managed outside of both the `QUICClient` and `QUICServer`.
119140

120-
![](/images/quic_structure_injected.svg)
141+
![image](/images/quic_structure_injected.svg)
121142

122143
This also means both `QUICClient` and `QUICServer` must share the same connection map. In order to allow the `QUICSocket` to dispatch data into the correct connection, the connection map is constructed in the `QUICSocket`, however setting and unsetting connections is managed by `QUICClient` and `QUICServer`.
123144

124-
## Dataflow
145+
### Dataflow
125146

126147
The data flow of the QUIC system is a bidirectional graph.
127148

128149
Data received from the outside world is received on the UDP socket. It is parsed and then dispatched to each `QUICConnection`. Each connection further parses the data and then dispatches to the `QUICStream`. Each `QUICStream` presents the data on the `ReadableStream` interface, which can be read by a caller.
129150

130151
Data sent to the outside world is written to a `WritableStream` interface of a `QUICStream`. This data is buffered up in the underlying Quiche stream. A send procedure is triggered on the associated `QUICConnection` which takes all the buffered data to be sent for that connection, and sends it to the `QUICSocket`, which then sends it to the underlying UDP socket.
131152

132-
![](/images/quic_dataflow.svg)
153+
![image](/images/quic_dataflow.svg)
133154

134155
Buffering occurs at the connection level and at the stream level. Each connection has a global buffer for all streams, and each stream has its own buffer. Note that connection buffering and stream buffering all occur within the Quiche library. The web streams `ReadableStream` and `WritableStream` do not do any buffering at all.
135156

@@ -139,7 +160,7 @@ The connection negotiation process involves several exchanges of QUIC packets be
139160

140161
The primary reason to do this is for both sides to determine their respective connection IDs.
141162

142-
![](/images/quic_connection_negotiation.svg)
163+
![image](/images/quic_connection_negotiation.svg)
143164

144165
### Push & Pull
145166

@@ -156,49 +177,7 @@ Keeping track of how the system works is therefore quite complex and must follow
156177
* Pull methods - these are either synchronous or asynchronous methods that may throw exceptions.
157178
* Push handlers - these are event handlers that can initiate pull methods, if these pull handlers throw exceptions, these exceptions must be caught, and expected runtime exceptions are to be converted to error events, all other exceptions will be considered to be software bugs and will be bubbled up to the program boundary as unhandled exceptions or unhandled promise rejections. Generally the only exceptions that are expected runtime exceptions are those that arise from perform IO with the operating system.
158179

159-
## Benchmarks
160-
161-
```sh
162-
npm run bench
163-
```
164-
165-
View benchmarks here: https://github.com/MatrixAI/js-quic/blob/master/benches/results with https://raw.githack.com/
166-
167-
### Docs Generation
168-
169-
```sh
170-
npm run docs
171-
```
172-
173-
See the docs at: https://matrixai.github.io/js-quic/
174-
175-
### Publishing
180+
## License
176181

177-
Publishing is handled automatically by the staging pipeline.
182+
js-quic is licensed under Apache-2.0, you may read the terms of the license [here](LICENSE).
178183

179-
Prerelease:
180-
181-
```sh
182-
# npm login
183-
npm version prepatch --preid alpha # premajor/preminor/prepatch
184-
git push --follow-tags
185-
```
186-
187-
Release:
188-
189-
```sh
190-
# npm login
191-
npm version patch # major/minor/patch
192-
git push --follow-tags
193-
```
194-
195-
Manually:
196-
197-
```sh
198-
# npm login
199-
npm version patch # major/minor/patch
200-
npm run build
201-
npm publish --access public
202-
git push
203-
git push --tags
204-
```

package-lock.json

Lines changed: 61 additions & 0 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

0 commit comments

Comments
 (0)