LB Connection v2.3.0-beta - a module that offers an alternative to RemoteEvent, RemoteFunction, BindableEvent, and BindableFunction in Roblox Studio

LB-Connection

LB Connection is a module that offers an alternative to RemoteEvent, RemoteFunction, BindableEvent, and BindableFunction in Roblox Studio. It is specifically designed and coded to function within the Roblox Studio environment.

GitHub Rojo Version | Roblox Marketplace
(The link will be changed after each version released)

API

The API is on the GitHub
GitHub

Example

Client

--!strict
local LBConnection = require(game:GetService("ReplicatedStorage").LBConnection)::any;
local TestRemote: any = LBConnection.RemoteEvent("Test", {
   RateLimit = 30,
   RateLimitTime = 2,
});
TestRemote:Fire("Hello World!")

Server

--!strict
local LBConnection = require(game:GetService("ReplicatedStorage").LBConnection)::any;
local TestRemote: any = LBConnection.RemoteEvent("Test");
TestRemote:CallBack(function(player: Player, str: string)
   print(player, str);
end)

Advantages

Queuing package to the next frame
The module operates by iterating over the queue and transmitting its contents. In the absence of any queued packages, no data is sent. This approach centralizes data traffic and reduces the risk of traffic overload.

Prevent memory leak
This module addresses the memory leaks caused by the invocation of InvokeClient with Roblox RemoteFunction without returning any value or the use of Roblox BindableFunction, which yields until the function halts or returns a value. To prevent these memory leaks, the module includes a TimeOut parameter in its RemoteFunction and BindableFunction implementations, which can be used to specify a maximum duration for the function call and prevent the hang-up or memory leak from occurring.

Rate Limit
The LBConnection module includes a rate-limiting mechanism for the RemoteEvent, RemoteFunction, BindableEvent, and BindableFunction objects, ensuring the platform’s stability and security. The RateLimit and RateLimitTime parameters allow developers to control the rate at which remote events are triggered and processed, providing a flexible and customizable experience for game development. By specifying these parameters, developers can prevent excessive usage or abuse of remote events, ensuring a smooth and enjoyable player experience.

Extremely light obfuscation
The RemoteFunction in this module employs a secure identification method by passing a random binary string packed with an unsigned integer to the client and requiring the client to return it to the server. This approach helps to prevent potential exploitation by ensuring that only the correct data is returned to the server. (It should be noted that the binary string obfuscation used in this module is extremely light and can still be viewed by exploiters, potentially allowing them to manipulate the data sent from the server.)

Faster execution
The implementation of RemoteFunction in the module utilizes two RemoteEvent objects to simulate the behavior of RemoteFunction. Furthermore, implementing BindableEvent and BindableFunction in the module does not utilize any BindableEvent and BindableFunction objects, resulting in faster performance and increased maintainability.

Tips

It is recommended to pre-add the RemoteEvent or a Folder containing two RemoteEvent, “Sent” and “Recieve”, to the Remotes folder using the Roblox Studio explorer. This can help to improve the speed at which LBConnection.RemoteEvent and LBConnection.RemoteFunction can access the RemoteEvent or RemoteFunction.

When firing the LBConnection.RemoteEvent, it is only necessary to declare the second parameter once on the side from which it is fired. For instance, if the event is being fired from the server, the ‘Info’ parameter should only be declared on the server side. It is unnecessary to declare it on the client side if you are setting the callback only.

To access an object that has been declared, it is recommended to use LBConnection.GetRemoteEvent , LBConnection.GetRemoteFunction , or LBConnection.GetBindable .

Q & A

Q: Why are you removing the feature of packing byte string to binary format on v2.1.0-beta?
A: My friend did a solo test in Roblox Studio, where networking isn’t a bottleneck, and there was no upper limit. The main problem was generating new data. Strings are already optimized for us, so further optimization might result in diminishing returns or worse network usage. The networking optimizations for strings are already in place, so we don’t need to optimize them further.

Q: How can I modify the remote folder location?
A: To modify the location of the remote folder, simply edit the value of the RemotesFolder variable within the module.

Portfolio

Violet Grace’s Portfolio

22 Likes

This is my second time posting a module I have created in the development forum. If you have any questions, please feel free to leave a comment below.

1 Like

Okay
…

What are the literal chances? I was literally making a game right now and needed a communication module (I just do not trust the default remotes and bindables anymore). From the post, it looks pretty nice. I’ll try it out in a bit!

Also, for the functions that have player as the first argument, maybe make the ID the first argument? Cuz you’ll be sending the player that is important, yeah, but the place that you’ll be sending it to matters the most so maybe make the ID the first argument? Not saying it’s a problem, but just gave a suggestion.

1 Like

For this module, I have only utilized three RemoteEvent and have not used any RemoteFunction , BindableEvent , or BindableFunction . However, the module is not entirely without remotes and bindables. In response to your second question, the reason for passing Player as the first argument is that if the function is being used from the server to the client, the Player must be included as the first argument.

2 Likes

Just noticed that. You’ve done a good and simple use of the task library and remotes and bindables.

Ah, yes. Our very old server to client communication. I guess yeah in that case it’s important. Gotcha!

3 Likes

By the way, you’ve an unused variable on line 90.

Don’t think it’s needed as the callback is in the server.

1 Like

This design decision was intentional because when a remote is fired from the client to the server, Player is automatically passed as the first argument to the listener of the OnServerEvent

You’re welcome! I agree that Roblox has done an excellent job in facilitating communication between the server and the client.

So how would scripts communicate to server or client without those remotes?

That is just an example to demonstrate the functioning of LBConnection.FireBindable

Right. Can you give me a single benefit to using this module over normal remotes?

To the best of my knowledge, there is currently no way to facilitate communication between the server and client without using RemoteEvent or RemoteFunction

If you are referring to RemoteEvent , it does not create an additional RemoteEvent. In addition, it offers additional functions beyond the default RemoteEvent. It is also more convenient to use as you do not need to define Remote:FireServer or Remote:FireClient like the default RemoteEvent.

If you are discussing RemoteFunction, it is primarily handled using two RemoteEvent without creating a single RemoteFunction. It runs faster than the typical RemoteFunction and includes a timeout feature to prevent memory leaks caused by unclosed remote functions. It also includes a security measure by passing a GUID from the server to the client while LBConnection.Invoke is processing, which provides a layer of obfuscation.

You can replace it with _ to have it be ignored

I’m slightly confused as how passing a GUID provides obsfucation?

Yea, you are totally right lol

During the process of passing data from the server to the client and back to the server, if the client attempts to deceive the module by passing an incorrect string instead of the original GUID generated by the server, the CallBackState will return false and the CallBack function will not execute. While there is no absolute security on the client side, this measure makes it more difficult for exploiters to obtain the GUID. As a result, it provides a slight level of obfuscation.

But can’t they just hook this like any old remote event, copy the guid and edit the data?

Correct, it is still possible for exploiters to copy the GUID, but the server-generated nature of the GUID makes it more difficult for them to do so. The only opportunity for them to obtain the GUID is during the process of it being passed to the client.

Does the client then send that GUID back to the server for further authentication?,

Actually even if they do or don’t exploiters can still override the data being fired to the server.