xiaco/mini_chat

简介

一款使用 rust 构建的简单聊天软件，分 server & client 端。

server 端无存储聊天功能，直接转发，不保证送达。

client 端目前只支持命令行形式

功能

基础功能

• 注册
• 登录
• 好友管理：搜索其他在线用户、添加好友、删除好友、查看好友列表

---

聊天功能

• 单聊：在线用户之间可以发送文本消息
• 群聊：创建群聊，用户端指定房间号&密码进行群聊
• 消息提醒：用户可以设置消息提醒，当有新消息时收到提醒。

---

todo

定义通信结构体

• 注册
• 登陆
• 搜索其他在线用户
• 单聊消息
• 群聊消息
• 创建群聊

---

• server 端实现对应处理响应逻辑
• 注册
• 登陆
• 搜索其他在线用户
• 单聊转发
• 群聊转发
• 创建群聊

---

• 定义client端通用接口，可以有不同实现，例如 命令行、GUI

---

client 端实现一个命令行，功能：

• 注册
• 登陆
• 搜索其他在线用户
• 添加好友（本地）
• 删除好友（本地）
• 查看好友列表（本地）
• 单聊消息
• 群聊消息
• 创建群聊

---

• server 端 Dockerfile

---

• p2p 通信

应用层协议

+-----------------------------------------------+---------------+
|                  Frame Payload Length (32)                    |
+---------------+---------------+---------------+---------------+
|                   Stream Identifier (32)                      |
+=+=============================================================+
|                   Frame Payload (0...)                      ...
+---------------------------------------------------------------+

Flags 预留

应用层帧

在通信包基础上封装帧层，以达到双工并发通信，概念类似于 http1.1/2.0

1. 顺序返回

• 优：实现简单

  client 端操作上使用同步模型或异步模型 都可以，只需要维护好发送到 socket 中的顺序即可，返回结果一定对的上

  server 端相同，需要一个模块维护每一个 tcp 连接的上读写包的顺序

• 劣：比如发多条消息，逻辑上不该有顺序概念；假如后面拓展耗时高的操作，服务器顺序返回就显得很不合理

2. 非顺序返回

实现上，与上面本质的区别在于需要一个字段维护包的唯一性，一个 req 一定有一个相同编号（一种实现方式）的 resp，这样通过编号找到乱序返回的 resp， 考虑在协议帧层增加 header 以实现