Protocols/MSNP/MSNP8/SB Messages

From NINA Wiki
Revision as of 10:30, 12 May 2022 by Animadoria (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
MSNP Protocol
Version 8
General
OverviewGlossary
Payload CommandsNames
Bitwise AND
Connecting
AuthenticationPresence
ChallengesGetting Details
Setting DetailsMessages
Miscellaneous
Example Session
Messaging
AuthenticationMiscellaneous
MessagesExample Session
Overview
IntroductionTermsClients
Reference
Error ListCommandsRelying Party SuiteSpotlife
Services
XMPPHTTP GatewayTabsActivities
Documentation
Development ToolsMSNP Grid
PolygamyURLs 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
IntroductionP2PObject DescriptorDisplay PicturesFile 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.