3

I'm developping a turn by turn strategy game and I'm trying to do the multiplayer part. I never did anything similar but I received strong advice to use rpc. My multiplayer games will be hosted on a main server, and basically the player send what he do and receive the new state of the game. If I understand right, with the rpc architecture, the server can only reply to a request he has received.

So what I thought is that the player first log into the server, sending credentials, he send what he does by rpc and each x milliseconds he try to refresh his current game (by sending a request "refresh"). What I dont understand is how with this I can have a memory of the authentification. Do I need to relog each time (and send credentials) for each request (that seems like an awful lot of imformation to send). How do I recognize a request from being from someone that I have currently granted authentication? How can I handle the logic between coherent but separated request?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Atol
  • 569
  • 4
  • 12

1 Answers1

3

One possible solution is to maintain session on a server side.

When user logs in you can generate session id and store session id to session data(user id, etc.) mapping on a server. Session data might be stored in memory or in some fast key value storage like redis or memcached. When you have stored your data you can send session id back to the client. Now you can send this session id to the server to identify the user.

Mairbek Khadikov
  • 7,939
  • 3
  • 35
  • 51
  • Does it have not big security issue and it ask for every request a redundant information no ? – Atol Nov 03 '12 at 10:02