Keep-Alive ping

[jorgenschaefer]

Circe should send out periodical PING messages to the server to test for broken connections. The PONG answer should be ignored.

[retroj]

this is what circe-lagmon-mode does, though it doesn't ignore the answer - it reports your lag.

[jorgenschaefer]

Hm. I think I want that as a general element in circe.el – Emacs doesn't do keepalive otherwise, and if you lose connection, Circe will just happily sit there doing nothing.

Basically:

• On any data send or received, reset timer to n seconds (defcustom)
• When/if timer runs out, send PING :circe-keepalive
• When PONG :circe-keepalive arrives, ignore it

No CTCP needed, just PING/PONG with the server. I think I can implement that with quite a few lines of code.

[retroj]

Is it legal/standard to send extra text in a PING? I don't see mention of this in the irc rfc (that is why lagmon uses CTCP).

[jorgenschaefer]

Heh. Re-checking the RFC 2812, no, that's not strictly speaking legal. But I know of no ircd implementation that implements PINGs like that. Guess more investigation needed.

[jorgenschaefer]

Ok, implementations differ slightly on the defailts, but all implementations tested send back the string passed.

PING foo

• IRCnet (ircd 2.1.1p1): :<server> PONG :foo
• EFnet (ircd-ratbox-3.0.6), Freenode (ircd seven 1.1.0 rc4)), Coldfront (Unreal 3.2.9): :<server> PONG <server> :foo

[retroj]

according to the rfc:

PING WiZ ; PING message being sent to nick WiZ

what gives?

[jorgenschaefer]

IRC has a historic problem with constantly confusing the server/server and server/client protocol. A few early exploits were based on that (servers trusting clients more than they should). The PING description is still from the server/server protocol. Clients should actually never need to send a PING, only PONG.

Implementation of PING from the Freenode ircd:

/*
** m_ping
**      parv[1] = origin
**      parv[2] = destination
*/
static int
m_ping(struct Client *client_p, struct Client *source_p, int parc, const char *parv[])
{
        struct Client *target_p;
        const char *destination;

        destination = parv[2];  /* Will get NULL or pointer (parc >= 2!!) */

        if(!EmptyString(destination) && !match(destination, me.name))
        {
                if((target_p = find_server(source_p, destination)))
                {
                        sendto_one(target_p, ":%s PING %s :%s",
                                   get_id(source_p, target_p),
                                   source_p->name, get_id(target_p, target_p));
                }
                else
                {
                        sendto_one_numeric(source_p, ERR_NOSUCHSERVER,
                                           form_str(ERR_NOSUCHSERVER),
                                           destination);
                        return 0;
                }
        }
        else
                sendto_one(source_p, ":%s PONG %s :%s", me.name,
                           (destination) ? destination : me.name, parv[1]);

        return 0;
}

I.e. if there is only one argument, that's always just sent back. You can send a PING to another server using PING foo other.server – I tested this, and that works, with a different response, even:

> PING foo
< :hitchcock.freenode.net PONG hitchcock.freenode.net :foo
> PING foo cameron.freenode.net
< :cameron.freenode.net PONG cameron.freenode.net forcer--

I.e. the second PING was passed over to the other server. The message between hitchcock and cameron will have been :hitchcock.freenode.net PING forcer-- cameron.freenode.net, to which it will have responded :cameron.freenode.net PONG cameron.freenode.net forcer-- so it actually reaches the right person (me).

The Freenode ircd implementation of PONG shows this confusion with server/server and server/client:

        /* Now attempt to route the PONG, comstud pointed out routable PING
         * is used for SPING.  routable PING should also probably be left in
         *        -Dianora
         * That being the case, we will route, but only for registered clients (a
         * case can be made to allow them only from servers). -Shadowfax
         */

[jorgenschaefer]

Forgot the important part: They took out client/client PING/PONG because that can be used for flooding. Get 5 clients to send PINGs to a single one, and he'll flood himself out.

[retroj]

Okay, thanks for explaining that. Do you have any feeling on whether circe-lagmon should be changed to use PING instead of CTCP? The one point against that I can see is that it would need to install a PONG handler, and if another PONG handler was installed for some reason, the conflict would need to be resolved.

[jorgenschaefer]

I'm a bit iffy about absolutely relying on the argument of PING to be passed back. If it doesn't, for the keepalive thing, Circe might show some spurious PONG messages. For lagmon, the whole code would break.

But thinking more about it, an own CTCP LAGMON isn't all that bad an idea, code-wise. Doesn't rely on spurious IRC protocol details that might change without warning, works reliably, no ambiguity. Hm.

[retroj]

k, i agree with that

[jorgenschaefer]

This is sufficiently handled by circe-lagmon. No further action required.

[Thaodan]

Not necessarily trying to revive a dead horse but CTCP requests have the side effect that they don't work as good when more than once client is used. The other clients might react on the CTCP request and send out notifications.