网络仿真中的有限状态机（FSM）

最近在看《OMNET++ User Mannul》，了解到了有限状态机的工作机制。相比早之前看过的《OPNET xxx》教材中讲解FSM不明不白，《OMENT++ User Mannul》讲解的更为清晰简洁，且有偏底层的代码做实例，更易理解。

 

FSM是指完成模块功能的一种手法（例如OMNET++中的模块功能可选择是否由FSM完成），下文的FSM均指模块中的FSM。

 

构成FSM的主体为状态（State）和状态跳转（State Transition），其中状态分为两种：1）稳定状态；2）临时状态。每个状态拥有进入（Enter）和离开（Exit）操作，各对应一段代码，也就是OPNET中状态圆圈的上半圆和下半圆。介绍FSM之前，先给一个结论，在设计FSM时，稳定状态必须使用，临时状态可用亦可不用。

 

1）稳定状态：在进入稳定状态时，执行稳定状态的Enter代码。接着此FSM就中断运行（向调度器交出代码执行权），直到下次新的Event抵达这个模块，执行此稳定状态的Exit代码，执行完毕后跳转到其他状态（当然也可以跳回自个）。

2）临时状态：执行Enter代码，接着立即执行Exit代码，跳转到其他状态（也能跳回自个）。

 

可以看到，临时状态仅仅是代码的执行，并不受Event的影响；而稳定状态则受Event影响。考虑到事件驱动仿真器的工作流程大致是：调度器中取出Event --> 将消息传递给Event所属的模块 --> 执行模块的消息处理函数 --> 执行完毕后，将执行权重归调度器。

 

根据工作流程，每个模块实现的关键且必须之处在于：1）当调度到相关Event时，才会进入模块执行；2）模块必须有执行退出点，将执行权交回调度器。由于仅稳定状态可使FSM运作停止，交出执行权，因此FSM中必须包含稳定状态，且FSM停止（退出模块）一定发生在稳定状态的Enter之后；FSM唤醒（模块被调度）必然发生在稳定状态的Exit之前（Init状态除外）。

 

在事件驱动仿真器中，Event可是整个仿真运行被调度时的主体，仿真的执行（具体执行哪个模块的代码）和仿真的时间完全是由Event控制的。缺乏Event直接影响的临时状态，作用仅仅是作为一段功能代码而已，存在的意义在于简化稳定状态和编写FSM更灵活。由于临时状态的存在，可带来如下好处：

1）可将稳定状态中的部分功能移至临时状态中；

2）将重复功能交给临时状态实现，减少稳定状态中代码的重复度；

3）增加了状态数量，使得状态跳转的设计更为灵活，且跳转条件的设计更为简单。

 

状态跳转就容易理解了，是指状态执行完Exit代码后，必须做一次状态跳转，直到跳转到一个稳定状态（Enter代码执行完后，FSM就会停止运行，交出运行权）。

 

了解了上述原理后，如何规避FSM陷进就不会纯抓瞎。我所了解的陷进包括：1）无穷跳转循环；2）FSM唤醒后，当前稳定状态的Exit代码不能处理Event中的msg。如果踩到这两个雷，那就想象一下FSM的运作过程，进行排雷。

 

在设计FSM时，OPNET有界面，OMNET++为纯代码编写。界面使得OPNET中状态跳转显示非常直观，当状态或跳转较多时非常受用，而OMNET++中就得拿出笔在纸上画。此外，OPNET的开发流程决定了模块开发必须使用FSM；而OMNET++则并不是必须。难道是两者所谓的philosophy不一样？

转载于:https://www.cnblogs.com/hellowangsai/p/3911217.html