标签: 协议解析

  以前需要写一个协议的解析程序。开始没有感觉会有多麻烦，感觉就是按照协议说的一步步走下去就行了。在写的过程中，慢慢发现没有自己想的那么简单。由于以前没有写过这方面的程序，在一开始就陷入了误区。对于上行数据，与下行数据的解析的描述，自己就搞错了。一直看着下行数据的描述，去想上行数据的代码怎么从数据中提取出来。开始忙了一周，程序还是很混沌。   第二周在将协议看了看，又问了问同事，才闹明白了自己所操作的主要接收下行数据，所以主要负责对下行数据的解析。知道上边发下的命令后，在组织一段上行数据发出去。如此就是一个解析程序。如此一个循环，即解析了下行数据。之后自己总结了当时理解的：   什么是协议解析？   将发送方发过来的数据，依照协议的要求规则进行数据的翻译，找出发送方要求接收方实现的动作，接收方将动作完成（给发送方回复它需要的数据，ACK或相应的数据记录）。   当时没有考虑，一个节点可能即要解析下行数据，又要解析上行数据。这样自己最早写的代码，就不能用了。因为它主要解析下行协议，对于接收的上行协议，没有解析。因为当时没有想到要接收上行数据，认为就是一个终端了。   现在在想如果这个节点只是通信中的一个既要负责接收下行数据，又要对别的节点发过来的上行数据做出反应，那样的协议解析程序，才算是比较完整的。   现在自己理解的一个协议的解析程序是这样组织：   1、发出数据的打包：   首先组织一个数据帧，打包函数将此帧依照协议的帧结构，将其解析到一个数组中，计算出长度，将其发送出去。   2、接收数据的解析：   有数据接受时，首先判断此数据是否为正确的帧（符合协议要求的校验规则），之后解析出功能码（或者到数据标识），在功能码解析函数中，依据协议的上下行标志，调用相应的代码进行数据解析。（这样即可以解析下行数据，也可以解析上行数据，构成一个完好的正解析模块）   补充 ：在解析接收过来的数据时，首先判断一下长度，对于长度不符合的可以跳出。有时候如果不判断这个，可能造成以后在判断时出现错误。   如何写协议解析程序：   读协议时，首先分析整个帧的结构，了解帧有几部分组成，各个标识是什么，含义什么。例如：长度，控制字，等一些关键信息的分析。   之后，了解它们具有的功能项，根据功能项的描述找到可能用到的功能项，并具体分析这些功能项的结构，与字节代表的意义。 到这里可以确定，帧的结构，使用到的功能项，并且已经有所了解。   然后根据帧结构，构建帧的打包与解析函数的框架，根据具体功能项，细化解析函数。   确定好框架后，开始编码，根据功能项的字节定义读取出帧数据中的信息，但是对于这些信息的处理，交由传入的函数处理，因为对于这些信息的处理可能会有不同，交由外部实现，一来简化协议内部的编码，二来增加协议解析处理的灵活性。   当然这些只是自己的理 解。