上一篇的飞鸽协议上下线报文分析，写的比较乱，并且其中有些分析还是有点出入。最近我又针对飞鸽协议做了详细的抓包分析，特此这一篇中对上下线报文做一个总结，其中也讲解了发送消息的一些内容。有关聊天报文和文件传输报文，以后我会在分析的比较透彻以后写出技术分析文章。

这里纠正上一篇中的一个错误，就是针对飞秋报文和飞鸽报文差异的那部分，经过我的分析后，发现飞秋的报文和飞鸽的报文基本上是一致的，飞秋的定制信息是在版本号部分。下面开始分析。

一、飞鸽协议格式分析

首先把飞鸽协议的报文的格式说明一下。飞鸽协议报文格式如下（注意，以下是一个完整字符串，使用字符冒号进行每部分的分隔）：

Ver(1):PacketNo:SenderName:SenderHost:CommandNo:AdditionalSection

整体报文的意思是：版本号（现在是1，飞秋就是针对这部分做了修改）:数据包编号:发送主机:命令:附加数据

各字段解析：

Ver:版本号，标准飞鸽协议为1

PacketNo:数据包编号，一般是取毫秒数。利用这个数据，可以唯一的区别每个数据包；

SenderName指的是发送者的昵称，对应windows系统上，取值为PC的当前用户的登录名

SenderHost:发送主机，对应windows系统上，取值为主机名；

CommandNo:命令字，指的是协议中定义的一系列命令，程序中使用十六进制常量数据定义。

AdditionalSection：附加数据，对应不同的具体命令，附加数据中有不同的数据内容。

这里对命令字部分进行详细解析。飞鸽协议中，命令字是由不同的十六进制数据定义的。我在阅读了飞鸽的文档和分析后，发现命令字的组成可以分为两个部分，一部分是基本命令字，另一部分是选项命令字（我自己起的叫法，嘿嘿）。基本命令字，是命令字数据的低8位。对应到十六进制数据，就是后两个数据。基本命令包括的有：上线广播，下线广播，发送消息，消息打开通知，文件传输请求，等等。第二部分，就是一些选项了，这些选项的命令字的定义在其余的位置，也就是不在基本命令字所占据的低8位上。使用时，只需将选项命令字与基本命令字做位或运算，这样所发送的消息就有了一些选项所附带的功能。举个例子说明：

当想要发送消息时，就需要用到发送消息基本命令字IPMSG_SENDMSG，对应十六进制数据是0x20。将所要发送的消息放到附加数据字段，再将其余个部分都添加上相应内容，这样一个飞鸽协议报文就组建好了，如下：

1:100:shirouzu:jupiter:32:Hello

注意：协议报文中，命令字是以十进制表示，其实32转换为十六进制就是0x20。将其使用UDP发送到另一个使用飞鸽的机器上，对应机器就可以收到内容为Hello的消息了。在这个例子中，我们只使用了基本命令字，所以消息接收端在收到消息后不对发送端回送任何数据。我们知道，UDP通信是不可靠的，我们在发送了数据后，并不知道接收端是否接收到了消息，若想要接收端在收到消息后，给我们返回一个收到消息的确认，这里，就要使用到选项命令字IPMSG_SENDCHECKOPT了，这个选项命令字对应十六进制数据是0x100，定义为传送验证。接收端在收到消息的同时需要检测是否有传送验证这个选项，若有，则需要向消息发送端回送一个包含通报收到消息基本命令字IPMSG_RECVMSG的报文。使用这个选项命令字很简单，只需要将基本命令字与选项命令字做按位的或操作，得到的命令字对应十六进制就是0x120，转换为十进制就是288。所以这个带有传送验证的飞鸽消息报文内容就是

1:100:shirouzu:jupiter:288:Hello

接收端在收到这个消息后，就会回送一个收到消息的报文了。

飞鸽协议中定义的选项命令字有很多，实现的功能也有不同，具体的可以阅读下源代码。

二、上下线报文分析

在明白了飞鸽协议报文格式之后，上下线就比较简单了。

飞鸽协议中规定的上线的步骤是：当打开了飞鸽程序以后，程序会向局域网中广播一条上线报文，若局域网中有其他飞鸽用户，则其在收到上线报文以后，向广播发送端回送一条收到上线广播的报文，通过这个机制，则局域网中所有飞鸽用户都有了相互信息。

飞鸽下线时，则相应的发送一条下线广播，收到下线广播的飞鸽用户则知道这个用户下线，将其从自己维护的在线用户中删除。收到下线广播不回送报文。

具体的飞鸽报文构造，同上面的一样，需要注意的就是，在一个局域网中，广播地址对应的就是255.255.255.255。

另外有一点说明一下，在上线报文中，附加信息中可以携带上线用户的用户名和分组名，用户名和分组名之间使用”\0”字符进行分隔。