阿冬对协议栈设计和架构的学习-------阿冬

我对协议栈设计和架构的理解

转自：http://blog.csdn.net/findaway123/article/details/18097273

转载于：http://www.52rd.com/bbs/Archive_Thread.asp?SID=54542&TID=2

因为工作的关系，有幸接触到一种不那么复杂的2G通信技术的协议栈（终端）和基带两方面的内容，经过一段较长时间的摸索和思考，再加上和终端厂商一线开发人员的的讨论深化，到现在总算对协议栈设计和架构方面有了一些比较粗浅的想法。

因为我的工作内容重点在于基带硬件（也涉及RF模块）和协议栈的（物理层+链路层，对于网络层的协议细节则不太熟悉），所以我这不多的想法也是集中在我所从事过的这些方面。
接下去的详细论述是从协议栈设计和架构方面去着眼的，从软件工程的角度来说顶多进行到概要设计那个阶段:-）
1，从协议规范的学习理解到协议栈的设计架构。
1.1 对于移动通信终端协议，首先去了解并理解协议规范的具体内容是最最基本的，这是个know what的过程，如果不做协议栈设计和实现的话，一般到这个程度也就差不多了；
1.2 知道并熟悉了协议规范的描述后，接下来就可以去考虑如何设计协议栈框架了，这是个know how的过程。
      协议规范一般会以自然语言和形式化语言两种方式去描述定义：自然语言有利于理解，但是定义不严格，理解起来有时会导致歧义性，于是各种形式化语言就作为必要的成分参与其中了。从协议的整体来看，我觉得“状态机”是个非常重要的概念和思想，虽然它离实际的协议栈实现还有一点点距离。从状态机可以衍生出SDL图和MSC图等等较严格规范化的形式化定义：
〉〉SDL侧重于从系统状态的变化角度去描述和定义单个系统的行为，这里“系统”的概念比较灵活，一个协议层可视为一个系统，多个系统的集合也可视为一个更大的系统，划分和界定系统主要是为了将概念域的“系统”映射到设计域的“状态机”（设计域的“状态机”接下来将被映射到实现域的“状态机实现”，具体的实现方式有“状态—事件表”法、“Switch-Case”法等）；
〉〉MSC图侧重于从多个系统间消息交互（包含消息内容和特定消息的传递顺序两方面的内容）的角度去描述和定义系统间的行为，这里的系统可能是一个物理通信实体（如终端或基站）内部的某个协议逻辑层系统，也可能是整个物理通信实体本身，当然准确地说在通信协议栈的规范和实现中，物理通信实体一般都会被划分为多个逻辑通信实体去分别对待的，而不会像在通常口头所说的终端和基站通信这么简单、笼统。
关于“状态机”概念，稍微深入下去讨论的话，我个人的理解是：状态机是状态和事件以及事件对状态的驱动规则的集合，前两个元素基本上可看作是静态的，而事件对状态的驱动规则可看作是动态的，这样的话“状态机”就可以理解为静、动结合的一个逻辑实体，当然用面向对象的思想去看待“状态机”这样一个逻辑实体的话，很容易地就会把它理解成一个对象，——在协议栈设计和实现的过程中，确实可以借用面向对象的方法（思想层面上）或手段（实现层面上），这样的话协议栈的结构和逻辑会更清晰。
通常我们所讨论和理解的“状态机”多是单层、扁平的状态机模型，此外对状态机概念的一个发展是“层次状态机”的概念：单层状态机概念是在将系统划分为一个个相对孤立的系统的前提下、将系统从概念域映射到设计域后得到的，而客观上，各个系统间并非都是完全孤立的，有的系统间存在逻辑上的包含与被包含关系，因而考虑到概念域的这种联系，在设计域也有必要将状态机在逻辑上进行层次划分，这种想法和面向对象思想中的继承是非常相像的，甚至多态的概念也可以加入到此中来。关于层次状态机的详细论述，可参考《嵌入式系统的微模块化程序设计——实用状态图C/C++实现》一书，作者是美国的一个资深工程师，书里面的内容我个人理解应该是经验之谈，不过我只吸收了其中的“层次状态机”这个核心思想，至于具体的代码实现细节，我没仔细去看了^&^。
在对协议栈的设计和架构有了总体的认识后，尝试着慢慢去把这些认识具体化就是件水到渠成的事情了。就个人体验而言，Visio用在这方面真是很不错，我尝试过用WORD画状态机图和SDL图、用Excel画MSC图，但是因为数据格式不统一而导致的内容分散，所以很难把自己的理解和想法在一种单一类型的文档中集中体现出来，而Visio的多页编辑功能和丰富灵活的编辑方式恰好满足了我的这种需求（Tips：平时有什么想法的话也可以在Visio里涂涂画画，想法变了可以再改，Visio给你提供足够的自由度：-）。
1.3 经过上面的两步工作，一个基本的协议栈架构和模型差不多就能出来了，不过在具体实现前，为了尽可能的避免一些理解的偏差或提高系统设计的质量，花些心思去理解或猜测协议规范为什么设计成现在的这个样子是很有意义的，这是个know why的过程，虽然都是去了解和理解协议，但是能达到know why的高度则非常厉害了，不过这个过程是个周而复始、循环上升的过程，需要长期不断地积累：在具体实现和运行之前，可以依托广泛的知识背景和高超的个人理解力去理解或猜测协议设计背后的思想或考虑，但是很多这方面的知识和经验是要等到协议真正实现运行了后，在调试和实测中发现问题、总结经验后才能逐步深化的，这些深化了的理解反过来可以指导前期的设计以提高系统设计的质量。所以要自行开发协议栈的话，我觉得在设计—〉实现这条路上不宜坚持一步走到底的“美好”想法，反过来若是以原型化的方法先开发一个简易的Demo，然后通过调试和测试不断地去细化和完善，这样协议栈开发成功的可能性会增大、总的开发周期也有可能会缩短。形象地说，是先搭骨架，再添器官，最后加肌肉和血管，这样一个有血有肉、鲜活的生命体就诞生了：-）
2，从协议栈的设计架构到协议栈的实现调试
这里的“实现”是指在软件级的实现，包括RTOS的选择、系统任务的划分和通讯机制的选择安排、以及最后的编码调试。

如前所述，一个完整的通信过程中会牵涉到不同逻辑通信实体间的信息交互（从终端用户的角度看，看到的是不同物理通信实体间的信息交互），各个不同的逻辑通信实体在整个的通信系统中既保持一定的独立性（这是状态机赖以存在的基石），又和其他逻辑通信实体存在一定的联系（这是整个系统得以实现通信功能的所在），因而在实际实现和运行中需要考虑怎样去协调这些逻辑通信实体间的行为（广义地说，逻辑通信实体间的通信也是为了协调逻辑通信实体间的执行顺序，如：物理层给链路层发送1个slot的接收数据，链路层收到此数据后触发其下一步的动作，否则链路层在接收数据方面的操作会被挂起暂停，因而可以理解功能上的消息通信实则影响了时间上的执行状态）。从逻辑设计到实际实现的过程中，每个逻辑通信实体所对应的状态机很自然地会被考虑映射到RTOS的任务上去，这中间不一定是一对一的关系，某些情况下，出于任务粒度划分的考虑，有可能是一对多的。

由于每个RTOS提供的任务同步和任务间通讯方式差异较大，所以在这里讨论以何种具体的任务同步和任务间通讯方式去实现两个特定逻辑通信实体间的同步和通信意义不大，据我所知道的日本比较流行的iTRON规范中，常见的有信号量（Mutex、Semphore）、事件标志、邮箱（适合大信息量的任务间通讯）、消息缓冲（适合中、小信息量的任务间通讯）这几种，至于会合，有些符合iTRON规范的RTOS中并未实现。
协议栈的调试是件烦人的事情，有时会因为一个小小的错误折腾很多天而不得其解，有时甚至会被逼得考虑重新设计状态机，这个过程很折磨人，也很锻炼人，协议栈实现能力和调试水平的提高，在这个过程中可以得到深化和升华，这可能也是TTPCOM这样的专业协议栈软件公司的经验和长处所在了：-）

后记：
写了这么多，虽然文字量不太大，但是涉及的内容面挺广，因而写完后还是感觉有点累！
我这人比较懒，有想法一般都在脑子里打转或在嘴上和人家说，不太习惯用文字的形式把它固化下来（敲字太累！图表倒是经常用，因为我把那个看作是思维的延伸:-）

因为我也是第一次接触无线通信终端协议栈和基带方面的内容，所以在无线通信协议上的经验和理解有限，2G里面我只碰过这个，不知道将来在3G领域有没有机会再碰碰。

协议栈的设计和实现与一般的软件系统开发不太一样，不过它有一套自身特有的模式，一旦接触过并掌握了这个模式后，以后再开发其他无线通信协议栈的话，难度应该会降低很多。而且协议栈开发中某些过程确实是可以模式化且能以CAD的形式实现出来的，如Telelogic的Tao据说就能根据SDL图自动生成C代码，其实这种转化并不难。

谈到CAD这块，有必要提提ITU在通信协议规范方面所做的形式化语言定义工作：从ASN.1对PDU（Protocol Data Unit）的定义，到SDL对状态机的定义，再到MSC对消息交互流程的定义，直到TTCN等对协议测试的定义等等。对这些形式化语言，我只是很粗略地看了看，有兴趣学习研究的朋友可以去ITU的网站上下载。

“话不说不明，理不辩不清”，欢迎其他对协议栈感兴趣的朋友积极讨论，以加深或纠正各自对这方面的理解。以后如有时间的话，可以再开个话题讨论协议栈开发和应用过程中的Troubleshooting，这个不属于纯技术的范畴了，可能很多人对此也没多大兴趣了^&^。

---------------------------------------------------------------------------------------------------------------------------------------------------------------

做协议栈的一点体会：
   个人觉得做协议栈需要具备一些基本素质:
        1：逻辑思维一定要强；
        2：要熟读并理解好协议的资料；
        3：根据资料理解掌握协议栈需实现的每一个功能；
        4：将每一个功能按照协议的分层实现原理，做出每个功能的层次流程图；
        5：根据层次流程图做出每一层的消息原语及消息元素；
        6：将所有功能的流程图分层整合；做出每层的状态图；
        7：做出每层的详细流程图；
        8：考虑每层的消息交互中可能的异常，设置保护定时器，对异常做适当处理：
   定时器的设置原则：
         对于空口中的每一条消息或几条消息设置定时器保护（假想任一条消息丢失了，看流程中是否有保护，若没有就得设定时器保护）
       以上仅是个人的一点愚见；欢迎讨论！！
[br]<p align=right><font color=red>+1 RD币</font></p>

---

zhiyunli Post at 2007-3-20 20:19:53

>> 1：逻辑思维一定要强；
>> 2：要熟读并理解好协议的资料；
>> 3：根据资料理解掌握协议栈需实现的每一个功能；

这应该属于“Know What”的过程，基本功确实省不得。

>> 4：将每一个功能按照协议的分层实现原理，做出每个功能的层次流程图；
>> 5：根据层次流程图做出每一层的消息原语及消息元素；
>> 6：将所有功能的流程图分层整合；做出每层的状态图；
>> 7：做出每层的详细流程图；

对以上4条的理解，是否遵循如下的流程：具体功能==>层次流程图==>层内消息原语/元素==>层内状态图==>层内详细流程图 ？
如果是的话，我感觉这种实施的流程有Use Case导向的迹象（“具体功能”是否指打电话、接电话这样的Use Case？），当然这从需求分析的角度来看确实可以这样操作的，不过除“具体功能”这个阶段的需求分析外，余下的系统摄接和实现过程似乎属于由繁至简的概括性思维方式，——个人愚见：在对协议内容和协议栈设计等关键知识点尚无经验的前提下，这种由繁至简的概括能总结出协议规范那样高度精炼的内容融概要（文字描述或State Chart / SDL图或MSC图等）吗？我觉得由宏观至微观、由简至繁的发散性思维方式可能更符合实际的思考过程，不过Hero前辈也是这个意思，只是没明确指出来。

>> 8：考虑每层的消息交互中可能的异常，设置保护定时器，对异常做适当处理：

对于异常情况的处理，可能比正常情况的处理更为复杂。定时器确实是一种防止异常情况的有效手段，不过我认为定时器针对的异常应该主要是物理层的收发状况/结果不确定造成的异常（任何无线甚至有线通信本质上都是不可靠的，都存在出错的可能性，因而需加以事先考虑），至于纯软件过纯协议逻辑造成的异常，用定时器的方法虽然也可以监视并处理（如坚实整个软件系统运行状况正常与否的看门狗，本质上还是一个定时器，只是这种定时器一旦溢出超时的话，就直接reset了），但是更根本的，可能还需要从协议逻辑本身（如状态机设计紊乱或有缺陷）和软件本身（如内存不足、堆栈溢出）分别预防并控制：前者的检验属于离散数学的范畴了，后者的检验则属于软件功底和修养的范畴了。