Idle timer? (Tiny)

skew

Something happened with our host over at Fate's Harvest, and it seems some people are getting perpetually disconnected. Setting idle timers on the client, or the "send null bytes" feature of some clients, seems to work. Keepalive by itself doesn't seem to do it for everyone.

People with clients can do it fine, but we've got some players using WebMU and the like. I wanted to see if it'd be possible to set something up in the game itself to run and keep people connected?

So, anyone have any tricks? Anyone have any quick snippets of code we could deploy? I was thinking of something like @fo me=@wait 300=@@; @wait 300=@@ ... Or something. I don't know, I'm sick and my brain is foggy!

ZekeTheG33k

You could setup a global timer via cron to just have it check for any PCs idle greater than say 7 minutes and force them to send a @@ to the game.

&Cron_time_IDLER OBJECT=||||00 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58|
&cron_job_idler object=@dolist [search(all,eplayer,[and([hasflag(##,connected)],[gte([idle(##)],300)])]=@fo ##={@pemit me=@@}

Something like that.

Sparks

If the disconnect is due to NAT, that won't help because you need traffic to go to or from the client; forcing a @@ server side will generate no traffic.

skew

@Sparks Yeah, that was my question. If I @force someone to do something, does it actually hit them client side, or is it all server side. Obvs I don't understand how it all works, but... sounds like this isn't a solution

@Seamus Thank you, but as Sparks says, if that doesn't ever hit the client side of the connection, it'll likely drop just the same.

ZekeTheG33k

@skew Fair enough. Does Tiny have an IDLE command like Rhost?

skew

@Seamus I'm not entirely sure. What Tiny has is a KEEPALIVE flag ( http://wiki.tinymux.org/index.php/KEEPALIVE ). It's supposed to send nullbytes to-from the client to keep connections active, but I've honestly no idea how it works, but I know some players have set it and it doesn't keep them alive, particularly when using a we client.

ZekeTheG33k

@skew http://rhostmush.com/autohelp/help.html#idle

faraday

@skew said in Idle timer? (Tiny):

Yeah, that was my question. If I @force someone to do something, does it actually hit them client side, or is it all server side.

A force would be handled server side.

KEEPALIVE works by sending null bytes to the client. This helps keep the connection alive with some routers.

Other routers will disconnect you unless you send bytes from the client. If you can't change the router config, the only way I know to fix that is for the player to set up an auto-timer in their MU client to periodically send a command to the server. The IDLE command is best for this because it doesn't actually update your idle timer (so it doesn't look like you're active if you're not), or you could just send a dummy command like @@. Way back when, I used to have it send think <IDLE> [time()] and then had my client filter out text starting with <IDLE>.

Sparks

KEEPALIVE works (on most servers) by sending Telnet IAC NOP sequences; if the client doesn't support telnet IAC sequences, not all servers will actually still send them even if the flag is set. I don't offhand remember Tiny's implementation.

Sadly, with a web client that supports no scripting, if KEEPALIVE isn't working you may be out of luck, unless you literally send text to the client. (I.e. if they've been idle five minutes and have some tag/attribute set on themselves, send a blank line via @pemit.)

As Fara notes, however, that still won't work with all routers.

Rook

Have your players do this:
&TR.ANTIIDLE me=@@; @wait 60=@trigger/quiet me/TR.ANTIIDLE

Then, in their @aconnect, or manually, do this:

@trigger me/TR.ANTIIDLE

Thenomain

@Rook: Take that one more step...

&trig.anti-idle [some wiz object]=
	@dolist lwho()={ @fo ##=@@ }; 
	@wait 500=@trig me/trig.anti-idle 

@startup [some wiz object]=@trig me/trig.anti-idle

But as said above, this may not work for a variety of reasons. I suspect that if KEEPALIVE isn't working, this won't either.

Rook

I believe that the global approach might mirror the Flag's behavior for the reasons outlined. Having one or two troubled players do this on their local character object should tell you if the approach is separate enough, and player-"involved" enough, to trick the connection into staying open.

I have had this work when KEEPALIVE wouldn't, myself. It is why I offer it.

faraday

@Thenomain @@ doesn't send any output to the client, does it? I'm failing to see how a server-side-only execution is going to help anything.

Thenomain

@faraday said in Idle timer? (Tiny):

@Thenomain @@ doesn't send any output to the client, does it? I'm failing to see how a server-side-only execution is going to help anything.

That's what I was thinking, but a global solution (mimicking a non-working flag) instead. Maybe it's time to start patching into TinyMUX.

faraday

@Thenomain I think you missed my point.

@wait triggered from MUSH execution queue (server side) --> trig.anti-idle (server side) --> @force (server side) --> player executes @@ (server side) --> nothing sent to client because @@ has no output (??)

This entire sequence has absolutely no client-side involvement whatsoever. Presuming that it's an issue with the client-side router, what does this accomplish?

If your presumption is that it's some wacky bug in TinyMUX, by all means give it a try, but I call Occam's Razor here: most random idle timeouts are the client's router.

Thenomain

@faraday said in Idle timer? (Tiny):

most random idle timeouts are the client's router

Which means there's no solution from the game. Finding out what is causing these people to be disconnected becomes an exercise for someone who knows networking tools.

faraday

@Thenomain said in Idle timer? (Tiny):

@faraday said in Idle timer? (Tiny):

most random idle timeouts are the client's router

Which means there's no solution from the game. Finding out what is causing these people to be disconnected becomes an exercise for someone who knows networking tools.

Yes. Or talk to whomever implemented the web client and see if they can do some kind of client-side keepalive feature.