CS_Communicator - An object oriented approach to client-server communication

Resources Community Resources
#1

CS_Communicator (Client-Server Communicator)

An easy to use, object oriented approach to client-server communication.

Why use CS_Communicator?

As Roblox grows into a massive ever-evolving platform, security is an issue. FilteringEnabled is a (deprecated) property in Workspace that is automatically toggled as you start a new place, which is a big first step to combat malicious exploits in-game, blocking client changes to the server. New scripters are required to learn how to work with FilteringEnabled to disable experimental mode in their games- through remotes.

Remotes can be tedious to maintain especially when the game grows to be complex.

CS_Communicator aims to make client-server communication seamless and easy.

CS_Communicator installation/ usage:

Here’s the GitHub code. Please familiarize yourself with the license (and very much appreciated if I can be credited somewhere in the game/description!)

Put this in a ModuleScript.

Examples:

-- Server script

local FE = require(path.to.module);

FE.hookUpClientRemotes {
    clientTest = 'async'
};

local Listener = FE.listen('sync', 'serverTest', function(Player, Text)
    print(Player.Name, Text);
    return 'Test done!'
end);

wait(3)

FE.fireAllClients('clientTest', 123);


-- Local script
local FE = require(path.to.module);

print(FE.request('sync', 'Test Name', 'abc'))

FE.listen('async', 'clientTest', function(Arg)
    print(Arg);
end)

-- Output
iiau abc (server)
Test done! (client)
123 (client)

API

  * <String>Type is an Enum, with values 'sync' or 'async'

  FE.listen(<String> Type, <String> Name, <Function> Listener)
  	return: <Communicator>
  	> On the server, creates a new remote and listens to it.
  	
  FE.request(<String> Type, <String> Name, <Variant> Args ...)
  	return: nil (async), or returned arguments (sync)
  	> Sends a request across client/server
  	
  FE.hookUpClientRemotes(<Dictionary> Remotes)
  	return: nil
  	> Remotes must have this format:
  	{
  		['Name'] = 'async'/'sync'
  		...
  	}
  	> Sets up remotes for the client to listen to.
  		
  FE.waitForRemote(<String> Type, <String> Name, [Number: 10] Timeout)	
  	return: Remote instance if exist, or nil if surpassed timeout
  	> Waits for given remote instance to exist for reference.

  FE.fireAllClients(<String> Name, <Variant> Args ...)
  	return: nil
  	> If a RemoteEvent is found with the given name and it's called on the server,
  	  fire all clients with given arguments
  	
  <Communicator>
  	:Destroy()
  	> Destroys the communicator, sets the object to nil

For experienced programmers:
You can also add your own methods to this module and specialize it to your likings. Have fun :slight_smile:

8 Likes
#2

This module doesn’t help with security, it only simplifies client-server communication. Saying it improves security will only make people slacker about security because they will think it keeps everything secure automatically. Please be more clear.

FE isn’t some magical anti-exploit. It is an industry standard method of client-server communication that Roblox should have forced from the beginning. Security is still just as much as a concern now as it was before FE was forced.

But using this module, new scripters still have to learn just as much than they would when just using remotes directly.

Other than all of that, this is a pretty cool module. I just think you should update the post the be a little more accurate.

Keep up the good work!

11 Likes
#3

It’s awesome that you wrote a wrapper for client-server communication, but I wholeheartedly agree with grilme99’s post. Security remains a top priority when building a game with FilteringEnabled, and in many cases just makes it easier for exploiters to find vulnerabilities when implemented without the required knowledge of building secure infrastructure (i.e. before FE exploiters had to read/manipulate scripts to break your purchasing logic, now simply scanning the game for badly programmed remotes and invoking them will do).

New scripters are indeed required to learn how to implement client-server communication properly and securely, but hiding the key components behind a module that doesn’t use the same terminology as the components it uses behind the scenes (i.e. you’re using sync/async instead of function/event) might, arguably, make it harder for new scripters to learn how client-server communication works.

The module itself is neat, and I think it can still serve developers for the use case that you provided (Remotes can be tedious to maintain especially when the game grows to be complex). I just want to make sure that any less experienced developers reading through this topic are aware of the risks and don’t see this module as a way to cut corners. Your slogan ‘Never fear about client-server communication again!’ makes it sound like an all-in-one solution that delivers more than it actually does.

3 Likes
#4

I personally think that this module is useless.

You have done a really nice job on the module but I think that it is useless. The way that this module works is similar to the way that you would typically do client-server communication through defining the remotes and calling them, in this case the only difference here is that instead of defining the remotes, you are using a module to call the remotes. I personally use modules too as I find them more organized but the way that the module works is kinda pointless in my opinion, the reason for that is that you are “recreating” default functions built into remotes for no reason. I think that there is no need for that.

However, I think that maybe this module could be helpful to people who also program with JS or new Lua programmers who have previously worked with JS as the structure of the code is kind of similar to JS and your module can probably make the code to a JS programmer seem more readable. I am not sure if you meant the structure to be like that but your module uses camelCases which are used a lot in JS modules and code. Also the functions .listen and .request are also used a lot in JS modules. I think that what I said in the second paragraph was kinda irrelevant and probably sounded stupid but just something that crossed my mind that I wanted to say.

EDIT: I meant to reply to @iiau, not you, sorry!

1 Like
#5

As someone who programs a lot in JS, I can say that this isn’t really that similar to JavaScript (or Node). camelCase doesn’t make something easier to understand. Lua itself is very self explanatory from just reading it, and the same goes for this module. If anyone has past programming knowledge than I can see them understanding this just a little.

1 Like
#6

First of all good job! I think that you approached advertising this new module the wrong way. Instead of telling people that it is some black box that magically gets rid of all security issues in games, you should market it as a communication module. I personally can not see myself using it due to the nature of making remote events/modules with less code than this solution.

The license for this module is also a mess for game owners if you are releasing your module you should make it open-source, not open credited source. I’ve used node, but you don’t see me going around everywhere telling people my website is based on it, do you?

If you want to continue with this module give examples of this new security your module brings, and how it will speed up peoples life.

Perhaps take a listen to what everyone here has said and move on to bigger projects, you clearly have some potential!

1 Like
#7

I program lot in JS too. I am not saying that the structure of the code of the module is really similar to JavaScript or exactly the same, but it somewhat is. I am not saying camelCases make code easier to understand or easier to read, but a JS programmer who has used camelCases a lot in the past would probably find the code of a module which uses camelCases easier to understand.

I also am aware of the fact that a lot of other Lua developers still use camelCases to this day and the might have not even heard of JavaScript, as I said it is just something that passed through my mind that I wanted to say.

#8

Nice work on this, but I just have to ask: Why should I use this module over using a more proven framework such as Aero?

#9

Little strange to add the name of a deprecated property in the module name, it kind of dates the module. I would recommend renaming it not to mention FE since no new developer is going to understand what this is, since this is just the default way of things now.

#10

Edited OP, but kept some info about FilteringEnabled.

1 Like
#12

This module isn’t a game framework, it’s some sort of wrapper around RemoteEvents and RemoteFunctions

#13

I’ve a few personal issues with your wording, primarily revolving around FilteringEnabled and Experimental Mode.

First, it’s an automatic feature now since Experimental Mode has been completely removed and is no longer possible on new places, only old places that aren’t updated since that patch. This wording needs to be re-arranged so it’s not explicitly saying FilteringEnabled is only enabled when toggled.

This is also another wrongly worded statement. You don’t ‘communicate’ with FilteringEnabled, but rather work in it. You also do not disable experimental mode just by communicating with FilteringEnabled, it’s something you can’t enable or disable as it’s been removed.

Just a few remarks about the post.

1 Like