book: rely on implicit targets

Author: djc

docs/book/Cargo.toml

@@ -15,15 +15,3 @@ quinn = { version = "0.11.7", path = "../../quinn" }
 rcgen.workspace = true
 rustls.workspace = true
 rustls-pemfile.workspace = true
-
-[[bin]]
-name = "certificate"
-path = "src/quinn/certificate.rs"
-
-[[bin]]
-name = "data-transfer"
-path = "src/quinn/data-transfer.rs"
-
-[[bin]]
-name = "set-up-connection"
-path = "src/quinn/set-up-connection.rs"

docs/book/src/quinn/certificate.rs docs/book/src/bin/certificate.rsdocs/book/src/quinn/certificate.rs renamed to docs/book/src/bin/certificate.rs

@@ -19,13 +19,13 @@ rustls = { version = "*", features = ["dangerous_configuration", "quic"] }
 Then, allow the client to skip the certificate validation by implementing [ServerCertVerifier][ServerCertVerifier] and letting it assert verification for any server.
 
 ```rust
-{{#include certificate.rs:8:60}}
+{{#include ../bin/certificate.rs:8:60}}
 ```
 
 After that, modify the [ClientConfig][ClientConfig] to use this [ServerCertVerifier][ServerCertVerifier] implementation.
 
 ```rust
-{{#include certificate.rs:63:72}}
+{{#include ../bin/certificate.rs:63:72}}
 ```
 
 Finally, if you plug this [ClientConfig][ClientConfig] into the [Endpoint::set_default_client_config()][set_default_client_config] your client endpoint should verify all connections as trustworthy.
@@ -45,10 +45,10 @@ This example uses [rcgen][4] to generate a certificate.
 Let's look at an example:
 
 ```rust
-{{#include certificate.rs:90:101}}
+{{#include ../bin/certificate.rs:90:101}}
 ```
 
-*Note that [generate_simple_self_signed][generate_simple_self_signed] returns a [Certificate][2] that can be serialized to both `.der` and `.pem` formats.*
+_Note that [generate_simple_self_signed][generate_simple_self_signed] returns a [Certificate][2] that can be serialized to both `.der` and `.pem` formats._
 
 ### Non-self-signed Certificates
 
@@ -68,7 +68,7 @@ certbot asks for the required data and writes the certificates to `fullchain.pem
 These files can then be referenced in code.
 
 ```rust
-{{#include certificate.rs:75:88}}
+{{#include ../bin/certificate.rs:75:88}}
 ```
 
 ### Configuring Certificates
@@ -79,15 +79,15 @@ After configuring plug the configuration into the `Endpoint`.
 **Configure Server**
 
 ```rust
-{{#include certificate.rs:107}}
+{{#include ../bin/certificate.rs:107}}
 ```
 
 This is the only thing you need to do for your server to be secured.
 
 **Configure Client**
 
 ```rust
-{{#include certificate.rs:108}}
+{{#include ../bin/certificate.rs:108}}
 ```
 
 This is the only thing you need to do for your client to trust a server certificate signed by a conventional certificate authority.
@@ -103,7 +103,6 @@ This is the only thing you need to do for your client to trust a server certific
 [5]: https://en.wikipedia.org/wiki/Self-signed_certificate#:~:text=In%20cryptography%20and%20computer%20security,a%20CA%20aim%20to%20provide.
 [6]: https://letsencrypt.org/getting-started/
 [7]: https://certbot.eff.org/instructions
-
 [ClientConfig]: https://docs.rs/quinn/latest/quinn/struct.ClientConfig.html
 [ServerCertVerifier]: https://docs.rs/rustls/latest/rustls/client/trait.ServerCertVerifier.html
 [set_default_client_config]: https://docs.rs/quinn/latest/quinn/struct.Endpoint.html#method.set_default_client_config

docs/book/src/quinn/data-transfer.rs docs/book/src/bin/data-transfer.rsdocs/book/src/quinn/data-transfer.rs renamed to docs/book/src/bin/data-transfer.rs

@@ -15,10 +15,10 @@ With QUIC, the programmer is in full control over the stream allocation.
 QUIC provides support for both stream and message-based communication.
 Streams and messages can be initiated both on the client and server.
 
-| Type | Description | Reference |
-| :----- | :----- | :----- |
-| **Bidirectional Stream** | two way stream communication. | see [open_bi][open_bi] |
-| **Unidirectional Stream** | one way stream communication. | see [open_uni][open_uni] |
+| Type                                 | Description                             | Reference                          |
+| :----------------------------------- | :-------------------------------------- | :--------------------------------- |
+| **Bidirectional Stream**             | two way stream communication.           | see [open_bi][open_bi]             |
+| **Unidirectional Stream**            | one way stream communication.           | see [open_uni][open_uni]           |
 | **Unreliable Messaging (extension)** | message based unreliable communication. | see [send_datagram][send_datagram] |
 
 ## How to Use
@@ -31,50 +31,50 @@ New streams can be created with [Connection][Connection]'s [open_bi()][open_bi]
 With bidirectional streams, data can be sent in both directions.
 For example, from the connection initiator to the peer and the other way around.
 
-*open bidirectional stream*
+_open bidirectional stream_
 
 ```rust
-{{#include data-transfer.rs:5:11}}
+{{#include ../bin/data-transfer.rs:5:11}}
 ```
 
-*iterate incoming bidirectional stream(s)*
+_iterate incoming bidirectional stream(s)_
 
 ```rust
-{{#include data-transfer.rs:14:22}}
+{{#include ../bin/data-transfer.rs:14:22}}
 ```
 
 ## Unidirectional Streams
 
 With unidirectional streams, you can carry data only in one direction: from the initiator of the stream to its peer.
 It is possible to get reliability without ordering (so no head-of-line blocking) by opening a new stream for each packet.
 
-*open unidirectional stream*
+_open unidirectional stream_
 
 ```rust
-{{#include data-transfer.rs:25:30}}
+{{#include ../bin/data-transfer.rs:25:30}}
 ```
 
-*iterating incoming unidirectional stream(s)*
+_iterating incoming unidirectional stream(s)_
 
 ```rust
-{{#include data-transfer.rs:33:39}}
+{{#include ../bin/data-transfer.rs:33:39}}
 ```
 
 ## Unreliable Messaging
 
 With unreliable messaging, you can transfer data without reliability.
 This could be useful if data arrival isn't essential or when high throughput is important.
 
-*send datagram*
+_send datagram_
 
 ```rust
-{{#include data-transfer.rs:42:45}}
+{{#include ../bin/data-transfer.rs:42:45}}
 ```
 
-*iterating datagram stream(s)*
+_iterating datagram stream(s)_
 
 ```rust
-{{#include data-transfer.rs:48:54}}
+{{#include ../bin/data-transfer.rs:48:54}}
 ```
 
 [Endpoint]: https://docs.rs/quinn/latest/quinn/struct.Endpoint.html

docs/book/src/quinn/set-up-connection.rs docs/book/src/bin/set-up-connection.rsdocs/book/src/quinn/set-up-connection.rs renamed to docs/book/src/bin/set-up-connection.rs

@@ -12,7 +12,7 @@ It all starts with the [Endpoint][Endpoint] struct, this is the entry point of t
 Let's start by defining some constants.
 
 ```rust
-{{#include set-up-connection.rs:5:13}}
+{{#include ../bin/set-up-connection.rs:5:13}}
 ```
 
 **Server**
@@ -22,7 +22,7 @@ The [server()][server] method, which can be used for this, returns the `Endpoint
 `Endpoint` is used to start outgoing connections and accept incoming connections.
 
 ```rust
-{{#include set-up-connection.rs:16:28}}
+{{#include ../bin/set-up-connection.rs:16:28}}
 ```
 
 **Client**
@@ -32,13 +32,13 @@ The client needs to connect to the server using the [connect(server_name)][conne
 The `SERVER_NAME` argument is the DNS name, matching the certificate configured in the server.
 
 ```rust
-{{#include set-up-connection.rs:31:41}}
+{{#include ../bin/set-up-connection.rs:31:41}}
 ```
+
 <br><hr>
 
 [Next up](data-transfer.md), let's have a look at sending data over this connection.
 
-
 [Endpoint]: https://docs.rs/quinn/latest/quinn/struct.Endpoint.html
 [server]: https://docs.rs/quinn/latest/quinn/struct.Endpoint.html#method.server
 [client]: https://docs.rs/quinn/latest/quinn/struct.Endpoint.html#method.client