|Overview • Glossary|
|Payload Commands • Names|
|Authentication • Presence|
|Challenges • Getting Details|
|Setting Details • Messages|
|Authentication • Miscellaneous|
|Messages • Example Session|
|Introduction • Terms • Clients|
|Error List • Commands • Relaying Party Suite • Spotlife|
|XMPP • HTTP Gateway • Tabs • Activities|
|Development Tools • MSNP Grid|
|Polygamy • URLs used by MSN|
|Introduction • P2P • Object Descriptor • Display Pictures • File Transfer|
|Microsoft Messenger for Mac|
|MSNP on WebTV (MSNTV)|
Server Pings (Challenges)
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 sent by the NS from time to time, the first one shortly after the initial status has been set with CHG. There's no regular period to the time between CHLs. They include two parameters - the first is always "0", the second is the "challenge string". This has always been a 20-digit number, but a client shouldn't rely on that. A challenge might look something like this:
<<< CHL 0 15570131571988941333\r\n
When you receive a challenge, you must send a QRY command to the server within about 50 seconds or you'll be disconnected. QRY is a payload command with a TrID and two parameters: a client identification string and the number of bytes in the payload. As with all payload commands, the length is be followed by a newline, then the payload, which is not followed by a newline. In MSNP8 the payload of the QRY command is the "MD5 digest" of the challenge string and a client identification code. MD5 digests are always 32 bytes in length.
If you sent an invalid client code or incorrect digest, the server will send error 540 and close the connection. If you get the payload wrong, the results will be hard to predict and not good. Otherwise, the server will send a QRY response with the same TrID and no parameters.
Client identification information
Different Microsoft clients use different ID codes and ID strings. Here is a list of the strings and their corresponding strings:
|Client ID string||Client ID code|
It doesn't matter which ID string you use, but you must use the corresponding ID code - for example, you can't use email@example.com with VT6PX?UQTM4WM%YR.
MD5 is a message digest algorithm. Taking the MD5 digest of a string gives you a 32 byte "fingerprint" of it. If possible, you should try to find a library or an external program that creates MD5 fingerprints, but it's is officially described in RFC 1321, so you can try to implement it yourself if you're feeling brave. Make sure that your library can produce lower-case hexadecimal digests (there should be an option for this)
When the server gives you a challenge string, add your client code onto the end of it. For example, if the server gives you abcdefg and your code is 1234567, the input to the MD5 function should be abcdefg1234567. The hexadecimal digest for abcdefg1234567 is d1713d0f1d2e8fae230328d8fd59de01. I suggest you check your implementation using this example.
Here is an example server ping and reply. You should check that your MD5 implementation against this example to make sure that you're encoding correctly. The most common mistake is to add a newline to the end of the challenge string before or after encoding it.
<<< CHL 0 15570131571988941333\r\n >>> QRY 1049 firstname.lastname@example.org 32\r\n 8f2f5a91b72102cd28355e9fc9000d6e (no newline) <<< QRY 1049\r\n
In this case, you would take the hexadecimal digest of 15570131571988941333Q1P7W2E4J9R8U3S5 which happens to be 8f2f5a91b72102cd28355e9fc9000d6e, and of course is 32 bytes long.