BACKGROUND: For the past couple of years, I have been constantly brainstorming, creating, fixing, destroying, and then remaking and redefining an advanced cloud-base administrative system for Roblox, and I’m at a stage now that I believe I have an almost-solid prototype that’s nearing a stage of beta release.
REMOTE COMMUNICATION: Today, I just finished the implementation of the finalized design for communication over the Client/Server. The way that this works is via a central module I have dubbed the “GATEWAY,” which has a single RemoteEvent parented to it. When one side wants to send data to the other, a metaphorical “portal” will be opened via the Gateway. The Gateway then signals another module called the “Station.” Like the Gateway, the Station is a shared module between the Client and the Server, so no matter which side we’re looking at, the functions within can be utilized locally. The Station compresses the data into a “packet,” which is really just a table. The packet is then given a header and a footer (both are strings), with the header being a long key/token combination that I randomly generate with obscure math and Greek letters prepended by some information about the packet, and the footer being a serial number dedicated to said packet. The packet is then stored locally in a table. A finalized packet may look something like:
{
Header = 'PACKET->\0\0\0Serial_Number=9999999&Timestamp=9999999&Key=UppercaseGreek:LowercaseGreek',
Data = {
'Destination',
NeverGonnaGiveYouUp = true,
UrMom = 'ROFLMAO LOL',
},
Footer = '1234567890',
}
Following this, another packet is generated, but this one has an empty Data field and hard-coded header of “->READY.” The serial number is added to the footer, and then returned to the Gateway. The purpose of this “ready” packet is to initialize a communication between the Client and the Server, as both sides will require data for the packet prior to the transmission being sent. The ready packet is then sent through the portal that has been created with RemoteEvent:Fire_(readyPacket). The other side processes said ready packet and adds some data that I’m too lazy to transcribe, then returns the packet back to the Gateway with an edited header of “READY->.” The acknowledged packet is then sent back through the portal to the original side, where the Gateway once again signals the Station. The Station analyzes the ready packet to ensure that everything is in order and both sides are ready to complete the transmission. Then the true packet, which has been idling in the local storage table, is passed back to the Gateway, and once again sent through the portal. The Station on the other side reads the data from the packet and determines where it’s supposed to end up, then fires a BindableEvent with the name of the requested destination with the packet as the first argument, and all data as the following arguments. If the Server is the one receiving the packet, the user who sent the packet is also documented and that variable is placed in between the packet and other data. Whatever function is assigned to the Bindable is then executed. Technically things can stop here, but they can also continue. If one side has a response to make to the other, the original packet can be sent back through the portal since it’s still running, and the other side can act on it until the Station and Gateway are both signaled to terminate the connection, at which time a packet similar to a ready one is sent, but with a header of “CLOSE->.” Both sides then remove all data about the packet from their local storage, so that then if any further attempts are made to send packets over the network with the same credentials, they will be declined and action such as kicking a user for exploiting may be taken.
MY CONCERN: I’m labeling this as a potential concern and not an issue because it might not even be a problem, but if it is I would like to know. Due to the nature of the Gateway and Station, a lot more is happening than just RemoteEvent:Fire_(). As of right now, there is no noticeable lag, but I’m worried that a potential issue could ensue if a lot of users were all making communications at once. The local storage could be overwhelmed, but I doubt that since tables can get pretty big with no adverse effects. What I’m more worried about is the RemoteEvent. Because everything operates off of this single Event and not multiple ones as many systems do, and due to multiple packets being sent in rapid succession, will this potentially cause:
- Significant lag for users
- The RemoteEvent to be so completely overwhelmed that critical data is either corrupted, lost entirely, or Roblox’s server will refuse to send it kind of like a DataStore throttle
I know it was a lot to read, but an answer would be very much appreciated!
SECURITY NOTE
Due the fact that the system is not in public beta yet, I’m keeping the files confidential for now, which is why I have not attached a .rbxl file to this post. If you require a section of the code to provide insightful feedback, please notify me and I’ll see what I am willing to divulge.