我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A发送Msg:R,服务端收到后回Msg:A，此时客户端cl_A认为消息已经送达，但是提示未读。
下半场：
服务端发送Msg:N给cl_B，无论是否送达cl_B都不给服务端回ack，而服务端认为消息是已经到达cl_B。

那下半场怎么保证消息必达呢？用客户端上线同步。
如果服务点Msg:N在发送给cl_B的过程中丢失，那么cl_B一定不在线或者网络有问题，因此如果cl_B再次上线就会向服务端拉取离线期间有没有新的消息，来保证消息不会丢失。

总体看来这种方法，大大简化了消息流程，不用超时不用队列，各位大神看看这种设计有何问题？@JackJiang@JackJiang

我们公司现在的消息必达是这么设计的，不需要6步那么复杂，只有Msg:R, Msg:A,MsgN。
上半场：
客户端cl_A发送Msg:R,服务端收到后回Msg:A，此时客户端cl_A认为消息已经送达，但是提示未读。
下半场：
服务端发送Msg:N给cl_B，无论是否送达cl_B都不给服务端回ack，而服务端认为消息是已经到达cl_B。

那下半场怎么保证消息必达呢？用客户端上线同步。
如果服务点Msg:N在发送给cl_B的过程中丢失，那么cl_B一定不在线或者网络有问题，因此如果cl_B再次上线就会向服务端拉取离线期间有没有新的消息，来保证消息不会丢失。

总体看来这种方法，大大简化了消息流程，不用超时不用队列，各位大神看看这种设计有何问题？@JackJiang@JackJiang