fuzzball
fuzzball copied to clipboard
fuzzball-muck
Allow for specification of a keepalive command
Server-side TCP keepalives can help, but we have a few players that need client-side keepalive capability. I'd like to see a command or a tuneable value that lets us set a command that a player can trigger via client-side timer that generates regular network activity, but does NOT reset their WHO idle time.
Maybe they should actually be active and inputting commands when they're on the MUCK, instead of idling. That'd be better than a keepalive. This idea promotes destroying immersion on MUCKs, and MUCKs are a form of virtual reality. Maybe individual MUCKs can implement this, but why do this in FuzzBall itself? It's a self-defeating idea.
Because some poorly-configured consumer-grade routers have obscenely short TCP keepalive values, for one. Some terminate idle sessions after just 60 seconds. Don't know about you, but it can take me a couple minutes to write a pretty in-depth pose. Or maybe I'm working on a MUF program in a text editor, and pasting the code into the MUCK when I want to test. For this and many other reasons, I, as the server administrator, should have the ability to deal with these cases.
Also, the reason I specified the NOT reset their WHO idle time criteria was so that this would not cause a user to circumvent the idleboot time value on configured MUCKs.
Maybe individual MUCKs can implement this, ...
Without the ability to exempt a command from resetting a user's idle time, how do you propose to do so?
Also, the reason I specified the NOT reset their WHO idle time criteria was so that this would not cause a user to circumvent the idleboot time value on configured MUCKs.
Good point. My bad.
I think @@ should work, as long as the recognize_null_command @tune is yes. Let me know if something about this doesn't work.
I just wanted to confirm, first. It still appears to reset the idle time when used.
It does in some cases, but not all it seems. Reopening until we can figure this out. Thanks for the report.
Is this fixed? Seems like the commit by @evenfl0wz addresses it, but I'm getting conflicting results in my environment.