Restore Mojang skins proxy

[erickskrauch]

Since Mojang disabled skins.minecraft.net API, Chrly doesn't proxy skins if skin not found in data storage.

---

We investigated current rate limits for Mojang API. From documentation we know that all public APIs are rate limited and currently set at 600 requests per 10 minutes. And it's true for the biggest part of endpoints, but not for UUID -> Profile + Skin/Cape endpoint. For this point there such note as "This has a much stricter rate limit: You can request the same profile once per minute, however you can send as many unique requests as you like". And it's confirmed: we easily performed 19k requests from the one IP for about a minute (Mojang, if it affects you, we are really sorry. You know, it's all for science!).

---

So here is our new solution.

Chrly must organize some processing queue. In this queue Chrly will send request to Playernames -> UUIDs endpoint to exchange usernames to actual uuids. These requests shouldn't be triggered more than once per second and contain more than 100 nicknames. After uuids received, we can exchange them to textures via UUID -> Profile + Skin/Cape endpoint. This request can be performed without any queue: just as fast as possible.

Data obviously should be cached, but there appear some questions:

• Should we cache username -> textures and always respond it or should we cache username -> uuid and request textures every time to immediately handle textures changes? It's important, 'cause if we will have rps over 100 (at daytime (UTC+3:00) Ely.by have a way more rps), than we will be unable to check all textures and some users will don't have skins.

• Another question is should we use primary storage (Redis) or cache it in the Chrly memory with fixed size and some sort of strategy of repression? Currently, Redis eats about 1.5Gb of memory on our production server and is not going to reduce appetites.

• Third question is how long we should cache it? Should it be hour or a few days?

---

If someone has any ideas about this stuff, I'd like to hear your opinion.

[Nik-mmzd]

we easily performed 19k requests from the one IP for about a minute (Mojang, if it affects you, we are really sorry. You know, it's all for science!)

It was pretty easy. Only 1k curl threads and about 100% CPU load :D

[afdw]

It is also possible to make new versions of patched Authlib for Minecraft 1.2.5+ that will pass special flag to Ely.by (like noMojang=true). When the server receives a request with this flag, it does not make a request to Mojang if there is no skin in Ely.by database, but instead informs the client that it has to fetch the skin from Mojang itself, using IP address of the user.

[turikhay]

@afdw it may also work as a proxy for Ely.by itself by forwarding the full response from Mojang to Ely. As far as I know all responses are signed, so Ely is able to do the validation.

[erickskrauch]

@turikhay yes, I have thought about it, but there is one key problem: we are going to receive textures, that we don't know. Ely.by codebase uses md5 to identify skins, but even with over 1 500 000 skins in our DB there will be very low hit rate of known textures. I'm not saying that it would not work, but I'd imagine that there will be a lot of skins, that'll never appear on Ely.by. Of course, we can drastically increase Ely.by's skins base, but without a skin recognition system this will only increase the memory costs without a real benefit to the project.

@afdw yeah, it sounds like a good idea. We may decrease the load by reallocating this logic into Authlib (Minecraft 1.7.10+), but for old versions (we are still keeping support for Minecraft 1.2.5) this solution could be the only possible solution, since writing patch for obfuscated classes is not a good idea.

[Nik-mmzd]

@erickskrauch we can use both solutions at once: 1.7.10+ will request Mojang textures by itself, older versions will ask chrly for Mojang textures, so it will lower Mojang textures RPS

[TheRadioGuy]

If skin is not exists in database - get skin by mojang api.

If you reached mojang api limit - add this task to queue, and return default Steve skin to client;

You can create longpoll connection, and when we will get skin, we will return skin to client;