Topic
[Feature Request] Server-side bank files
|
Edited by MaxiTB on 11/4/12 11:32 PM (PST)
Hello everyone,
As everyone knows, SC2 currently only supports client-side bank files. That means user data for custom maps are stored on the client machine instead of Blizzard b.net servers. This has certain consequences: SC2 achievements and ranks on the other hand are stored on their servers and are usually well protected against direct manipulation. While this seems to be a minor issue for most custom maps, it is actually a big one for those who depend on solid values for rankings. On example may be the map StarBattle: It uses ELO based ratings to balance teams in specific modes, but this system only works when those ratings are persistent (cant be saved/restored) and protected against manipulation (cheating). In the end this has not only an effect on one player but all 12, because players are assigned to teams by ranking. Proposal for implementation Every b.net account should have up to 1 MB server-side bank space. The maximum size of a single bank file should be limited to 16kB. Server-side bank files expire after a set time (for example 3 month) when not used. Map creators can only store strings assigned to keys (key-value pairs). A non-existing string returns an empty string, setting a key to an empty string value will remove the string. API proposal openServerBank(boolean autoCreate) : integer Opens the server bank for the currenty loaded custom map. If autoCreate parameter is set to true and no file already exists, a new bank file will be created. An integer returns the success of the function: readServerBank(string key) : string Reads a key from the server bank. If the key doesnt exists, an empty string is returned. Same happens if the bank file doesnt exist. writeServerBank(string key, string value) : integer Writes a key value pair into the bank. If the value is an empty string then an existing key in the bank file is removed. If the key doesnt exist yet, a new one is created with given value. An integer returns again the success of the function: Summary As soon as you can open a server bank file, only the 16k limit will apply to you. Therefore a map maker doesnt have to consider the total storage available. In other words the size limit of the server bank should be predictable and not limited by the 1 MB limit. Opening a server bank will also adjust the expire date. Conculsion The 1MB/16kB limit allows for at least 64 server-side banks on b.net server. With proper compression more should be available. If you assume 64 bytes average per entry it will allow for 256 entry per file. Considering the low space requirements, the costs are minor compared to the benefits. I predict that only a view custom maps will implement server-side banks, even less player will play them, therefore most users will consume way less than 1MB, most none at all. Thanks for your attention, comments are welcome. PS: Greetings from the Gold Coast, I am heading to the beach now :). Appendix A: Reducing network traffic by caching This appendix extends my initial proposal by refining the concept with additional implementation details, in this case caching. While updates to keys are required to be transferred to the server after calling the function (to prevent ALT+F4 exploits), reading values does not. Due to the very same size of 16k for the dictionary it is possible to get all values with the first mandatory openServerBank call. openServerBank Execution: Blocking Opens or creates the dictionary with all key/value pairs and holds them in RAM client-side till the end of the game. Everything else was already documented. readServerBank Execution: Blocking Reads the data from the cached dictionary. No interaction with the server is required. writeServerBank Execution: Asynchron Updates the value in the dictionary and sends the update to the server as well. The last part is not blocking, this ensures that no lag effects will occur. Additionally if the send fails for some reason (like the unlikely event that Blizz servers are down), the map has to receive a proper notification which can be handled accordingly. All this will greatly improve the performance of the feature and minimizes all traffic with Blizz servers while still keeping the initial concept ideas intact. Thanks for the attention, thoughts and comments are welcome as always ! |
|
+1, even if you have to reduce the size of the bank, still worth it imo.
|
|
Edited by MaxiTB on 11/4/12 10:31 PM (PST)
Well, I dont see a big issue with the size as mentioned below already.
However constant getServerBank/setServerBank calls can use lag issues, but this can be fixed by limiting the length of names and values: For example 32 chars for the name and 256 for the value. The downside is ofc the amount time spend to implement the feature. Server-side its about a week time job for one person (incl. testing etc), while the Client-side is properly the same or more depending how well it will be handled. The communication layer is another topic, and I am pretty sure Blizz wants to reduce the amount of packages send to their server ... there is code available for all the social stuff like chat etc., but I have no idea how hard it will be to reuse/expand this code for low-latency communication. Besides, the idea is not really new. AFAIR Blizz announced something like that eons ago at BlizzCon, however the feature took somehow the path of the Titans. |
however the feature took somehow the path of the Titans. I like! :P |
|
Appendix A: Reducing network traffic by caching
This appendix extends my initial proposal by refining the concept with additional implementation details, in this case caching. While updates to keys are required to be transferred to the server after calling the function (to prevent ALT+F4 exploits), reading values does not. Due to the very same size of 16k for the dictionary it is possible to get all values with the first mandatory openServerBank call. openServerBank Execution: Blocking Opens or creates the dictionary with all key/value pairs and holds them in RAM client-side till the end of the game. Everything else was already documented. readServerBank Execution: Blocking Reads the data from the cached dictionary. No interaction with the server is required. writeServerBank Execution: Asynchron Updates the value in the dictionary and sends the update to the server as well. The last part is not blocking, this ensures that no lag effects will occur. Additionally if the send fails for some reason (like the unlikely event that Blizz servers are down), the map has to receive a proper notification which can be handled accordingly. All this will greatly improve the performance of the feature and minimizes all traffic with Blizz servers while still keeping the initial concept ideas intact. Thanks for the attention, thoughts and comments are welcome as always ! |
|
You are a bit late to the party, this was requested since years.
I support server side banks though, as long as they can store as much data as the local banks can right now. |
You are a bit late to the party, this was requested since years. Actually I posted a similar thing about 2 weeks after the launch of SC2 on EU ... but this time seems to be a good opportunity with the next addon and stuff. Server-side banks should be used for sensitive stuff only, because settings and other things are usually not so relevant. Therefore not much space is required. However I would ofc prefer if server-side banks would have the same functionality and access than the local ones. |
As I pointed out in my OP it is actually pretty cheap. Chat channel cause more traffic than my proposal, the storage costs are minimal especially with the expire mechanic which is similar to HTTP cookies. |
|
+1
Something map makers have been wanting since we started using banks. Editor scripts for encryption and obfuscation can be hacked too easily -- client side is bad. |
