This page illustrates what an entire notification session might look like. This page does not (yet) exhaustively show every command that can be sent to a notification server.
Throughout this page, the protocol is displayed from the point of view of Alice's (alice@passport.com) client.
The client (alice@passport.com) connects to messenger.hotmail.com on TCP port 80. The client understands protocol versions 4, 5, 6, and 7. It also supports CVR0.
>>> VER 1 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
<<< VER 1 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
Next, Alice's client checks which authentication mechanisms this server supports.
>>> INF 2\r\n
<<< INF 2 MD5\r\n
Alice's client can handle MD5-based authentication, so it attempts to authenticate itself. However, the server redirects it to the server baym-cs118.msgr.hotmail.com (IP address 207.46.106.118), port 1863.
>>> USR 3 MD5 I alice@hotmail.com\r\n
<<< XFR 3 NS 207.46.106.118:1863 0 207.46.104.20:1863\r\n
The client (alice@passport.com) connects to baym-cs118.msgr.hotmail.com on TCP port 80. The client understands protocol versions 4, 5, 6, and 7. It also supports CVR0.
>>> VER 4 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
<<< VER 4 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
Next, Alice's client checks which authentication mechanisms this server supports.
>>> INF 5\r\n
<<< INF 5 MD5\r\n
Alice's client can handle MD5-based authentication, so it attempts to authenticate itself.
>>> USR 6 MD5 I alice@hotmail.com\r\n
<<< USR 6 MD5 S 1056561624.17795\r\n
Alice's password is "abcdefg1234567", so her client finds the MD5 digest of "1056561624.17795abcdefg1234567", which is "ae931a41daebc7703b84beba4183bc2f".
>>> USR 7 MD5 S ae931a41daebc7703b84beba4183bc2f\r\n
<<< USR 7 OK alice@hotmail.com Alice 1\r\n
Alice has now successfully logged into the notification server. Her client might remember to log straight into baym-cs118.msgr.hotmail.com next time it connects to MSN Messenger, instead of going through messenger.hotmail.com. The server takes this opportunity to send Alice's profile details.
<<< MSG Hotmail Hotmail 427\r\n
MIME-Version: 1.0\r\n
Content-Type: text/x-msmsgsprofile; charset=UTF-8\r\n
LoginTime: 1056561624\r\n
EmailEnabled: 0\r\n
MemberIdHigh: 425982\r\n
MemberIdLow: -2136938054\r\n
lang_preference: 1033\r\n
preferredEmail: \r\n
country: UZ\r\n
PostalCode: \r\n
Gender: f\r\n
Kid: 0\r\n
Age: 35\r\n
BDayPre: 2\r\n
Birthday: 24699\r\n
Wallet: 0\r\n
Flags: 1027\r\n
sid: 507\r\n
kv: 4\r\n
MSPAuth: 41bbzZ*NzDmDQ8ic4HWo89b9zhCBk!ONDJKB3Los8UMgBnCOLSwQKo!8IeIHQF0vVItSlOzIL36e5MAdMaB3mpZw$$\r\n
\r\n
Alice's client now synchronises her local copy of her contact lists with the copy held on the server. Last time Alice's client logged on, the list was at version number 6 but the list has now jumped to version number 27.
>>> SYN 8 6\r\n
<<< SYN 8 27\r\n
Because the list versions don't match, the server sends all of Alice's of contact information (not just what's changed between versions 6 and 27). At first, the server sends one message in every packet of data.
<<< GTC 8 27 A\r\n
<<< BLP 8 27 AL\r\n
<<< PRP 8 27 PHH \r\n
<<< PRP 8 27 PHW 0123-456789\r\n
<<< PRP 8 27 PHM \r\n
<<< PRP 8 27 MOB N\r\n
<<< PRP 8 27 MBE N\r\n
Then, the server sends the entire group list in a single packet. Since Alice's client is written in a programming langauge that handles incoming data one packet at a time, it has to separate these lines out and handle them one at a time.
<<< LSG 8 27 1 4 0 Other%20Contacts 0\r\n
LSG 8 27 2 4 1 Coworkers 0\r\n
LSG 8 27 3 4 2 Friends 0\r\n
LSG 8 27 4 4 3 Family 0\r\n
Then the server sends Alice's forward list. The first person in her forward list is Bob, whose nickname is "Bob". He hasn't chosen to share any phone numbers, and doesn't have an MSN mobile device we can use. His details are all sent in a single packet, which we have to separate out and handle individually.
<<< LST 8 FL 27 1 4 bob@hotmail.com Bob 0\r\n
BPR 27 bob@hotmail.com PHH \r\n
BPR 27 bob@hotmail.com PHW \r\n
BPR 27 bob@hotmail.com PHM \r\n
BPR 27 bob@hotmail.com MOB N\r\n
The second person in Alice's forward list is Carol, whose nickname is "Carol". She has shared her work phone number (9876-54321), but no other information. Unfortunately, the server sends Carol's details in two packets, split in the middle of a command. Alice's client will have to reconstruct the lines of data before handling them.
<<< LST 8 FL 27 2 4 carol@hotmail.com Carol 0\r\n
BPR 27 carol@hotmail.com PHH \r\n
BPR 27 carol@hot
<<< mail.com PHW 9876-54321\r\n
BPR 27 carol@hotmail.com PHM \r\n
BPR 27 carol@hotmail.com MOB N\r\n
Then, the server sends details for Dave and Emily.
<<< LST 8 FL 27 3 4 dave@hotmail.com Dave 0\r\n
BPR 27 dave@hotmail.com PHH 3.1415926535\r\n
BPR 27 dave@hotmail.com PHW 2.71841844\r\n
BPR 2
<<< 7 dave@hotmail.com PHM sqrt(-1)\r\n
BPR 27 dave@hotmail.com MOB N\r\n
LST 8 FL 27 4 4 emily@hotmail.com Emily 0
<<< ,1,2,3,4,7\r
<<<
<<< \n
BPR 27 emily@hotmail.com PHH \r\n
BPR 27 emily@hotmail.com PHW \r\n
BPR 27 emily@hotmail.com PHM \r\n
BP
<<<
<<< R 27 emily@hotmail.com MOB Y\r\n
The server has now finished sending the forward list, so it sends the add and block lists. Alice has allowed Bob and Carol to see her online presence, but has blocked Dave, Emily and Eve (the evil eavesdropper)
<<< LST 8 AL 27 1 2 bob@hotmail.com Bob\r\n
LST 8 AL 27 2 2 carol@hotmail.com Carol\r\n
LST 8 BL 27 1 3 dave@hotmail.com Dave\r\n
LST 8 BL 27 2 3 emily@hotmail.com Emily\r\n
LST 8 BL 27 3 3 eve@hotmail.com Eavesdropper\r\n
Finally, the server sends the reverse list. Bob, Dave, Eve, and Fred wish to receive Alice's presence.
<<< LST 8 AL 27 1 4 bob@hotmail.com Bob\r\n
LST 8 AL 27 2 4 dave@hotmail.com Dave\r\n
LST 8 AL 27 3 4 eve@hotmail.com Eavesdropper\r\n
LST 8 AL 27 4 4 fred@hotmail.com Fred\r\n
Here is a summary of who will receive whose presence:
BLP is set to AL, he is treated as if he was in Alice's allow list. Alice's client should ask Alice to add him to one or other list immediately.Now Alice has synchronised her contact lists, she sends her initial presence and consumer version information. This causes the server to send presence information for Alice's contacts that are currently online. Notice how the CVR reply comes in the middle of the ILNs, making it impossible to elegantly handle them.
>>>CHG 9 NLN\r\n
>>>CVR 10 0x0409 win 4.10 i386 MSMSGS 4.6.0076 MSMSGS\r\n
<<< CHG 9 NLN\r\n
ILN 9 NLN bob@hotmail.com Bob\r\n
ILN 9 IDL carol@hotmail.com Carol\r\n
<<< CVR 10 5.0.0543 5.0.0543 1.0.0000 http://download.microsoft.com/download/6/1/a/61a02bc6-eecd-408e-bc2f-fe0e0bcfdd19/setup9x.exe http://messenger.microsoft.com\r\n
ILN 9 BSY emily@hotmail.com Emily\r\n
The server challenges Alice's client with the string "29409134351025259292".
<<< CHL 0 29409134351025259292\r\n
Alice's client adds "Q1P7W2E4J9R8U3S5" to the end of this string, to produce "29409134351025259292Q1P7W2E4J9R8U3S5". The MD5 digest of that string is "d0c1178c689350104350d99f8c36ed9c".
<<< QRY 11 msmsgs@msnmsgr.com 32\r\n
d0c1178c689350104350d99f8c36ed9c (no newline)
The server accepts Alice's response to this challenge.
<<< QRY 11
Alice walks away from her computer. After a few minutes, Alice's client sets her online state to "idle".
>>> CHG 12 IDL\r\n
<<< CHG 13 NLN\r\n
While Alice is away, Bob goes offline.
<<< FLN bob@hotmail.com\r\n
When Alices returns, her client sets her online state to "online".
>>> CHG 13 NLN\r\n
<<< CHG 13 NLN\r\n
Shortly afterwards, Carol changes here online state to "Busy", and changes her friendlyname.
<<< NLN BSY carol@hotmail.com Caroline\r\n
Because Carol changed her friendlyname with her last change of online state, Alice's client updates Carol's nickname to match.
>>> REA 14 carol@hotmail.com Caroline\r\n
<<< REA 14 28 carol@hotmail.com Caroline\r\n
Alice decides that she doesn't want Bob to see here presence information any longer, so her client removes him from her allow list, and adds him to her block list.
>>> REM 15 AL bob@hotmail.com\r\n
ADD 16 BL bob@hotmail.com Bob\r\n
Finally, Alice decides to log out of MSN Messenger.
OUT\r\n
<o> Server closes connection