roblox-networking

roblox networking

When to Load

Load when adding a remote, handling untrusted client input, implementing cooldowns, or deciding which side owns a gameplay result.

Quick Reference

• Treat every client argument as attacker-controlled input.
• Validate type, size, ownership, state, distance, and cooldown on the server.
• Look up prices, damage, rewards, and permissions from server-owned definitions.
• Choose the authority model before designing movement or continuous simulation. Server Authority uses client input prediction and server rollback; it is not the same thing as handing a part to a client with SetNetworkOwner.
• For simulation-affecting input in Server Authority, use InputAction/InputContext and RunService:BindToSimulation() (requires Workspace.UseFixedSimulation enabled in Studio) rather than feeding continuous input through a RemoteEvent.
• Use events for most gameplay requests. Keep RemoteFunction calls short and bounded.
• Use RemoteEvent for reliable state changes within its event channel. Do not assume a RemoteEvent is ordered with property or attribute replication; use one explicit state channel or version the state when ordering matters. Use UnreliableRemoteEvent only for replaceable or ephemeral data such as VFX and continuous snapshots.
• Unreliable does not mean automatically faster: delivery is unordered, packets may be dropped, and payloads should stay at or below the documented 1000-byte limit.
• Measure payload size and fire rate under load. Do not treat a community packet-size estimator as an official wire-format specification.
• Validate numeric inputs for NaN and infinity (x ~= x, math.abs(x) == math.huge) before range checks: NaN defeats </>. Apply the same class of check to strings: utf8.len(s) returns nil for malformed UTF-8 that would fail a DataStore save.
• Rate limits protect the server, but validation must still reject invalid requests.
• Record suspicious behavior and use thresholds. Do not punish a player for one malformed packet.