[Feature Request] Server-side bank files

Editor Discussion
Post Limit:
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:

  • Bank files can be corrupted, manipulated or lost by user interaction (cheating).
  • Bank files are not easily available across different machines while using the same account.


  • 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:
  • 0 ... SUCCESS: An existing bank file was successfully opened.
  • 1 ... SUCCESS: A new bank file was created and successfully opened.
  • 2 ... ERROR: No bank file exists.
  • 3 ... ERROR: Cannot create bank file - out of space (1 MB limit).


  • 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:
  • 0 ... SUCCESS: The key was updated.
  • 1 ... ERROR: Bank file doesnt exist (openServerBank wasnt successfully called beforehand).
  • 2 ... ERROR: Cannot write key - out of space (16k limit).


  • 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 !
    I support this!
    +1 Lets go blizzard make it happen in HOTS!
    +1, even if you have to reduce the size of the bank, still worth it imo.
    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 !
    Come on Blizz, it can't be that hard. :) After all, you did make a whole arcade patch so you must care about it somewhat.
    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.
    Cloud banks would be such an amazing feature addition to SC2, it may single-handled reshape the modding community.

    Unfortunately, it's such a dangerous and costly feature for battle.net that it may never become true.
    come on blizz do something right

    +1 to the suggestions from MaxiTB
    OP: +1!
    Good idea hope this can happen
    +1
    +1
    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.


    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.
    11/05/2012 01:51 PMPosted by Soulzek
    Unfortunately, it's such a dangerous and costly feature for battle.net that it may never become true.


    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.
    Please make it happen. If it's not implemented for HotS I think I'll lose all hope.
    +1 You got my vote. It's way to easy to modify bank files. And server side bank would allow to play the game from a different computer and keep your stats which would be really great.
    +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.
    Thumbs upped and sticky requested.

    It would be nice to not loose your bank files if you had to either switch computers, or your current one went bad.

    Join the Conversation