| Communication Type | Sender | Receiver | Object | Example |
|---|---|---|---|---|
| Event sent from the server to all clients | Server | Client | RemoteEvent | Game Over |
| Event sent from the server to a specific client | Server | Client | RemoteEvent | Display level-up UI on level-up |
| Event sent from the client to the server | Client | Server | RemoteEvent | Skill button click |
| Request sent from the client to the server, with a result returned | Client | Server | RemoteFunction | Purchase result and remaining balance |
| Request sent from the server to a client, with a result returned (not recommended) | Server | Client | RemoteFunction | See Important Notes below |
| Item | RemoteEvent | RemoteFunction |
|---|---|---|
| Direction | One-way (request only) | Two-way (request and response) |
| Sender behavior | Keeps running without stopping | Waits until a value is returned |
| How to connect | OnServerEvent:Connect(function) | OnServerInvoke = function — only one can be assigned |
| Return value | Cannot receive one | Receives multiple values as a Tuple |
| Sending to many clients | FireAllClients supported | Not supported |
> 💡 Tip. To clearly distinguish whether the object is for communication from the server to the client (Server to Client) or from the client to the server (Client to Server), it is recommended to use **prefixes** such as **S2C\_** for server-to-client communication and **C2S\_** for client-to-server communication. This makes the object’s role intuitive, enhancing code readability and maintainability.
## Communication Using RemoteEvent
You can send **arguments** along with events when firing a RemoteEvent. The arguments are passed when calling the FireServer, FireClient, or FireAllClients methods, and the receiving side can receive the data in a callback function.
### FireAllClients (Server ➡ All Client)
The server sends an event to **all clients**. This is useful for synchronizing global game states or delivering the same information to all players.
**In Script**
```lua
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local S2C_GameEnd = ReplicatedStorage:WaitForChild("S2C_GameEnd")
local function TimeOver()
local isWin = false
S2C_GameEnd:FireAllClients(isWin) -- Passing arguments
end
```
**In LocalScript**
```lua
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local S2C_GameEnd = ReplicatedStorage:WaitForChild("S2C_GameEnd")
local function OnGameEnd(isWin)
print("[OnGameEnd] ", Players.LocalPlayer.Name, " / isWin : ", isWin)
end
S2C_GameEnd.OnClientEvent:Connect(OnGameEnd)
```
### FireClient (Server ➡ Specific Client)
This method sends an event from the server to a **specific client**. It is used when handling tasks related to an individual player.
**In Script**
```lua
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local S2C_LevelUp = ReplicatedStorage:WaitForChild("S2C_LevelUp")
local function LevelUp(player)
local prevLevel = 1
local curLevel = 2
S2C_LevelUp:FireClient(player, prevLevel, curLevel) -- Passing arguments
end
```
**In LocalScript**
```lua
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local S2C_LevelUp = ReplicatedStorage:WaitForChild("S2C_LevelUp")
local function OnLevelUp(prevLevel, curLevel)
print("[OnLevelUp] ", Players.LocalPlayer.Name, " / LevelUp : ", prevLevel, " -> ", curLevel)
end
S2C_LevelUp.OnClientEvent:Connect(OnLevelUp)
```
### FireServer (Client ➡ Server)
This method sends an event from the client to the **server**. It is used when the server needs to handle the user’s input or specific events (e.g., button clicks, skill use requests).
**In LocalScript**
```lua
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local C2S_UseSkill = ReplicatedStorage:WaitForChild("C2S_UseSkill")
local function ClickSkillButton()
local skillID = 1
C2S_UseSkill:FireServer(skillID)
end
```
**In Script**
```lua
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local C2S_UseSkill = ReplicatedStorage:WaitForChild("C2S_UseSkill")
local function OnUseSkill(player, skillID)
print("[OnUseSkill] ", player.Name, " / skillID : ", skillID)
end
C2S_UseSkill.OnServerEvent:Connect(OnUseSkill)
```
## Communication Using RemoteFunction
A server Script **assigns** a callback to `OnServerInvoke`, and a client LocalScript calls it with the `InvokeServer` method. The **arguments** passed in the call arrive **starting from the second parameter** of the callback, and whatever the callback returns goes back to the client.
### InvokeServer (Client ➡ Server ➡ Client)
**In Script (handling side)**
```lua
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local C2S_BuyItem = ReplicatedStorage:WaitForChild("C2S_BuyItem")
local function OnBuyItem(player, itemId, amount)
-- player is determined by the server from the request itself, so it can be trusted
print("[BuyItem] ", player.Name, " / itemId : ", itemId, " / amount : ", amount)
local isSuccess, balance = Purchase(player, itemId, amount)
return isSuccess, balance -- Returning multiple values at once
end
C2S_BuyItem.OnServerInvoke = OnBuyItem -- Assign the function instead of using Connect
```
**In LocalScript (calling side)**
```lua
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local C2S_BuyItem = ReplicatedStorage:WaitForChild("C2S_BuyItem")
local function ClickBuyButton(itemId, amount)
-- Waits on this line until the server responds
local isSuccess, balance = C2S_BuyItem:InvokeServer(itemId, amount) -- Passing arguments
if isSuccess then
print("[BuyItem] Success / balance : ", balance)
else
print("[BuyItem] Failed")
end
end
```
**The first parameter of `OnServerInvoke`, `player`, is not a value sent by the client.** The server determines it from the request itself, so you can rely on it for permission checks. Everything after it is **sent by the client** and cannot be trusted.
### Callback Rules for OnServerInvoke
`OnServerInvoke` is not an event but a **property that holds a function**. It works differently from `OnServerEvent`, so keep these three points in mind.
* **You cannot use `:Connect()`.** Assign it as `OnServerInvoke = function`.
* **Only one function is kept.** If you assign more than once, only the last assigned function runs.
* **If you omit `return`, the caller receives `nil`.** Using that value directly can cause an error later in the code.
Overlapping calls each run the callback separately. If you replace `OnServerInvoke` while a call is in progress, **that call finishes with the previous function**, and only new calls made afterward use the new one.
## Server-Side Validation
The engine passes values sent by the client to the callback **without inspecting them.** Checking the type and the range is entirely up to your script. **This applies equally to `OnServerInvoke` of a RemoteFunction and `OnServerEvent` of a RemoteEvent.**
Check the following three steps in order.
1. **Permission** — Confirm that this `player` is entitled to make this request right now. (Distance, state, ownership, cooldown)
2. **Type and structure** — Check the actual type with `typeof()`. A client can send a **forged table that looks like an Instance**, so filter with `typeof(item) == "Instance"`.
3. **Value range** — Check the minimum and maximum. `NaN` passes range checks because every comparison against it is `false`, and `Inf` passes unless you check for an upper bound.
```lua
local function OnBuyItem(player, item, amount)
-- 1. Permission
if not CanPurchase(player) then
return false
end
-- 2. Type and structure (defend against forged tables)
if typeof(item) ~= "Instance" or not item:IsA("Tool") then
return false
end
-- 3. Value range
if typeof(amount) ~= "number" then
return false
end
if amount ~= amount then -- NaN : differs even from itself
return false
end
if math.abs(amount) == math.huge then -- Inf
return false
end
if amount < 1 or amount > 99 then
return false
end
return Purchase(player, item, amount)
end
C2S_BuyItem.OnServerInvoke = OnBuyItem
```
* **Limit the call interval and count per player** to block excessive requests.
* Do not rely on client-side validation alone. Client code can be tampered with, so server-side validation is always required.
* Do not accept values from the client that the server already knows. (For example, price or ownership)
## Important Notes
### The Call Never Resumes Without a Callback
If you call a RemoteFunction whose `OnServerInvoke` has not been assigned, **the calling thread stops forever with no error and no timeout.** There is no way to cancel the wait.
* Design your initialization order so the server assigns the callback before any client call is made.
* If the work can take a long time, consider sending the request with a RemoteEvent and reporting the result through a separate event when it finishes.
**You can tell a hang and an error apart by the symptom.** Assigning a value that is not a function (a module table, for example) **passes silently**, and the error appears the moment you call it. In other words, if nothing happens at all, the callback is **not assigned**; if an error appears right at the call, a **non-function value was assigned**.
### Use the Correct Script Type
`InvokeServer` can only be called from a LocalScript, and `InvokeClient` only from a Script. Calling from the wrong place is not silently ignored; it raises an error.
### Callback Errors Propagate to the Caller
An error raised in the server callback is delivered to the calling client and interrupts the client code. If the work can fail, wrap the call in `pcall()` or return a success flag instead of raising an error.
```lua
local isSuccess, result = pcall(function()
return C2S_BuyItem:InvokeServer(itemId, amount)
end)
if not isSuccess then
print("[BuyItem] Error : ", result)
end
```
RemoteEvent has no such propagation. An error in the receiving callback does not affect the sender.
### Do Not Use InvokeClient
`InvokeClient`, which lets the server call a client, carries three risks, so **its use is strongly discouraged.**
* An error raised on the client **propagates to the server** and interrupts the server code.
* If the target client **disconnects during the call, an error is raised.**
* If the client never returns a value, **the server stops forever.** A malicious client can trigger this on purpose.
If the `player` argument is not valid, the callback does not run and an error is raised at call time. These are the four cases.
* The value is `nil`
* The value is an Instance that is not a Player
* The value is not an Instance (including a table forged to look like a Player)
* The value is a reference to a Player who has already left
Be especially careful when you **store a reference to a player who has left and call with it later.** Check that a stored reference is still under `Players` before using it.
**Alternative** : Send the request with `RemoteEvent:FireClient()`, and if you need a result, have the client send it back through a separate RemoteEvent.
```lua
-- In Script
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local S2C_RequestSetting = ReplicatedStorage:WaitForChild("S2C_RequestSetting")
local C2S_ReplySetting = ReplicatedStorage:WaitForChild("C2S_ReplySetting")
local function RequestSetting(player, settingKey)
S2C_RequestSetting:FireClient(player, settingKey)
end
local function OnReplySetting(player, settingKey, value)
-- Receive the result through a separate event instead of a return value
print("[ReplySetting] ", player.Name, " / ", settingKey, " : ", value)
end
C2S_ReplySetting.OnServerEvent:Connect(OnReplySetting)
```
### Values Change When Crossing the Boundary
Values that cross the server-client boundary are converted along the way. **This applies equally to RemoteEvent arguments and to RemoteFunction arguments and return values, and no error or warning is raised.**
* **Functions are not delivered.** Passing one directly results in `nil`, and placing one as a table value **removes that key entirely.** If you need to pass a callback, agree on a string name and map it on the receiving side.
* **Instances that are not replicated**, such as those under `ServerStorage`, disappear the same way.
* **Tables are delivered as copies.** Filling an argument table on the receiving side leaves the sender’s original empty, so receive what you need as a return value. Metatables are not delivered.
* **Use string keys only.** If a table holds both array elements and named fields, the named fields disappear, numeric keys turn into strings, and instances or functions used as keys can no longer be looked up with the original key.
```lua
-- Risky — the callback key disappears, and owner disappears with it
C2S_SomeFunction:InvokeServer({ "Sword", "Bow", owner = "Diva", callback = OnDone })
-- Safe — nest the array one level in, and agree on a name for the callback
C2S_SomeFunction:InvokeServer({ items = { "Sword", "Bow" }, owner = "Diva", callbackId = "OnDone" })
```
### Passing Instances in a Streaming-Enabled World
When `StreamingEnabled` is on, an Instance the server created and returned **may not exist on the client yet.** In that case you receive `nil`, and it may never arrive at all.
* Check for `nil` before using the returned value.
* Wait **with a time limit**, as in `WaitForChild(name, timeout)`.
* If necessary, consider loading the area in advance.
```lua
local Part = C2S_CreatePart:InvokeServer(position)
if Part == nil then
print("[CreatePart] Not streamed yet")
return
end
```
## Advanced Usage
* For communication that needs no return value, use **RemoteEvent** instead of RemoteFunction. A synchronous call stops the caller.
* Since data sent from the client cannot be trusted, it should always be **validated by the server**. (See **Server-Side Validation** above)
* Send only the necessary information to the server to reduce network load. (Send **only minimal data** from the client)
* Avoid creating too many RemoteEvents or RemoteFunctions. If tasks can be handled in the same context, process them with a single object.
* Create RemoteEvent connections only when necessary, and **disconnect** when finished to avoid memory leaks. (`Disconnect()` function)
* When using a single object to handle multiple tasks, add the first argument (EventType) to indicate the **task type**. (Example of using EventType: PlayerActionType and ActionID)
* Do not perform long waits inside a callback. The calling client waits just as long.
* For communication within the same environment, use BindableEvent or BindableFunction.