Pings are commands sent by either the server or the client presumably to ensure the connection. These are analogous to the PINGs and PONGs of IRC. Pings sent from the server are sent with the CHL command and replied to with the QRY command. Pings from the client are sent with the PNG command and replied to with the QNG command.
Pings from the server are sent with the CHL command. They are often referred to as challenges, because that is a good possibility as to what the three letter code stands for. Challenges are new in MSNP6, and are never seen in earlier version of the protocol.
Challenges are sent only from the NS and can be sent anytime from when the initial status has been set with CHG up until the end of the session. You cannot rely on them being sent periodically, but one is usually sent following the initial CHG. They are normal commands sent with a TrID of 0 and only one parameter. The one parameter has always been a 20-digit number, but a client should expect anything. A possible challenge might look something like this:
<<< CHL 0 15570131571988941333\r\n
A response to every challenge is necessary. If one does not respond, the server will close the socket after a reasonable amount of time (somewhere around 50 seconds). To respond, use the QRY command. The QRY is one of the exceptions to normal command syntax, and behaves just like a MSG. The TrID is required of course, followed by the exact string msmsgs@msnmsgr.com. Note that this is not your account name, but it is a static string that must always be sent as is. The last parameter is the length of the payload that follows, which because of the nature of MD5, will always be 32. The length will be followed by a newline, which will be followed by the payload, which will not be followed by a newline.
The payload of the QRY command is an MD5 digest and should be approached the same way one approaches the USR authentication when first connecting to the NS. Take the 20-digit number given in the CHL command, add Q1P7W2E4J9R8U3S5 to the end, and take the hexadecimal digest. That will be the payload of the QRY command.
In this case, you would take the hexadecimal digest of 15570131571988941333Q1P7W2E4J9R8U3S5 which happens to be 8f2f5a91b72102cd28355e9fc9000d6e, and of course contains 32 bytes. You send the QRY command to the server, and if done correctly, the server will respond with another QRY with the TrID of the one you sent and no parameters. If you have an invalid email address or an invalid digest, the server will send error 540 and close the connection, but if you get the message length wrong, you will have unpredictable results. Below is an example of what a correctly done challenge looks like. The numbers are all accurate, and you may use them to test your MD5 functions.
<<< CHL 0 15570131571988941333\r\n
>>> QRY 1049 msmsgs@msnmsgr.com 32\r\n
8f2f5a91b72102cd28355e9fc9000d6e
<<< QRY 1049\r\n
A common theory to the reason of the addition of challenges to MSNP6 is to keep third party client developers away from the protocol. The only possible way that the method to deal with challenges could have been discovered is by reverse engineering or by leaked information from Microsoft. Because both of these are potentially illegal, it may be safest to write clients that use versions of the protocol older than MSNP6. There is a thread in the forum discussing the legality of using challenges.
The information above was obtained from the MSN documentation at Venky's World. I am uncertain as to where the information was first found, but there are rumors that it leaked from Microsoft.
Note that the above implementation for challenges has only been found in versions of the official client before MSN 5.0 and not including Windows Messenger. Other keys, to replace msmsgs@msnmsgr.com and Q1P7W2E4J9R8U3S5 can be used. PROD0039E3VGM%GB is an example of one such replacement for msmsgs@msnmsgr.com in Windows Messenger. It's interesting how they are both exactly 16 characters long.
In addition to the server sending pings to the client, the client can send pings to the server as well. These pings are most often used to either make sure the connection is still working or to prevent some NATs from automatically closing idle sockets. One can also use these pings to find the latency between the client and the server.
Like server pings, these pings may only be sent to the notification server. But they may be sent at any time after the second USR has been sent with the password. These pings may be sent in any version of the protocol (at least, from MSNP2 to MSNP8).
Client pings are very simple to implement. The client sends PNG with no TrID or parameter of any type, and just followed by a newline. The server will respond with QNG with no TrID or parameter followed by a newline immediately after receiving the PNG. A ping and server response will always look like this:
>>> PNG\r\n
<<< QNG\r\n