[Enhancement]: Change PID assignment strategy

[jonbarrow]

Checked Existing

• I have checked the repository for duplicate issues.

What enhancement would you like to see?

Change the way PIDs are assigned to new NEX accounts/PNIDs. Back when this server was first made, we went with a random assignment approach. Every user got a random PID assigned to them. The way this was done was by literally just generating a random PID, seeing if it was used already, and then if not assign it to the user, otherwise generate a new one. This worked fine initially, but is HORRIBLE for something production as it's incredibly slow once there's more than a few users.

The problem is that since we have almost a million users (current counts are 305,240 PNIDs and 782,870 NEX accounts), we have a HUGE pool of random PIDs that have been assigned already. So we have to do something such as:

1. Create a new pool of all PIDs that have yet to be assigned, and then sequentially pick from that pool (would work, but would also require more setup and would be kinda weird/annoying for new instances which have 0 PIDs assigned)
2. Find the smallest assigned PID and sequentially count down from it (would work, but we might end up clashing with internal user PIDs and idk how well these consoles like small PIDs)
3. Find the highest assigned PID and sequentially count up from it (would work, but idk how well these consoles like large PIDs)

Any other details to share? (OPTIONAL)

Several years ago I remember having issues with assigning PIDs to a Wii U account where the PID was outside the range of 1000000000-1799999999 (which is the full range we pick from currently). This was backed up by the facts that:

• https://account.nintendo.net/v1/api/admin/mapped_ids?input_type=pid&output_type=user_id&input=1800000000 returns nothing
• https://account.nintendo.net/v1/api/admin/mapped_ids?input_type=pid&output_type=user_id&input=1799999999 returns prodtest1, and the next few accounts counting down seem to be admin, service and internal test accounts

So it seems like when Nintendo rolled out NNIDs, they started counting down PIDs from 1800000000. However we have definitely seen PIDs way outside of this range. For example, our Animal Crossing: New Leaf DataStore archive has PIDs between 132542879 and 2000677499. So the 3DS is able to handle PIDs outside of the NNID range, maybe this is a NNID-specific issue? Or there was something else that went wrong in my tests back then? I'm unsure

If NNIDs really can't handle any value outside of that range, then that does pose an issue for us. Currently the PNID with the smallest PID is 1000003692, and the PNID with the highest PID is 1799999791. If we're limited to the range 1000000000-1799999999, then that means if we go with the "find the smallest and count down" method, we'd only have 3692 PIDs left to assign. If we go with the "find the largest and count up" method, we'd only have 208 PIDs left to assign. Neither of which are options that work for us

If we're not limited by the range, and can go HIGHER than 1799999999, then that would be the best option for us since we can avoid colliding with internal accounts. We'd still need to stay within the uint32 bounds, but even starting at 1800000000 and going up leaves us 2,494,967,296 PIDs to assign

If we ARE limited to the range, then our only real option seems to be creating a pool of unassigned PIDs and picking from that

[jonbarrow]

Requesting thoughts from @DaniElectra on this one

[DaniElectra]

FWIW on 3DS NEX accounts the maximum limit used by the official server seems to be the max signed int32 (2147483647). I'm unsure as to how the console would react with PIDs outside the signed limit, but I believe there were certain instances of the PID being represented as a signed integer (can't remember where though), so we should be careful about that upper bound

[jonbarrow]

FWIW on 3DS NEX accounts the maximum limit used by the official server seems to be the max signed int32 (2147483647)

Even then, if we're able to start and 1800000000 and go up that leaves us 347,483,647 PIDs available to assign before we hit the max signed int. Which should be more than enough. That's 144x the number of users even Wiimmfi has, and is ~4x the number of Wii U and 3DS units sold combined

I'm unsure as to how the console would react with PIDs outside the signed limit, but I believe there were certain instances of the PID being represented as a signed integer (can't remember where though), so we should be careful about that upper bound

The only instance of this I can find is in OLS Storage, where it seems like all the structures (but not methods) use an sint32 for PIDs. So yes, we do have to keep this in mind it seems. But like I said, that SHOULD be fine assuming NNIDs can have PIDs outside of the known range