A networking library for Roblox designed to simplify communication between the client and server, with support for remote events, remote functions, and network exhaustion detection.
Roblox provides built-in networking objects such as RemoteEvent, UnreliableRemoteEvent, and RemoteFunction. While these are crucial to making any game in the platform, managing them directly across a project can lead to repetitive setup and inconsistent networking patterns, apart from having the ability to be more compressed using buffers.
Examples of this are having folders for each type with tens of instances in them, and though they can be organized through folders, it's not ideal to have many references to those in any scripts, mainly for organization.
Dysconnect aims to make networking easier to organize and use by providing a unified interface for supported communication types, apart from optimizing network as much as possible while keeping commodity intact.
-
Simplified networking: Work with supported network objects through a consistent API.
-
Multiple communication types: Support for reliable remote events, unreliable remote events, and remote functions.
-
Client-server communication: Organize communication between clients and the server.
-
Network exhaustion detection: Help protect against excessive remote requests with configurable per-player rate limiting.
-
Event call batching: Reduce remote event calls by batching every single one called in a single frame to only one remote call.
-
Configurable behavior: Adjust network exhaustion detection settings to suit your experience.
Dysconnect supports almost every type of network instance:
BindableFunctions aren't supported due to their rare usage (at least personally) but might be in a future update.
Dysconnect uses Roblox's buffer library to serialize supported values into a compact binary representation before transmitting them over the network.
Instead of relying solely on Roblox's default argument serialization, Dysconnect encodes values into a single buffer using a type-tagging system. Each value is assigned a type identifier, allowing the receiving side to determine how to decode it.
This approach provides several optimizations:
-
Compact data representation: Numbers use appropriately sized int or float representations where supported (bit-size wise).
-
Precomputed payload sizes: Fixed-size data types have predefined sizes, avoiding repeated size calculations for those values.
-
Custom serialization: Supported types (including Vector2, Vector3, CFrame, Color3, UDim2, TweenInfo and other Roblox data types) have dedicated encoding and decoding logic.
-
Table serialization: Each key and value in a table carries its own type identifier so it's possible to encode every key and value individually.
Strings, existing buffers, and JSON-encoded values are length-prefixed, allowing the decoder to determine where each payload ends. Values that use JSON encoding can also be represented through the same tagged serialization system.
The actual savings depend on the values being transmitted and how Roblox's default serialization represents them. Performance and bandwidth improvements should be measured against representative workloads rather than assumed for every payload.
Something to note is that Instances aren't serialized into buffers for one main reason: serializing an Instance would mean turning it into a .rbxm file using SerializationService and deserializing it in client, effectively making a copy of the same Instance. This is something that shouldn't usually be done over the network as it'd take up a lot of space, and it's just better to recreate those instances in client if really needed to (like hitbox visualizers) with the bare minimum data required to do so. Instance serializing isn't included in this package to enforce good practices networking-wise, preventing so much data to be sent unnecessarily.
Dysconnect includes network exhaustion detection to help mitigate excessive remote requests from individual players (DDoS).
Its configuration includes a usage threshold, a recovery rate, and a modifier controlling how UnreliableRemoteEvent calls contribute to accumulated usage.
The detection system is configurable to accommodate different networking requirements.
Dysconnect also has an option to batch events, which is true by default when installing the library.
This means that any (reliable / unreliable) remote event calls applicable for this will be added to a queue so all calls in a single frame are then batched into a single remote call containing all the data in the same frame.
If the packet for that single call is big enough, packets that don't fit under the hard cap (16 KB by default) will be passed to the next frame to avoid lag spikes due to high amounts of data being sent at once.
This is opt-in and can be disabled by default by specifying it in the settings of the module when initializing, or editing it directly if a package manager isn't being used.
This can also be disabled for specific remote calls that need to be fired immediately instead of sent with the rest of the batched calls, which should be crucial things like fast gameplay mechanics or stuff that needs to arrive ASAP. This can be configured by sending a Dysconnect.FireOptions() as a last argument to a remote event, with a table for the options including a Batch boolean, indicating if that call should be batched or not.
Of course, there are many other good alternatives out there to check out.
- Packet: Similar to this package, but with different usage, allowing you to make individual event objects (NOT instances).
- Warp: Supports schemas and is also very similar to typical events.
- ByteNet: Minimizes packet size as much as possible using schemas to define events, saving on sending value types and position pointers, though is harder to use.
Dysconnect was made to keep everything centralized in a single place and to be the most simple to use out of them all while keeping most of that network performance gain.
See the license for more information.