So I realized that I will need some way to push out events to the browser without having to poll all the time with HTTP.
For this I decided to use Redis together with Socket.IO.
I wont write a tutorial about this right now, just thought I'd share the technology a bit.
Tutorial might come later however .
Apart from needing some way to push out my events to the browser (WebSockets with Socket.IO), I also needed some way to store very temporary session data.
My application does not use standard sessions, and instead makes use of JWT tokens.
This is because the auth server and the game server that I'm building are on different servers, so when you login on the auth server you will get a token which will contain your session state, which is then simply validated on the game server.
Thus no actual session data is stored on the game server, until now with Redis.
Basically I will use the key:value part of Redis to store the user UUID and a value from the game that I need to keep track of (The value will become old very fast, so storing it in the database didn't feel like a good option).
Redis, from what I've read, is an excellent option to speed up the web application as a whole (6 times faster according to some blogs I've read).
Anyway, until I've gathered enough material for a short tutorial, here's some stuff you can read if you're interested
I'll be linking some stuff from Laravel as well since that's the framework I'm using for my API.
https://redis.io/" onclick="window.open(this.href);return false;
https://laravel.com/docs/5.5/broadcasting" onclick="window.open(this.href);return false;
https://laravel.com/docs/5.5/redis" onclick="window.open(this.href);return false;
https://socket.io/" onclick="window.open(this.href);return false;
If you want to stay in the front of web dev, I highly recommend these technologies
Having at least tried them seems to give some bonuses during job interviews right now (as they are trendy, and interviewers appear to like the trendy stuff).
Redis - in-memory data store, a database and message broker
Redis - in-memory data store, a database and message broker
"The best place to hide a tree, is in a forest"
- z3r0aCc3Ss
- Fame ! Where are the chicks?!
- Posts: 700
- Joined: 23 Jun 2009, 16:00
- 14
- Contact:
Re: Redis - in-memory data store, a database and message broker
Sounds intriguing... I tried using Redis a year ago, but couldn't get it working.
Let me know how it works...
Let me know how it works...
Beta tester for major RATs, all kinds of stealers and keyloggers.
Learning NMAP
Learning NMAP
-
- cyber messiah
- Posts: 1201
- Joined: 30 Apr 2006, 16:00
- 17
- Location: 127.0.0.1
Re: Redis - in-memory data store, a database and message broker
Cats,
I know this is an old thread, I was just curious as to how will you be scaling? You may want to be careful about eviction policy, let's say if its LRU, if these sessions are going to be persistent as it would be in case of a game server, then these will be evicted, and users will start getting disconnected or whatever your "lack of sessions" handling is.
If not, you will hit the memory limit of your Redis server, and with redis, you also need to be careful about active connections, it does not manage any connection pools within its implementation, so you need to manage that at the client application level.
I know this is an old thread, I was just curious as to how will you be scaling? You may want to be careful about eviction policy, let's say if its LRU, if these sessions are going to be persistent as it would be in case of a game server, then these will be evicted, and users will start getting disconnected or whatever your "lack of sessions" handling is.
If not, you will hit the memory limit of your Redis server, and with redis, you also need to be careful about active connections, it does not manage any connection pools within its implementation, so you need to manage that at the client application level.
Re: Redis - in-memory data store, a database and message broker
pseudo_opcode wrote:Cats,
I know this is an old thread, I was just curious as to how will you be scaling? You may want to be careful about eviction policy, let's say if its LRU, if these sessions are going to be persistent as it would be in case of a game server, then these will be evicted, and users will start getting disconnected or whatever your "lack of sessions" handling is.
If not, you will hit the memory limit of your Redis server, and with redis, you also need to be careful about active connections, it does not manage any connection pools within its implementation, so you need to manage that at the client application level.
Actually haven't gotten this far yet.
Building a UI library for the game (but have taken a break to finish up a few others things first).
I will take this into consideration however!
"The best place to hide a tree, is in a forest"