场景：

一台中心服务器，定时发送 keepalive 包给另外几台同类型的 application server 检测和对方的网络链接故障以及对方是否 DOWN 掉。检测不能太灵敏，导致误报，比如网络抖动导致的 keep alive 没有收到回应。也不能太迟钝，导致中心服务器不能及时把 DOWN 掉的app server上的负载移到其他 app server。

首先让 CHATGPT O3 写，要求 N 秒发送一个包，如果 M 秒内没有收到就计算为该包超时。连续 X 个包都没有收到回应就认为 DOWN 了。如果在 X 个包内收到任一回复，认为链接正常。

O3 给出了一个比较简单的基于 RTT, SRTT 的实现，把它的实现丢给 GEMINI 2.5 PRO， 它 REVIEW 之后，增加了 RTTVAR, 以及根据当前状态动态调整 N 的实现。

初步测试效果不错，正在丢给测试部门折腾。
--
FROM 218.76.62.*

是的
但很多码农不善于这个
一下子拉平了码农之间的距离  
  
【 在 buildtolast (buildtolast) 的大作中提到: 】
:  这种都是造轮子，AI最擅长
:  
:  【 在 speedboy2998 的大作中提到: 】
:  : 场景：  
--
FROM 114.254.0.*

其实大多数初级程序员缺的是这种描述需求的能力。

【 在 speedboy2998 的大作中提到: 】
: 场景：
: 一台中心服务器，定时发送 keepalive 包给另外几台同类型的 application server 检测和对方的网络链接故障以及对方是否 DOWN 掉。检测不能太灵敏，导致误报，比如网络抖动导致的 keep alive 没有收到回应。也不能太迟钝，导致中心服务器不能及时把 DOWN 掉的app server上的负
: 载移到其他 app server。
: ...................
--
修改:hgoldfish FROM 223.104.53.*
FROM 223.104.53.*

这玩意儿在开始架构设计的时候就应该考虑高可用实现吧。java spring全家桶天然就带
这种failover的实现啊，自己写轮子完全没有必要


【 在 hgoldfish 的大作中提到: 】
: 直接用现成的系统会引入大量组件。
: 比如 websocket 就有个 ping/pong 机制，你不能说引入 zookeeper 来实现
: websocket 协议吧。
--
FROM 119.139.197.*

做 C++ 码农的，逻辑思维都没有问题吧。哈哈。

不过确实，现实中和人交流，发现很多人确实把一个事情前因后果，当前的状态，以及期待达到的目标描述清楚的能力。



【 在 hgoldfish 的大作中提到: 】
: 其实大多数初级程序员缺的是这种描述需求的能力。
:
--
FROM 218.76.62.*