1.缘起：
假设我们的C/S系统中服务端与客户端之间采用UDP进行通信，那么服务端如何知道每个客户端当前是否仍然在线了？有可能某个客户端一直没有退出，但是在很长一段时间内都没有与服务端作任何通信，那么服务端就应该认为这个客户端已经离线了吗？为了能让服务端掌握每个客户端是否在线的状态，我们可以这样做，只要客户端一启动起来，就每隔一段时间间隔（如10秒）就向服务端发一个“我还在线”的消息，以表明自己的状态。而服务端如果在一个更大的时间间隔内（如20秒）都没有收到某个客户端的任何消息，则可以判定这个客户端已经离线了。
这就是我们常用的“心跳”机制，客户端每隔一段时间间隔发的那个消息就称为“心跳消息”，只要心跳还在，就表示自己还是Alive的，否则就是断线/下线了。
心跳监测器的形象示意图如下：
2.适用场合：
在很多基于非连接的通信系统中，心跳机制是经常使用的方案。其最主要的目的是让服务端能比较及时的掌握到每个客户端当前的在线状态，因为这个信息是相当重要的，而且这个状态改变时服务端知道得越及时越好。ESBasic.Threading.Application.IHeartBeatChecker（心跳检测器）便是用于对每个客户端的心跳进行监控以掌握每个客户端的在线状态的。它经常使用在类似下面的这些场合：
（1）服务端无法感知客户端的离线或意外掉线（如网络中断、系统重启等），而这个信息对于服务端而言却是非常重要的。
（2）服务端可以感知客户端的离线或意外掉线，但是这种感知有延迟，而且延迟可能非常大（比如几分钟），其程度已经超过了服务端能接受的范围。比如，基于TCP的C/S系统，客户端之间与服务端之间有防火墙等相关设备的存在，客户端掉线时，服务端与防火墙之间对应的连接仍然存在，所以服务端认为客户端仍然在线，这种状况可能要持续几秒钟到几分钟不等。
（3）以上所说的服务端/客户端可以认为是一个广义的定义，只要是通信的双方（如P2P）需要知道对方的在线状态，那么都可以使用心跳机制来解决。
3．设计思想与实现
IHeartBeatChecker接口定义如下：
{
/// <summary>
/// SurviveSpanInSecs 在没有心跳到来时，可以存活的最长时间。SurviveSpanInSecs小于等于0，表示存活时间为无限长，而不需要进行心跳检查
/// </summary>
int SurviveSpanInSecs { get ; set ; }
/// <summary>
/// DetectSpanInSecs 隔多长时间进行一次状态检查。
/// </summary>
int DetectSpanInSecs { get ; set ; }
/// <summary>
/// Initialize 初始化并启动心跳监测器。
/// </summary>
void Initialize();
/// <summary>
/// RegisterOrActivate 注册一个新的客户端或激活它（收到心跳消息）。
/// </summary>
void RegisterOrActivate( string id);
/// <summary>
/// Unregister 服务端主动取消对目标客户端的监测。
/// </summary>
void Unregister( string id);
/// <summary>
/// Clear 清空所有的监测。
/// </summary>
void Clear();
/// <summary>
/// SomeOneTimeOuted 当在规定的时间内没有任何消息过来，那么将会触发该事件。
/// 注意：该事件的处理函数严禁抛出任何异常。
/// </summary>
event CbSimpleStr SomeOneTimeOuted;
}
根据上述对心跳监测器的介绍，我们知道需要定时检查每个客户端的状态，看在规定的时间间隔内是否有“心跳”消息过来。我们可以借助循环引擎（ICycleEngine）来进行定时检查。从IHeartBeatChecker接口定义，你有看到它并没有从ICycleEngine继承，那表明心跳监测器不需要被反复的Start、Stop。相反的，IHeartBeatChecker提供了一个Initialize方法，用于初始化和启动监测器。监测器一旦启动就会在随系统的生命周期运行，这和我们的绝大部分需求是完全一致的。
DetectSpanInSecs属性表示需要间隔多少秒检测一次客户端的状态，这个属性的值将被直接传递给循环引擎的同名属性。
SurviveSpanInSecs属性表示在没有心跳到来时，客户端可以存活的最长时间。这个时间通常要比客户端定时发送“心跳”消息的时间间隔大一些。
当心跳监测器发现某个客户端在规定的时间内没有心跳消息过来，那么将会触发SomeOneTimeOuted事件以通知服务端目标客户端掉线了。
HeartBeatChecker实现了IHeartBeatChecker接口，其实现要注意以下几点：
（1）HeartBeatChecker继承自BaseCycleEngine，它借助于循环引擎来进行任务状态的循环检测。
（2）为了允许在多线程的环境中回调定时器，HeartBeatChecker必须对内部集合（dicIDTime）进行加锁控制。
（3）为了在初始化的时候启动监测器，其在Initialize方法中调用了循环引擎的Start方法。
4. 使用时的注意事项
（1）如果服务端已经确切知道客户端已经离线（比如，客户端向服务端发送“我要退出了”的消息），那么服务端可以调用IHeartBeatChecker. Unregister方法来主动清除对目标客户端的监测。
（2）SomeOneTimeOuted事件的处理函数不要抛出任何异常，否则会导致后续的客户端掉线事件无法被触发。这点从我们的实现源码就可以看到，一旦一个SomeOneTimeOuted抛出异常，foreach将会被迫中断。而且，更严重的是，会导致循环引擎的停止运行――监测器会停止运行。
（3）不一定只有心跳消息到来时，才调用RegisterOrActivate方法来激活对应的客户端。实际上，我们只要收到来自客户端的任何消息时，都可以调用RegisterOrActivate方法来激活它。
（4）如何设置SurviveSpanInSecs属性和DetectSpanInSecs属性的值，取决于我们系统的需求。服务端要求感受客户端掉线越及时，那么DetectSpanInSecs就要设得越小，而且客户端发送心跳的时间间隔也要越小，SurviveSpanInSecs也要相应的小。SurviveSpanInSecs的设定取决于客户端发送心跳的时间间隔和可以允许的最大网络延时。可以采用如下公式：SurviveSpanInSecs = 客户端发送心跳时间间隔 + 允许的最大网络延时
5.扩展
心跳监测器IHeartBeatChecker暂时没有任何扩展。
注： ESBasic已经开源，点击这里下载源码。
ESBasic开源前言
