Signal-CLI中GetUserStatus命令无响应问题的分析与解决

在Signal-CLI项目使用过程中，开发者可能会遇到通过Unix Socket调用GetUserStatus命令时无响应的问题。本文将深入分析该问题的成因，并提供有效的解决方案。

问题现象

当用户尝试通过Unix Socket调用Signal-CLI的GetUserStatus接口时，发现以下异常情况：

1. 直接使用signal-cli jsonRpc命令可以正常获取响应
2. 使用socat工具通过Unix Socket发送请求时无任何返回
3. 故意制造参数错误时反而能收到空响应

技术分析

通过日志分析可以发现，该问题与CDSI(Certificate Directory Service Interface)请求的处理机制有关。CDSI是Signal用于验证用户状态的接口，其请求需要一定时间完成。

关键日志显示：

• 当使用socat发送请求时，连接在0.5秒后被主动关闭
• CDSI请求需要约1.5秒才能完成
• 此时响应尚未生成，连接就已中断

根本原因

socat工具默认设置了0.5秒的超时时间(从输入流关闭开始计时)。由于CDSI查询需要较长时间，导致：

1. 客户端(socat)在收到响应前就关闭了连接
2. 服务端(Signal-CLI)无法将查询结果返回
3. 最终表现为命令无响应

解决方案

通过增加socat的超时时间参数即可解决此问题：

printf '{"jsonrpc":"2.0","method":"getUserStatus","params":{"recipient":["+SOMENUMBER"]},"id":6}' | socat -t 60 UNIX-CONNECT:/path/to/socket -

其中-t 60参数将超时时间延长至60秒，确保有足够时间等待CDSI响应。

最佳实践建议

1. 对于所有可能耗时较长的Signal-CLI JSON-RPC请求，都应适当增加客户端超时时间
2. 生产环境中建议将超时时间设置为至少10秒
3. 可以考虑使用更稳定的IPC通信方式替代socat
4. 实现客户端重试机制以应对可能的超时情况

总结

Unix Socket通信中的超时设置是影响Signal-CLI接口可靠性的重要因素。通过合理配置客户端参数，可以确保长时间操作的顺利完成。这个问题也提醒开发者在使用IPC通信时，需要特别注意双方的超时设置匹配问题。