Enhanced MessagingService Limits

if my math isnt entirely wrong, this basically makes it possible to have a permanent cross-server chat system. that’s actually insanely cool

4 Likes

While that’s true, I don’t see when that would ever be an issue. All events in Roblox are loops done internally anyway, just in a faster and more optimized language. This is also something that doesn’t need to be checked rapidly, even once a second is probably faster than it would ever be needed.

But again, my concern is the per-experience limitations. Anything with a per-experience limitation is instantly a scalability issue, and therefore something I’d rather avoid. Memory stores use a per-experience limitation as well, but this limitation is dynamic and based on player count. This makes memory stores actually capable of virtually infinite scalability, where as this messaging service has finite scalability. Now whether or not that limit will ever be an issue will obviously completely depend on your usage of it, but it’s still a concern of mine regardless.

Actually I realized after re-reading the original post than the per-experience limit is actually dynamic (except for subscribe requests), based on the number of servers. This limit, however, is still very small compared to memory stores. Memory stores are also based on the number of players rather than the number of servers.

5 Likes

This is an amazing upgrade to the MessagingService - when will we get access to the MessagingService budget analytics similar to what we have for the MemoryStoreService? And as an extra ask, will we be getting a way at some point to view the remaining budget in live servers similar to how we can with the DataStoreService GetRequestBudgetForRequestType?

5 Likes

The limit Messages sent per game server is to limit the number of messages that can be sent from each server; the limit Messages received per topic limits how many messages can be delivered to ALL servers that subscribed to the topic. You can have multiple topics, and your experience can receive 40 + 80 * (number of servers) messages for each topic.

5 Likes

I’m new to the MessagingService… and wondering on what it will allow for our games.

Are there ways to create in-game telegrams… or even a mini forum (as topics are mentioned) ?

4 Likes

Would it be possible to get something better than the 1KB limit for message sizes? I realize that the network MTU in most situations is 1500 bytes, but 1KB is kind of limiting.

Perhaps a data compression API would be something interesting to consider adding to help increase this limit? Apply compression after JSON encoding of data? It wouldn’t be too hard to implement for LUA, but it would be faster if it was implemented in C/C++, and on the fly.

4 Likes

Hmm…

Your post gives me an idea for a hybrid messaging system.

Since MemoryStores don’t have events when things change, what you can do is modify the memory store and then send a message to say that the memory store was modified, then everyone listening to that topic can then read the memory store. That would be one way to give memory stores the topic feature and have it event driven.

4 Likes

Cool! Does this mean you can make an all servers matchmaking system?

Lets assume that each server has 50 players.

That gives us 1050 messages sent per sec. We only need to send 1 per 5 seconds. (If we compress all matchmaking into a table, and send it as the message.)

Messages received for entire game = (400 + 200 * number of servers) per minute

This is per minute, lets change it to per 5 seconds.

Messages received for entire game = (400 + 200 * number of servers)/12

Lets assume 1000 servers. - 16700 request per 5 second. 1000 servers would be sending 1000 requests per 5 seconds.

Lets try 10000 servers. = 166666 per 5 seconds. Which gives us 10000 requests.
(I’m starting to feel that my logic is wrong. :expressionless: )

Lets try a whopping 500 billion. = 8.3E12. They send out 500000000000 requests per 5 seconds (which is enough to communicate with all servers, and is still below the limit), which is 5E11. Lets just stop here, Each server has 50 players. 50*500 billion is 25 trillion. Therefore, this new update allows you to communicate with over 25 trillion people!!!

I tried this 3 times. My logic keeps failing. WHERE DID I MESS UP?!?!? :frowning:

3 Likes

Bypassing the data limits.

Good idea if you need to send more data than allowed.

Keep in mind MemoryStore data storage limits are rather strict and based on another metric. While the MessagingService limit is 1kB per message, MemoryStore limits are 64KB + 1KB ⨉ [number of users] for the entirety of memorystores. Re-evaluated every week or so.

This looks like a very big number, but it can get used up very quickly…

Might be a hassle to enforce both data limits depending on use-case.
Definitely an interesting idea!

3 Likes

MemoryStores were specifically designed for this sort of thing (also including things like a player auction house / marketplace, and many other things).

One important key difference is that MemoryStores hold on to data for a given length of time, where as this MessagingService just sends a message like remotes. This means that MemoryStores are better for things like matchmaking and server lists, where as this MessagingService is better for event-based cross-server communication.

6 Likes

To be honest I won’t use MemoryStore for auction house but DataStore instead since they remove the set cooldown limit…

3 Likes

The issue with DataStores is that they’re permanent and have extremely strict limitations, which will also eat into other DataStore usage for your server. You’d have to keep the auction house updated often enough, and then update whenever attempting to purchase. It may also increase the chances of item duplication if you’re not careful (when multiple people are attempting to buy the same item at the same time, whether in the same server or not). I also think the expiration time for MemoryStores is a positive thing as you probably don’t want things sitting in the auction house forever. You can set how long you want the item to be stored for. Most non-Roblox MMOs appear to have a similar system to this.

1 Like

Yeah I think I will try both option and see which one is the best but the problem with memory store is that I also use it for my Matchmaking

This is a massive W, good job there!

Great update, will be utilizing these new limits!

MessagingService does work in Studio.

1 Like

Now that’s great news.
Thanks for the great efforts!

@jjwu_play Has reliability been improved? Sometimes messages sent through the open cloud messaging API wouldn’t be received by servers even thought it responded with 200 status code. Can this be changed or could this be made to return a different status code in case it could not send the message to any topics. Thanks.

1 Like

The amount of subscriptions allowed always limited servers on the amount of cross server communication that could be done on the server when only 1 user was in game.

Having the default limit at 20 is huge and makes it possible to have separate topics for several server wide things with ease without having to put them all through a single or a few topics.

This all in general means a lot more cross server experimenting can be done and I like it, thanks Roblox.

1 Like

It’s still called out in the documentation that Delivery is best effort and not guaranteed, but we did try to improve the reliability as well. Have you experienced the issue recently (last 30 days)?

1 Like