通过网络安全地创造“心跳”（Ping？）

Question

我创建了扩展的TCP服务器和TCP客户端类（在C＃中），用于通过网络进行通信，以供我的项目使用。

据我所知，客户端无法真正知道服务器是否已关闭，除非它请求某个需要回复但未获得回复的内容。

在我们的应用程序中，（服务器的）时间和可用性是关键因素，因为它涉及重型机器的自动化。因此，根据对设计的讨论，服务器应该定期发送其“Heart Beat”，这样如果客户端在一段时间后没有从服务器接收任何内容，它将：

1. 开始尝试自己的恢复操作，如果仍然失败，
2. 它会向控制室的服务人员发出警报

我应该在服务器中实现“心跳”部分。而且我创建了“Heart Beat”的简单实现。

public void SendHeartBeatToAllClients(byte[] hbdata) {
  foreach (Socket socket in clientNoSocketList.Select(x => x.Value).ToList())
    socket.Send(hbdata);      
}

到目前为止它工作正常，但令我担心的一件事是，心跳数据（hbdata）很短（只有少数预先排列的字节，以节省在多台机器上通话的时间）和自我由于服务器还发送了除hbdata之外的其他一些数据，并且考虑到可能的延迟或其他意外情况，因此总是有可能将此hbdata混淆。此外，在我的“心跳”实现中，客户端不需要回复任何服务器。

所以这是我的问题：

1. 我的担心是否没有良好的基础（因为它到目前为止还好）？有没有瑕疵？
2. Ping是通过TCP获得此类心跳功能的更好或更常见的方法吗？为什么或为什么不呢？
3. 如果Ping要实施，考虑到Ping有回复，是否有办法实施无回复Ping？
4. 是否有任何建议可以在尽可能短的数据量下使心脏足够健壮？

Answer 1

  

    

在我的“心跳”实现中，客户端不需要回复任何服务器。

  

应用程序级别保持活动需要双向不是吗？以上功能是客户可以确保服务器在接收到心跳时仍然健康。如果客户端没有响应，服务器将不知道客户端的真实状态。如果客户端无法访问，心跳会在服务器发送缓冲区堆积。服务器应用程序将忽略这一事实。

  

    

我的担心是否没有良好的基础（因为它到目前为止还好）？有没有缺陷？

  

小尺寸字节应该不是问题。它的心脏跳动越小越好。

  

    

Ping通过TCP获得这样的心跳功能是更好还是更常见的方式？为什么或为什么不呢？

  

即使客户端应用程序已关闭但系统运行正常，Ping也会为正。

Answer 2

1. 这可能是最难回答的问题。你能提供更多细节吗？为什么您认为您的服务器无法处理超过几个字节的发送？我们在这里谈论成千上万的机器吗？一切都在本地局域网上，或者是通过多个网络还是互联网？

2. Ping是一个ICMP回应请求 - 网络监控软件等通常使用ping来确保客户端在线。通常，如果您只是ping网络访问权限，则不需要实现自己的（请参阅：https://msdn.microsoft.com/en-us/library/system.net.networkinformation.ping(v=vs.110).aspx）。

   另请注意，ping根本不是TCP，而是ICMP，一种稍微不同的协议，用于网络诊断等。但这让我想到了3号......

3. Ping 没有回复是没有意义的。对于你的想法，我认为你想要的协议是UDP - 你可以广播任意数据报，不需要任何形式的握手或回复（TCP定义涉及建立一个握手会话） - 它只是发送。这些是带SocketType.Dgram而不是SocketType.Stream的套接字，而ProtocolType.Udp代替Tcp或ICMP。如果您想更多地参与其中，您可以使用广播将相同的内容发送到整个局域网，或者将多播发送到特定的一组客户端。

4. 同样，您确定需要关注限制流量等吗？

   就个人而言，我会翻转它，并让客户＆＃34; Check In＆＃34;在设定的时间间隔内，向服务器报告状态代码。如果服务器注意到客户端没有签入一段时间，它应该向客户端发送消息并期待回复。

   如果你真的遇到了扩展问题，我会让服务器发送＆＃34; Heart beats＆＃34;在设定的时间间隔内通过UDP，如果客户认为它错过了它们，就有一种机制让它到达服务器并要求回复 - 然后然后如果它没有＆＃39;得到回应，发出警报。

编辑：刚刚看到Prabhu的回答 - 他是对的，ping只会告诉你计算机是否启动，你肯定想要在实际应用程序内部报告回来，而不仅仅是网络连接的状态。