<commit_before># ATM机模拟系统上机报告
## 小组名单及各自工作

## 协议设计
### 客户端如何定位服务器
客户端静态绑定服务器的IP与PORT,由于客户端与服务端中间加入了一个协调者（下文会提到），因此客户端实际上绑定的是协调者的地址与端口。
### 请求与响应流程的详细步骤
**客户端向服务器发送请求及得到结果的整个流程的详细步骤**

具体的操作有登录，取款，存款，转账：

#### 登录：
1. 客户端使用银行卡号与密码请求登录
2. 服务端收到请求后，验证银行卡号与密码
3. 验证成功后，服务端会签发一个 token，再把这个 token 发送给客户端；若验证失败，则返回错误原因
4. 客户端收到 token 后把它存储起来，每次向服务端请求资源的时候带着服务端签发的 token
5. 服务端收到请求后，验证客户端请求里面的 token
6. 服务端返回消息时，也会带上 token

关于参数 token:

* 每次打开客户端，都会发起登录请求，获取新的 token
* 因客户端崩溃导致 token 的存在，客户端登录成功后覆盖之
* 关闭客户端，即删除当前的 token

关于参数 deadline:

* 初始值为当前时间+一天(86400秒)
* 当前时间与 deadline 相差 300 的时候，客户端发起**续期**请求
* 当前时间大于等于 deadline 的时候，token 无效，服务端删除该值

其余操作详细过程类似

### 数据包的结构内容和解析方法
基于 TCP 的应用层协议。TCP 是基于点到点的可靠的传输层协议，无需考虑应用层协议的一致性问题。采用基于 Key-Value 模式的 JSON 数据格式实现。JSON有其固定的解析方式，大大简化了解析的工作。具体的数据结构实例在下文应用层实例中。
### 系统崩溃策略

使用**二阶段提交协议**解决事务操作中客户端或服务端崩溃的情况。二阶段提交主要保证了分布式事务的原子性，即所有节点要么全做要么全不做。

#### 基于以下假设:
* 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
* 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
* 所有节点不会永久性损坏，即使损坏后仍然可以恢复

#### 客户端与服务端二阶段提交协议具体步骤如下:
```
ATM request --> Coordinator
                      |
                      v
                 Transaction
ATM recv <-- First stage start     --> Server recv
 |                                        |
 | local transaction                      | local transaction
 |                                        |
 v                                        v
ATM send --> First stage complete  <-- Server send
                     |
                     v
ATM recv <-- Second stage start    --> Server recv
 |                                        |
 | complete                               | complete
 v                                        v
ATM send --> Second stage complete <-- Server send
```
**数据包格式如下:**

第一阶段提交:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| msg | JSON 数据 | 所执行的操作 |

第一阶段返回结果:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| status | 状态 | 执行结果 | |

第二阶段提交:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| status | 状态 | 0 代表执行，1 代表回滚 |

第二阶段返回结果:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| status | 状态 | 执行结果 | |
#### 考虑系统崩溃的时间段

ATM

1. 业务请求发送前
2. 业务请求发送之后，收到协调者询问之前
3. 收到协调者询问之后，发送 ACK 之前（1）、应用服务器运行数据负荷较轻。
最简单的C/S体系结构的数据库应用由两部分组成，即客户应用程序和数据库服务器程序。二者可分别称为前台程序与后台程序。运行数据库服务器程序的机器，也称为应用服务器。一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户应用程序运行在用户自己的电脑上，对应于数据库服务器，可称为客户电脑，当需要对数据库中的数据进行任何操作时，客户程序就自动地寻找服务器程序，并向其发出请求，服务器程序根据预定的规则作出应答，送回结果，应用服务器运行数据负荷较轻。
（2）、数据的储存管理功能较为透明。
在数据库应用中，数据的储存管理功能，是由服务器程序和客户应用程序分别独立进行的，前台应用可以违反的规则，并且通常把那些不同的（不管是已知还是未知的）运行数据，在服务器程序中不集中实现，例如访问者的权限，编号可以重复、必须有客户才能建立定单这样的规则。所有这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉）背后的过程，就可以完成自己的一切工作。在客户服务器架构的应用中，前台程序不是非常“瘦小”，麻烦的事情都交给了服务器和网络。在C/S体系的下，数据库不能真正成为公共、专业化的仓库，它受到独立的专门管理。
（3）、C/S架构的劣势是高昂的维护成本且投资大。
首先，采用C/S架构，要选择适当的数据库平台来实现数据库数据的真正“统一”，使分布于两地的数据同步完全交由数据库系统去管理，但逻辑上两地的操作者要直接访问同一个数据库才能有效实现，有这样一些问题，如果需要建立“实时”的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，网络管理工作人员既要对服务器维护管理，又要对客户端维护和管理，这需要高昂的投资和复杂的技术支持，维护成本很高，维护任务量大。
其次，传统的C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，由于产品的更新换代十分快，代价高和低效率已经不适应工作需要。在JAVA这样的跨平台语言出现之后，B/S架构更是猛烈冲击C/S，并对其形成威胁和挑战。
6. 发送 ACK 之后，收到结果前
7. 收到结果后

Server

1. 收到协调者询问之前<commit_msg>上机报告1<commit_after># ATM机模拟系统上机报告
## 小组名单及各自工作

## 协议设计
### 客户端如何定位服务器
客户端静态绑定服务器的IP与PORT,由于客户端与服务端中间加入了一个协调者（下文会提到），因此客户端实际上绑定的是协调者的地址与端口。
### 请求与响应流程的详细步骤
**客户端向服务器发送请求及得到结果的整个流程的详细步骤**

具体的操作有登录，取款，存款，转账：

#### 登录：
1. 客户端使用银行卡号与密码请求登录
2. 服务端收到请求后，验证银行卡号与密码
3. 验证成功后，服务端会签发一个 token，再把这个 token 发送给客户端；若验证失败，则返回错误原因
4. 客户端收到 token 后把它存储起来，每次向服务端请求资源的时候带着服务端签发的 token
5. 服务端收到请求后，验证客户端请求里面的 token
6. 服务端返回消息时，也会带上 token

关于参数 token:

* 每次打开客户端，都会发起登录请求，获取新的 token
* 因客户端崩溃导致 token 的存在，客户端登录成功后覆盖之
* 关闭客户端，即删除当前的 token

关于参数 deadline:

* 初始值为当前时间+一天(86400秒)
* 当前时间与 deadline 相差 300 的时候，客户端发起**续期**请求
* 当前时间大于等于 deadline 的时候，token 无效，服务端删除该值

其余操作详细过程类似

### 数据包的结构内容和解析方法
基于 TCP 的应用层协议。TCP 是基于点到点的可靠的传输层协议，无需考虑应用层协议的一致性问题。采用基于 Key-Value 模式的 JSON 数据格式实现。JSON有其固定的解析方式，大大简化了解析的工作。具体的数据结构实例在下文应用层实例中。
### 系统崩溃策略

使用**二阶段提交协议**解决事务操作中客户端或服务端崩溃的情况。二阶段提交主要保证了分布式事务的原子性，即所有节点要么全做要么全不做。

#### 基于以下假设:
* 该分布式系统中，存在一个节点作为协调者(Coordinator)，其他节点作为参与者(Cohorts)。且节点之间可以进行网络通信。
* 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上，即使节点损坏不会导致日志数据的消失。
* 所有节点不会永久性损坏，即使损坏后仍然可以恢复

#### 客户端与服务端二阶段提交协议具体步骤如下:
```
ATM request --> Coordinator
                      |
                      v
                 Transaction
ATM recv <-- First stage start     --> Server recv
 |                                        |
 | local transaction                      | local transaction
 |                                        |
 v                                        v
ATM send --> First stage complete  <-- Server send
                     |
                     v
ATM recv <-- Second stage start    --> Server recv
 |                                        |
 | complete                               | complete
 v                                        v
ATM send --> Second stage complete <-- Server send
```
**数据包格式如下:**

第一阶段提交:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| msg | JSON 数据 | 所执行的操作 |

第一阶段返回结果:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| status | 状态 | 执行结果 | |

第二阶段提交:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| status | 状态 | 0 代表执行，1 代表回滚 |

第二阶段返回结果:

| 参数 | 意义 | 备注 |
| ---- | ---- | ---- |
| sequence | 事务序列号 | |
| status | 状态 | 执行结果 | |
#### 考虑系统崩溃的时间段

ATM

1. 业务请求发送前
2. 业务请求发送之后，收到协调者询问之前
3. 收到协调者询问之后，发送 ACK 之前
4. 发送 ACK 之后，收到协调者确认之前
5. 收到协调者确认之后，发送 ACK 之前
6. 发送 ACK 之后，收到结果前
7. 收到结果后

Server

1. 收到协调者询问之前
{'fraction_non_alphanumeric': 0.12326795033291345, 'fraction_numerical': 0.008997660608241857, 'mean_word_length': 2.613784135240572, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 12, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '59255', 'n_tokens_mistral': 3817, 'n_tokens_neox': 4509, 'n_words': 355}