So the Server has information that the client doesn't hold, and I wish to update the client on this. For example, if a Player clicks on a button to claim a land, all the server stuff will make the appropriate changes to do so, but the client still doesn't know that. I can either use RemoteEvents or RemoteFunctions and both I can use comfortably, but in terms of practice, which is the quickest, most efficient, exploit-proof way method?
✓ ANSWER ACCEPTED
Which way is better for Server to Client communication?
2 answers
✓ Accepted answer
Firstly, exploit-proofing is 100% reliant on the developer. For example, don't have the customer tell the clerk how much he's going to pay. That's just stupid. Another example would be having the client prevent spam. However, things can be bypassed on the client, can't it?
To answer your question, RemoteEvents are good for all-around use, whilst RemoteFunctions are good for yielding the current thread. This is both good and bad, I'll get to why in a second.
##RemoteEvents You can get anything done with these babies. They're efficient, non-yielding (unless you tell it to), don't pose any immediate drawbacks/security threats, and are overall very nice to use.
##RemoteFunctions
These are pretty much a "feedback" version of its Event counterpart. When you fire this remote, the current thread will yield until the function on the other computer returns (uses the return keyword). This is both good and bad. Good because it makes working with them a lot nicer for "GET" requests. Example:
local localData = PlayerData:InvokeServer(LocalPlayer)
Very clean-looking! The thread will yield until the server replies.
The downside is that, well, I'd recommend not using InvokeClient for the simple reason that a client doesn't have to respond. This can be game-breaking for scripts that do require the client to respond. Even if you use spawn to make another thread, the thread will simply become dead; a dead thread, just a thread that's only taking up precious memory.
##Conclusion Both have their applications. RemoteEvents are good for both simple communication or complex relationships. You may use RemoteFunctions for readability if that's what you like. However, never expect that the client will give you correct data, or any in that manner. Always be prepared. If you're not, your game may break.
####If I helped, be sure to upvote/accept!
which is the quickest, most efficient, exploit-proof way method?
If one was worse than the other, it wouldn't exist in the first place.
Both types of remotes work the same way internally -- they pass data over the network. The key difference is that invoking a RemoteFunction will yield the caller thread until it gets a response from the target. A network request sent using a RemoteEvent will immediately be forgotten about once it is sent.
Which one is better in your case then? That would be up to you but the simpler approach, especially for a beginner, is using a RemoteFunction. When the player clicks the button (*), it invokes the RemoteFunction. The server receives the request, validates it, performs the necessary actions and returns whether the "claim land" request was successful or not alongside other data if you so want. The client then makes sure the result of the action is displayed.
* For the smoothest user experience, the client should here assume the action is valid. This is a very widely used trick to battle network latency issues. If you've played FPS games where the bullet hits the enemy on your screen but doesn't register it, it's exactly because of this client-side prediction.
1 comment
0
Thank you for the clarification thank you!
This discussion is preserved as it was. New answers, comments, and votes are closed.
3 comments
Lovely stuff! Thank you!
If a client not responding to a request is able to break a game, it is the developer's fault. A dead thread doesn't take up any memory as it is removed from the scheduler and the memory is then free'd. Invoking an RF will of course keep the thread alive until it does get a response and that'll take up a small bit of memory which is not something to worry about, unless one is invoking tons of RFs->
Roblox will automatically abort RF connections with clients who have left the game, so the threads will all die eventually. There however absolutely should be an option to close the connection if an answer wasn't received before a certain time limit has passed.