Communication Protocol - Client specification

[dAmihl]

What the client sends: (Request for Comment ;) )

-passwords will always be sent hashed -token is the sessionID given at logIn -items written in bold have highest priority!

• checkLogIn(username, password)
• registerUser(email, username, password)
• getAllTreasures(token)
• getNearTreasures(token, myLongitude, myLatitude, [optional radius?])
• getProfileData(token, userID)
• eventTreasureOpened(token, treasureID, userID) [a treasure is opened when the quiz is solved]
• eventTreasureWrongAnswer(token, treasureID, userID) [serverside handling of wrong answer given, maybe reset treasure or whatever]
• getHighscoreListAll(token)
• getHighscoreListAroundMe(token, userID, [range])

  What the client could receive: (also Request for Comment)

• checkLogin with a token, if login successful, else null
• registerUser with boolean
• getAllTreasures a list of treasures
• eventTreasureOpened boolean, if opening was allowed
• eventTreasureWrongAnswer boolean, if correctly handled by server

Please remember, items in bold first!

[dAmihl]

@BenjaminGAUGLER

[bfjmg]

@dAmihl You can look up the current rank of the user via getProfileData. Thus there is no need for more than one method getHighscoreList(Integer token, int low, int high).

edit: changed order of from high low to low high btw. low is the best rank you want to recieve - high the worst

[Philipp-p]

@dAmihl regarding getAllTreasures, i wouldn't let the client ever get all treasures

[Philipp-M]

Additionally I would say, that the priority should be as following(while the priority shouldn't be overrated, since the requests should be handled within milliseconds, and the case where more than one request is handled inside the server is rather unusual, it's more something like a theoretical construct): 100 is the highest,

• checkLogin: 100
• registerUser: 80
• getAllTreasures(if at all, like @Philipp-p said): 10
• getNearTreasures: 20
• getProfileData: 70
• eventTreasureOpened: 90
• eventTreasureWrongAnswer(I would suggest the name eventCheckTreasureQuizAnswer): 85
• getHighscoreListAll(this command shouldn't be used too often, when thinking in a bigger context, since there could be a - lot - users(well not in our case I guess ;) but just to be general), better use getHighscoreListAroundMe): 15
• getHighscoreListAroundMe: 85

I weighted the commands mostly based on the expensiveness and the time that the user has to wait( a getNearTreasures can run in background, while a getProfileData and eventTreasureOpened should be handled immediatly to not bore the user/client)

There should also be a command for checking if the user is still active(heart beat)

[bfjmg]

@damihl RequestParser is fully implemented, but some methods still don't have a connection the Core. @Philipp-M and me will finish this in the next couple of days.

@Philipp-M There is at least a theoretical problem. What if we had a lot of users logging in, and second user trys to open the same treasure cheast as that one still waiting for the others to log in. Short: can you assure first come first served for the treasure chest opening? As I already mentioned - it's just a theoretical question. However a way to solve this issue is to give the TreasureOpenEvent method the highest priority.

[Philipp-M]

Well no problem with that(and I'll do that ;) ), but the login user check shouldn't be a problem at all, since it is quite a cheap command in comparison to open a treasure, and since it should be highly unlikely that about a million users will login at the same time(and it really has to be almost the same time, since even on a Raspberry pi the user login check should not take more than maybe 10-50ms), this shouldn't be of concern, because the connection to the clients is parallel and thus the time mainly needed to handle the request is wasted there. By the way the commands are almost completed, and will be committed soon.

[Philipp-M]

Another thing I see while reading the commands, the user id shouldn't be given since the token is the user id, the commands can thus be simplified.

And a check for the correct answer can also be saved, since the convention is, that the 1st answer inside the Quiz Object is the correct answer(so it has to be shuffled if it will be displayed)

[dAmihl]

@Philipp-M fun fact: I wasn't talking about some execution queue priorities in my suggestion, more of a implementation priority ;)