错误！未指定书签。
上层应用将大块数据通过TCP Socket发送给通信守护进程
收到一片数据通过TCP Socket从上层应用接收大块数据首片数据判断标志字段尾片数据/PATCH正常数据NAKACK构造一个发送任务并加入发送任务队列，此任务的数据区就是上层应用来的数据新建一项接收任务，分配数据空间，加入接收任务缓冲池根据任务号将数据拷贝到相应的接收任务的数据区根据任务号将数据拷贝到相应的接收任务的数据区重新发送丢失的数据片，标志字段设为PATCH检查任务状态首片发送完数据发送完更新定时器数据向发送端发送ACK确认否检查数据是否收全是找出丢失数据片的序列号，构造NAK并发送到发送端向发送端发送ACK确认发送“正常数据”和“尾片数据”撤销相应的发送任务项构造“首片数据”并发送更新定时器数据将收全的数据通过TCP Socket递交给上层应用，撤销相应的接收任务项图4-4 可靠通信的工作流程图
从图4-4中可以看出可靠通信使用了定时器，定时器的作用主要有三点。第一，发送端发出“首片数据”以后，可能得不到ACK，这时候可能有两种情况，要么是接收端出现故障，要么是数据出现了丢失。等预设时间一到，如果没有收到ACK，发送端就应当查询接收端的状态，如果有响应，那么重发“首片数据”，如果无响应，更新节点列表。第二，发送端发送完所有数据以后，可能收不到ACK，这时候也要查询接收端状态，如果无响应，更新节点列表。第三，接收端可能收不到“尾片数据”，这时候，收到最后一片“正常数据”后所更新的定时器数据就可以发挥作用，等预设时间一到，接收端检查哪些数据片没有接收完成，并且构造NAK发送给发送端。
定时器是借助Linux的信号机制实现的，在预设的超时时限到达以后，就会向本进程发送SIGALRM信号，系统捕获到这个信号以后就可以进行相应的处理。 4.2.2 选择多播技术和算法
选择多播技术是借助IP多播技术和主机掩码实现的。
除了单播和广播支持，IP协议还提供一种发送和接收IP多播流的机制。IP多播流发送到单个目标IP地址，但是由多个IP主机接收和处理。一个主机侦听一个特定的IP多播
第 13 页 共 39 页
错误！未指定书签。
地址，并接收发送到该IP地址的所有数据包。
对于一对多的数据传输，IP多播要比IP单播和广播更为高效。与单播不同，多播仅发送数据的一个副本。与广播不同，多播仅由正在侦听它的计算机进行接收和处理。
侦听特定IP多播地址的那一组主机称为一个主机组。
主机组的成员关系是动态的，主机可以在任何时候加入或离开该组。 主机组的成员数量没有限制。
主机组可以跨越多个网段。这种配置需要IP路由器上的IP多播支持，并要求主机能够将它们对接收多播流量的意愿注册到该路由器。主机注册是使用“Internet组管理协议（Internet Group Management Protocol，IGMP）”来完成的。
IP 多播地址（也称为组地址）在224.0.0.0到239.255.255.255的D类地址范围内，这是通过将前四个高序位设置为1110来定义的。在网络前缀或无类别域间路由（Classless Inter-Domain Routing，CIDR）表示法中，IP多播地址缩写为224.0.0.0/4。 从224.0.0.0到224.0.0.255 (224.0.0.0/24)范围的多播地址保留用于本地子网，而IP报头中的生存时间（Time to Live，TTL）可忽略，它们都不会被IP路由器转发。
本系统对通信中间件提出了“选择多播”要求，期望达到这样一种效果：接收者并不是所有加入了某一个多播组的所有成员，而是其中的一个子集，并且这个子集是可以任意指定的。
为了支持选择多播，我们定义了一种叫“主机掩码”的数据结构，它包含256个位，每个位唯一对应一个C类局域网的256台主机，某个位为1表示对应的主机属于接收对象。发送数据的时候，如果传输类型是选择多播，则“首片数据”中会携带有一个主机掩码，属于接收多播组的每一台主机均可以收到这个“首片数据”。这些主机收到首片数据后，会根据主机掩码判断自身是否属于接收对象，如果是，那么新建一个接收任务项，加入接受任务缓冲池并分配相应的数据空间。否则将首片数据丢弃。 4.2.3 日志记录技术和算法
通信守护进程在运行的时候可能出现各种情况，有时候我们希望能将这些信息记录下来以便管理人员分析，因此我们设计了日志记录子模块。
第 14 页 共 39 页
错误！未指定书签。
我们可以让通信守护进程在运行的时候向控制台输出各种信息，但是有几点理由让我们没有采用这种方式。第一，向屏幕输出信息是一种比较“昂贵”的IO操作，它会引发系统调用，降低整个系统的效率。第二，我们的通信守护进程被设计成为一个可以以Daemon模式运行的程序，这个时候守护进程可能关闭标准IO设备，使得这些信息无法输出。第三，即便通信守护进程没有以Daemon模式运行，它也可能是无人值守的，也就是说，系统管理员可能在运行守护进程以后退出登录，这时也会使得信息无法输出。
写日志文件本身也是一种费时的IO操作，因此我们不能在每一处需要记录的地方都直接对日志文件进行读写。我们专门创建了一个日志记录线程负责将日志项写入文件，同时设计了一个日志项环形缓冲池。日志记录线程一开始处于睡眠状态，程序每到一处需要记录的时候就将日志项写入环形缓冲池，同时唤醒日志记录线程，日志记录线程将缓冲池中的每一项写入文件以后，继续睡眠，等待下一次被唤醒。 4.2.4 通信中间件的整体工作流程
上层应用调用通信中间件进行数据传输的过程主要是三大步：与通信守护进程建立会话——请求数据传输——注销与通信守护进程的会话。通信守护进程是通信中间件的主体。
图4-5是通信守护进程启动和退出时的工作流程：
第 15 页 共 39 页
错误！未指定书签。
开始运行解析命令行参数收到SIGINT、SIGQUIT或SIGTERM信号从配置文件读取系统配置信息初始化为Daemon是是否以Daemon模式运行？否忽略SIGHUP信号，为SIGINT、SIGQUIT和SIGTERM信号注册处理函数system_exit()清理发送任务队列，释放相关资源清理接收任务缓冲池，释放相关资源创建Log线程是是否启用日志？否事件子模块初始化将所有日志项输出到日志文件会话子模块初始化是关闭每一个会话并释放相关资源是否启用了日志？否发送任务队列初始化安全退出通信Socket初始化接收任务缓冲池初始化定时器初始化进入事件循环
图4-5 通信守护进程启动和退出流程图
通信守护进程进入事件循环以后，会接收并处理各种各样的事件，比如：上层应用与守护进程建立连接，会话Socket上送来了一个数据传输请求，上层应用断开了与守护进程的连接，数据读Socket上面有了从其他守护进程送来的数据等等。除非接收到了SIGINT、
第 16 页 共 39 页
错误！未指定书签。
SIGQUIT和SIGTERM三种信号，守护进程将启动正常的退出流程外，系统将一直运行于事件循环中。SIGKILL信号无法被捕获和注册信号处理函数，因此一旦管理员向守护进程发送SIGKILL信号，将造成系统非正常退出。
4.3 关键数据结构
4.3.1
first_frame
typedef struct dummy_first_frame{
u_char flag;
// 在本系统中必须为0x51
// 对于“首片数据”，必须为F_FLAG_BEGIN
u_char type;
short task_number; // 任务号，用于唯一标识一个任务 int task_size;
// 本任务对应的文件大小
int total_frame_num; // 本任务的分片总数 int xmit_type; int service_type; int16 mess_type;
// 传输模式：单播、多播或选择多播 // 服务类型：可靠或不可靠 // 用户自定义
host_mask group_mask; //主机掩码，用于选择多播
} first_frame;
First_frame就是前面提到的“首片数据”的结构。它在正常的数据前发送，接收端根据它来构造一个“接收任务”。 4.3.2
data_frame
typedef struct dummy_data_frame{
u_char flag; // 在本系统中必须为0x51
u_char type; // 本字段必须为F_FLAG_DATA、F_FLAG_END或F_FLAG_PATCH short task_number; //任务号，用于唯一标识一个任务 short data_length; //本小片内数据区长度
short ser_number; //片序列号，用于大文件的分片与重组 char data[MAX_DATA_LEN]; //数据区指针
} data_frame;
Data_frame这个数据结构就是上文提到的“正常数据”和尾片数据。接收端会根据任
第 17 页 共 39 页