Gru: Storing session info on server

When a client tries to establish a new connection with the server using the auth token, if the auth token is valid and hasn’t expired yet, we issue a session token to the client.

The client must send the session token in all the calls that it makes now. We need to ensure that

  • Client can’t start another session 1 hour(a constant) after he started the first session - This would require the start time of the first session to be written to the file which has all other info
    <name> <email> <valid-until> <token only alphanumerics> <start-time>.

  • Multiple sessions for the same user aren’t active at the same time - The session info for the current session can be kept in memory. When the client conn is closed we can clear the session info in memory.

  • Client shouldn’t be shown a repeated question if he starts another session if the first session got killed for some reason.
    This should be fine if the connection got disconnected from the client as the question list that we store in memory is specific to an auth token. Though, it might be a problem if we store the question list in memory and the server crashed. Should we worry about the server crashing case?

Thoughts @mrjn, @ashwin95r?

Use the log files more thoroughly than you’re doing now. So:

  • Session and auth tokens both get stored in log file, as probably one of the first entries. Don’t store it in the manually written auth token file.
  • Think of session token as a throwaway temporary object.
  • If the server crashes and we get a call from a valid auth token, the server can read the log file back (lazily) and load all the questions it has already asked in memory.
  • Also, this would give the server the necessary context to figure out which question to ask next when it becomes smarter.
1 Like

Okay, so I can have the log file start with an auth token dummyauthtoken.log or with the email of the candidate like pawan@dgraph.io.log. I think starting it with the auth token should serve us well enough. In the file we can write the auth token, session token, test start time, responses like below.

2016/06/13 13:13:13 auth_token dummy-auth-token
2016/06/13 13:14:13 session_token dummy-session-token
2016/06/13 13:16:13 test_start
2016/06/13 13:16:10 ping qid1 
2016/06/13 13:16:15 ping qid1 
2016/06/13 13:16:22 response qid1 [A1,A2] 10
2016/06/13 13:16:25 ping qid2
2016/06/13 13:17:24 response qid2 [A3,A2] -5
2016/06/13 13:17:25 ping qid3 
  • Now when a client tries to start another session, we can compare it against the test_start.
  • We can check for multiple sessions for being active at the same time too now that we have the session_token in memory.
  • Since we know the questions he has looked at, we can make sure he isn’t shown the same question that he say earlier from the ping info.

Yeah, makes sense. Note that you want to avoid reading the log file. You only read from the log file when server crashes and restarts, or when we generate reports offline.

1 Like

For the ping interaction

  • Setup a ping to client every 5(this would be a constant) seconds.
  • Send the time left for the candidate, we record the startTime after the first qn is sent to the candidate.
  • Also there should be a way to signal end of test through these pings whenever the time for the test is up.
  • Check on the client the total time left. If there is a discrepancy of more than 1 sec, update clock on client.
  • The client should send a ping every 5 seconds too with the question id that the user is looking at currently. This should be logged to the file for this auth token like so 2016/06/13 13:17:25 ping qid3

I think we could just update the client’s clock with the server time when it receives a ping, no need to have a discrepancy check I guess.

1 Like

That would cause an issue in case of network latency or intermediate network delays – also the rate of timer update in the client view then would have to be dictated by how often does the client talk to the server. It’s better to keep them separate. So, the client can update every 1s, but only talk to the server every 5s or so.

Also, if we miss X pings to the server, we should have a way to indicate to the client that we’re missing network connection. Then, the user can do something about it.

Ah, what I meant was we could sync the time variable when it receives the ping. The time displayed in the client can be updated every second.

I think if we do that, we’ll end up abruptly jumping our clock too much. My sense is that it would look weird to the human eye. It’s better to only sync if we are beyond a certain error level.

2 Likes

Hey @ashwin95r

Did you find a way to know if a client connection got disconnected? We need someway to know if a client hasn’t sent a ping in a while and then we can remove the in memory sessionId, so that he can create another session. We need this so that we can differentiate between a genuine disconnect and the user trying to open multiple sessions at the same time.

Yeah it could be found out if we get an error while trying to send a message via the stream

@ashwin95r. So we would need to clear out the session id when this happens.

Also thinking about changing some stuff on the server side. In the scenario when the user has taken the test and say the client crashed at some point. If he wants to boot up again, I show him the demo screen again and then I send the GetQuestion request. When the server tells me he has already taken the demo, I send another GetQuestion request which then gives me the question if he hasn’t already finished the test.

Instead of all this, I was thinking that the Authenticate request apart from sending me the session token, could also send me some config which would include a

  • state - demo_not_taken | demo_started | test_not_taken | test_started | test_finished

  • duration_left_in_test

So the first screen can be a Authenticating.... screen, which would display errors like Invalid token etc. If the token is valid it will get a session_id and start the demo/test based on the status the server sends.

This would help in the case when the client or server crashed and the user has to take the test again. For e.g. if the user has already started the test I don’t need to show him the instructions screen again, I can directly continue with the qns that have not been shown to him for the test. Similarly for demo.

Sure, we can have a authenticate RPC which does this.

There is already an Authenticate RPC, it can me modified to return the config too.

Also, duration left in the test need not be sent explicitely as that would automatically sync up via the ping. So, only the state should be enough

Hmm, but then the candidate would see 60 mins initially as the sync would happen after 5 seconds?

That won’t be a nice experience.

Umm actually when the client comes up, the stream is created and immediately a ping is exchanged. So there won’t be a delay. But yeah, we can have the duration sent, it’s just one extra string.

I suggest we try this out and see if there isn’t any noticeable delay, then great. Otherwise, we should pass it as part of config.

Yep, just for a fraction of second it shows 60, it then changes immediately.

Did you try it out? How?