The first step in an MSN Messenger session is logging into a notification server. If you have previously stored the IP address of a notification server, you can connect directly to that. Otherwise, you must connect to the "dispatch server". The official client usese messenger.hotmail.com, port 1863 as the dispatch server for direct and SOCKS-based connections, and gateway.messenger.hotmail.com, port 80 as the dispatch server for HTTP connections. If you want to connect to a third-party MSN Messenger network, you should use a different dispatch server.
If you cannot connect to a previously stored notification server, try the dispatch server instead. If you cannot connect to the dispatch server, either you are having connection problems, or the MSN Messenger network is down (which happens from time to time).
When you first connect to a notification server, you are in the "login stage", which involves agreeing on a protocol version to use, authenticating yourself to the MSN server, and possibly being redirected to another notification server if the current one is overloaded.
During the login stage, the server behaves differently to normal. Communication essentially synchronous - the client sends a message to the server, the server replies, the client sends another message, and so on. If you send a command at the wrong time (for example, if you send a VER command when the protocol version to use has already been negotiated), the server will send a 715 error, then disconnect you. If you send a CVR command at any time before sending the initial USR command, the server will send error 731, then disconnecy you. If you send CVR after the initial USR, but before the subsequent USR, you will receive error 715, then disconnect you. If you send a command which has no meaning during the login stage (for example, a SYN command), you will be disconnected immediately with no error. None of these rules apply outside of the login stage.
The VER command specifies which versions of the MSN Messenger protocol are supported. The VER command has a TrID and a list of supported protocol versions as parameters (note that protocol versions are case sensitive). The server will reply with a VER command with the same TrID. If the server supports at least one of these protocols, the parameters will be a list of the supported protocol(s), with the first parameter in the list will being the protocol version you must use in this session. If the server doesn't understand any of the specified protocols (which shouldn't normally happen), it will reply with a single parameter of 0, and will disconnect you immediately.
You can include "CVR0" in the list of protocols you support, but in protocol versions up to and including MSNP7, it's essentially decorative - though it's presumably supposed to affect the handling of the CVR command, the server behaves the same in practice whether you send it or not.
Below are some examples:
<o> Connect: messenger.hotmail.com 1863
>>> VER 0 MSNP4 MSNP5 MSNP6 MSNP7 CVR0\r\n
<<< VER 0 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
<o> Continue Session . . .
<o> Connect: messenger.hotmail.com 1863
>>> VER 0 MSNP7 MYPROTOCOL\r\n
<<< VER 0 MSNP7\r\n
<o> Continue Session . . .
<o> Connect: messenger.hotmail.com 1863
>>> VER 0 MYPROTOCOL\r\n
<<< VER 0 0\r\n
<o> Server Closes Connection
<o> Connect: messenger.hotmail.com 1863
>>> VER MSNP7 (No TrID)\r\n
<o> Server Closes Connection
After the client and server agree on a protocol version, the client may send INF with a TrID and no parameters. This asks the server what form of authentication will be used.
The server will reply with an INF, the TrID, and the type of authentication system as the parameter. In protocol versions up to and including MSNP7, it is always MD5, so it's really pretty pointless. In fact, everything will be fine if you just leave it out, but you should send it if you want to fully emulate the official client.
After receiving the response to INF (or VER if you skipped it), you must send the USR command. It has a TrID.
MD5).I (standing for initiating authentication).If the server does not like your USR, it will close the connection with no reply, or possibly send an error first (I've seen error 911 when replacing the I with an S or when sending invalid account names such as hotmail.com).
Sometimes, when the server is having problems or is down for maintenance, it will reply with an error instead of logging you in. Some possible errors include error 500, error 601, error 910, and error 921.
Otherwise, the server will either respond with a XFR (transferring you to another notification server) or a subsequent USR.
messenger.hotmail.com always sends XFR, but gateway.messenger.hotmail.com never does. Microsoft's other notification servers very rarely send XFR - presumably, they send it when they are overloaded or going down for maintainence.
The XFR command will have the same TrID as the previous USR, and two, three, or four arguments depending on the version of the MSN protocol being used.
NS, telling you that it is transferring you to a notification server.0 (zero).Below is an example of what it would look like in MSNP7:
>>> USR 2 MD5 I example@passport.com\r\n
<<< XFR 2 NS 207.46.106.145:1863 0 207.46.104.20:1863\r\n
After you receive the XFR, the server will close the connection. You must connect to the specified notification server and start the login process again. Because there is no real communication between notification servers, you can specify a different protocol version and name when logging into the new notification server.
The subsequent USR has an S for subsequent instead of an I. The only parameter is a random string. This random string is actually the current UNIX time, but don't rely on that, and treat it as a string of any length made up of any characters. You will need this string for encrypting your password.
Add your password to the end of the random string, then take the MD5 hexadecimal digest of the whole thing, as described in the MD5 page. Send the server another USR with a TrID, MD5 as the first parameter, an S as the second, and your 32-digit digest as the third.
If the password is correct, the server will respond with a USR with OK as the first parameter, your account name as the second parameter, your URL-encoded friendly name as the third parameter, and if you are using MSNP7, there will be a 0 or 1 as the last parameter. It represents whether or not your Passport has been verified (1 is true, 0 is false).
If your your password is incorrect, the server will respond with error 911 and close the connection. If anything else is wrong (including an invalid digest size), the server will close the connection with no error.
Sometimes, when the server is having problems or is down for maintenance, it will reply with an error instead of logging you in. Some possible errors include error 500, error 601, error 910, and error 921.
In this example, the client first logs into Microsoft's dispatch server, is redirected to 207.46.106.145, then logs in successfully. At the time of writing, messenger.hotmail.com resolves to the IP address 207.46.104.20.
<o> Client Connects to messenger.hotmail.com 1863 (Dispatch Server)
>>> VER 0 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
<<< VER 0 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
>>> INF 1\r\n
<<< INF 1 MD5\r\n
>>> USR 2 MD5 I example@passport.com\r\n
<<< XFR 2 NS 207.46.106.145:1863 0 207.46.104.20:1863\r\n
<o> messenger.hotmail.com closes connection
<o> client connects to 207.46.106.145 1863
>>> VER 0 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
<<< VER 0 MSNP7 MSNP6 MSNP5 MSNP4 CVR0\r\n
>>> INF 1\r\n
<<< INF 1 MD5\r\n
>>> USR 2 MD5 I example@passport.com\r\n
<<< USR 2 MD5 S 1013928519.693957190\r\n
>>> USR 3 MD5 S 23e54a439a6a17d15025f4c6cbd0f6b5\r\n
<<< USR 3 OK example@passport.com My%20Screen%20Name 1\r\n
<o> continue NS session . . .
You are now successfully logged in, and can set your initial status, as shown in the Statuses page. You should also sync your lists soon after you are logged in. You will probably also receive one or more messages (MSG) from the NS after receiving the final USR as explained in the DS/NS Messages page. You may also want to send the CVR command to identify your client version.
To make things go as quickly as possible when logging in, you can send multiple commands at once without waiting for response (for some reason, I have problems when putting them in the same packet). Send VER and USR together to the DS. Only specify the one protocol version you intend to use, and send a@b.c to messenger.hotmail.com as your email address. Don't bother with the INF. You may also substitute \ns for \r\ns to save bandwidth.
To log off of the NS (and have MSN send your offline status to everyone), the easiest way is to just close the socket. If you do not properly tear down your connection (e.g. if you're on a modem and are disconnected), you will still appear to be online and unresponsive for several minutes afterward.
The proper way to log off is by sending the OUT command to the NS with no parameter and no TrID. The server will immediately close the connection. According to the original draft of the protocol, the server should send an OUT in response, but in practice, it never does.
Sometimes the server will initiate the closing of the connection. This can happen for two reasons: either the server is going down, or someone logged into MSN with your account elsewhere.
When someone logs into your account elsewhere, the original connection will be closed, and the new one will be connected. Before closing the connection, the NS will send the client the OUT command with the parameters OTH - the user logging in from another location.
When the server is going down for maintainence, it will send OUT SSD - server shutting down. The server will close the connection immediately after sending this command.
Often, before sending OUT SSD, the server will send a warning message. For example, you might see in MSN Messenger, "The server will be shutting down for maintenance in 5 minutes." These messages are described here.