在局域网场景下，让新接入的设备无需配置就能被控制中心或其他节点找到，最简洁的做法是利用UDP的广播与多播能力。Ruby凭借原生套接字支持，可以用很少代码完成服务宣告与监听。不过实际落地时，开发者往往会遇到包发不出去、组里其他机器收不到、或者连续收包后数据粘在一起等状况。理解套接字选项与数据报边界，是写出稳定发现逻辑的前提。
UDP广播与多播的基础原理及Ruby套接字配置
UDP本身是无连接的数据报协议，每一份数据独立路由。广播是指将报文发往子网内所有主机，目标地址通常是子网广播地址（如192.168.1.255），而多播是把主机加入一个D类组播组（224.0.0.0至239.255.255.255），仅组内成员接收。Ruby的UDPSocket在创建后默认不允许发送广播，必须显式开启SO_BROADCAST选项，否则会抛出权限错误。
对于多播，发送端一般要设置IP_MULTICAST_TTL来控制包能跨越几跳路由，避免无意义的网络扩散；接收端则需绑定到具体端口，并通过IP_ADD_MEMBERSHIP选项把套接字加入多播组。下面代码演示了一个既支持广播发送、又能加入多播组的Ruby套接字初始化过程，注意setsockopt的参数结构。
require 'socket'
# 创建UDP套接字
sock = UDPSocket.new(Socket::AF_INET)
# 允许广播
sock.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
# 设置多播TTL为1，仅本地子网
sock.setsockopt(Socket::IPPROTO_IP, Socket::IP_MULTICAST_TTL, 1)
# 加入多播组 239.255.0.1，使用默认网卡
mreq = IPAddr.new('239.255.0.1').hton + IPAddr.new('0.0.0.0').hton
sock.setsockopt(Socket::IPPROTO_IP, Socket::IP_ADD_MEMBERSHIP, mreq)
# 绑定到多播端口
sock.bind('0.0.0.0', 4567)
puts 'socket ready'
上面的代码在Linux与macOS通常可直接运行，Windows上多播成员结构也类似，但需注意防火墙放行UDP端口。广播地址不要硬编码，应通过Socket.getifaddrs计算，否则在子网掩码非24位的网络中会发错目标。多播组地址应避免使用224.0.0.x等路由协议保留段，推荐从239.0.0.0私有范围选取。
基于Ruby的局域网服务发现机制设计与心跳实现
服务发现的核心思路是：每个服务实例周期性地向外宣告自己的标识与访问地址，监听方收集这些信息并维护一张带过期时间的表。广播适合小型网络全量通知，多播更适合按业务划分逻辑组，减少无关主机的中断。Ruby中可以用一个独立线程执行发送循环，间隔例如3秒，包体采用简单文本或JSON，包含服务名、IP和端口。
监听端在recvfrom处阻塞等待，将收到的宣告解析后写入共享哈希，同时另起定时器清理超过9秒未刷新的条目。这样即使某个服务异常退出，也不会在列表中残留。下面示例展示宣告发送端的简化实现，使用广播地址且附带JSON内容。
require 'socket'
require 'json'
sock = UDPSocket.new
sock.setsockopt(Socket::SOL_SOCKET, Socket::SO_BROADCAST, true)
info = { name: 'auth_service', ip: '192.168.1.20', port: 9090 }
payload = JSON.generate(info)
loop do
sock.send(payload, 0, '192.168.1.255', 4567)
puts 'broadcast sent'
sleep 3
end
实际系统里，心跳间隔要根据网络规模权衡：过快会产生大量冗余包，过慢则故障感知延迟。若使用多播，可将不同服务类型分到不同组，比如订单服务进239.255.1.1，用户服务进239.255.1.2，监听方只加自己关心的组即可。此外，宣告包建议带上序列号或时间戳，便于接收端判断是否为重复旧包，避免列表反复重置。
还有一种常见优化是被动发现：新节点上线时先发一个查询广播，已存在的服务收到后单播回应自身信息，从而减少常态流量。Ruby里查询包和宣告包可用同一个端口，通过包内type字段区分。这种机制在笔记本频繁休眠唤醒的办公网络中尤其有用，能快速补全拓扑。
UDP数据包边界问题分析与正确的接收端写法
很多开发者在写UDP接收循环时，习惯参照TCP用recv不断读入缓冲区再做分割，结果在UDP下出现半包或合并错乱。根本原因是UDP保留数据报边界：一次send对应一次recvfrom，内核不会把两个小包拼起来，也不会把一个大包拆开（除非超过MTU导致IP层分片，但应用层仍按一个数据报交付）。因此接收缓冲区必须足够大，且每次读取都应视为完整业务消息。
如果业务消息可能超过65507字节，应改为在应用层分片并自己重组，而不是指望单次收全。标准接收写法是用recvfrom(maxlen)，其中maxlen取比最大包稍大的值，例如65535。以下代码展示了一个安全的多播接收循环，直接把每个数据报当独立JSON处理。
require 'socket'
require 'json'
sock = UDPSocket.new
mreq = IPAddr.new('239.255.0.1').hton + IPAddr.new('0.0.0.0').hton
sock.setsockopt(Socket::IPPROTO_IP, Socket::IP_ADD_MEMBERSHIP, mreq)
sock.bind('0.0.0.0', 4567)
loop do
data, addr = sock.recvfrom(65535)
begin
msg = JSON.parse(data)
puts "from #{addr[3]}: #{msg['name']}"
rescue JSON::ParserError
puts 'invalid datagram ignored'
end
end
当网络中存在多个服务高频广播时，接收端可能瞬时堆积多个数据报。Ruby的UDPSocket在阻塞调用间会自动逐个交付，不会因为没及时读取就混淆内容。但要注意如果在回调中执行了耗时操作，后续包可能由于套接字缓冲区满被内核丢弃，表现为发现列表闪烁。解决方法是把解析结果推入队列，由其他线程消费，保持recvfrom循环轻量。
最后需提醒，UDP不保证送达，局域网虽稳定但仍可能因交换机多播过滤、网卡offload等丢失报文。服务发现不能依赖单包，而要靠周期性重发与接收端过期机制来掩盖丢包。把边界处理与重传策略结合，才能构建出在真实办公或工控网络中可靠的Ruby局域网发现模块。