谈谈我对协议栈设计和架构的理解
转载于：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，这个不属于纯技术的范畴了，可能很多人对此也没多大兴趣了^&^。
---------------------------------------------------------------------------------------------------------------------------------------------------------------
其实我自己也是刚入了门，以后要深入下去的路还很长，有时间的话可以互相交流一下，我的邮箱：cache@163.com 。
[em02][em01]
抛砖只为引玉，但愿hero4422前辈能把自己这么多年来的一些体会和感悟写出来和大家分享一下，也为国内的通信软件事业发展添砖加瓦，先谢了！（我会时不时跑到坛子上来等的哦）
个人觉得做协议栈需要具备一些基本素质:
1：逻辑思维一定要强；
2：要熟读并理解好协议的资料；
3：根据资料理解掌握协议栈需实现的每一个功能；
4：将每一个功能按照协议的分层实现原理，做出每个功能的层次流程图；
5：根据层次流程图做出每一层的消息原语及消息元素；
6：将所有功能的流程图分层整合；做出每层的状态图；
7：做出每层的详细流程图；
8：考虑每层的消息交互中可能的异常，设置保护定时器，对异常做适当处理：
定时器的设置原则：
对于空口中的每一条消息或几条消息设置定时器保护（假想任一条消息丢失了，看流程中是否有保护，若没有就得设定时器保护）
以上仅是个人的一点愚见；欢迎讨论！！
[br]<p align=right><font color=red>+1 RD币</font></p>
>> 2：要熟读并理解好协议的资料；
>> 3：根据资料理解掌握协议栈需实现的每一个功能；
这应该属于“Know What”的过程，基本功确实省不得。
>> 4：将每一个功能按照协议的分层实现原理，做出每个功能的层次流程图；
>> 5：根据层次流程图做出每一层的消息原语及消息元素；
>> 6：将所有功能的流程图分层整合；做出每层的状态图；
>> 7：做出每层的详细流程图；
对以上4条的理解，是否遵循如下的流程：具体功能==>层次流程图==>层内消息原语/元素==>层内状态图==>层内详细流程图 ？
如果是的话，我感觉这种实施的流程有Use Case导向的迹象（“具体功能”是否指打电话、接电话这样的Use Case？），当然这从需求分析的角度来看确实可以这样操作的，不过除“具体功能”这个阶段的需求分析外，余下的系统摄接和实现过程似乎属于由繁至简的概括性思维方式，——个人愚见：在对协议内容和协议栈设计等关键知识点尚无经验的前提下，这种由繁至简的概括能总结出协议规范那样高度精炼的内容融概要（文字描述或State Chart / SDL图或MSC图等）吗？我觉得由宏观至微观、由简至繁的发散性思维方式可能更符合实际的思考过程，不过Hero前辈也是这个意思，只是没明确指出来。
>> 8：考虑每层的消息交互中可能的异常，设置保护定时器，对异常做适当处理：
对于异常情况的处理，可能比正常情况的处理更为复杂。定时器确实是一种防止异常情况的有效手段，不过我认为定时器针对的异常应该主要是物理层的收发状况/结果不确定造成的异常（任何无线甚至有线通信本质上都是不可靠的，都存在出错的可能性，因而需加以事先考虑），至于纯软件过纯协议逻辑造成的异常，用定时器的方法虽然也可以监视并处理（如坚实整个软件系统运行状况正常与否的看门狗，本质上还是一个定时器，只是这种定时器一旦溢出超时的话，就直接reset了），但是更根本的，可能还需要从协议逻辑本身（如状态机设计紊乱或有缺陷）和软件本身（如内存不足、堆栈溢出）分别预防并控制：前者的检验属于离散数学的范畴了，后者的检验则属于软件功底和修养的范畴了。
总的说来，实现同样的东西，各人的具体方法和流程可能是不完全相同的，求同存异、互相交流，相信能达到开拓思路、集思广益的目的。在此，谢过Hero前辈的热心指教了！[br]<p align=right><font color=red>+1 RD币</font></p>
说实话我一直很佩服能潜心埋头苦干的人，因为我自己不容易做到。
我很羡慕前辈能有这么丰富的开发经历，要是能够予以适时地总结、提炼、升华的话，对后来人真是功莫大焉啊！期待ing。。。
从这句话可以看出：
如：物理层给链路层发送1个slot的接收数据，链路层收到此数据后触发其下一步的动作，否则链路层在接收数据方面的操作会被挂起暂停，因而可以理解功能上的消息通信实则影响了时间上的执行状态）。从逻辑设计到实际实现的过程中，每个逻辑通信实体所对应的状态机很自然地会被考虑映射到RTOS的任务上去，这中间不一定是一对一的关系，某些情况下，出于任务粒度划分的考虑，有可能是一对多的。
slot 用的就是不懂装懂的典型。
是TIME SLOT吗？2G里面一个TIME SLOT的数据物理层实现时是不会单独传给链路层的，GSM是需要一帧的数据才有意义，构成FACCH或SACCH或DCCH的数据。GRPS需要4个连续帧的同一时隙号才组成一个无线块，物理层还需要均衡，信道解码，解交织，才能还原成链路层能识别的一个数据块。所以一个所谓SLOT物理层就给链路层一个数据，这种系统是无效的。楼主要装高级可以说FRAME或者RADIO BLOCK。
同篇没有什么技术含量，说了很多跟协议栈不粘边的。
鄙视一下，不要介意，做技术讲的就是实事求是，不谈虚的。
1，“做技术讲的就是实事求是”，这话放在哪里都适用，不过你可能自己都忘了一个事实，你所说的GSM/GPRS和我所暗指的PHS并非一码事，所以你要实事求是的话，就在共同的PHS基础上再讨论，如果你不熟悉这个的话，可以请教一下hero4422前辈，他是这方面的元老了。不要告诉我说2G只有GSM啊，PHS就不属于2G技术了^&^；
2，“面向对象的手段（如C++ JAVA），是没有用到过协议栈上的”，看你这么武断地把“面向对象的手段”就等同于C++、Java语言了，我真是有点担心。你不会不知道用C语言可以实现绝大部分的C++语言特性吧，最简单的如封装！你看过这么多家公司的协议栈代码确实很好，但是希望你不要只看到协议栈是用哪种语言写的，更要看清其设计思想和实现手段。将面向对象的思想和手段融入进协议栈设计实现的肯定是有的，因此希望你对系统设计的理解不要仅仅停留在编程语言的层面上；
我写这篇小文的目的只是为了把自己的一点点体会写出来，好让后来者能少走点弯路。我从来都知道在这方面比我经验丰富、比我修养高的人多的是，所以我也是抱着讨论、学习的态度来到52RD的。一个人乐于贡献的态度应该比他/她所贡献出来东西的质量高低更重要。轻率地妄下结论于事无补，于己也无利。
[align=right][color=#000066][此贴子已经被作者于2007-6-17 10:45:55编辑过][/color][/align]
这样说就让人觉得藐视一切哦.即使别人有一点没说到位也可以用好的语气吧
学习了。[em01]
我认为下面这位才是真正开发过协议栈的，或至少看过协议栈实现源代码的。
本人做过5年协议栈开发，期间开发过多个协议栈（BT、WiMax、UWB）。不过主要集中在数据链路层和MAC层。
楼主说了点基本的道理，但我认为实际动手做的经验不多，可能看spec比较多而已。
===================================================＝＝＝
楼主显然没有做过协议栈。也不懂协议。
从这句话可以看出：
如：物理层给链路层发送1个slot的接收数据，链路层收到此数据后触发其下一步的动作，否则链路层在接收数据方面的操作会被挂起暂停，因而可以理解功能上的消息通信实则影响了时间上的执行状态）。从逻辑设计到实际实现的过程中，每个逻辑通信实体所对应的状态机很自然地会被考虑映射到RTOS的任务上去，这中间不一定是一对一的关系，某些情况下，出于任务粒度划分的考虑，有可能是一对多的。
slot 用的就是不懂装懂的典型。
是TIME SLOT吗？2G里面一个TIME SLOT的数据物理层实现时是不会单独传给链路层的，GSM是需要一帧的数据才有意义，构成FACCH或SACCH或DCCH的数据。GRPS需要4个连续帧的同一时隙号才组成一个无线块，物理层还需要均衡，信道解码，解交织，才能还原成链路层能识别的一个数据块。所以一个所谓SLOT物理层就给链路层一个数据，这种系统是无效的。楼主要装高级可以说FRAME或者RADIO BLOCK。
同篇没有什么技术含量，说了很多跟协议栈不粘边的。
鄙视一下，不要介意，做技术讲的就是实事求是，不谈虚的。
“本人做过5年协议栈开发，期间开发过多个协议栈（BT、WiMax、UWB）。不过主要集中在数据链路层和MAC层。”，他曾经是我们的一个主要客户，我们提供基带芯片和协议栈，但绝对不是你假想的GSM，你是第二个先入为主、这般臆想的了，再来第三个我再也不会感到惊讶了!
只有协议栈的网络层我确实只看过没写过（太繁琐复杂），不过我最熟悉的是物理层和基带芯片本身，当然也不是GSM的！每个协议栈实现的方式不尽相同，以某个人的理解去推测其他人的情况不客观，抑彼未必能扬此，更何况我当初写小文的目的并非借此想显示什么，只是感叹国内比较核心的技术的交流比较少，所以斗胆写一下个人孔见，如能抛砖引玉，引来高人施手，众R&Der们幸莫大焉！期待你能根据曾经从事过的BT或WiMAX或UEB等把你的理解和体会比较完整的写出来，只言片语或一鳞半爪不足以解我辈之渴啊！
我现在已经不在通信行业了，事实上也基本脱离了纯技术的范畴。自古文人相轻，现今工程师相轻也颇烈，悲乎。。。人生大好时光，岂在争技术之一时之长短？！
时间有的时候能说明问题，但不见得都在一个点上。
回头学习学习这个帖子里讨论的内容。
感谢分享见解。
文人相轻的恶习我始终不能理解.
咱工程师讨论点技术问题为什么就不能以谦虚的态度来切磋呢~~
难道搞技术搞多了真的会目空一切.持才傲物?
有楼主这种胸怀的工程师就不能多点？
祝福楼主职业道路越走越好。。
对上面的问题提提自己粗浅的认识,实际上DataLink层每次发给物理层或者从物理层接收的都是一个信息单元,以GSM的NB为例,大部分是23个Octets的一个消息包,该消息包是从某个物理信道的一个块得到的.当然SB只需要一个Frame, 而大部分的块都是占用连续的四个Frame的.(其中的某个物理信道), 而物理信道则对应相应的TimeSlot, 例如SI都是从TS0得到的等等.
[em01]
And then, to update!!
第一次到这个版块，近来刚刚接触协议栈方面开发东西～
谈谈我对协议栈设计和架构的理解相关推荐
- 诊断（UDS）协议栈设计-总体架构设计
1 概述 车辆总线协议(VBP)组件是指符合ISO14229-1.ISO15765-3.ISO15765-2等一系列汽车标准协议的集合,并支持OSEK NM.AUTOSAR NM等网络管理协议. 诊断 ...
- 谈谈你对MVC和三层架构的理解？（月薪三万的面试题）
V 是皮肉,是看到的东西 M 是骨骼,是里面真实的东西 C 就是连接皮肉和骨骼的筋 对于界面设计可变性的需求,MVC把交互系统的组成分解成模型.视图.控制三种部件. 模型部件是软件所处理问题逻辑在独立 ...
- SPA设计与架构-理解单页面Web应用 (埃米顿.A斯科特) 中文pdf扫描版
SPA 开发技术的运用是当今Web 开发领域的热门趋势,但真正全面掌握该技术的开发者并不多.本书详尽阐述单页面Web 应用(SPA)开发技术,从SPA 构建基础入手,通过MV*.模块化编程.路由.模块 ...
- Java生鲜电商平台-团购模块设计与架构
Java生鲜电商平台-团购模块设计与架构 说明:任何一个电商系统中,对于促销这块是必不可少的,毕竟这块是最吸引用户的,用户也是最爱的模块之一,理由很简单,便宜. 我的经验是无论是大的餐饮点还是小的餐饮 ...
- 架构设计(5)—架构愿景分析
架构设计学习思维导图: 架构设计系列主要的ADM(架构开发方法)主要基于TOGAF9或者TOGAF9.1来论述.这是个人学习实践和总结笔记,专注并不断积累和更新,努力精进自己.个人拙见,仅供参考. 1 ...
- 电商平台-团购模块设计与架构
说明:任何一个电商系统中,对于促销这块是必不可少的,毕竟这块是最吸引用户的,用户也是最爱的模块之一,理由很简单,便宜. 我的经验是无论是大的餐饮点还是小的餐饮店,优惠与折扣永远是说福他们进入平台的最好 ...
- java 团购开发_Java生鲜电商平台-团购模块设计与架构
Java生鲜电商平台-团购模块设计与架构 说明:任何一个电商系统中,对于促销这块是必不可少的,毕竟这块是最吸引用户的,用户也是最爱的模块之一,理由很简单,便宜. 我的经验是无论是大的餐饮点还是小的餐饮 ...
- Java生鲜电商平台-监控模块的设计与架构
点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 来源:https://www.cnblogs.com/ ...
- 插件式设计的架构模型与实例
插件式设计近年来非常流行,其中eclipse起了推波助澜的作用,提到插件式就会不由自主的想到eclipse.其实插件式设计并不是什么新事物,早在几十年前就有了.像X Server就是基于插件式设计的, ...
最新文章
- 解决IDEA中，maven依赖不自动补全的问题
- actuator的原理_使用Spring Boot Actuator监视Java应用程序
- python自动化办公 书籍-python自动化办公知识点整理汇总
- 深度学习核心技术精讲100篇（七十四）-教你如何最快入门用户画像
- 不同对象的通话是时长
- 实例14:python
- 如何领导团队做好技术债管理？
- html图标框架中文版,常见css框架有哪些？
- GPS时间服务器在电力监控系统中的应用方案
- HTTP 错误 500.19 Internal Server Error的解决方法
- (转)机器学习入门，强烈推荐
- emacs之配置代码风格
- 人体的神经系统图 分布,人体神经图分布图高清
- 中国各省市及省会城市名称的由来
- 20155201 2016-2017-2 《Java程序设计》第六周学习总结
- hp服务器安装系统分区,hp 服务器分区
- trimmed ICP运行出现“aux”、“transform“的error
- 28 爬虫 - re 正则 匹配中文
- SystemUI（一）基于Android9.0SystemUI的启动与定制化
- 【Win 10 应用开发】在代码中加载文本资源