1.背景及概述
1.1 背景
在做NFV的过程中，由于控制面进程被放置到不同虚拟机中，中间可能跨越路由器，因此期间网络有可能震荡，这种情况下保证高可用性就必须有保护机制，本文正是在这种背景下的考虑。
1.2 概述
原理其实很简单，有两个原则，一是这种保护机制不能让业务感知，二是尽可能简单。
2. 详述
2.1 正常交互
（1）源进程发送消息给目的进程
（2）目的进程回应消息给源进程
注意的是这些应该封装成公共库，以便复用。
2.2 异常交互
异常交互为两个方面，一是上述msg由于震荡被丢或被严重延时，二是ack由于震荡被丢弃或被严重延时。
2.2.1 msg异常
1）被丢，需要重传，为了保证唯一，需要加入进程1的id（记为clientid）、消息id（本进程唯一，且递增，记为msgid）、发送时间send_time。此外，需要设定重传interval、次数times。这些依然可能被丢弃，则应该通知源进程，所以这里应该有一段buff，用来唯一标识源数据（建议除正常id外，包括时间戳）。
2）被延时。除重传外，上次发送的消息的应答应该丢弃。
2.2.2 ack异常
1）被丢，则msg会被重发，重发时目的进程应该重新回复，若关联数据已不存在，则由目的进程业务做相关处理（如发送删除等）。
2）被严重延时。源进程重发，目的进程不论如何要回复。
2.3 总结及综述
（1）公共库的消息应该包含clientid、msgid、send_time，并设定interval、times，提供短buff（如64字节）；
#define MAX_STORED_MSG 1000
#define MAX_BUFF_LEN 64
typedef unsigned int uint32;
typedef unsigned char byte;
typedef VOID (*send_fail_callback)(byte *user_buff);
typedef struct
{
uinit32 clientid;
uinit32 msgid;
uinit32 send_time;
byte times;
byte pad[3];
} MSG_T;
BOOL send_msg(byte *msg, uinit32 msg_len, const byte *user_buff, uinit32 user_buff_len);
（2）公共库lib有一个定时器，interval/2时间扫描重传链；
（3）发送消息挂在重传链中；
（4）若无回应，则更新发送时间后重传；
（5）若重传X次（如10次）后，回掉业务进程send_fail_callback。
（6）接收端若收到interval之前的消息，则丢弃。
（7）收到后立刻回应ack，clientid、msgid应与源消息相同，更新send_time。
（8）接收端若收到重复msg，与（6）处理相同重复回应，但要更新send_time。
（9）源端收到interval之前发送的ack，则丢弃。