WebSockets would be greatly beneficial to Roblox. Their nature allows for real-time communication for both the Roblox server and a web server, in both directions.
Currently, there is no effective way for a server to wait for information to be sent from a web server to a Roblox server, other than long polling (inefficient). We have to just keep continuously sending HTTP(S) requests to the web server to check if there are any pending requests, etc.
I’m aware that this post (Web Sockets for servers) was made, however, this post was posted a long while ago, with no detail as to how it was actually a security risk (I understand from a client perspective, but not a Roblox server perspective). In addition, some people feel as if the original question was misinterpreted, so it’d be great if we could get an update regarding this.
Whilst it may put stress on their servers, limitations could always be imposed like with the current HTTP API available, such as no more than 3 WebSocket connections per game instance at one time.
Use Cases:
Cross-server chat.
Cross-server player positioning? (Ambitious, but would be awesome).
Cross-server alerts.
Player banning system.
Server statistics system.
I’m sure there are many more people can think of. WebSockets would unlock the door to a large set of possibilities.
It should absolutely be clarified whether or not you want WebSocket server or WebSocket client support. Are you wanting Roblox to act like a web browser? If so, then you want WebSocket client support, which has fewer security risks and is more likely to be looked on favorably. If that’s what you want, you should change the title to “Add WebSocket Client Support” to clarfiy.
Some of these will be possible when MessagingService comes out, which is a cross-server communications service.
The rest don’t need WebSockets and can be done with DataStores or regular HTTP requests.
I do like the idea of WebSocket client support, but those aren’t convincing use cases. Can you think of anything that is only achievable with WebSockets that can’t be done with MessagingService, DataStores, or HttpService? Can you think of anything that’s not a super niche use case? If you can, those would make for much better use case examples!
When MessagingService does release, I guess a lot of the cases I provided could use that, however, for some use cases, an external server is absolutely required.
I’ll go into some more detail using the “banning system” use case.
Currently, I’m having to check every 30 seconds or so if a player is banned. At high player counts (50+), this sometimes fails due to the HTTP limit being reached. There are other systems in the background using HTTP requests also, which are using up the request threshold.
30 seconds is a long time for a player to be banned, especially if they are exploiting. I want more “snappy” communication - near instant action. I would reduce the check time, but that’s simply not an option, due to the mentioned reason.
We also have systems that are controlled via a control panel, such as in-game actions (events you could say). It’s very important this communication remains fast, and doesn’t fail often.
Systems like these would greatly benefit by the use of WebSockets, especially if there are usually HTTP requests flying around. It can all be simplified by the use of WebSockets.
There is an alternative: long polling. Send a request from Roblox to your server, and have your server keep that request until it times out. Then send another from Roblox. This lets your server respond instantly any time before the request times out. This should give you instant results and only require you sending a new request around every 2 minutes.
You’ll have to do some testing with it. That 2 minutes number might be off (it’s at least 30 seconds), and I’m not aware of any libraries to handle this. I actually wrote a cross-server-communication service around two years ago with this method!
Bumping this thread as support for a websocket client would be nice.
Additionally, if I understand how websockets work correctly, having a client shouldn’t interfere with server strain as it utilizes http requests under the hood, meaning it could tie into the already existing 500 http request limit. Of course, it’d be nice if websocket requests were in the own separate pool, even if it was 500 total per minute.
Right now, we’re relying on something called “long polling” for real-time communication. Think of it as constantly asking someone if they have any news—it works, but it’s far from the most efficient method and it eats up a lot of resources. I’ve developed a tool called Roblox Long Polling to try and make this easier and more scalable, but I’ve seen the limitations of this system myself. Despite trying to optimize it, we hit roadblocks when multiple scripts are using HttpService, often putting us right up against our limit of 500 requests per minute.
As we keep integrating more platforms into games via HttpService, usage is ramping up. More users mean more data requests, putting more strain on our limited resources. You can think of each game or platform as a customer in a shop, where the shop can only serve 500 times per minute. As we get more customers—scripts checking bans externally, logging events to databases, and so on—we quickly hit a point where the shop just can’t keep up, increasing competition for resources.
This is where WebSockets come in, offering a solution to this issue. They provide a faster, more direct way for real-time communication. Instead of constantly asking for updates, we get notified right away when there’s an update, turning our clunky conversation into a smooth, easy chat. Plus, they allow us to offload some high-frequency requests—like ban checking or player and chat logging—to a more efficient system.
Basically, introducing WebSockets is like opening up a fast lane in our shop specifically for these ‘high-frequency’ transactions. This not only makes things more efficient but also doesn’t count towards the 500 request limit, leaving more room for other important processes in our HttpService.
Previously, a Roblox staff member mentioned this will never be added. However, this API would make running external services which require real-time communication easier, and stop games from spamming unnecessary HTTP requests.
p.s. it’d be cool to if the HTTP cap was raised proportinate to the number of players… or bumped in general
I saw this got bumped so I’ll mention that this is only really viable in Studio, otherwise, Roblox’s internal servers would be opened up to external data or abuse.
Studio already opens a port when you host a play server (that can be connected to by other Studio clients, which is pretty interesting). I’d like it if you could just open a localhost port on Studio, with a handler callback that sends the request body (similar to RequestAsync).
We can add a limit from the max connected clients in a websocket by a default defined value or the max available players in a roblox game to prevent unwanted connections from trying to (possibly) manipulate messages between clients.
The client can connect to the Websocket Connection if or has:
a Valid Client Token is sent to the Websocket Connection (dynamic token, hidden from the user and is only Client-accessible.)
a Unique Digital Signature(s) to verify the Client connecting to the Websocket is a Legit Connection and not a malicious one.
If you want to actually ignore authentication and just allow that connection, we can do the thing called Client Behavior Analysis (i made the name nerdy lol) where the server analyzes each client’s behavior to detect unusual client activities. (e.g. Detecting user requests such as (for example): Economy Modifications, Game Data Modifications, etc.)
To verify requests coming from Websocket is true is to:
Receive a Response based on the expected data wanting to be recieved
Have a unique identifier/key for each responses
I cannot guarantee a 100% secure websocket connection for these following methods as there are some ways that some of the given methods to prevent abuse is possibly exploited / bypassed.
I believe that there is someone else there that is much more better at security and can come suggest much more better ways to make a highly secure websocket connection.
Couldn’t agree more. Currently I am using HTTP Requests and the Messaging Service API to interact with my Database Service. But it’s way to inefficient and very limited. I’m easily hitting the limit & it’s just way too complex rather then just using WebSockets which allows for more features and more great things to be made easier & more efficient compared to the solutions I’ve come up with for now.
WebSockets would be super useful for certain things (mostly push-based notifications, which currently can only exist w/ long polling, which is resource intensive) however using them as a bypass to HTTP limits wouldn’t solve your issue - WebSockets are web requests too and would likely be throttled to the same, if not more.
A more full solution to the limitations you face here would just be to improve bulk requesting & caching so you’re not constantly having to read and write from an external database.
Bump. This would be extremely useful for real-time applications. Long-polling is not sufficient for developers. We need this flexibility. I’m sure the countless others that have already bumped this post can agree.
Bump. Roblox’s HTTP long polling system is not sufficient for our games in 2023. As developers are more and more frequently integrating outside services with their games via HTTP (Discord, Trello, etc), Roblox is not adapting to a bit of it. As some developers have said on this thread, they’re hitting Roblox’s 500 request limit, and what will happen when we need even more resources than that? It not only restricts us, but it puts unnecessary strain on the Roblox servers, and in some cases, client devices. I’ve been working with WebSockets since 2015; they’re very easy to use, and they do not take up the amount of resources that long polling does.
Roblox just has a track record of being very ignorant of developer needs, so I don’t think we’ll get WebSockets any time in the future. Here’s to hoping though!
But I think that limits for WebSockets will not be like how the limits for HTTP Requests are. WebSockets overall don’t require as much resources as HTTP Requests do.
HTTP GET request with minimal headers might be around 0.5 KB to 2 KB.
HTTP POST request with a small payload could be around 1 KB to 5 KB, depending on the headers and payload size.
VS
WebSocket Request for small to moderate-sized messages and basic connection management, 1 KB to 5 KB
WebSocket Request for larger messages and more complex connection management, 5 KB to 20 KB or more
So I think a Database Event Listener with only one side actively sending requests, will take less memory usage then long polling or constantly sending HTTP Requests. Therefore, as in most cases it will propl. use less memory, it’s limit will be lower than the limit for HTTP Requests.
However, I think there will be a strict limit on how many WebSocket Connections you are allowed to have open, as connections take up more memory, also depending on the implementation.
Overall, I just hope that this feature gets added.
