0

I am working on a draft for an application which offers subscription based service for mobiles, there is a requirement that an account is only used on one device, if its logged into another one then first one is logged out. developer gave some ideas of regular polling but i need a smart way to reduce bandwidth rather than regular polling the DB for logged in users.

Issue is to keep heartbeat comms and warns user if someone else is logged in and save bandwidth as there will be over 10000 devices regularly querying.

Im not worried about language or code yet, I am after best way/logic currently. thanks for advise in advance regards, K

Kaleem Rehman
  • 48
  • 5

1 Answers1

1

Here's one approach.

  1. On authentication, a mobile receives a random security token which is stored against the user in the database, but also stored in an in-memory cache (shared by all servers) mapping a user id to a token.

  2. Every time a mobile user communicates, it includes the user id and security token which is checked against the cache: if the token does not match the token in the cache, then the database is checked. If the token does not match the token in the database, the communication is rejected with a message indicating the user is not logged in on this device or logged in elsewhere, with the option of re-authenticating.

  3. If a user explicitly logs out, the security token can be set to a special value in the database indicating the user is not logged in, and the entry removed from cache.

Size of in-memory cache is of the order of (number of users logged in) * (user id + security token length + overhead) * 2. For 10,000 users, GUID used for user id and security token, gives approximately 10,000 * (16 + 16 + 8) * 2 = 800 kBytes. So size of cache is not problematic. Use hash-with-chaining to allow deletion of hash entries, or look at the many open source key value stores out there.

It the "sessions" table containing the user and session token is small enough, the database may do a good job of caching the table it itself, in which case the sessions cache and extra logic may not be needed.

If you have an estimate for the frequency of communication between the mobile and the server, consider running an experiment to see if the cache is needed.

MZB
  • 168
  • 7