A terminus coming from sports.. a ping should be answered by a pong and is intended to figure out if the other side is receiving your transmissions.
Contents |
End-to-end /ping
psyced provides a /ping command which checks if the other side is alive. It is translated to the IRC and XMPP equivalents if necessary.
Pings frequently carry a timestamp in order to measure the network latency.
Connection ping
Sometimes reliability checks are made on top of circuit technology like TCP by periodically sending some data. Most notably IRC sends PING commands and requires PONG replies within a short time. This used to be redundant with the SO_KEEPALIVE feature of TCP and to defeat ISDN cost minimizing technologies, which used to shut down the phone line as long as there isn't any traffic on the active TCP links, just KEEPALIVEs. In these days of flatrates it doesn't really matter any more, and in fact more and more NAT and firewall technologies require you to do it the formerly wrong way. On the other hand, mobile phone technology would appreciate a more careful approach to pinging.
psyced currently accepts and handles pings from XMPP and IRC clients, but it doesn't actively pollute bandwidth with server-side pings. This is a fine approach for interserver communications that in general stay up just like that, but might not be good enough in today's world of nasty NAT proxies and routers in people's homes and offices, who think an idle TCP connection must be in error and don't even send back a connection reset by peer as was customary in ancient times.
Most of today's clients do enough aggressive pinging and polling, that this doesn't show to be much of an issue. Nonetheless, psyced should at option offer to be more aggressive on pinging by issuing server-side pings on all client interfaces (PSYC, IRC, XMPP, telnet), ideally by means of a generic shared ping timer implementation that can be activated or tuned by a tuning switch. In the case of telnet this is particularly necessary, as most telnet clients have no ping-on-idle mechanism. The protocol does provide something called AYT as in "are you there?" however, so the server could be sending that, periodically.
See also an idea for a keep-alive protocol.
PSYC PING
PSYC pings are simple empty packets like.(yes, a mere dot on a line by itself) and they are replied to exactly the same way. This has the side effect that, should both sides send such a ping at the same time, they will interpret the other side's ping as pong and be happy.
The only downside of this is, you can't safely use such pings as network latency measurement, if the other side may be generating them, too. But pings aren't intended for that, so you may want to use a tagged request in that case.
You are supposed to send pings:
- Only when your circuits had no traffic over around 30 seconds of time and thus are in risk of getting zapped by the messed up routing technology your ISP gave you.
- Only when you are likely to be affected by bad NATs, best if you find out by trying and slowly optimize the value. Pah, not easy, ok forget it.
- Don't give up if pings do not get through - your user may just be replugging his cable in a few minutes (on linux I can stay off the cable for almost a dozen minutes and my links stay up.. on windows I get immediately kicked out of my puttys - but I presume it's a configuration/programming issue).
- Don't use a constant ping value, always add a random factor of +/- some seconds. You don't want a million instances of your client software that happen to be started at the same time to continuously DoS your servers - we have to be prepared for the next Microsoft Patch Day attack... ;D
- 24/7 running servers and services SHOULD NOT be placed behind messed up routing technology that forces you to ping dozens or hundreds of hosts. Servers should not necessitate pinging.
These are just current estimates of mine, feel free to make better guesses and time will surely change all science in this area again.
Blog Pings
Some blog technologies call their change notification events pings - quite an inaccurate use of the word. Anyway, see Newscasting.