3 教程：实现聊天程序 on 编程那些事儿

3.1 规格说明与入门

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/specification.html

规范

聊天程序使用基于 TCP 的简单文本协议。协议由以 \n 分隔的 utf-8 消息组成。

客户端连接到服务器后，第一行发送登录名。之后，客户端可以使用以下语法向其他客户端发送消息：

3.2 编写 Accept 循环

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/accept_loop.html

编写 Accept 循环

让我们实现服务器的骨架：一个将 TCP 套接字绑定到地址并开始接受连接的循环。

首先，添加所需的导入样板代码：

1
2
3
4
5
6
7


use async_std::{
 prelude::*, // 1
 task, // 2
 net::{TcpListener, ToSocketAddrs}, // 3
};

type Result<T> = std::result::Result<T, Box<dyn std::error::Error + Send + Sync>>; // 4

prelude 重新导出了处理 future 和 stream 所需的一些 trait。
task 模块大致对应 std::thread 模块，但任务要轻量得多。单个线程可以运行许多任务。
对于套接字类型，我们使用 async_std 中的 TcpListener，它与 std::net::TcpListener 类似，但是非阻塞的，并使用 async API。
在本示例中，我们将跳过全面的错误处理。为了传播错误，我们将使用装箱的错误 trait 对象。你知道标准库中有 From<&'_ str> for Box<dyn Error> 实现吗？它允许你在 ? 运算符中使用字符串。

现在我们可以编写服务器的 accept 循环：

3.3 接收消息

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/receiving_messages.html

接收消息

让我们实现协议的接收部分。我们需要：

将传入的 TcpStream 按 \n 分割，并将字节解码为 utf-8
将第一行解释为登录名
将其余行解析为 login: message

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


# use async_std::{
# net::{TcpListener, ToSocketAddrs},
# prelude::*,
# task,
# };
#
# type Result<T> = std::result::Result<T, Box<dyn std::error::Error + Send + Sync>>;
#
use async_std::{
 io::BufReader,
 net::TcpStream,
};

async fn accept_loop(addr: impl ToSocketAddrs) -> Result<()> {
 let listener = TcpListener::bind(addr).await?;
 let mut incoming = listener.incoming();
 while let Some(stream) = incoming.next().await {
 let stream = stream?;
 println!("Accepting from: {}", stream.peer_addr()?);
 let _handle = task::spawn(connection_loop(stream)); // 1
 }
 Ok(())
}

async fn connection_loop(stream: TcpStream) -> Result<()> {
 let reader = BufReader::new(&stream); // 2
 let mut lines = reader.lines();

 let name = match lines.next().await { // 3
 None => Err("peer disconnected immediately")?,
 Some(line) => line?,
 };
 println!("name = {}", name);

 while let Some(line) = lines.next().await { // 4
 let line = line?;
 let (dest, msg) = match line.find(':') { // 5
 None => continue,
 Some(idx) => (&line[..idx], line[idx + 1 ..].trim()),
 };
 let dest: Vec<String> = dest.split(',').map(|name| name.trim().to_string()).collect();
 let msg: String = msg.to_string();
 }
 Ok(())
}

我们使用 task::spawn 函数为每个客户端的工作生成独立任务。也就是说，在接受客户端后，accept_loop 立即开始等待下一个。这是事件驱动架构的核心优势：我们并发服务许多客户端，而无需消耗大量硬件线程。

3.4 发送消息

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/sending_messages.html

发送消息

现在是时候实现另一半——发送消息了。实现发送最明显的方法是让每个 connection_loop 访问其他每个客户端 TcpStream 的写半部分。这样，客户端可以直接向接收者 .write_all 消息。然而，这是错误的：如果 Alice 发送 bob: foo，而 Charley 发送 bob: bar，Bob 实际上可能收到 fobaor。通过套接字发送消息可能需要多次系统调用，因此两个并发的 .write_all 可能会相互干扰！

3.5 连接读写端

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/connecting_readers_and_writers.html

连接读取端与写入端

那么，我们如何确保在 connection_loop 中读取的消息流入相应的 connection_writer_loop？我们应该以某种方式维护一个 peers: HashMap<String, Sender<String>> 映射，使客户端能够找到目标 channel。然而，这个映射将是一些共享可变状态，因此我们必须在其上包装 RwLock，并回答棘手的问题：如果客户端在接收消息的同时加入，应该发生什么。

3.6 整合在一起

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/all_together.html

整合在一起

此时，我们只需启动 broker 即可获得一个功能完整的（在理想情况下！）聊天程序：

 1
 2
 3
 4
 5
 6
 7
 8
 9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129


# extern crate futures;
use async_std::{
 io::BufReader,
 net::{TcpListener, TcpStream, ToSocketAddrs},
 prelude::*,
 task,
};
use futures::channel::mpsc;
use futures::sink::SinkExt;
use std::{
 collections::hash_map::{HashMap, Entry},
 sync::Arc,
};

type Result<T> = std::result::Result<T, Box<dyn std::error::Error + Send + Sync>>;
type Sender<T> = mpsc::UnboundedSender<T>;
type Receiver<T> = mpsc::UnboundedReceiver<T>;

// 主函数
fn run() -> Result<()> {
 task::block_on(accept_loop("127.0.0.1:8080"))
}

fn spawn_and_log_error<F>(fut: F) -> task::JoinHandle<()>
where
 F: Future<Output = Result<()>> + Send + 'static,
{
 task::spawn(async move {
 if let Err(e) = fut.await {
 eprintln!("{}", e)
 }
 })
}

async fn accept_loop(addr: impl ToSocketAddrs) -> Result<()> {
 let listener = TcpListener::bind(addr).await?;

 let (broker_sender, broker_receiver) = mpsc::unbounded(); // 1
 let _broker_handle = task::spawn(broker_loop(broker_receiver));
 let mut incoming = listener.incoming();
 while let Some(stream) = incoming.next().await {
 let stream = stream?;
 println!("Accepting from: {}", stream.peer_addr()?);
 spawn_and_log_error(connection_loop(broker_sender.clone(), stream));
 }
 Ok(())
}

async fn connection_loop(mut broker: Sender<Event>, stream: TcpStream) -> Result<()> {
 let stream = Arc::new(stream); // 2
 let reader = BufReader::new(&*stream);
 let mut lines = reader.lines();

 let name = match lines.next().await {
 None => Err("peer disconnected immediately")?,
 Some(line) => line?,
 };
 broker.send(Event::NewPeer { name: name.clone(), stream: Arc::clone(&stream) }).await // 3
 .unwrap();

 while let Some(line) = lines.next().await {
 let line = line?;
 let (dest, msg) = match line.find(':') {
 None => continue,
 Some(idx) => (&line[..idx], line[idx + 1 ..].trim()),
 };
 let dest: Vec<String> = dest.split(',').map(|name| name.trim().to_string()).collect();
 let msg: String = msg.to_string();

 broker.send(Event::Message { // 4
 from: name.clone(),
 to: dest,
 msg,
 }).await.unwrap();
 }
 Ok(())
}

async fn connection_writer_loop(
 mut messages: Receiver<String>,
 stream: Arc<TcpStream>,
) -> Result<()> {
 let mut stream = &*stream;
 while let Some(msg) = messages.next().await {
 stream.write_all(msg.as_bytes()).await?;
 }
 Ok(())
}

#[derive(Debug)]
enum Event {
 NewPeer {
 name: String,
 stream: Arc<TcpStream>,
 },
 Message {
 from: String,
 to: Vec<String>,
 msg: String,
 },
}

async fn broker_loop(mut events: Receiver<Event>) -> Result<()> {
 let mut peers: HashMap<String, Sender<String>> = HashMap::new();

 while let Some(event) = events.next().await {
 match event {
 Event::Message { from, to, msg } => {
 for addr in to {
 if let Some(peer) = peers.get_mut(&addr) {
 let msg = format!("from {}: {}\n", from, msg);
 peer.send(msg).await?
 }
 }
 }
 Event::NewPeer { name, stream} => {
 match peers.entry(name) {
 Entry::Occupied(..) => (),
 Entry::Vacant(entry) => {
 let (client_sender, client_receiver) = mpsc::unbounded();
 entry.insert(client_sender);
 spawn_and_log_error(connection_writer_loop(client_receiver, stream));
 }
 }
 }
 }
 }
 Ok(())
}

在 accept_loop 内部，我们创建 broker 的 channel 和 task。
在 connection_loop 内部，我们需要将 TcpStream 包装到 Arc 中，以便与 connection_writer_loop 共享。
登录时，我们通知 broker。注意我们在 send 上使用 .unwrap：broker 应该比所有客户端存活更久，如果不是这种情况，broker 可能已经 panic 了，所以我们也同样可以升级 panic。
同样，我们将解析后的消息转发给 broker，假设它仍然存活。

3.7 干净关闭

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/clean_shutdown.html

优雅关闭

当前实现的一个问题是它没有处理优雅关闭。如果我们因某种原因跳出 accept 循环，所有进行中的任务都会被直接丢弃。更正确的关闭顺序应该是：

停止接受新客户端
投递所有待处理消息
退出进程

在基于 channel 的架构中，优雅关闭很容易，尽管起初可能看起来像魔术。在 Rust 中，一旦所有发送端被丢弃，channel 的接收端就会关闭。也就是说，一旦生产者退出并丢弃它们的发送端，系统的其余部分就会自然关闭。在 async_std 中，这转化为两条规则：

3.8 处理断开连接

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/handling_disconnection.html

处理断开连接

目前，我们只是在映射中_添加_新对等方。这显然是错误的：如果对等方关闭了与聊天的连接，我们就不应再尝试向其发送任何消息。

处理断开连接的一个微妙之处在于，我们可以在 reader 任务或 writer 任务中检测到它。这里最明显的解决方案是在两种情况下都从 peers 映射中移除对等方，但这是错误的。如果读和写_都_失败，我们会移除对等方两次，但对等方可能在两次失败之间重新连接了！为了修复这个问题，我们只会在写端完成时移除对等方。如果读端完成，我们将通知写端它也应该停止。也就是说，我们需要为 writer 任务添加发出关闭信号的能力。

3.9 实现客户端

Sun, 23 Aug 2026 16:35:00 +0800

原文链接: https://book.async.rs/tutorial/implementing_a_client.html

实现客户端

由于协议是基于行的，实现聊天客户端很简单：

从 stdin 读取的行应通过套接字发送。
从套接字读取的行应回显到 stdout。

虽然 async 不会显著影响客户端性能（因为与服务器不同，客户端只与一个用户交互，只需要有限的并发），但 async 对于管理并发仍然很有用！