[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  General
. . -> [Subject]  Design: Ping to modify timers?
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: Design: Ping to modify timers?
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please).
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Sat 29 Oct 2011 12:16 AM (UTC)  [ quote  ]
Message
Cool, good to know. :D
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Rivius   (93 posts)  [Biography] bio
Date Fri 28 Oct 2011 09:39 PM (UTC)  [ quote  ]
Message
Quote:

Greetings. We've been told that you won't put any real stress on the server, so your suggestion should be fine. Thank you.


Just in case you're still interested :).

Although, I'd still be mindful if this ever got 'popular'.
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Sat 22 Oct 2011 10:44 PM (UTC)  [ quote  ]
Message
Rivius said:
The game is lusternia, and I may just end up asking an admin what they regularly do, and what might be permissable.

Probably a good idea. I'd like to hear what they say when you find out. :)

Rivius said:
Also, are you suggesting I set my timers at an amount, and when I receive my ping, I retroactively modify them? I could do that...seems complicated though.

No, I'm suggesting that when you receive your ping response, only then do you set up your reaction timers. So like:

1. Send command + ping
2. When ping is returned, OR it takes too long to get a response, set up reaction timer.

You want to begin your reaction times from the moment you know that your command was received.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Rivius   (93 posts)  [Biography] bio
Date Sat 22 Oct 2011 06:49 PM (UTC)  [ quote  ]
Message
I'll try doing the median then and see if that helps. The game is lusternia, and I may just end up asking an admin what they regularly do, and what might be permissable.I'm afraid of doing it before a command, since in combat I would be spamming quite a few. I could try to limit it to every group of commands, but even then, it sounds like it would be fairly often. Also, are you suggesting I set my timers at an amount, and when I receive my ping, I retroactively modify them? I could do that...seems complicated though.
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Sat 22 Oct 2011 06:04 PM (UTC)  [ quote  ]

Amended on Sat 22 Oct 2011 06:08 PM (UTC) by Twisol

Message
Which game is this? Like I said, if it's an IRE game such as Achaea, Lusternia, etc. they already ping frequently from their Nexus client. And if you're particularly worried you could email support.

Also, the heartbeat ping is just meant to ensure that the timer doesn't fire extremely late. It's not meant to be super-accurate, though I'm sure there are ways to account for fluctuating latency. You want to use a single ping before or after a command and use the ping reply as confirmation - it's practically guaranteed to have been received at that point.

(Also, I'm curious whether using the median instead of the mean would affect things. Might be worth playing with.)
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Rivius   (93 posts)  [Biography] bio
Date Sat 22 Oct 2011 03:05 PM (UTC)  [ quote  ]

Amended on Sat 22 Oct 2011 03:09 PM (UTC) by Rivius

Message
Alrighty. Well, I want this to be as accurate as possible, but I also don't want to cause the server any unnecessary strain. How about a timer that fires every five seconds and adds the current ping into a table.

Here's more or less what I do now, taking twisol's idea:


<timers>
  <timer 
  enabled="y"
  group="Core"
  name="ping_timer"
  second="5.00" 
  offset_second="0.00"
  send_to="12"
  >
  <send>Execute("ping")</send>
  </timer>
</timers>

pings = {}
function core.latency()
	if #pings < 1 then
		return 1.5
	end
	
	local c = 0
	for _, i in ipairs(pings) do
		c = c + i
	end
	return (c/#pings + 0.1)
end

function pong()
	table.insert(core.pings, os.clock() - pinged)
	if #core.pings > 5 then
		table.remove(core.pings, 1)
	end
	print(core.latency())
end


I'm just legitimately worried about how much strain this might cause. While I know I'm just one person, I'd like to know that if multiple people were doing the same thing, we wouldn't be "bringing the server to its knees". The game in question, as it is, already has quite a bit of server stress.

The accuracy is also a bit iffy. My pings seem to vary a little too much to be entirely reliable.
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Thu 20 Oct 2011 08:55 AM (UTC)  [ quote  ]

Amended on Thu 20 Oct 2011 08:57 AM (UTC) by Twisol

Message
So the average-ping-updating timer would just be an idle action that happens when nothing special's going on, I guess? The trick is being able to show causality between a command and some output. With Core.Ping, you can just keep a queue of tasks waiting on a ping response, because the server should never send a ping response without you sending a ping request. If you try to move, but someone pushes you into another room before your movement goes through, a naive implementation might think that your command caused that movement when it didn't.

For what it's worth, Iron Realms' Nexus client has a ping widget that shows your connection status, and it seems to update every couple seconds. Since Core.Ping is a GMCP command, and pennyroyal is an herb in at least one IRE game, I'm going to assume that it's okay to use Core.Ping like this.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Nick Gammon   Australia  (18,770 posts)  [Biography] bio   Forum Administrator
Date Thu 20 Oct 2011 07:17 AM (UTC)  [ quote  ]
Message
I would be cautious about doing too much pinging. Let's say you ping twice a second, and then your concept becomes popular, and everyone does it. And then 100 players ping twice a second. Then gradually people say "hey this server is getting a bit laggy - better do more pings, just in case". Then the pinging brings the server to its knees.

You can probably interpolate response times a bit by simply looking for the delay between (say) entering "north" and seeing the room number change. Since you would be doing this anyway, that is hardly extra server load.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top
Posted by Twisol   USA  (2,229 posts)  [Biography] bio
Date Thu 20 Oct 2011 06:57 AM (UTC)  [ quote  ]

Amended on Thu 20 Oct 2011 07:09 AM (UTC) by Twisol

Message
You should ping immediately before sending your command. When you get the ping response, that's your confirmation that the server has received the command, and that's when you should start your timers. This effectively ensures that you'll never act too early.

Unfortunately, they might still act too late because the ping response itself might be delayed. To counter this, you might want to add a safeguard timer based on your average ping. When the safeguard fires or when you get a ping response - whichever comes first - you should set up your timers regardless.

To keep your average ping updated, I'd send a Core.Ping every ten seconds or so.

Good job thinking of Core.Ping for this, by the way. :)

[EDIT]: Rationale for pinging before instead of after is to marginally account for some of the delay in the ping response. It could go either way, frankly.
'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top
Posted by Rivius   (93 posts)  [Biography] bio
Date Thu 20 Oct 2011 04:23 AM (UTC)  [ quote  ]
Message
I'm currently making a system for a MUD, and find myself using timers a lot to track what actions I sent to the server, so as to avoid illusions, or when to retry a cure.

eg. If I did "eat pennyroyal", I would make a timer called "sent_eat_pennyroyal" and set it to say, 1.5 seconds and then clear it as soon as I see the "You eat a pennyroyal." message.

Now, 1.5 seconds is a nice little safe buffer, but sometimes there's lag spikes and my timers go off before their time, causing me to eat several times in a row.

The GMCP of this MUD allows me to send a message 'Core.Ping' and it will send back 'Core.Ping'. By using os.clock() at when I sent mine, and then using it again and subtracting the difference when the server sends it back, I end up getting a rough estimation for my ping times.

Unfortunately, I'm not very good at designing these things. I want to make my timers more dynamic based on your latency instead of a flat 1.5 seconds.

My problem is, how often should I send core.ping to get an average ping time? And when I do, how should I use this information to modify my timers? (eg. If I get a constant ping of 200, how many seconds should I put as minimum?)

How would you guys do it?
[Go to top] top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

1,281 views.

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum

[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]