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.
