Re: Current PING/PONG implementation to violate the RFC

[Q <Q@xxxxxxx>]

Kaspar Landsberg wrote:
> 
> Hi all.
> 
> Everyone, who has been watching the recent discussion about the
> PING/PONG implementation in the current ircnet ircd, has probably noticed
> that the change it underwent some time ago aimed to fix the traditional
> behavior in order to make the new one RFC compliant.
> 
> Well, as you will see below, the current implementation of the PING/PONG
> procedure is still violating the RFC both in its spirit and in its letter.
> 
> The RFC says in section 4.6.2:
> 
>    Servers should not respond to PING commands but rely on PINGs from
>    the other end of the connection to indicate the connection is alive.
> 
> The current implementation is violating the spirit of this by responding
> to PINGs with a PONG.

"should not" != "is not allowed". "should not" means that he can send a
ping, but he shouldn't. It means that any message received (like a
ping), is enough for the connection to be alive. If you read what's just
below, you see that PONG is the reply to a PING. You say that I never
should send a PONG ....

> Furthermore, the RFC says in section 4.6.3:
> 
>    Command: PONG
>    Parameters: <daemon> [<daemon2>]
> 
>    PONG message is a reply to ping message.  If parameter <daemon2> is
>    given this message must be forwarded to given daemon.  The <daemon>
>    parameter is the name of the daemon who has responded to PING message
>    and generated this message.
> 
> The current implementation is violating the letter of this by responding
> to a PING (from a client) with
> 
> ":prefix PONG <server name> [:]<nickname>"
> 
> (that´s a quote from syrk´s first reply on the other thread). According to
> the quoted paragraph above, a second argument to PONG may only be present
> if it´s a server ("daemon" designates always a server). But in the current
> implementation the second argument to PONG is a nickname (see the quote).

"daemon" is not defined in the rfc, but probably means just the same as
server, and can be interpreted as the client. the client should get the
message, so it could send back the nick as deamon2. (There are more
defenitions missing.)
The ':' could be removed. It's probably a leftover from old behaviour.
Also note the rfc never says you should send a ':' in the defenition of
a command. (only with user message it's stated that you should not
forget it, afaik.)

> And finally (this one is for the RFC compliancy die-hards ;) the RFC says
> in section 4.6.2:
> 
>    Command: PING
>    Parameters: <server1> [<server2>]
> 
> The current implementation is violating this in addition to the
> first mentioned violation by not responding with an ERR_NOSUCHSERVER
> numeric reply to a PING in which the first argument is not a valid
> (existing) server name and in general by letting clients use PING.

<server> is either the name of a server, or a cient using that server.
If you fail to set your own nick in <server1>, the server should not
return ERR_NOSUCHSERVER, because <server1> isn't a "server".

> Ok, now let´s have a look at the whole issue from a reasonable point of
> view:
> 
> Most servers allow clients to send PINGs out.
which is normal.

> Most servers allow clients to send out remote PINGs.
which is normal.

> Most servers allow clients to send PINGs with random data to the server
would you like it to generate a (new) error, or just change your data
your nick?

> and then get that data back in the corresponding PONG reply.
> Most servers replace <daemon2> with a nickname in the PONG reply when
> appropriate.

What do most server do? They return both the nick and the data? Or only
nick or data?



Q