协议设计小记

前天周二晚上做代码review时候，代码里面有部分在处理接收协议数据包的代码，对协议的处理代码基本全部揉在一起了；可能是项目在开始的时候没有考虑周全，又或者在项目开发过程中因为需求的变更，改的面目全非。当时就在想这个地方有点不太对，应该要做拆分，但没想好怎么拆；回家之后总结了几个常见的协议，总结下，或者这应该就是和协议设计有关，协议应该设计得让程序容易去分层，分模块。

那协议的设计是否应该让程序更加的容易去分层，分模块？

举例常见协议：

• TCP/IP协议栈
• HTTP协议
• MQTT协议
• DBus协议

TCP/IP协议栈：

HTTP协议：

MQTT协议：

DBus协议:

DBus参考资料：

• Message Protocol：https://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol
• dbus-protocol.h：https://github.com/brianmcgillion/DBus/blob/master/dbus/dbus-protocol.h

上面协议特点：

• TCP/IP协议栈属于流程处理协议，自己处理下然后交给下一个流程去处理；其它的属于终端协议，接收到的进程就是最终处理的进程。
• 前面三个走网络，dbus走unix socket
• 从这几个协议上看基本分为两部分：header + body，header属于协议数据包的概要信息，body里面放数据参数

总结：

• 对于TCP/IP协议栈：每个模块只需要处理和关心属于自己部分的数据，然后交由下一阶段的去处理
• 对于web server来说：可以通过协议里面的method和path去路由转发到对应的模块及函数去处理
• 对于MQTT协议：可以通过message type来转发
• 对于DBus协议：header里面包含了address；dbus-daemon只需要解析header部分就可以实现转发；信息接收可以通过message type，object path，method一层层的来转发，分给对应的模块及函数处理

在刚开发看dbus的时候，不是很理解dbus搞了那么概念：bus name, message type, object path, method，类似一个socket链接，有个地址不就行了吗？后来才明白dbus就是复杂应用场景，为模块化设计的，可以通过前面的概念一级一级来转发，直到最后一个确定的处理函数

结论：

回到最开始的问题，答案似乎已经肯定了很多

但，我好像又有了另外的疑问，项目中一次性上报所有数据包合理吗？如果上报数据越来越多？越来越大呢？这个问题就会越来越明显