cgisesh - a tiny cgi session manager for games

TLDR: I am making a minimal in-memory "session database server" for keeping track of user data, ideal for games. Any thoughts?

Every time I try to make a quick-and dirty CGI game or sketch out a simple application, I get really frustrated. Gemini conviniently provides user certificates which can be used to track sessions, but things get complicated very fast.

I am making a minimal subsystem for keeping track of user-associated data, ideal for simple games and Gemini doohickeys.

Rationale

To make even a very simple game you need to resolve certificates to sessions and keep track of them somewhere. A natural solution is a database, but that is quite a bit of overhead for a simple game! Not to mention that now you have to manage a database. And if you are running on someone else's server, you have to ask for the database to be installed and access rights.

When I was building Spellbinding, I've looked for minimal solutions, and settled on a very small embedded database engine called Kissdb. It worked fine, but I am not entirely happy with it. It is basically a persisted hashtable, so in addition to hitting the file system a bunch of times, it forces me to do stupid things like hashing the SHA256 hash, which is already hashed! And having looked inside, it is pretty stupid in terms of dealing with collisions.

Last week I wanted to make a quick prototype of another game, but got really bogged down in this stupidity. And I realized that what I wanted is something very lightweight that can track sessions for a CGI environment, that requires no maintenance and presents a minimal footprint -- disk, memory, server time, and most importantly my time.

A Minimal Session Component For CGI Games

cgisesh is a tiny server that runs in a separate process (with no special privileges required). Its purpose is to associate users (client certificates) with some data (you decide what you want to keep track of -- game state, user name, etc).

It listens on a socket for one of two commands sent by cgi scripts. Given a SHA256 hash from a user certificate, it provides you with a record associated with it. Given a record, it updates it. That is all.

Creating a cgi game or a simple thingamajig is very simple. You start cgisesh server providing it a record size and a domain socket path (which can be in your own directory). That's it for session management.

You send it the user's SHA256, from your CGI environment;

It returns a record containing the current game state; (all nulls first time around;

Your game logic generates gemtext and updates the record as needed;

You send the update to the cgisesh server;

Notes:

SpellBinding has not exceeded a couple of dozens of unique daily users (any database is an overkill)

Games are very session-bound: once a session starts, many subsequent hits follow (optimizations ahead!)

Games are non-critical (an in-RAM datastore is fine)

Status:

I am screwing around with an early implementation.

If you have any thoughts, please discuss here on BBS.

🚀 stack

May 15 · 4 weeks ago · 👍 drh3xx, mediocregopher

4 Comments ↓

🍀 gritty · May 15 at 23:59:

I like this idea. It kind of sounds like scgi using the sockets. what kind of data do you point it to, something loaded from disk just one time into memory?

I've found myself also wanting a nice routing system like some of these web frameworks have. I don't have a use for it yet, but a CGI framework for gemini seems useful, no?

🚀 stack [OP] · May 16 at 00:17:

@gritty: I am aiming for something completely minimal, no persistence, and very few in-memory records with MRU search optimization. It's data-agnostic, with binary fixed-size records (you can map your struct on it).

I could add persistence easily, but kind of like the idea of ephemeral services...

🚀 mbays · May 16 at 13:13:

Another solution to the same kind of problem, with sessions as processes rather than stored data:

— gemini.thegonz.net/gemrepl/

(It's an unfinished work-out-of-progress, but it basically works and I use it for some things)

🚀 stack [OP] · Jun 05 at 21:16:

Caching implemented. Most-recent 16 users are now in the cache, with an instant response.

Not only the cache accelerates access (repeated hits expected), but within the cache itself, every hit gets a promotion towards the start of the search, guaranteeing top position after a few hits. Active users will get super-fast results.