mcpField
R
roblox-networking

roblox-networking

github.com/luumenlabs开发13203 次安装22 周前更新
代码仓库

关于 roblox-networking

roblox-networking 是用于设计和审查 Roblox 体验多人通信的技能,重点涵盖远程调用选择、服务端校验、复制行为与信任边界,帮助保持游戏逻辑的服务端权威性。

主要功能

  1. 01RemoteEvent 与 RemoteFunction 的选择
  2. 02服务端请求校验
  3. 03安全的远程载荷设计
  4. 04复制与流式加载考量
  5. 05网络所有权风险建议
  6. 06服务端权威游戏模式

适用场景

  1. 01审查远程调用的漏洞风险
  2. 02设计安全的客户端发起交互
  3. 03为可丢弃更新选择通信方式
  4. 04处理流式内容与复制时序

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/luumenlabs/luau-skills --skill roblox-networking

安装后在 Claude Code 中输入/roblox-networking确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
client-server-boundary-guidance.md
client-server-runtime.md
input-action-system.md
network-ownership.md
remote-events-and-callbacks.md
security-and-defensive-design.md
server-authority-model-and-techniques.md
streaming-and-replication-behavior.md

详细介绍

roblox-networking

适用场景

当任务主要涉及 Roblox 体验中的多人通信、复制或信任边界时,使用此技能:

  • 设计或审查 RemoteEvent、UnreliableRemoteEvent 和 RemoteFunction 的用法。
  • 判断允许客户端发送哪些内容,以及哪些内容必须由服务器推导或验证。
  • 选择安全的远程调用载荷结构、验证参数并处理复制时序。
  • 保护服务器逻辑,避免受到垃圾请求、格式错误的载荷、不可能的请求或漏洞利用导致的滥用。
  • 构建由客户端发起操作、但仍由服务器掌控权威的交互。
  • 分析网络所有权、客户端预测物理效果或 Touched 相关的漏洞利用风险。
  • 为竞技或权威型玩法应用服务器权威、预测、支持回滚的结构或输入路由等理念。
  • 设计多人游戏逻辑,确保其在流式传输影响客户端当前可见或可访问的内容时仍能正常运行。

以下任务的主要内容不适用此技能:

  • 持久化数据架构、保存格式、交易存储或 DataStore 与 MemoryStore 设计。
  • 主要任务是广泛查询引擎 API。
  • Open Cloud、OAuth 或外部 Web 集成。

判断规则

  • 如果核心问题是“客户端和服务器应如何安全、正确地通信?”,请使用此技能。
  • 如果某项功能依赖远程调用、复制时序、模拟部件的所有权或服务器验证,请使用此技能。
  • 单向信号和状态通知优先使用 RemoteEvent;仅在数据可丢弃且持续变化时使用 UnreliableRemoteEvent;只有确实需要同步回复时才使用 RemoteFunction。
  • 将服务器视为共享游戏状态、奖励、战斗结果、移动权限以及任何影响其他玩家的操作的权威方。
  • 如果客户端可以请求执行操作,服务器必须先验证权限、上下文、类型、结构、取值范围和请求频率,然后才能更改状态或广播结果。
  • 如果任务主要涉及脚本存放位置、核心服务、属性、Bindable 或基本运行时结构,且没有明显的网络或安全重点,请转交给 roblox-core。
  • 如果任务主要涉及数据持久化或跨服务器状态,请转交给 roblox-data。
  • 如果任务主要涉及全面查询类或成员,请转交给 roblox-api。
  • 如果请求将网络内容与范围外的系统混在一起,只回答多人游戏和信任边界相关部分,并明确排除其余内容。
  • 不确定时,省略可能偏离到持久化、云端身份验证或广泛 API 目录指南的内容。

说明

  1. 首先对每条信息进行分类:
    • 客户端输入意图。
    • 服务端派生的权威状态。
    • 复制的呈现内容或通知。
    • 可丢弃的遥测数据或装饰性更新。
  2. 选择与任务匹配的最精简网络原语:
    • RemoteEvent 用于异步单向通信。
    • UnreliableRemoteEvent 用于可接受更新丢失或乱序的高频数据。
    • 仅在允许让出执行权、且由服务端明确负责决策的短时、范围有限的请求-响应流程中使用 RemoteFunction。
  3. 保持远程调用契约明确且精简:
    • 优先使用稳定的参数顺序,以及键为字符串的字典。
    • 不要依赖元表、函数值、混合表、未复制的实例,或网络传输后仍保持不变的表身份。
    • 传递标识符、紧凑值或经过验证的已复制实例,而不是任意对象树。
  4. 围绕意图而非结果设计远程调用:
    • 客户端表示“我按下了交互键,目标是这个对象”或“我尝试从这里朝这个命中点开火”。
    • 由服务端判断操作是否合法并计算结果。
    • 避免客户端直接声明奖励、伤害、库存变更或不受限制的实例修改。
  5. 在服务端验证每个由客户端触发的请求:
    • 权限/上下文:玩家是否存活、处于范围内、处于正确状态,并且当前允许执行此操作?
    • 类型/形状:参数是否属于预期类型、大小和实例类?
    • 值合理性:拒绝不可能的数字、NaN、inf、超出范围的向量或未知 ID。
    • 时机:在执行高开销操作或向多个客户端广播之前,应用每玩家速率限制或冷却时间。
  6. 将服务端向客户端的再广播视为特权操作:
    • 绝不能充当将一个客户端的信息盲目转发给其他客户端的中继。
    • 先验证,再仅广播呈现所需的最少安全数据。
  7. 谨慎使用 RemoteFunction:
    • 预期调用方会让出执行权。
    • 保持回调快速且确定。
    • 避免在关键流程中使用 InvokeClient(),因为客户端出错、断开连接或迟迟不返回时,服务端可能挂起或失败。
  8. 明确考虑复制行为:
    • 收到远程调用并不保证相关实例或属性已复制到客户端。
    • 启用流式传输时,客户端可能暂时没有远处的工作区内容。
    • 使用 WaitForChild()、考虑复制行为的设计、标签或模型流式传输控制,而不要假设对象一定存在。
  9. 将网络所有权视为一种具有安全代价的性能工具:
    • 由客户端拥有物理模拟可以提升响应速度。
    • 由客户端拥有物理模拟也可能被滥用,基于 Touched 的服务端逻辑尤其危险。
    • 除非响应速度的收益值得承担额外的验证负担,否则应由服务端拥有对玩法至关重要的物理模拟。
  10. 对于权威性或竞技性玩法:
  • 优先采用服务端权威思路,由服务端作为事实来源,客户端主要提供输入。
  • 对影响核心权威模拟的输入使用 Input Action System。
  • 将模拟状态与本地渲染和特效分开。
  1. 讨论示例时,不要超出范围:
  • 聚焦于多人通信、验证、所有权、权威性和流式传输正确性。
  • 不要扩展到持久化架构、云 API 或通用 API 目录。

使用参考资料

  • 打开 references/remote-events-and-callbacks.md,了解远程选择、方向性、参数形状限制和安全的载荷设计。
  • 打开 references/client-server-runtime.md,了解复制时机、延迟预期,以及游戏职责由哪一侧负责。
  • 打开 references/security-and-defensive-design.md,了解安全思维、防御式设计和速率限制模式。
  • 打开 references/client-server-boundary-guidance.md,了解具体的验证层、安全的重新广播模式,以及如何保护由客户端触发的交互。
  • 如果问题涉及物理响应、客户端拥有的部件或 Touched 的有效性,请打开 references/network-ownership.md。
  • 打开 references/server-authority-model-and-techniques.md,了解权威模拟、预测、支持回滚的结构,以及考虑延迟的设计。
  • 如果联网或权威游戏玩法依赖以操作为导向的跨平台输入路由,请打开 references/input-action-system.md。
  • 如果正确性取决于已流式传输的工作区内容、复制焦点或本地可能不存在的模型,请打开 references/streaming-and-replication-behavior.md。

检查清单

  • 客户端与服务器之间的约定应以玩家意图为依据,而不是客户端声明的结果。
  • 所选远程原语应符合所需的可靠性和响应行为。
  • 远程载荷应采用稳定且可安全复制的形状。
  • 在修改共享状态之前,服务器应验证权限、上下文、类型、结构和值。
  • 服务器应为容易遭滥用的入口应用速率限制或冷却时间。
  • 服务器到客户端的广播只能在验证之后进行,绝不能盲目转发。
  • 使用 RemoteFunction 必须有充分理由,并受到限制。
  • 应明确复制时机方面的假设,尤其是在远程引用刚创建或刚流式传输的内容时。
  • 网络所有权的选择应经过审慎考虑,并在需要时配合服务器端验证。
  • 不能仅因为引擎触发了交互,就信任 Touched、近距离、点击或拖动交互。
  • 权威游戏玩法应使用客户端输入和服务器拥有的状态,而不是信任客户端模拟结果。
  • 输入指南应聚焦于输入操作系统的联网或权威用途。
  • 不应包含持久化架构、Open Cloud、OAuth 或宽泛的 API 目录内容。

常见错误

  • 让客户端告知服务器谁受到了伤害、获得了什么奖励,或已经发生了哪种状态变更。
  • 为了方便而使用 RemoteFunction,而不是使用异步 RemoteEvent 加服务器端状态这种更安全的方式。
  • 未经验证就将一个客户端的载荷广播给所有其他客户端。
  • 通过远程传递混合表、带元表的对象、超大载荷或仅发送方拥有的实例。
  • 忘记拒绝 NaN、inf、超长字符串或伪造的实例引用。
  • 假设远程调用意味着相关部件、属性或模型已经完成复制。
  • 只依赖客户端冷却时间,而不实施服务器端速率限制。
  • 将客户端拥有的物理对象或 Touched 事件当作接触的权威证明。
  • 将不可靠通道用于必须按顺序到达的状态。
  • 将核心权威模拟逻辑与仅限本地的动画、摄像机或特效代码混在一起。

示例

设计安全的客户端触发交互
-- Client: request an interaction attempt, not the reward itself.
InteractRemote:FireServer(targetId)
-- Server: verify range, state, and target validity before applying effects.
InteractRemote.OnServerEvent:Connect(function(player, targetId)
    -- Validate player state, target existence, distance, cooldown, and permissions.
    -- Then mutate shared state on the server.
end)
仅对可丢弃的更新使用不可靠远程
-- Suitable for frequent cosmetic aim or camera direction updates.
AimDirectionRemote:FireServer(lookVector)
  • 接受数据包丢失或乱序。
  • 不要将此模式用于库存、伤害、计分或一次性事务。
将权威模拟与渲染分开
-- Core state changes live in shared/server-side simulation logic.
-- Local VFX and sounds react to the synchronized state afterward.

评论

支持 Markdown