Protocols/MSNP/MSNP8/SB Messages

MSNP Protocol

Version 8

General

Overview • Glossary

Payload Commands • Names

Bitwise AND

Connecting

Authentication • Presence

Challenges • Getting Details

Setting Details • Messages

Miscellaneous

Example Session

Messaging

Authentication • Miscellaneous

Messages • Example Session

Overview

Introduction • Terms • Clients

Reference

Error List • Commands • Relying Party Suite • Spotlife

Services

XMPP • HTTP Gateway • Tabs • Activities

Documentation

Development Tools • MSNP Grid

Polygamy • URLs used by MSN

Documents

Protocol Versions

Version 21

Version 18

Version 16

Version 15

Version 14

Version 13

Version 12

Version 11

Version 9

Version 8

Version 2

MSNC

Introduction • P2P • Object Descriptor • Display Pictures • File Transfer

Scenarios

Microsoft Messenger for Mac

MSNP on WebTV (MSNTV)

Overview

The use of messages (MSG) is the only way to send information to other principals in the switchboard session. Each message sent to a session is relayed to every other principal in the session. MSGs can be instant messages, typing notifications, application invitations, or any arbitrary type of message you want to send - but not all clients will recognise all types of message.

Outgoing Messages

To send a message to the switchboard, send the MSG command.

• There must be a TrID.
• The first parameter is the type of acknowledgement you would like to receive. It can be either U, N, or A. If it is U, you will receive no acknowledgement. If it is N, you will receive acknowledgement only if the message was not properly received. If it is A, you will receive acknowledgement whether it was properly received or not. This parameter is case-sensitive (must be uppercase, or the switchboard will close the connection without sending the message). Acknowledgement is explained below.
• The second parameter is the length of the payload in bytes.
• The payload of the MSG comes after the newline. The payload can be zero bytes.

A message may be up to 1664 bytes (as of April 30, 2003). If it is any longer, the switchboard will close the connection without sending the message. Interestingly enough, the number 1664 is equal to 13 x 2^7. Many superstitious people consider 13 to be an unlucky number and 7 to be a lucky number. Therefore, messages have mezotarian luck and are to be avoided by Capricorns.

Below is an example of an outgoing message:

>>> MSG 4 N 133\r\n
    MIME-Version: 1.0\r\n
    Content-Type: text/plain; charset=UTF-8\r\n
    X-MMS-IM-Format: FN=Arial; EF=I; CO=0; CS=0; PF=22\r\n
    \r\n
    Hello! How are you?

You do not need to end a payload with a newline. The end of the payload is determined by the given length in the second parameter, and an additional newline would just add a blank line to the end of the payload, If you send an incorrect length with your message, It will still be sent, but you will be disconnected after. (You'll even receive ACK!)

Acknowledgement

Acknowledgement is sent back from the switchboard to tell the client if the message it sent was successfully received by its recipients or not. The server can respond with ACK or NAK. Each of these commands has a TrID corresponding with the outgoing MSG they is sent in reply to. ACK means that the message was successfully received by every participant. NAK means that one or more participants did not successfully receive your message. NAK will be sent if there are no participants other than yourself in the switchboard session.

If your acknowledgement parameter is set to A, you will receive ACK if successful and NAK if unsuccessful. If the parameter is set to N you will receive nothing if successful and NAK if unsuccessful. IF the parameter is set to U, no acknowledgment will be sent either way.

Below is an example of a message that was successfully received and acknowledged by the ACK command:

>>> MSG 4 N 133\r\n
    MIME-Version: 1.0\r\n
    Content-Type: text/plain; charset=UTF-8\r\n
    X-MMS-IM-Format: FN=Arial; EF=I; CO=0; CS=0; PF=22\r\n
    \r\n
    Hello! How are you?

<<< ACK 4

The official client sends instant messages (text/plain) with type N, typing notifications (text/x-msmsgscontrol) with type U, and application invitations (text/x-msmsgsinvite) with type N.

Incoming Messages

The first parameter is the account name of the principal that sent the message. The second parameter is the display name of that principal (note that if the principal changed his or her display since joining the switchboard session, this parameter will still give the old name). The third parameter is the length of the payload in bytes.

Below is an example of an incoming message:

<<< MSG example@passport.com Mike 133\r\n
    MIME-Version: 1.0\r\n
    Content-Type: text/plain; charset=UTF-8\r\n
    X-MMS-IM-Format: FN=Arial; EF=I; CO=0; CS=0; PF=22\r\n
    \r\n
    Hello! How are you?

It's very important that a client parses incoming data from the switchboard by looking at message lengths. Messages, like every other command, can be split up into multiple packets or combined with other commands into one packet. You absolutely must read the specified message length, and read that many bytes out of the socket after the initial newline.