question

Jason Irvan avatar image
Jason Irvan asked

Unexpected Results returned from CloudScript

Running the Handler below I am getting very odd results. The number stored should increment, and it does, but it "bounces" around as it increases. I ran this in Postman eight times in about 5-6 seconds and this was the results in the order received.

 

10010, 10011, 10012, 10013, 10011, 10012, 10014, 10015

 

I assume this is a side effect of multiple front ends caching and/or replication delays on whichever KVP/NoSQL data store you are back-ending PlayFab with.

 

I can work around this problem by basically doing what you guys did in your Union example for Usernames that are already taken after I get the NextDefaultId. Even if I do end up with a collision due to several new customers connecting at the same time and getting the same key, I should be able to resolve the collision with a minimal number of calls.

 

So my question(finally) is should I expect this behavior when calling directly to the various data stores from the client API or is this just a CloudScript Server issue? I ask because this will drastically change how I handle data that updates often.

 

// Account management handlers
handlers.GetDefaultUsername = function(args) {
    var titleData = server.GetTitleData({ "Keys" : "Key_NextDefaultID" });
    var next = parseInt(titleData.Data["Key_NextDefaultID"]) + 1;

    server.SetTitleData({ Key: "Key_NextDefaultID", Value: next });

    return {
        nextDefaultId : titleData.Data["Key_NextDefaultID"]
    }
}
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

As opposed to user data, title-level data (title data, publisher data, news items, catalog items and their custom data) is cached, as it is optimized for its use - to be read by all players for the game. The TTL for those data types is currently around 10 seconds, though that could change as we update the service. The key is that title-level data is not intended to be something that changes frequently. It is for configuration-type data, that is shared across all users of the game (game balance info, etc.).

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Jason Irvan avatar image
Jason Irvan answered

Ok, that makes sense.

Would storing active data like this in a SharedGroup with Public permissions on the keys make more sense perhaps? If I understand correctly, anyone can read public keys in shared groups, but only the server, admin, or the owner can edit public keys correct?

 

Thanks for the info.

 

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

Can you describe what the intended usage is? While it's true that a shared group data object wouldn't have the cache time, it's not designed for every user in the game to be calling the same keys - that could result in throttling of responses to your game, which I'd rather avoid.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Jason Irvan avatar image
Jason Irvan answered

New users are allowed to begin playing the game semi-anonymously using only a deviceId authentication to create the account. On the first (and only the first) time they login from a new device, I was intending for that CloudScript call to generate a unique player name without user intervention (User101002 for example).

 

 

The intent is to store the next valid number portion in a variable and increment it for each new player. Once that initial authentication occurs, that user should never request the variable again unless they wipe their device or connect from a new device.

 

The user will eventually be asked to change their player name and link the account to a another authentication method. But that's after we have them into the game and hopefully engaged, but before their first IAP.

 

Thanks,

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

The service isn't really designed for that usage model. If you have a large number of users creating accounts in a short time, that's definitely going to cause some throttling issues. What I would recommend instead is auto-generating a GUID for the user instead - that's the system being used by most of the major platforms (have a look at the default usernames for phone accounts in Xbox Live, for example).

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Jason Irvan avatar image
Jason Irvan answered

If you guys cannot handle

- a single zero parameter web call per new user

-that has the server increment a stored integer by 1, and then returns it for each new device that requests an account, what is it you would say that you are offering exactly?

That is practically the "Hello World" web service example on MSDN that you just stated your service can't handle...

And all within your companies own stated limits (2 calls to the api from inside the handler, way under 1Mb of data transferred, and returns in 23 ms)

I just wasted 3 days coming up to speed on your platform and working it into our current title to be told you can't handle the most basic of functions without rate limiting my account.. 

Thanks but no thanks, I'll be moving on now.

 

 

 

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image
brendan answered

I'd say what we're offering is a service which provides authentication, a full economic system, title data, user data, and a host of other services. What you're specifically asking for is a counter which increments by one for every user signed into your title. We don't have that specific counter implemented as a service offering right now, as we haven't had developers asking for it. We do add any new request we hear to our backlog, and we prioritize in part based upon aggregating that info - so, if a feature is being asked for by a lot of people, it'll move up in our priority list. We can also do custom development work for titles that have a key need for something not currently scheduled, on a contractual basis.

Using title data for this isn't really viable, as title data is cached. Meanwhile, user data (shared group data, specifically) isn't really the right place for this, as you're talking about having every user in the service query the data. The limitation there is that non-cached data like that can't be distributed, so you wind up having every query hit the same source. All database systems have limits, in terms of query throughput - hence the need to cache (and so distribute) things that are going to be queried by tons of people - that's how any backend service provides scale to titles.

So, is it possible to use Shared Group Data to do what you describe? Yes, it's certainly possible. I'm advising against it simply because if you have a large number of users - and in particular, any periods of new user spikes due to UA campaigns, etc. - you'll wind up in a situation where too many calls are being made to retrieve the same key, for a data source that can't be scaled, as it cannot be cached. That's not a limitation of our service - it's just physics.

Again, my recommendation would be to use the same system that many games use on mobile platforms - to randomly generate the ID that you append to the username, and use that, providing for the same retry mechanism you described on collisions. As with an incrementing counter, this would provide a means to create an arbitrarily generic username for your players.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.