# Pastebin 4gWKe8ty [2019-02-22 10:30:26] weird Q. PING/PONG *always* has to have an argument right? [2019-02-22 10:30:39] at present yes [2019-02-22 10:30:41] my code supports it not having one and i suspect that's just because i didn't think it through [2019-02-22 10:30:47] also i can't read BNF [2019-02-22 10:30:52] though for the most part the argument is meaningless unless pinging a remote server [2019-02-22 10:31:08] no i mean the `PING :nonce goes here` [2019-02-22 10:31:22] yeah I know what you meant [2019-02-22 10:31:22] that's not useless? [2019-02-22 10:31:24] :s [2019-02-22 10:31:25] yep, should always have at least one arg [2019-02-22 10:31:28] but PING and PONG can take 2 params too [2019-02-22 10:31:33] right [2019-02-22 10:32:05] fwiw I just grab the params on the PING and throw exactly the same list of params on the reply PONG [2019-02-22 10:32:06] works well enough as a client [2019-02-22 10:32:28] ircu requires PING to have at least one param [2019-02-22 10:33:01] sends this numeric if no param supplied: [2019-02-22 10:33:02] { ERR_NOORIGIN, ":No origin specified", "409" }, [2019-02-22 10:34:15] 1459 says this about NOORIGIN: [2019-02-22 10:34:16] - PING or PONG message missing the originator parameter [2019-02-22 10:34:16] which is required since these commands must work [2019-02-22 10:34:16] without valid prefixes. [2019-02-22 10:34:40] so 1459 requires PING and PONG both have at least one param [2019-02-22 10:40:11] does that really apply to c2s as well as s2s? [2019-02-22 10:41:26] 1459 is mostly C2S [2019-02-22 10:41:51] also S2S, id argue is none of our business :P [2019-02-22 10:42:03] right, just that justification sounds very s2sey [2019-02-22 10:42:09] I mean how an IRCd impliments its S2S protocol is irrelevent so long as the client protocol works properly all the way through [2019-02-22 10:42:28] and 1459 did have some s2sey considerations in it [2019-02-22 10:42:34] the 2 examples of PING given in 1459 are PING and PING [2019-02-22 10:42:56] tbh 1459 doesnt go into enough depth on S2S to be a sufficiant S2S protocol imho [2019-02-22 10:43:06] though at a basic level it can work [2019-02-22 10:43:21] no it doesn't, but it's clearly written by someone thinking about s2s specifics [2019-02-22 10:43:38] there is some argument for standardizing a subset of s2s stuff [2019-02-22 10:44:00] I think at this point the only thing you can standardize about S2S protocol is concepts [2019-02-22 10:44:05] the sasl protocol is kind of a de facto standard [2019-02-22 10:44:10] as there are already too many protocol varients around [2019-02-22 10:44:32] these days ping is only c2s, you don't ping other nicks, you just ping a server and it echoes back what you said [2019-02-22 10:44:43] eg "must have a means to pass information X in direction Y to destination Z" [2019-02-22 10:44:55] (or s2c, but forget that for now) [2019-02-22 10:45:12] most cases of S2C ive seen just send PING [2019-02-22 10:45:12] insp requires one param though [2019-02-22 10:45:24] 461 jwheare PING :Not enough parameters. [2019-02-22 10:45:29] unreal also requires one [2019-02-22 10:45:46] unreal and ircu both respond with ERR_NOORIGIN [2019-02-22 10:45:50] but the param is just an opaque blob [2019-02-22 10:46:08] which is what 1459 says to respond with [2019-02-22 10:46:15] does an invalid ping reset the timer, though? [2019-02-22 10:46:19] it's not interpreted as a server or nick [2019-02-22 10:46:23] it only is if there's 2 args [2019-02-22 10:46:44] the values of PING's params only matter if youre supply 2 [2019-02-22 10:47:04] although on insp it actually ignores the 2nd param [2019-02-22 10:47:29] you can't remote ping apparently [2019-02-22 10:48:06] looking at the code ircu ignores the second too [2019-02-22 10:50:07] ircu has an RPING/RPONG for IRCops to use to ping servers locally and remotely [2019-02-22 10:50:36] i tend to just motd other servers to see if they're there [2019-02-22 10:51:11] I TIME em [2019-02-22 10:51:16] shorter responses :P [2019-02-22 10:51:19] and useful info too [2019-02-22 10:51:28] well, on seven pinging them does work [2019-02-22 10:51:42] recently debugged a time issue on a network where one of the servers was a whole 7 days out of whack [2019-02-22 10:51:56] the time thing isn't super interesting to me [2019-02-22 10:52:07] i'd rather use alerts to find out if ntp is broken [2019-02-22 10:52:19] heh on 7, the 2nd arg is the server [2019-02-22 10:52:42] on seven ping with two arguments works as specified [2019-02-22 10:52:55] ofc ircu also has an out of band "UPING" that uses UDP to ping a remote server [2019-02-22 10:53:18] well, except it won't let you ping a user. does 1459 allow that? [2019-02-22 10:53:29] I believe Unreal also impliments the remote PING with 2 params to PING [2019-02-22 10:53:35] Jobe: seems like a bit of an overreach again [2019-02-22 10:53:40] i can ssh server1 ping server2 [2019-02-22 10:53:45] i don't need ircd to do it for me [2019-02-22 10:53:57] yeah the UPING is probably one of ircu's silliest features imho [2019-02-22 10:54:11] 1459 doesn't specify c2s ping, only s2c [2019-02-22 10:54:25] UPING also relies on the IRCd being operational too [2019-02-22 10:54:33] as it requires the IRCd be bound to a UDP port [2019-02-22 10:54:51] thus the UPING option is only useful to tell if 2 servers that arent currently linked will be able to [2019-02-22 10:54:51] it actually says "Servers should not respond to PING commands but rely on PINGs from the other end of the connection to indicate the connection is alive." [2019-02-22 10:54:56] which is... weird [2019-02-22 10:55:12] yeah [2019-02-22 10:55:36] the mix of s2c/c2s commands in the rfcs is, in general, a bit weird [2019-02-22 10:56:06] 281* made progress on that by at the least specifically stating one was client protocol [2019-02-22 10:56:38] 2812 does say "The PING command is used to test the presence of an active client *or server* at the other end of the connection. Servers send a PING" [2019-02-22 10:57:35] 2812 also gives this useful example: [2019-02-22 10:57:36] PING WiZ tolsun.oulu.fi ; Command from WiZ to send a PING [2019-02-22 10:57:36] message to server "tolsun.oulu.fi" [2019-02-22 10:58:02] which makes understanding the 2 params easier [2019-02-22 10:58:32] well kind of, except the 1st param isn't who it's "from" [2019-02-22 10:58:41] it's a blob [2019-02-22 10:58:58] it's from whoever sent it, which the server already knows [2019-02-22 11:00:41] I would have thought that ERR_NOORIGIN would be a good idnicator that the intent of the first param is that it be the origin [2019-02-22 11:01:27] maybe at the time, but does anyone treat it as such now? [2019-02-22 11:01:37] pretty much [2019-02-22 11:01:57] pretty much no? [2019-02-22 11:02:08] hell in terms of preventing ping timeout, you often dont even have to send a PONG, you need only send a message that resets the ping delay [2019-02-22 11:03:05] what's an ircu network? [2019-02-22 11:04:26] undernet [2019-02-22 11:04:36] or afternet uses a fork of ircu [2019-02-22 11:05:15] ircu clears the ping sent flag, and sets the last received time for a client every time it receives a packet from a client [2019-02-22 11:05:19] doesnt matter what the packet contains [2019-02-22 11:05:55] Undernet doesn’t treat the first param as anything special, just echoes it back [2019-02-22 11:06:07] by packet I dont mean the empty TCP packets used to keep the TCP connection established [2019-02-22 11:06:16] indeed it does just echo it [2019-02-22 11:06:23] ircu also ignores the second param [2019-02-22 11:06:41] So the origin stuff is just legacy that no one cares about. [2019-02-22 11:06:43] except from IRCops [2019-02-22 11:06:47] Modern should clarify that [2019-02-22 11:13:03] Modern should also have a marker for numerics and messages that have exact definitions which are also used in real world [2019-02-22 11:13:10] e.g. the numerics introduced by IRCv3 [2019-02-22 11:14:26] We've still got lots of numerics that no one interprets anyway and just displays to users uninterpreted — ideally we'd start to spec some of those out, too. [2019-02-22 11:14:46] Yes I still have my dream about someday the messages a modern IRCd sends all being specced out [2019-02-22 11:16:36] — Jobe wonders how a client expecting an ERR_NOORIGIN would handle receiving a "Not enough parameters" from insp [2019-02-22 11:16:59] I mean a well written client shouldnt have an issue [2019-02-22 11:17:38] both of them are just gonna show some sort of error to the user, or ignore them [2019-02-22 11:19:01] indeed [2019-02-22 11:19:30] more an issue for clients that try and do something with the reply [2019-02-22 11:19:53] like wait for either a numeric reply or a PONG [2019-02-22 11:20:19] though if the client knows its sent a param it shouldnt need to expect a noorigin or notenoughparams anyway [2019-02-22 11:20:48] so really a client expecting to receive a noorigin is poorly written to begin with [2019-02-22 11:21:15] I mean if youre expecting noorigin, then you know youve sent an invalid PING