MLAPI项目中Rpc(SendTo.NotMe)重复发送消息问题解析

问题背景

在MLAPI网络框架中，开发者使用Rpc(SendTo.NotMe)标记方法时遇到了一个关键问题：当客户端调用该方法时，服务器会收到重复的消息。这个问题特别影响多人互动应用中需要精确控制网络消息传递的场景，比如多人协作中的效果同步。

问题现象

开发者设计了一个投射物功能，需要在本地客户端触发对目标单位的效果，同时通过Rpc(SendTo.NotMe)将这个动作传播给其他所有客户端，使观察者客户端也能看到相同的效果。当服务器执行这个动作时，一切工作正常——效果正确地发送给所有客户端。然而，当客户端尝试执行相同操作时，服务器会收到重复的消息。

技术分析

Rpc(SendTo.NotMe)的设计初衷是让调用者(无论是服务器还是客户端)能够向除自己之外的所有连接发送远程过程调用。但在实际实现中，当客户端调用这个方法时，消息会被错误地重复发送到服务器端。

这种行为的根本原因在于MLAPI框架内部的消息路由机制存在缺陷。在客户端发起调用时，框架没有正确处理"不发送给自己"这一条件，导致服务器作为消息中转站时收到了重复的调用请求。

影响范围

这个问题会影响所有使用Rpc(SendTo.NotMe)进行网络通信的场景，特别是：

1. 需要将本地动作同步给其他所有用户的应用机制
2. 需要避免消息回发给发送者的网络交互
3. 对网络消息数量敏感的性能关键场景

解决方案

MLAPI开发团队已经确认在1.9.0版本中修复了这个问题。修复后的版本确保了Rpc(SendTo.NotMe)能够严格按照其设计意图工作：只将消息发送给除调用者外的其他所有连接，而不会产生重复消息。

对于正在使用旧版本MLAPI的开发者，建议升级到1.9.0或更高版本以获得正确的行为。在升级前，开发者可以使用发布分支中的代码提前验证修复效果。

最佳实践

在使用Rpc(SendTo.NotMe)时，开发者应该注意：

1. 明确区分服务器和客户端调用的场景
2. 在网络关键逻辑中添加消息去重机制作为防御性编程
3. 充分测试各种网络拓扑结构下的消息传递行为
4. 考虑使用更精确的目标选择机制(如特定客户端RPC)来替代广播式调用

总结

多人互动应用开发中精确控制消息传递至关重要。MLAPI框架通过持续改进解决了Rpc(SendTo.NotMe)的重复消息问题，为开发者提供了更可靠的网络通信基础。理解这类问题的本质有助于开发者在遇到类似网络同步问题时能够快速定位和解决。