网络软件设计10——有状态设计
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
接收方
9
段景山
停等协议状态机
超时 发送方
重发帧1
接收方
收到ACK
并准备好 一个帧 发送帧0
准备 发送帧0
准备 发送帧1
收到ACK
并准备好一 帧数据 发送帧1
收到帧0 发送ACK 帧0上交
等待 接收帧0
等待 接收帧1
收到帧1 发送ACK 帧1上交
超时 重发帧0
10
段景山
有限状态机小结
状态
状态是复合的
case 事件1:
state = initial;
if（当前状态==X）{ action 1; next_state = xxx;
}
while(1){ waite for a event; state = fsm(state,event);
case 事件2:
}
……
}
default：ignore；
} return next_state; }
由多个要素形成 如：准备发送帧0状态
▪ 刚发送了帧1 ▪ 上层有一个待发的SDU
状态1
－/－
x
状态2
▪ 收到了对前一帧的应答
▪ 等待刚发送的帧的应答还没有超时
系统的状态是稳定的
不触发就不变化
制定状态的结果可能不唯一
11
段景山
有限状态机小结
事件
转换的输入条件
若是别的状态的动作造成转换，则跃迁的状态是不稳定 状态，不应出现
可以是对等实体的动作
状态机一次只处理一个事件
如果有必要处理多个事件，应定义为复合事件
事件1/动作1
状态1
，动作2
状态2
事件2 （动作1)/动作2
状态3
事件2/动作2
状态1 事件1/动作1
事件13,事件2 /动作3
12
段景山
有限状态机小结
动作
动作一定由事件触发
不触发就自发产生动作是不稳定状态
无状态服务器
不保存状态信息的服务器程序
例：聊天应用
2
段景山
有状态服务
为什么要求设计有状态服务器
任务需求 可以减少报文开销（利用报文间的相关性）
有状态服务器面临的问题
增加实现的复杂程度 需要复杂的协议控制 系统在多个状态下转换时，可能因错误事件而导
致：进入非期望状态、死锁、崩溃 可以设计有限状态机来指导软件实现
下一状态 连接建立
事件2 … …
事件3 … 事件n …
处理
…
…
连接建立
下一状态
处理
状态n
下一状态
14
段景山
状态转移表
停等协议的状态转移表
超时 重发帧1
准备 发送帧0
收到ACK 发送帧0
收到ACK 发送帧1
准备 发送帧1
超时 重发帧0
状态
事件 事件1
动作
状态1
处理
…
下一状态 …
状态2
处理 下一状态
3
段景山
无状态是一个协议问题
为什么要设计无状态服务
任务需求 服务实现简单，可靠性强 一个报文的意义不依赖先前的报文－－状态的依
赖性
究竟网络应用软件是有状态的还是无状态的
从系统的角度，系统是“无状态”的
系统能不断为各次通信服务
从功能实现角度，复杂的通信应采用有状态方法 设计
4
段景山
…
状态n
处理 下一状态
事件2 … 事件n …
准备发帧 0
准备发帧 1
处理 下一状态
处理 下一状态
收到ACK 超时
发送帧0 重发帧1
准备发帧1
/
发送帧1 重发帧0
准备发帧0
/ 15
段景山
状态转移表
停等协议的状态转移表
等待帧0
收到帧0 发送ACK
收到帧1 发送ACK
状态
事件 事件1
动作
状态1
处理
…
下一状态 …
fsm.c
17
段景山
改进的fsm程序框架
x_fsm(事件) {
switch( 事件）{
case 事件1:
action 1; next_state = xxx;
} case 事件2:
…… default：ignore；
} return next_state; }
main(){ state = initial; while(1){ waite for a event; switch（state）{ case X: state = x_fsm(event); case Y: state = y_fsm(event); … } }
动作：
处理队列中的一个事件，转移到下一状态
不同状态下，对同一事件可能有不同的处理方法
最简动作：忽略事件，保持状态（图中可省略不画）
事件e1 / 动作a1
状态1
事件e2 / 动作a2
状态2
事件e3 / 动作a3 6
段景山
例 以停等协议为例，讲解利用有限状态机实现
有状态设计
发送方发送完一个数据包后，需得到接收方的确 认才能发送下一个数据包
状态2
处理 下一状态
…
状态n
处理 下一状态
事件2 … 事件n …
等待帧1
等待帧0 等待帧1
收到帧0 收到帧1
处理 发送ACK
/
下一状态 等待帧1
/
处理
发送ACK
下一状态
等待帧0 16
段景山
fsm程序框架
根据状态转移表形成fsm程序可能的框架
fsm( 当前状态,事件 ）
{
switch( 事件）{
main(){
若接收方超时没有确认，发送方将重传
7
段景山
停等协议的状态机（1）
协议实体
上层DU
递交
状态机 （Ns, Nr）
发送
接收
PDU、ACK To：对等实体
PDU、ACK From：对等实体
状态机的位置
8
段景山
停等协议（2） 状态的确定
准备发送帧1 准备发送帧0
发送方
0 ACK
1
ACK
等待帧0 等待帧1
有限状态机
一种直观、全局、准确的协议描述方法
状态 转换 事件 动作
缺点 时序 性不 强
5
段景山
有限状态机的基本结构
状态：
Fra Baidu bibliotek
事
实体有有限个状态
件
每一时刻，实体只处于其中一个状态
事件：
事件引起实体产生动作，如收到PDU、定时器到时等
事件按发生的顺序排在事件队列中，等待处理
FSM
事件可能有附加条件
网络软件设计
服务器的有状态与无状态 有状态协议设计
制作 主讲
段景山
段景山
有状态与无状态服务器
状态
由服务器维护的，关于服务器与客户机正在进行 的交互 的信息称为状态
“信息”不是指服务器和客户机交互的数据，而 是关于交互过程本身
有状态服务器
保存状态信息的服务器程序
例：认证服务器需要记录与客户交互的状态－－正在认 证（等待用户名、等待口令）、已认证等
某些转换不一定产生动作，动作不一定伴随状态 转换
触发不一定有动作产生，不一定造成状态转换
状态1 －/动作1 x
事件3/－ 状态1 事件1/－
事件2/动作2
13
段景山
有限状态机的作用(1)
指导协议实现
根据有限状态机形成状态转移表 状态转移表
状态
关闭
事件 命令：
动作
Open
处理
发送： ConnReq
}
9
段景山
停等协议状态机
超时 发送方
重发帧1
接收方
收到ACK
并准备好 一个帧 发送帧0
准备 发送帧0
准备 发送帧1
收到ACK
并准备好一 帧数据 发送帧1
收到帧0 发送ACK 帧0上交
等待 接收帧0
等待 接收帧1
收到帧1 发送ACK 帧1上交
超时 重发帧0
10
段景山
有限状态机小结
状态
状态是复合的
case 事件1:
state = initial;
if（当前状态==X）{ action 1; next_state = xxx;
}
while(1){ waite for a event; state = fsm(state,event);
case 事件2:
}
……
}
default：ignore；
} return next_state; }
由多个要素形成 如：准备发送帧0状态
▪ 刚发送了帧1 ▪ 上层有一个待发的SDU
状态1
－/－
x
状态2
▪ 收到了对前一帧的应答
▪ 等待刚发送的帧的应答还没有超时
系统的状态是稳定的
不触发就不变化
制定状态的结果可能不唯一
11
段景山
有限状态机小结
事件
转换的输入条件
若是别的状态的动作造成转换，则跃迁的状态是不稳定 状态，不应出现
可以是对等实体的动作
状态机一次只处理一个事件
如果有必要处理多个事件，应定义为复合事件
事件1/动作1
状态1
，动作2
状态2
事件2 （动作1)/动作2
状态3
事件2/动作2
状态1 事件1/动作1
事件13,事件2 /动作3
12
段景山
有限状态机小结
动作
动作一定由事件触发
不触发就自发产生动作是不稳定状态
无状态服务器
不保存状态信息的服务器程序
例：聊天应用
2
段景山
有状态服务
为什么要求设计有状态服务器
任务需求 可以减少报文开销（利用报文间的相关性）
有状态服务器面临的问题
增加实现的复杂程度 需要复杂的协议控制 系统在多个状态下转换时，可能因错误事件而导
致：进入非期望状态、死锁、崩溃 可以设计有限状态机来指导软件实现
下一状态 连接建立
事件2 … …
事件3 … 事件n …
处理
…
…
连接建立
下一状态
处理
状态n
下一状态
14
段景山
状态转移表
停等协议的状态转移表
超时 重发帧1
准备 发送帧0
收到ACK 发送帧0
收到ACK 发送帧1
准备 发送帧1
超时 重发帧0
状态
事件 事件1
动作
状态1
处理
…
下一状态 …
状态2
处理 下一状态
3
段景山
无状态是一个协议问题
为什么要设计无状态服务
任务需求 服务实现简单，可靠性强 一个报文的意义不依赖先前的报文－－状态的依
赖性
究竟网络应用软件是有状态的还是无状态的
从系统的角度，系统是“无状态”的
系统能不断为各次通信服务
从功能实现角度，复杂的通信应采用有状态方法 设计
4
段景山
…
状态n
处理 下一状态
事件2 … 事件n …
准备发帧 0
准备发帧 1
处理 下一状态
处理 下一状态
收到ACK 超时
发送帧0 重发帧1
准备发帧1
/
发送帧1 重发帧0
准备发帧0
/ 15
段景山
状态转移表
停等协议的状态转移表
等待帧0
收到帧0 发送ACK
收到帧1 发送ACK
状态
事件 事件1
动作
状态1
处理
…
下一状态 …
fsm.c
17
段景山
改进的fsm程序框架
x_fsm(事件) {
switch( 事件）{
case 事件1:
action 1; next_state = xxx;
} case 事件2:
…… default：ignore；
} return next_state; }
main(){ state = initial; while(1){ waite for a event; switch（state）{ case X: state = x_fsm(event); case Y: state = y_fsm(event); … } }
动作：
处理队列中的一个事件，转移到下一状态
不同状态下，对同一事件可能有不同的处理方法
最简动作：忽略事件，保持状态（图中可省略不画）
事件e1 / 动作a1
状态1
事件e2 / 动作a2
状态2
事件e3 / 动作a3 6
段景山
例 以停等协议为例，讲解利用有限状态机实现
有状态设计
发送方发送完一个数据包后，需得到接收方的确 认才能发送下一个数据包
状态2
处理 下一状态
…
状态n
处理 下一状态
事件2 … 事件n …
等待帧1
等待帧0 等待帧1
收到帧0 收到帧1
处理 发送ACK
/
下一状态 等待帧1
/
处理
发送ACK
下一状态
等待帧0 16
段景山
fsm程序框架
根据状态转移表形成fsm程序可能的框架
fsm( 当前状态,事件 ）
{
switch( 事件）{
main(){
若接收方超时没有确认，发送方将重传
7
段景山
停等协议的状态机（1）
协议实体
上层DU
递交
状态机 （Ns, Nr）
发送
接收
PDU、ACK To：对等实体
PDU、ACK From：对等实体
状态机的位置
8
段景山
停等协议（2） 状态的确定
准备发送帧1 准备发送帧0
发送方
0 ACK
1
ACK
等待帧0 等待帧1
有限状态机
一种直观、全局、准确的协议描述方法
状态 转换 事件 动作
缺点 时序 性不 强
5
段景山
有限状态机的基本结构
状态：
Fra Baidu bibliotek
事
实体有有限个状态
件
每一时刻，实体只处于其中一个状态
事件：
事件引起实体产生动作，如收到PDU、定时器到时等
事件按发生的顺序排在事件队列中，等待处理
FSM
事件可能有附加条件
网络软件设计
服务器的有状态与无状态 有状态协议设计
制作 主讲
段景山
段景山
有状态与无状态服务器
状态
由服务器维护的，关于服务器与客户机正在进行 的交互 的信息称为状态
“信息”不是指服务器和客户机交互的数据，而 是关于交互过程本身
有状态服务器
保存状态信息的服务器程序
例：认证服务器需要记录与客户交互的状态－－正在认 证（等待用户名、等待口令）、已认证等
某些转换不一定产生动作，动作不一定伴随状态 转换
触发不一定有动作产生，不一定造成状态转换
状态1 －/动作1 x
事件3/－ 状态1 事件1/－
事件2/动作2
13
段景山
有限状态机的作用(1)
指导协议实现
根据有限状态机形成状态转移表 状态转移表
状态
关闭
事件 命令：
动作
Open
处理
发送： ConnReq
}