diff --git a/src/ch17-02-concurrency-with-async.md b/src/ch17-02-concurrency-with-async.md
index 716b9c8..d09adb4 100644
--- a/src/ch17-02-concurrency-with-async.md
+++ b/src/ch17-02-concurrency-with-async.md
@@ -172,4 +172,66 @@ hi number 9 from the first task!
 
 </figure>
 
-除了发送消息之外，我们需要接收它们。
+除了发送消息之外，我们需要接收它们。在这个例子中我们可以手动接收，就是调用四次 `rx.recv().await`，因为我们知道进来了多少条消息。在现实生活中，我们通常会等待 *未知* 数量的消息。这时我们需要一直等待直到可以确认没有更多消息了为止。
+
+在示例 16-10 中，我们使用了 `for` 循坏来处理从异步信道接收的所有消息。然而，Rust 目前还没有还没有方法在 *异步* 序列上编写 `for` 循环。为此，我们需要一个我们还没有见过的新循环类型，`while let` 条件循环。`while let` 循环是我们在第六章中见过的 `if let` 结构的循环版本。只要其指定的模式持续匹配循环就会一直执行。
+
+`rx.recv` 调用产生一个 `Future`，我们会 await 它。运行时会暂停 `Future` 直到它就绪。一旦消息到达，future 会解析为 `Some(message)`，一有消息到达就会生成。当信道关闭时，不管是否有 *任何* 消息到达，future 都会解析为 `None` 来表明没有更多的值了，我们也就应该停止轮询，也就是停止等待。
+
+`while let` 循环完成上面说的所有工作。如果 `rx.recv().await` 调用的结果是 `Some(message)`，我们会得到消息并可以在循环体中使用它，就像使用 `if let` 一样。如果结果是 `None`，则循环停止。每次循环执行完毕，它会再次触发 await point，如此运行时会再次暂停直到另一条消息到达。
+
+现在代码可以成功发送和接收所有的消息了。不幸的是，这里还有一些问题。首先，消息并不是按照半秒的间隔到达的。它们在程序启动后两秒（2000 毫秒）后立刻一起到达。其次，程序也永远不会退出！相反它会永远等待新消息。你会需要使用 <span class="keystroke">ctrl-c</span> 来关闭它。
+
+让我们开始理解为何消息在全部延迟后立刻一起到达，而不是每个在延迟后到达。在一个给定的异步代码块，`await` 关键字在代码中出现的顺序也就是程序执行时其发生的顺序。
+
+示例 17-10 中只有一个异步代码块，所以所有的代码线性地执行。这里仍然没有并发。所有的 `tx.send` 调用交叉着所有的 `trpl::sleep` 调用和它们关联的 await point 一起发生。只有在此之后 `while let` 循环才开始执行 `recv` 调用上的 `await` point。
+
+为了得到我们需要的行为，在接收每个消息的休眠延迟发生时，我们需要将 `tx` 和 `rx` 操作放置于它们各自的异步代码块中。这样运行时就可以使用 `trpl::join` 来分别执行它们，就像在计数示例中一样。我们再一次 await `trpl::join` 调用的结果，而不是它们各自的 future。如果我们顺序地 await 单个 future，则就又回到了一个顺序流，这正是我们 *不* 希望做的。
+
+<!-- We cannot test this one because it never stops! -->
+
+<figure class="listing">
+
+<span class="file-name">文件名：src/main.rs</span>
+
+```rust,ignore
+{{#rustdoc_include ../listings/ch17-async-await/listing-17-11/src/main.rs:futures}}
+```
+
+<figcaption>示例 17-11：将 `send` 和 `recv` 分隔到其各自的 `async` 代码块中并 await 这些代码块的 future</figcaption>
+
+</figure>
+
+采用示例 17-11 中的更新后的代码，消息会以 500 毫秒的间隔打印，而不是在两秒后就全部一起打印。
+
+但是程序仍然永远也不会退出，这是由于 `while let` 循环与 `trpl::join` 的交互方式：
+
+- `trpl::join` 返回的 future 只会完成一次，即传递的 *两个* future 都完成的时候。
+- `tx` future 在发送 `vals` 中最后一条消息之后的休眠结束后立刻完成。
+- `rx` future 直到 `while let` 循环结束之前都不会完成。
+- 当信道的另一端关闭后 await `rx.recv` 将只会返回 `None`。
+- 信道只有在调用 `rx.close` 或者发送端 `tx` 被丢弃时才会关闭。
+- 我们没有在任何地方调用 `rx.close`，并且 `tx` 直到传递给 `trpl::run` 的最外层异步代码块结束前都不会被丢弃。
+- 代码块不能结束是因为它阻塞在了等待 `trpl::join` 完成，这就又回到了列表的开头！
+
+我们可以在代码的某处调用 `rx.close` 来手动关闭 `rx`，不过这并没有太多意义。在处理了任意数量的消息后停止可以使程序停止，但是可能会丢失消息。我们需要其它的手段来确保 `tx` 在函数的结尾 *之前* 被丢弃。
+
+目前发送消息的异步代码块只是借用了 `tx`，因为发送消息并不需要其所有权，但是如果我们可以将 `tx` 移动（move）进异步代码快，它会在代码块结束后立刻被丢弃。在第十三章中我们学习了如何在闭包上使用 `move` 关键字，在第十六章中，我们知道了使用线程时经常需要移动数据进闭包。同样基本原理也适用于异步代码块，所以 `move` 关键字也能像闭包那样作用于异步代码块。
+
+在示例 17-12 中，我们将发送消息的异步代码块从 `async` 代码块修改为 `async move` 代码块。当运行 *这个* 版本的代码时，它会在发送和接收完最后一条消息后优雅地关闭。
+
+<figure class="listing">
+
+<span class="file-name">文件名：src/main.rs</span>
+
+```rust
+{{#rustdoc_include ../listings/ch17-async-await/listing-17-12/src/main.rs:with-move}}
+```
+
+<figcaption>示例 17-12：一个可以工作的在 future 之间接收和发送消息的示例，其在结束后会正确地关闭</figcaption>
+
+</figure>
+
+这个异步信道也是一个多生产者信道，所以如果希望从多个 future 发送消息可以调用 `tx` 上的 `clone` 方法。在示例 17-13 中，我们克隆了 `tx`，在第一个异步代码块外面创建 `tx1`。我们像第一个 `tx` 一样将 `tx1` 移动进代码块。接着，将原始的 `tx` 移动进一个 *新的* 异步代码块，其中会用一个稍微更长的延迟发送更多的消息。我们碰巧将新代码块放在接收消息的异步代码块之后，不过也可以放在之前。关键的是 future 的 await 的顺序，而不是它们创建的顺序。
+
+