Requesting method for resetting client.inactivity to 0

Page: 1 2
Sep 5 2008, 7:32 pm
In response to Tom
I was using a MUD client called ZMUD to test this, which I've let idle for hours at a time on other various MUDs out there (edited to say: without any problem or booting, of course.)

Also, may I point you to [link]

The telnet inactivity boot is discussed in-depth there.
Sep 5 2008, 7:52 pm
In response to Larynx9
Larynx9 wrote:
I was using a MUD client called ZMUD to test this, which I've let idle for hours at a time on other various MUDs out there (edited to say: without any problem or booting, of course.)

Also, may I point you to [link]

The telnet inactivity boot is discussed in-depth there.

Hmm, that's very interesting. I wonder how I missed that thread six years ago!

I did a quick investigation and I am seeing some code that looks like it might be used for this purpose. We'll have to do some testing to see what exactly is going on, but I'm sure it's fix-able. My gut feeling is that the telnet protocol is supposed to boot inactive clients and our code respects that. However, keepalives (which are probably used by your client) might not be triggering anything on ours-- we should be able to fix that. If that's not the case, we'll just set it up not to boot (or at least not for a much longer time).
Sep 6 2008, 6:46 am
In response to Tom
Tom wrote:
I did a quick investigation and I am seeing some code that looks like it might be used for this purpose. We'll have to do some testing to see what exactly is going on, but I'm sure it's fix-able. My gut feeling is that the telnet protocol is supposed to boot inactive clients and our code respects that. However, keepalives (which are probably used by your client) might not be triggering anything on ours-- we should be able to fix that. If that's not the case, we'll just set it up not to boot (or at least not for a much longer time).

Great to see this being looked into ;) Its one of the more severe long-standing 'issues' for telnet.
Sep 6 2008, 3:54 pm
In response to Alathon
Agreed wholeheartedly.
Sep 6 2008, 8:09 pm
In response to Tom
Tom wrote:
That said, I don't see any harm in making it writeable, in cases where you specifically want to do this. We'll have to see if there's a real restriction here (I'm assuming Dan put this in circa 1996), but I doubt it's a problem.

My only request, if possible, would be that Dream Maker let out at least a warning about writing to client.inactivity when it sees that happening, for people that aren't quite sure what they're doing and accidentally break their code in doing so.
Sep 7 2008, 12:24 am
In response to Audeuro
Audeuro wrote:
My only request, if possible, would be that Dream Maker let out at least a warning about writing to client.inactivity when it sees that happening, for people that aren't quite sure what they're doing and accidentally break their code in doing so.

My request, by extension, would be that all read-only values (such as client.virtual_eye/key/ckey) would throw errors when attempting to write to them in a proc/verb. For example, trying to set the above 3 in a verb compiles cleanly, but attempting to modify client.address throws this error:

error:client.address:cannot change constant value

I should think something similar should come up as in:

error:client.ckey:cannot change read-only value
Sep 10 2008, 5:19 am
In response to Kuraudo
Actually, changing client.key is acceptable without any errors. This will change the key you appear online with. It is used in DMCGI to get the username you're currently logged in with in a secure area of a website. (i.e. the username of the user you're logged in with in an area protected with htaccess/htpasswd)
Page: 1 2