New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Hmm I hadn't heard of sourcemod before, but I found it on github and it looks like it has wrappers for mysql and sqlite. Depending on how much hacking you're willing to do, adding redis doesn't seem impossible.
You can still get free PaaS from OVH.. https://www.runabove.com/SaaSDBMySQL.xml
Online.net has it too (free beta), though it looks like you need a server with them to get it. But, I think this is not a good application for MySQL. Maybe there's some other way to do it within the Sourcemod framework, like with some simple in-memory table.
How does sourcemod work? Is it just server extensions, or client too?
Thats what I have done for now, Ive cached lookups and done all the updates when the client exits. If the server crashes the state is lost so I will have to write it out periodically.
They have an API: https://sm.alliedmods.net/new-api/
Through it I am able to do all sorts of fun things in the game
Thanks, that's interesting, I see the earlier version had a sockets module but the new one doesn't seem to? Is there a way to talk to sockets from scripts now? The pawn scripting language looks so low-level that you might as well write C++ modules anyway. If there's a socket module then communicating with Redis is pretty simple, and there are tons of Redis client libraries for other languages that you could start from. So you could write a Redis client directly in Pawnscript. Otherwise adding one in C++ doesn't seem that bad. Just start with the MySQL client and hack out all the SQL stuff
.
Rather than write out the whole state, you could log updates, then play them back if you restart the server. You can write out the whole state during quiet times or with some separate program that munches the logs, so you can start from the most recent snapshot instead of having an ever-growing pile of update logs to play through. This is a common database technique that's used by Redis, MongoDB and others.
Run SQLite as an in-memory database, and save it on a timer with its backup API (https://www.sqlite.org/backup.html). You will save the latency of network transfers to a separate DB process, and don't need separate caching. Plus, I think SQLite is faster than Redis.
The issue is that the db has to be called through the SM internal API which exposes only limited functions through Pawnscript. For this particular workload I'd expect Redis to be faster, though sqlite would be faster at some other things, e.g. involving larger result sets. I dunno though.
There was also a question of notifying 500 concurrent clients of updates, which is not sqlite's forte. Redis is good at that. But now it sounds like the clients aren't supposed to have direct connections to the db.
I can offer a dual L5520 with 16gb of ram and 1tb disk in raid 1 for £35 per month.
Correct, matches are in sets of up to 10 players, I run many concurrent matches each as a process on game servers with DDoS protection (not important for a DB server as it is not client facing). Each server process creates a connection to a MySQL table so for each match I have a connection for each event I want to hook.