Hey! I’m trying to create a global messaging system for my upcoming custom chat system & I’m trying to find the best way possible to make the messaging seamless.
I’m aware of the existence of MessagingService but I’m just afraid the rate limits would be hit too quickly in larger servers and encounter many more issues.
I was thinking about using a combination of MessagingService and MemoryStoreService but I’m just not sure how effective that it would be without interrupting user-experience.
My goal is to create a system that can support tens to maybe over a hundred messages / minute and I’m not sure how to combat the rate limiting in a safe and effective way while making it simultaneously instantaneous. For the record, the messages I’m sending are arrays (fully compressed) are about ~ 400 bytes so stacking with something like a queue might also become an issue.
Anywhere I should start with this? I haven’t used these services on this kind of scale before.
HttpService grants each server instance of a game 500 HTTP requests per minute, that works out to around 8 requests per second (per server), which should be more than enough.
I had kind of thought about using HTTPService but;
This would be a public resource for people to access via a model & I’m not sure if my server memory and API could handle potential thousands of messages per minute
After thinking about this reply for a while, it seems pretty plausible but I’m just not sure how to ensure that the poster of the message is legit if this resource goes beyond just my own closed-source games
2A. What I mean by that is, by posting a message to the server I’m not sure how to 100% rule out the chance of someone sending a false request.
If you wanted to be really efficient, you could pack messages together into larger packets and just send ~1 per second, or even more often, like ~10 per second. Then you definetly shouldn’t have trouble with the amount limits, however, you may run into a problem with the 1Kb limit.
That’s what I wanted to do initially but it just feels off when it’s delayed by 1-2 seconds and you’re right abt the 1KB limit, from testing an average message with 200 characters (and other metadata for it) is about 450 bytes with compression.
HttpService is also a plausible solution to ignore this limitation but I feel that with this being open-sourced someone would find a way to forge fake messages through the API and abuse that and end up having games open to moderation.
Filtering is all in place, just with it being HTTP I feel like I’d need to filter it again just to be safe.
I’d use this probably to check even then but I’m still not sure what the player parameter is required for, I could pass a random player and have it probably work just fine but I don’t know if that would get them in moderation trouble for it being passed as them being the sender if it contained profanity? I understand the other methods needing it but this one that’s for broadcast doesn’t make sense in requiring the player as an argument to me personally.
I don’t think a 1 second delay will be problematic, especially with the amount of players you are trying to account for. Having the “scroll” not be constant can be helpful for comprehension as well, so have the chat move, and then stop for a second, then move again may just be better.
Alternatively, you could intelligently package the messages. Basically, have a set interval, like 1/10th of a second, or just 1 second, then during that time, constantly add messages to the packet. You could do a rough calculation of size by saying that each char is 10 bit (which is higher than it really is, but just for the sake of leaving some space for error. Then if the packet “fills up” send it early and start packing the next one. It would allow for you to send more packets if need be, and send fewer packets if it’s not necessary.
I had done this initially but I think I did something wrong. I got it working now again and I can successfully send 100 messages in 25 seconds in near live time but I’m just not sure where the limit is, this should be good for now since the chat has cooldown limits built-in for message sending.
Thanks for helping me go back to that concept! In the end I ending up using: (in order)
Check if the compressed packet size + the current packet size (compressed) >= (limit) then → post → clear packet data → retry the packet that was just sent that couldn’t fit
Waiting about 1 second and seeing if that packet was the last request or there’s more than 5 packets in the queue then → post
No, that is a perfectly good solution. In the event that too many messages are being sent, a queue may just build up, which may act as a buffer for a while, until eventually messaging cools down and the queue can be emptied.
EDIT: Roblox has chat lag with big games anyways, I don’t think that a few extra seconds of chat-lag will be a big deal to players.
To account for this I might have it replicate the message to the origin server channel while waiting for it to send to the other servers. This way it doesn’t look like it took multiple seconds for the message to be sent by the sender waiting for it to show up in the channel.
