Unity网络：在局域网P2P网络中利用UDP广播实现保活/心跳

C/S与P2P

严格来讲客户端与服务器指的都是进程，N个Client客户端进程与一个或多个Server服务器进程可以组成一个C/S结构的网络，而同时既是客户端也是服务器的N个节点可以组成一个P2P网络。

CS架构中，Client向Server提出请求，Server处理请求。P2P网络中每个节点互相都可以提出请求，也都可以处理请求。

UDP在应用层实现保活/心跳

在TCP网络中，已连接的两个端点互相知道对方端点的状态，例如连接时要三次握手，正常断开时要发FIN，异常断开时可以通过保活机制发现。UDP一个重要特征是无连接，因为无连接，使用它进行广播就特别方便，不必像TCP先连接才能通讯，因为无连接，它没有保活机制，一个节点不知道其他节点的状态。

在一个在局域网场景中，可以应用UDP灵活的广播能力设计一个保活机制，各个P2P节点保存一个邻居节点列表，根据网络消息实时更新各个节点在线状态。

以上的设计在一个节点进程开始就需要随时掌握其他邻居节点当前状态的场景中是OK的，但是在一个只需要某些时间掌握邻居节点状态，所有的节点都不断的广播自身状态就有些浪费网络带宽和性能了。可以略微改进，加入一个查询邻居的消息，需要掌握邻居状态的节点广播查询消息，邻居节点在收到查询消息时回复自身状态。

在以上保活机制中，检测上线/在线状态与正常断线状态比较简单，异常断线状态的检测中需要考虑一个保活时间。在一个广播循环中，邻居节点列表中的最后更新时间如果小于一个阀值，就可以判定此节点已经异常断线。这里还要考虑UDP数据包不保证100%到达的问题，因此建议保活时间设计为广播时间间隔*n，UDP连续丢包的概率应该还是很小的，只要n不等于1即可规避此问题。邻居节点上线与下线消息因为只会发一次，丢包的可能性是有的，但是上线消息如果发生丢包，之后的在线消息还会连续广播，之前说了局域网中UDP连续丢包的可能性可以忽略不计，因此这个case退化为了只是对对方上线时间的精确度发生误判。下线消息丢包后，对邻居节点列表的保活检查会判定它为异常断线。所以就算发生上下线广播丢包也并不影响程序的正确性。因此以上的机制表面看起来很松散，鲁棒性实际上是足够的。同时，相比于TCP，这个设计是在应用层实现，可控性强，逻辑上比较简单，不需要连接，在频繁发生节点状态切换的场景下性能消耗较小。

——————————————————————
维护日志：
2017-8-22：更新了标题
2020-8-13：review