Home arrow HTML arrow Page 2 - The MSN Messenger Protocol Torn Apart: Part 1/3

The MSN Messenger Protocol Torn Apart: Part 1/3

Ever wanted to build your own MSN messenger? In this article series Neville rips apart the MSN messenger protocol for all to see. It's a must read for any developer!

Author Info:
By: Neville Mehta
Rating: 5 stars5 stars5 stars5 stars5 stars / 93
October 20, 2002
  1. · The MSN Messenger Protocol Torn Apart: Part 1/3
  2. · Digging Into the Protocol
  3. · The Workings of the Protocol
  4. · Change Your Initial Status
  5. · Order the List
  6. · User Statuses
  7. · Conclusion

print this article

The MSN Messenger Protocol Torn Apart: Part 1/3 - Digging Into the Protocol
(Page 2 of 7 )

Msn messenger uses tcp/ip to communicate. All data transmitted from the client and the server is in clear text. That means if you monitor msn messenger on your pc, you can actually read the data being passed.

Before starting off, let me introduce you to a few concepts of the msn messenger protocol. There are 3 servers involved in this entire process:

The dispatch server
This is the server which we initially connect to. The main function of this server is the basic authentication of the client. You can connect to the dispatch server through (or its FQDN which is messenger.hotmail.com) on port 1863.

The notification server
After the basic authentication is handled through the dispatch server, the dispatch server refers the client to a notification server. Until the client lives, he is connected to the notification server. The main functions of the notification server are to store most of the clients session details. Things like contact list management, status changes, email arrivals, etc are all sent to you through the notification server.

The switchboard server
The switchboard server is mainly used to initiate chat sessions between you and your msn contacts. Let me give you an example. When "Fred" sends a message to "Tom", the following are the steps that would take place:
  • Fed would send a request to the notification server that he would like to chat with Tom.
  • The notification server then refers Fred (sender) to a switchboard server.
  • Soon Tom (receiver) gets a notification from the Notification server to connect to the same switchboard server that Fred (sender) is connected to.
  • Once connected to a common switchboard server, they begin instant messaging.

It's not easy to reverse-engineer a protocol just by looking at the data packets being passed through the network using that protocol. If you at this moment take a port monitor and try to figure out the entire msn messenger protocol by just looking at what's being transmitted, its not that simple. I suggest you complete reading this article and then try. I assure you that after you have read this article the packets you monitor on your PC will make a lot more sense than they would right now.

Also, make sure that you get a good port monitor. I suggest you use Uasoft's sniffer -- it's what I use. You can choose which packets you want to monitor too. You should choose to monitor just the TCP and the IP packets, because that's what the msn messenger protocol works on. 

Whenever the client and the server want to communicate with each other, they send commands to do so. Every command has a 3-word identifier. This tells the receiver of the command what itís all about. Most of these commands end with a new line character to tell the receiver they have ended. There are a few exceptions to this. I will tell you about those commands a little later. For now, the typical command syntax (with the exception of a few) would be something like this:


Transaction Id's
Whenever the client sends a command to the server, the server sometimes has to respond back. Now let me give you a small example. Have you ever come across a support ticket system somewhere on the Internet? (If not, see ours). How does it work? Well, when you enter your query into the system you are given a support ticket id. Whenever your question is answered, it is accompanied by the support ticket id just to let you know that it's your question being answered.

Similarly in case of the msn messenger, when the client sends a command to the server he sends along with the command a transaction ID. Itís any number between 0 and 4294967295. When the server responds back to your command it includes the transaction id that you sent through with that command. Many a time the server would send more than one reply to your command.

What happens when the server wants to send a command to the client? We must remember that commands are mostly send from the server to the client. When this is the case, the server sends a transaction id of 0. This means that the server doesn't really require any response back from the client. Usually these are challenge commands (I will discuss challenge commands a bit later).

Whenever an error occurs, the server sends error command. The error command is nothing but a three-digit code accompanied by the transaction id of the command, which has caused the error. Every error command also includes a short description of the error thrown. So a typical error command sent by the server to the client would look like this:


We have a list of these error identifiers and their description in Microsoft's official draft on the protocol. I have attached this as part of the support material for this article on the last page.

blog comments powered by Disqus

- Does HTML5 Need a Main Element?
- Revisiting the HTML5 vs. Native Debate
- HTML5: Not for Phone Apps?
- HTML5 or Native?
- Job Hunting? Freelancer.com Lists This Quart...
- HTML5 in the News
- Report: HTML5 Mobile Performance Lags
- The Top HTML5 Audio Players
- Top HTML5 Video Tutorials
- HTML5: Reasons to Learn and Use It
- More of the Top Tutorials for HTML5 Forms
- MobileAppWizard Releases HTML5 App Builder
- HTML5 Boilerplate: Working with jQuery and M...
- HTML5 Boilerplate Introduction
- New API Platform for HTML5

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials