MSN协议

声明

	Q1P7W2E4J9R8U3S5
PROD0038W!61ZTF9	VT6PX?UQTM4WM%YR
PROD0058#7IL2{QD	QHDCY@7R1TB6W?5B
PROD0061VRRZH@4F	JXQ6J@TUOGYV@N0M

下面给出了每个需要处理的高亮的变量。

.URL
来自于初始化邮件通知中的
Post-URL
。

.action
来自于
URL
命令（带
INBOX
、
FOLDERS
、
COMPOSE
参数）（尤其是，第二个响应参数）。

．
login
—
你的邮件地址

.sid
与
kv
来自
profile
中
sid
与
kv
的值

.id
来自于新邮件通知或
URL INBOX, FOLDERS
或者
COMPOS
命令应答的第三个参数。

.sl
—（
session-length
）是从收到初始
profile
消息的秒数。不应该用
profile
中的
LoginTime
字段来计算该值，实际上，你本地的时钟是不准确的。

.rru
—
可以为
Inbox-URL
，
Folders-URL
，
Message-URL
或
Compose-URL
中的任意一个。这可以从初始邮件通知、新邮件通知或
URL
命令的第一个参数中获得。如果你选用了
Compose-URL
，你可以指定一些特殊变量，包括“
mailto
”（必须设置为
1
），“
subject
”和“
to
”。所以你可以指定
/cgi-bin/compose?mailto=1&subject?=Hi%20Dave&to=example%40hotmail%2ecom
来直接到窗体，其中收件人为“

”，主题为“
Hi Dave
”。

.auth
—
来自于
profile
中的
MSPAuth
。

.creds
—是
MSPAuth + sl + password
的
MD5
串。

其他值为常数。

4.6.5.
       系统消息

系统消息是 NS 以 Content-Type 为
application/x-msmsgssystemmessage 发送的消息。我们只发现了一种系统消息，那就是服务器将停止服务，并进行维护。

 

格式

 

系统消息的头部总会是 MIME-Version: 1.0 与 Content-Type 字段，如下所示：

MIME-Version: 1.0/r/n

Content-type: application/x-msmsgssystemmessage

/r/n


/r/n

消息主体中包含 Type 字段，可能还会有一些附加字段。 Type 字段指出了系统消息类型。最后总会是一个新行。

我们只见过系统消息为 1 的 Type ，该类型意味着“服务器因维护将在 Arg1 分钟后停止服务”。 Arg1 字段总是服务器将要停止服务的分钟数。下面示例中服务器将在 5 分钟后停止服务：

Type: 1/r/n

Arg1: 5

/r/n

与头部信息连起来，整个内容为：

MSG Hotmail Hotmail 88/r/n

MIME-Version: 1.0

/r/n

Content-type: application/x-msmsgssystemmessage

/r/n


/r/n

Type: 1

/r/n

Arg1: 5

/r/n

收到 1 类型的系统消息后，在指定分钟后你将收到 OUT SSD 命令， DS/NS 验证节有描述。

http://www.hypothetic.org/docs/msn/phorum/read.php?f=1&i=1043&t=1068 有关于系统消息的讨论。

 

4.7.
        杂项

4.7.1.
       服务的 URL

URL 命令提供外部或内嵌浏览器可以打开的 MSN 不同服务的 URL 。它有一或两个参数，如下是第一个参数：

·      
INBOX
- Hotmail
收件箱

·      
FOLDERS
- Believed to be the Hotmail's "MSN home" URL.

·      
COMPOSE
- Compose an email

·      
CHGMOB
- Mobile settings (pager etc.)

·      
PROFILE
- Edit your MSN member directory profile.

·      
PERSON
- Member services, password, secret question, account info

·      
CHAT
- Chat rooms

官方客户端看起来也会发送
MOBILE ,
ADDRBOOK ,
ADVSEARCH 和
INTSEARCH ，但这些从来没有被发现过。

INBOX ， FOLDERS 与 COMPOSE 是访问 Hotmail 的方法。 COMPOSE 可以携带第二个参数 — 收件人的邮件地址。

PROFILE ， PERSON 与 CHAT 的 URL 需要第二个参数 — 你的 locale ID 的十六进制数（如 0x0409 为 U.S.English ）。

服务器将响应另外的 URL ，通常包含 3 个参数：两个 URL 和一个 ID ，这些参数指出了怎样访问浏览器。

如下指出了访问 Hotmail 收件箱的 URL 信息：

>>> URL 15 INBOX/r/n

<<< URL 15 /cgi-bin/HoTMaiL https://loginnet.passport.com/ppsecure/md5auth.srf?lc=1033 2/r/n

URL 命令不能给出 MSN 成员列表的 URL ，但我们还是可以查看单个人员的 profile ：
http://members.msn.com/default.msnw?mem=ACCOUNTNAME ，其中 ACCOUNTNAME 是你要查看的人员账号。

4.7.2.
       发送一个邮件邀请

你可以发送一个 e-mail 邀请他人使用 MSN Messenger 。有两个命令可以实现： SDC 与 SND ，建议使用 SDC — SND 是协议早期版本的产物。

 

SDC 命令

 

你可以用 SDC 命令发送一个邮件到指定邮件地址，然后告诉他“

wants to talk to you! ”。它是一个有效载荷命令，需要事务 ID 和 8 个参数：

. 第一个是你要邀请的邮件地址

. 第 2 、 3 、 4 、 5 、 6 个参数是“ 0x0409 MSNMSGS WindowsMessenger X X ”。

. 第 7 个参数是标题中你的名字“

wants to talk to you! ”。

. 第 8 个是有效载荷的长度。

下面，我们将邀请 ，其中消息为“ Hi Mike! ”：

>>> SDC 3 0x0409 MSMSGS WindowsMessenger X X Andrew%20Sayers 8/r/n

    Hi Mike!

(no newline)

如果发送成功则返回 SDC 命令及事务 ID 和参数“ OK ”：

<<< SDC 21 OK/r/n

 

SND 命令

 

可选择的，你可以用 SND 命令发送邮件“

wants to talk to you! ”，这个命令没有做更多测试。

SND 包含事务 ID 及 4 个参数：

. 第一个是被邀请人的邮件地址

. 第二个是发送信息的语言的 locale ID 。

. 第 3 、 4 个是“ MSMSGS MSMSGS ”。

如果发送成功服务器响应 SND 及事务 ID 与 OK ：

>>> SND 22 0x409 MSMSGS MSMSGS/r/n

<<< SND 22 OK/r/n

如果 发送的此消息， Alice 将收到邮件“ wants to talk to you! ”

4.7.3.
       发送页

你可以用 PAG 命令在对方的 MSN Mobile 上 page 他们，并用 IPG 命令接收来信。

如果 FL 中某人有一个 MSN Mobile ，并且允许你给他们发送消息，他们的“ MOB ”设置为“ Y ”。 PAG 命令包含事务 ID 及 2 个参数：

. 第一个参数是对方联系人的护照

. 第二个是消息主体的长度

有效载荷可以选择是否以
?
string?
string? 开始，来指定一个回呼号。然后是

string ，其中包含了要发送的消息。严格的说，
enc="utf-8" 仅当消息包含非 ASCII 字符时有必要，但包含它总是保险的。

如果命令失败，将收到 800 错误。如果还有其他错误（如你不被允许使用 PAG 命令，或者 PAG 命令畸形）你会得到 220 错误。如果发送成功，不会有任何响应。

PAG 命令发送的消息不应该长于 113 个字符，由于它是一个 XML 文档，所以应该是经过 XML 编码的。

 

4.7.4.
       接收页

来的 Page 可以用 IPG 命令接收，命令包含一个参数：有效载荷长度：

<<< IPG 643/r/n


643 bytes in the message body

有效载荷是一个通知文档，官方客户端在一个消息框中显示文本，就像一个标准的对话窗那样，并且不需要使用通知中的任一 URL 。

4.7.5.
       注意

注意被 MSN Messenger 用来提示你有事情发生（如某人的生日临近了）。目前，已知只有 MSN 日历和 MSN Alerts 使用注意。命令为 NOT ，就像 IPG ，这个命令只包含一个参数指出了有效载荷的长度：

<<< NOT 589/r/n

589 bytes in the message body

有效载荷是一个通知文档，官方客户端在一个弹出式窗口中显示通知文本（称为“ toast ”），就像有人登录时那样。点击其上的消息，就会通过浏览器访问真正的 URL ，或者点击“ Option ”，转到指定 URL 。

 

4.8.
        会话示例

4.8.1.
       概述

本节对通知会话的整个过程作了一个示范，但本节并没有（也不会）显示每一个与 NS 交互的命令。

 

约定

 

本节中客户端以 为例。

4.8.2.
       示例

登录 — messenger.hotmail.com

 

客户端（ ）连接到 messenger.hotmail.com:1863 ，客户端使用协议 8 ，支持 CVR0 。

>>> VER 1 MSNP8 CVR0/r/n

<<< VER 1 MSNP8 CVR0/r/n

成功商议协议版本后，客户端给出了它的协议版本信息。

>>> CVR 2 0x0409 win 4.10 i386 MSNMSGR 5.0.0544 MSMSGS /r/n

<<< CVR 2 6.0.0602 6.0.0602 1.0.0000 http://download.microsoft.com/download/8/a/4/8a42bcae-f533-4468-b871-d2bc8dd32e9e/SETUP9x.EXE http://messenger.msn.com/r/n

Alice 的客户端尝试自行认证，而服务器重定位到 baym-cs118.msgr.hotmail.com(IP:207.46.106.118) ，端口号 1863 。

>>> USR 3 TWN I /r/n

<<< XFR 3 NS 207.46.106.118:1863 0 207.46.104.20:1863/r/n

登录 — baym-cs118.msgr.hotmail.com

 

客户端连接到 baym-cs118.msgr.hotmail.com:1863 ，客户端可以解释协议版本 8 ， CVR0 。

>>> VER 4 MSNP8 CVR0/r/n

<<< VER 4 MSNP8 CVR0/r/n

客户端再次给出协议版本信息

>>> CVR 5 0x0409 win 4.10 i386 MSNMSGR 5.0.0544 MSMSGS /r/n

<<< CVR 5 6.0.0602 6.0.0602 1.0.0000 http://download.microsoft.com/download/8/a/4/8a42bcae-f533-4468-b871-d2bc8dd32e9e/SETUP9x.EXE http://messenger.msn.com/r/n

Alice 的客户端尝试自行认证，服务器返回了 Passport 认证所需的一长字符串。

>>> USR 6 TWN I /r/n

<<< USR 6 TWN S lc=1033,id=507,tw=40,fs=1,ru=http%3A%2F%2Fmessenger%2Emsn%2Ecom,ct=,kpp=1,kv=5,ver=2.1.0173.1,tpf=43f8a4c8ed940c04e3740be46c4d1619

Alice 通过 MS Passport 认证，响应她的 ticket ：

>>> USR 7 TWN S t=53*1hAu8ADuD3TEwdXoOMi08sD*2!cMrntTwVMTjoB3p6stWTqzbkKZPVQzA5NOt19SLI60PY!b8K4YhC!Ooo5ug$$&p=5eKBBC!yBH6ex5mftp!a9DrSb0B3hU8aqAWpaPn07iCGBw5akemiWSd7t2ot!okPvIR!Wqk!MKvi1IMpxfhkao9wpxlMWYAZ!DqRfACmyQGG112Bp9xrk04!BVBUa9*H9mJLoWw39m63YQRE1yHnYNv08nyz43D3OnMcaCoeSaEHVM7LpR*LWDme292X3j8N/r/n

<<< USR 7 OK Alice 1 0/r/n

现在 Alice 成功登录到 NS 。她的客户端可能会记住下次直接访问 baym-cs118.msgr.hotmail.com ，而不是 messenger.hotmail.com 。服务器这时会发送 Alice 的 profile ：

<<< MSG Hotmail Hotmail 491/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsprofile; charset=UTF-8

/r/n

    LoginTime:

/r/n

    EmailEnabled: 0

/r/n

    MemberIdHigh: 85040

/r/n

    MemberIdLow: -

/r/n

    lang_preference: 1033

/r/n

    preferredEmail:

/r/n

    country: US

/r/n

    PostalCode: 90201

/r/n

    Gender: m

/r/n

    Kid: 0

/r/n

    Age:

/r/n

    BDayPre: 5

/r/n

    Birthday: 0

/r/n

    Wallet: 0

/r/n

    Flags: 1027

/r/n

    sid: 507

/r/n

    kv: 4

/r/n

    MSPAuth: MSPAuth: 41bbzZ*NzDmDQ8ic4HWo89b9zhCBk!

?ONDJKB3Los8UMgBnCOLSwQKo!8IeIH?QF0vVItSlOzIL36e5MAdMaB3mpZw$$/r/n

    ClientIP: 1.2.3.4

/r/n

    ClientPort: 516.

/r/n

   

/r/n

 

同步

 

Alice 的客户端现在需要同步她的联系表，上次登录时 Alice 的客户端版本号为 6 ，但现在版本号已经是 27 了。

>>> SYN 8 6/r/n

<<< SYN 8 27 5 4/r/n

由于版本信息不匹配，服务器将发送所有 Alice 的联系信息（而不是版本 6 与 27 之间更改的部分）。首先，服务器在每个数据包中发送一个信息。

<<< GTC A/r/n

<<< BLP AL

/r/n

<<< PRP PHH 01%20234


/r/n

<<< PRP PHM 56%20789

/r/n

然后服务器在一个包中发送全部组列表。由于 Alice 的客户端使用的编程语言一次获取一个数据包，不得不把每行都分开，然后每次处理一行。

<<< LSG 0 Other%20Contacts 0/r/n

    LSG 1 Coworkers 0

/r/n

    LSG 2 Friends 0

/r/n

    LSG 3 Family 0

/r/n

然后服务器发送 Alice 的联系表，联系表中第一个人是 Bob ，昵称为“ Bob ”，他在 FL ， BL 与 RL 中。他没有共享电话号码，但我们却可以使用一个 MSN mobile 设备。他的详细信息在一个包中被发送，我们也不得不分开，然后一行一行处理。

<<< LST Bob 13 0/r/n

    BPR MOB Y

/r/n

Alice 列表中的第二个人是 Carol ，昵称 Carol ，她共享了她的工作电话（ 9876-54321 ），但没有其他信息了。不幸的是，服务器用两个包来发送 Carol 的资料，中间有间隔。 Alice 的客户端必须重建这些行数据，然后才可以进行处理。

<<< LST Carol 3 0/r/n

    BPR PHM 9876

<<< -54321/r/n

然后服务器发送来 Dave 的资料， Dave 在 Alice 的 FL 中，并处在 Coworkers 、 Friends 、 Family 组中。他的家庭电话为“ 3. ”，工作电话为“ 2. ”，移动号码为 sqrt(-1) ，服务器用了几个包来发送资料。

<<< LST 1 1,2

<<< ,3/r/n

    BPR PHH 3.

/r/n

    BPR PH

<<< W

<<<

<<< 2./r/n

    BPR PHM sqrt(-1)

/r/n

下一个是 Eve （邪恶的偷听者），已经被阻止，而看不到 Alice 的在线状态。

<<< LST Eavesdropper 12/r/n

最后是 Fred ，应该是最近添加的，因为他在 Alice 的 RL 中，但既不在 AL 也不在 BL 中。

<<< LST Fred 8/r/n

下面是相互之间能接收状态信息的描述：

.Alice 想得到 Bob, Carol 与 Dave 的在线信息，但她不知道对方是否允许她知道。

.Bob 想得到 Alice 的在线状态， Alice 也允许。

.Carol 可以得到 Alice 的在线状态，但他并不想。

.Dave 想得到 Alice 的在线信息，但不被允许

.Eve 想得到 Alice 的在线信息，但不被允许

.Fred 想得到 Alice 的在线信息，且允许得到。他既不在 Alice 的 AL 中也不在 BL 中，但由于 Alice 的 BLP 设置为 AL ，所以他将按 AL 处理。 Alice 的客户端应该马上提示 Alice 应该加入哪个列表中。

 

初始状态

 

好的， Alice 已经同步完毕她的联系表，现在她需要发送她的初始状态，并且允许 Fred 看到她的在线状态。在线状态命令将导致服务器发送状态信息给联系人。注意 ADD 响应处在了 ILN 中，这样更难处理了一些。

>>> CHG 9 NLN 0/r/n

>>> ADD 10 AL Fred

/r/n

<<< CHG 9 NLN 0/r/n

    ILN 9 NLN Bob 24

/r/n

    ILN 9 IDL Carol

/r/n

<<< ADD 10 AL 28 Fred 1/r/n

    ILN 9 BSY Emily

/r/n

 

Challenge

服务器用“ 0 ”询问 Alice 的客户端

<<< CHL 0 0/r/n

客户端添加“ Q1P7W2E4J9R8U3S5”到尾部，得到串“0Q1P7W2E4J9R8U3S5”，然后获得 MD5 摘要“ d0c1178c0d99f8c36ed9c ”。

>>> QRY 11 32/r/n

    d0c1178c0d99f8c36ed9c

(no newline)

服务器接收了 Alice 的响应

<<< QRY 11

 

在线状态变更

 

Alice 离开了她的计算机，数分钟后， Alice 的客户端设置她的在线状态为“ idle ”。

>>> CHG 12 IDL 0/r/n

<<< CHG 12 IDL 0/r/n

这个时候， Bob 离线了

<<< FLN /r/n

Alice 回来后，客户端设置在线状态为“ online ”

>>> CHG 13 NLN 0/r/n

<<< CHG 13 NLN 0/r/n

不久， Carol 设置为“ Busy ”，并改变了她的显示名

<<< NLN BSY Caroline /r/n

 

昵称变更

 

由于 Carol 最后改变在线状态时变更了显示名， Alice 的客户端就需要更新资料。

>>> REA 14 Caroline/r/n

<<< REA 14 28 Caroline/r/n

Alice 决定不再让 Bob 看到她的在线信息了，于是她的客户端把 Bob 从 AL 中删除，然后添加到 BL 中。

>>> REM 15 AL /r/n

    ADD 16 BL Bob

/r/n

 

登出

 

最后， Alice 退出 MSN Messenger 。

OUT/r/n



Server closes connection


 

5.
         交换板

5.1.
        认证

5.1.1.
       概述

连接到一个交换板有两种方法：或者请求一个交换板会话或者被邀请加入一个已存在的交换板中。这两个事件都是发生在 NS 上。当连接到一个交换板时，客户端需要处理会话创建 (XFR) 与被邀请 (RNG) 之间的不同。

5.1.2.
       请求一个交换板会话

通知服务器

 

要请求一个交换板会话，客户端必须发送 XFR 命令到 NS ，其中包含事务 ID 及一个参数 SB( 交换板 ) ，服务器将用另外的 XFR 响应，其响应需要依照交换板认证指示，下面是一个示例：

>>> XFR 15 SB/r/n

<<< XFR 15 SB 207.46.108.37:1863 CKI ..32308/r/n

. 第一个参数告诉你正在转入交换板中（这应该总是相同的）。注意 DS 中，这个参数将变为 NS 。

. 第二个是交换板服务器的地址与端口（总会是 1863 ），其间用冒号分隔

. 第三个指出了认证类型，总应该是 CKI

. 第四个是认证串，当连接到交换板时，客户端用它来证明身份。

然而如果你没有设置你的初始状态，或者你处于 HDN 中，你就不能连接到交换板中，并收到 913 错误，而不是 XFR 应答。

 

交换板服务器

 

现在，客户端必须创建一个 TCP 连接到指定 IP 及端口（不要关闭 NS 连接）。客户端可以等待至少 2 分钟，而连接到交换板还很安全。

一旦连接到交换板，客户端必须发送 USR 命令，它包含事务 ID ，帐号及认证串。这个命令必须在约一分钟内发送，否则交换板将断开连接。

如果成功的话，服务器将用 USR 响应，并包含事务 ID 、 OK 、你的帐号及显示名。

. 如果账号与认证串之一（或全部）不正确，服务器将响应 911 错误，并关闭连接。

. 如果格式不正确，服务器将立即关闭连接，不响应错误。

. 如果用正确的认证串尝试错误的交换板服务器（不同ＩＰ），将被立即断开，不响应错误。

. 如果已经用此认证串登录到交换板服务器，还尝试登录，将收到 911 错误，并断开。注意你可以同时连接多个交换板，但你需要发送多个 XFR ，然后根据一个连接一个。

示例：（正确登录）



Client Connects to 207.46.108.37 1863 (Switchboard)


>>> USR 1 ..32308/r/n

<<< USR 1 OK Example%20Name/r/n



Continue SB Session . . .


示例（不正确）：



Client Connects to 207.46.108.37 1863 (Switchboard)


>>> USR 1 ..32307/r/n

<<< 911 1/r/n



Switchboard Closes Connection


你已经连接到交换板，现在邀请他人加入吧。

5.1.3.
       被邀请到交换板会话中

通知服务器

 

当一个联系人邀请你加入一个交换板会话，你会收到通过 NS 发送的 RNG 命令，官方客户端将自动连接到一个交换板会话中，并且如果直到文本消息被发送对话框才会打开，但第三方的客户端能选择不同行为。

RNG 不带事务 ID ，带 6 个参数：

. 第一个参数是新的交换板会话的 session ID 。每个交换板会话都有一个唯一 ID ，每个被邀请的联系人使用同一个 session ID 。你需要拿 ID 与交换板进行认证。

. 第二个参数是交换板服务器的 IP 及地址（冒号分隔）

. 第三个参数是认证类型，总会是 CKI 。

. 第四个参数是认证串，与交换板认证是需要用到。

. 第五个、第六个参数是邀请你的联系人的账号及 URL 编码的显示名。

示例：

<<< RNG 207.46.108.38:1863 CKI . Example%20Name/r/n

客户端不响应此命令，而是根据第二个参数打开一个到指定 IP 及端口的连接。

 

交换板服务器

 

由于 XFR 的原因，你应该在两分钟内打开一个 TCP 连接到服务器以接收 RNG 命令。首先你应该发送 ANS 命令，它包含事务 ID 及 3 个参数：账号名、认证串及交换板会话 ID 。

如果成功的话，服务器将响应一个或多个 IRO ，最后跟随一个 ANS ，但毕竟还有很多事情会导致错误发生：

. 如果你连接，但没有发送 ANS ，交换板将在约 1 分钟后关闭连接，且不含任何错误。

. 如果接收 RNG 一分钟内你没有连接，交换板将关闭连接，在 ANS 前不包含任何错误。

. 无论怎样，只要会话 ID 错误，将立即断开，不含错误。

. 如果你发送一个不存在的或者非法的账号，并且（或者）不正确的认证串， 911 错误，服务器将关闭连接。

. 如果 ANS 语法错误，立即断开，没有错误

. 连接到错误的交换板，并尝试认证，断开并不含错误。

. 你（或攻击者）已经连接并认证，再次认证，将得到 911 错误，交换板将关闭连接。

. 如果交换板会话中的联系人在你连接并发送 ANS 前离开，交换板会话将在你进入前撤销，因此你 ANS 发送后也将被断开且不含任何错误。

已在交换板中的参与者被发送 IRO 命令，可能作为初始名册。每个参与者将收到一个 IRO 。注意你，已经进入，但并不包含在这个名单内。 IRO 包含 ANS 中同样的事务，并且有 4 个参数：

. 第一个参数表示当前 IRO 为列表中的第几个。第一个 IRO 命令中为 1 ，第二个中为 2 ，依次类推。

. 第二个参数是 IRO 命令总数。

. 第三个参数是参与者的账号

. 第四个参数是参与者的显示名，如果自从加入会话板后，参与者修改了他们的显示名，这个参数将过期。

由于交换板给你的显示名可以是过期的，你应该使用尽可能使用 NS 给你的显示名。

收到最后一个 IRO 后（增加数同总数同），你将收到 ANS ，事务 ID 与你发送的相同，并携带参数 OK 。收到此命令后，你将正式进入交换板会话，可以收发消息了。

如下，是交换板的认证，并且找到了两个参与者（总共 3 人）：



Client Connects to 207.46.108.38 1863 (Switchboard)


>>> ANS 1 . /r/n

<<< IRO 1 1 2 Mike/r/n

<<< IRO 1 2 2 My%20Name/r/n

<<< ANS 1 OK/r/n



Continue SB Session . . .


5.2.
        杂项

5.2.1.
       邀请参与者

如果没有被当前的一个参与者邀请的话，一个联系人不能进入一个交换板会话中。任何参与者，不一定是会话的创建者，都可以邀请其他联系人。不知道一个交换板中最多可以有多少人，但很可能大于 30 。过去的限制为 5 人。

你可以邀请同一个联系人到不同的交换板中 — 如，在一个中交谈，另外一个中传输文件。然而，官方客户端将尝试在单个窗口中处理所有的会话，可能导致结果有些混乱。如果你有一个以上的会话需要选择，你应该总是发送消息到最后收到消息的会话中。

 

CAL

 

邀请一个联系人到交换板会话中，就需要发送 CAL 命令，它包含事务 ID 还有要邀请的账号。

如果成功的话，服务器将用 CAL 加刚才的事务 ID 响应，同时 RINGING 作为第一个参数，交换板的会话 ID 作为第二个参数。注意这只不过是邀请某人的一个确认 — 这个联系人还没有加入会话中。稍后，我们就知道还需要 JOI 命令。当然，会话 ID 对于客户端来说并不重要，对于每个被邀请的联系人来说他们是相同的。

下列情况将会导致 CAL 命令错误：

. 如果你尝试邀请已在会话中的联系人（包括你自己）， 215 错误。这个错误同样会在对方已经被邀请或者被另外的参与者邀请但还没有加入时产生。

. 如果格式不正确（如太少或者太多参数），将被交换板立即断开。然而对于交换板其他的事实是， NS 不被通知，而且 NS 的连接仍旧会保持打开着。

. 如果账号非法，如 @@a ， 208 错误，但仍保持连接。

. 如果联系人离线或者账号名不存在（比如说 myname@hotmail ）， 217 错误，但不会断开连接。

. 如果你尝试邀请的联系人虽然在线但阻止了你，或者 BLP 设置为 AL 但你不在对方的 AL 中， 216 错误。不会被断开。

. 如果重复邀请已经阻止你的联系人，你将收到 713 错误。

示例：

>>> CAL 2 /r/n

<<< CAL 2 RINGING /r/n

>>> CAL 3 /r/n

<<< 217 3/r/n

>>> CAL 4 /r/n

<<< 217 4/r/n

>>> CAL 5 @@a/r/n

<<< 208 5/r/n

>>> CAL 5 /r/n

<<< 216 5/r/n

>>> CAL 5 /r/n

<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 713 5/r/n

发送 CAL 的人才会看到这些来往的 CAL 命令还有错误。当制定的联系人加入会话时，每个联系人将受到一个 JOI 命令。

 

JOI

 

如果 CAL 成功，指定的联系人将收到 NS 发送的 RNG 命令，如果他们连接到交换板并认证的话，他们将加入到会话中，一旦发生，每个会话中的联系人（除了刚被加入的）将被发送 JOI 命令。

JOI 命令不包含事务 ID 。第一个参数是刚进入会话的联系人的账号，第二个参数是他的显示名（ URL 编码），示例：

<<< JOI Name_123/r/n

 

5.2.2.
       退出交换板会话

要离开交换板，客户端应该发送 OUT 命令，并且不需要挟带事务 ID 及任何参数。交换板将关闭连接并从会话中把你去除。断开连接但没有发送 OUT 命令，效果是相同的。示例：

>>> OUT/r/n



Switchboard Closes Connection


当一个参与者离开会话，其他参与者（如果还有的话）将收到 BYE 命令，不带事务 ID ，包含刚离开的联系人的账号。示例：

<<< BYE /r/n

 

空闲会话

 

如果你是会话中唯一的一个参与者（或者你没有邀请别人或者其他人都已经离开），交换板将在 5 分钟后关闭连接。关闭连接前，服务器不会发送任何命令。

如果会话中有两个人，但互相间有 5 分钟没有发送任何命令，交换板将给两人都发送 BYE 命令，显示对方离开并立即关闭连接。然而 BYE 命令在账号后包含一个附加参数，值为 1 ，表示交换板是由于发呆而被关闭的。示例：

<<< BYE 1/r/n



Switchboard Closes Connection


会话中 3 个及以上人员的情况同 2 个的类似，除了发呆期间延长为 15 分钟，并且你只将收到一个参与者的 BYE （随机选择）。

 

官方客户端

 

无论使用官方客户端的用户何时关闭了打开交换板的消息窗口，它将断开与交换板的连接。 3 个及以上的参与者的会话，如果有一个人离开官方客户端都会通知你，但如果为 2 个的话，不会通知。

 

与 NS 的关系

 

由于交换板服务器与 NS 结合并不十分紧密，一个联系人可以退出了 NS ，但仍然在一个或多个交换板会话中。官方客户端退出 MSN Messenger 时，首先对每个会话板发送 OUT 命令，然后才 OUT NS 。

5.3.
        消息

5.3.1.
       概述

    在交换板会话中 MSG 是发送消息给其他联系人仅有的方法。每个发送给会话的消息都会转而发送给会话中其他的人。 MSG 可以是即时会话，类型通知，应用邀请，或者任意类型（只要你想发送的话）— 但并不是所有客户端都会识别所有类型。

5.3.2.
       输出消息

发送消息到交换板，需要发送 MSG 命令

. 必须有一个事务 ID

. 第一个参数是你希望收到的确认类型，可以为 U ， N 或者 A 。如果为 U ，你将收不到任何确认。如果为 N ，你仅在消息没有正确被接收时得到确认。如果为 A ，不管被接收成功与否，都会得到确认。该参数是大小写敏感的（必须为大写，否则交换板将关闭连接，并不发送消息）。确认将叙述如后。

. 第二个参数是有效载荷的长度。

.MSG 的有效载荷在新行后，有效载荷可以为 0 字节长。

. 一个消息最多可达 1664 字节长（ 2003 年 4 月 30 日 ），再长的话，交换板将关闭连接，且不会发送消息。有趣的是： 1664=13*2^7 。许多迷信的人认为 13 是一个不吉利的数字， 7 是一个吉利数字。……

示例：

>>> 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 或 NAK 响应，他们包含事务 ID 及外出消息 MSG 。 ACK 意味着所有接收者接收成功。 NAK 意味着一个或多个参与者不能正确接收消息。如果交换板会话中只有你的话， NAK 将被发送。

如果确认参数设置为 A ，则成功的话返回 ACK ，否则 NAK 。与协议草案中暗示的相反，类型 A 工作着，并且正确与否都会回应。如果为 N 仅当不成功时才会收到消息，且为 NAK 。如果为 U ，不会有任何确认。

示例：

>>> 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

官方客户端用 N 发送即时消息 (text/plain) ， U 发送键入通知（ text/x-msmsgscontrol ）， N 发送应用邀请。

5.3.3.
       来报

来报的格式已经在有效载荷命令中叙述了，第一个参数是发送人的帐号，第二个参数是发送人的显示名（注意加入会话后变更显示名，仍将为原名），第三个参数是有效载荷的长度。

示例

<<< MSG 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?

按照长度解析来报长度非常重要！消息就像其他命令一样，可能被分割到若干包中，然后与其他命令合成一个包。现在知道长度有多重要了吧。

5.4.
        会话示例

5.4.1.
       概述

本节演示了交换板会话的整个过程，至少看上去是这样的。有两个例子：第一个是来报 RNG ，第二个是外出的 XFR 。

 

约定

 

本节示例都是从 Alice 的客户端（ ）角度看的。

5.4.2.
       示例 1

通知服务器

 

另外一个联系人（ ）邀请 Alice 加入一个会话，当前会话中已经有两个人： Bob 与 Carol 。

<<< RNG 207.46.108.78:1863 CKI .26158 Bob/r/n

保持打开 NS 连接， Alice 的客户端按指定服务器又打开一个新连接。现在开始 NS 不会影响 SB ，反之亦然。

 

交换板

 

Alice 的客户端连接服务器 207.46.108.78:1863 ，然后发送认证信息

>>> ANS 1 .26158 /r/n

认证成功，服务器发送参与者名单，并以 ANS 应答来确认。

Bob 输入了一条信息并发送，这个信息是以 Lucida Sans Unicode 字体写的，并加粗，颜色为绿色。

<<< MSG Bob 89/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgscontrol

/r/n

    TypingUser:

/r/n

   

/r/n

   

/r/n

<<< MSG Bob 143/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/plain; charset=UTF-8

/r/n

    X-MMS-IM-Format: FN=Lucida%20Sans%20Unicode; EF=B; CO=ff0000; CS=0; PF=22

/r/n

   

/r/n

    Hello.

Alice 输入消息，然后发送，消息以 MS Sans Serif 字体，黑色书写，并没有其他效果。

<<< MSG 2 U 91/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgscontrol

/r/n

    TypingUser:

/r/n

   

/r/n

   

/r/n

>>> MSG 3 N 127/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/plain; charset=UTF-8

/r/n

    X-MMS-IM-Format: FN=MS%20Sans%20Serif; EF=; CO=0; CS=0; PF=0

/r/n

   

/r/n

    Hi.

Alice 输入了另外一个消息并发送。然而 Carol 网络出了问题，没有收到此消息，所以 Alice 的客户端收到了 NAK ，即使 Bob 收到了消息。 Alice 被通知有一个或多个参与者没有收到消息。

>>> MSG 4 U 91/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgscontrol

/r/n

    TypingUser:

/r/n

>>> MSG 5 N 138/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/plain; charset=UTF-8

/r/n

    X-MMS-IM-Format: FN=MS%20Sans%20Serif; EF=; CO=0; CS=0; PF=0

/r/n

   

/r/n

    Are you there?

<<< NAK 5/r/n

接着 Alice 再次输入消息并发送，但她花费了很长时间输入，所以我们的客户端发送了两次键入通知。这次消息以类型 A （没有特殊原因），每个人都收到， Alice 的客户端收到 ACK 。

>>> MSG 6 U 91/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgscontrol

/r/n

    TypingUser:

/r/n

>>> MSG 7 U 91/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgscontrol

/r/n

    TypingUser:

/r/n

>>> MSG 8 A 139/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/plain; charset=UTF-8

/r/n

    X-MMS-IM-Format: FN=MS%20Sans%20Serif; EF=; CO=0; CS=0; PF=0

/r/n

   

/r/n

    I like turtles.

<<< ACK 7/r/n

Alice 邀请 Dave （ ）， Dave 加入会话。

>>> CAL 8 /r/n

<<< CAL 8 RINGING /r/n

<<< JOI Dave/r/n

Alice 尝试邀请 Ed() ，但他离线了。

>>> CAL 10 /r/n

<<< 217 10/r/n

Alice 尝试邀请 Frank （ ），但他的个人设置及列表设置表明 Alice 不被允许邀请他，尽管他在线。

>>> CAL 10 /r/n

<<< 216 10/r/n

Bob 邀请了 George() ，并加入

<<< JOI George/r/n

Carol 离开

<<< BYE /r/n

15 分钟没有动作，会议超时。

<<< BYE 1/r/n

交换板服务器关闭连接， Alice 的客户端通知 Alice 会议超时终止。

5.4.3.
       示例 2

通知服务器

 

客户端 () 登录到 NS 并成功认证，但由于“显示为脱机”，收到 913 错误。

>>> XFR 7 SB/r/n

<<< 913 7/r/n

Alice 更改了状态为 NLN ，并重新请求。

>>> CHG 8 NLN 0/r/n

<<< CHG 8 NLN 0/r/n

>>> XFR 9 SB/r/n

<<< XFR 9 SB 207.46.108.46:1863 CKI ..29994/r/n

到 NS 仍旧打开，但 Alice 的客户端建立到指定服务器的连接。现在 NS 与 SB 之间不会有什么事情发生了。

 

交换板

 

Alice 的客户端连接到 207.46.108.46:1863 并发送认证信息，认证正确，服务器给出了确认信息。

>>> USR 7 ..29994/r/n

<<< USR 7 OK Alice/r/n

Alice 邀请 Bob() 加入会话并加入

>>> CAL 8 /r/n

<<< CAL 8 RINGING /r/n

<<< JOI Bob/r/n

Bob 想发送一个文件给 Alice

<<< MSG Bob 277/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Application-Name: File Transfer

/r/n

    Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F}

/r/n

    Invitation-Command: INVITE

/r/n

    Invitation-Cookie:

/r/n

    Application-File: turtle.txt

/r/n

    Application-FileSize: 2341

/r/n

   

/r/n

Alice 接收这个文件。

>>> MSG 9 N 182/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: ACCEPT

/r/n

    Invitation-Cookie:

/r/n

    Launch-Application: FALSE

/r/n

    Request-Data: IP-Address:

/r/n

   

/r/n

<<< MSG Bob 244/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: ACCEPT

/r/n

    Invitation-Cookie:

/r/n

    IP-Address: 203.121.147.134

/r/n

    Port: 6891

/r/n

    AuthCookie:

/r/n

    Launch-Application: FALSE

/r/n

    Request-Data: IP-Address:

/r/n

   

/r/n

Alice 的客户端建立到 Bob 的 IP 及端口 6891 的连接，并在当前交换板外进行文件传输。

然而，如果 Alice 的客户端在一段时间内（官方客户端为 30 秒）没有连接的话， Bob 的客户端将停止等待连接，并发送如下消息，提示超时了。

<<< MSG Bob 152/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: CANCEL

/r/n

    Invitation-Cookie:

/r/n

    Cancel-Code: FTTIMEOUT

/r/n

   

/r/n

Alice 邀请 Bob 实用 NetMeeting 会话，然而他拒绝了，并没有更多事情发生。

>>> MSG 10 A 292/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Application-Name: NetMeeting

/r/n

    Application-GUID: {44BBA842-CC51-11CF-AAFA-00AA00B6015C}

/r/n

    Session-Protocol: SM1

/r/n

    Invitation-Command: INVITE

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {60F887C8-A5D0-11D7-A88E-0040F43DB1D9}

/r/n

   

/r/n

<<< ACK 10/r/n

<<< MSG Bob 225/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: CANCEL

/r/n

    Cancel-Code: REJECT

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {CE1ABB0F-D40D-432F-A359-5AEC532CDBC3}

/r/n

    Session-Protocol: SM1

/r/n

   

/r/n

Bob 邀请 Alice 使用白板，但 Alice 没有安装，所以她的客户端以 REJECT_NOT_INSTALLED 自动拒绝了邀请。

<<< MSG Bob 335/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Application-Name: Whiteboard

/r/n

    Application-GUID: {1DF57D09-637A-4ca5-91B9-2C3EDAAF62FE}

/r/n

    Session-Protocol: SM1

/r/n

    Application-URL: http://www.microsoft.com

/r/n

    Invitation-Command: INVITE

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {463CB365-0213-4933-AA8A-D01FAA}

/r/n

   

/r/n

>>> MSG 11 A 216/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: CANCEL

/r/n

    Cancel-Code: REJECT_NOT_INSTALLED

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {60F887CB-A5D0-11D7-A88E-0040F43DB1D9}

/r/n

   

/r/n

<<< ACK 11/r/n

Alice 关闭了会话窗，因此客户端发送了 OUT 。

>>> OUT/r/n

服务器关闭了连接。

6.
         客户端

6.1.
        通知文档

6.1.1.
       概述

MSN Messenger 中通知消息被用来发送时间敏感的事件，如文本信息或者新闻项。不要理会它的名称，实际上它与 NS 没有任何关系。目前，它用来接收 MSN Calendar 与 MSN Alert 的提示，并用来接收 MSN Mobile 的来信。 MSN Calendar 在 2003 年 5 月成为了收费服务，所以这里的讨论过时了。

通知是 UTF 格式的 XML 文档，所以你需要一个现成的 XML 解析库来处理通知。不幸的是，有一些通知格式是不友好的 — 如 URL 中可能包含少数 & 字符（应该被编码为 & ），还有反斜杠， URL 中的 http:// 应该被编码为 http%3a%2f%2f 。我们必须假定服务器产生这些通知时出现了 bug ，但你在编程时就需要十分注意。

并不是所有的通知都有相同的格式，因此，你可以写一个单个复杂程序来处理所有，或者分成多个简单程序处理每种格式。大多数消息变化仅仅影响其中一部分，一旦发送后就没有什么用了（如，联系人离线时发送消息到一个邮件地址），而且很有可能微软将来又有其他变化。官方客户端看起来是在使用一个复杂功能，所以也建议你如此。

迄今为止，开起来 MSN Calendar 、 MSN Alerts 与 MSN Mobile 每一个使用一种不同的通知格式 — 但绝对有可能目前 MSN Calendar 使用了同 MSN Alerts 一样的格式，但毕竟我们所知道的信息已经过期了。 NOTIFICATION 元素中 ver 属性看来被用来标识通知文档格式，但官方客户端不会注意这个属性，所以也不该严格依照上面所述。

6.1.2.
       通知格式

MSN Calendar 的 DTD ：

 

 

 

 

 

 

 

 

    ver         CDATA   #FIXED "1"

    siteid       CDATA   #REQUIRED

    siteurl     CDATA   #REQUIRED

    id           CDATA   #REQUIRED

> 

 

    pid          CDATA #REQUIRED

    name      CDATA #REQUIRED

> 

 

    pri          CDATA #FIXED ""

    id           CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    id           CDATA #REQUIRED

> 

 

    langCDATA #REQUIRED

    iconCDATA #REQUIRED

> 

 

 

MSN Alerts 的 DTD ：

 

 

 

 

 

 

 

    ver         CDATA   #FIXED "2"

    siteid       CDATA   #REQUIRED

    siteurl     CDATA   #REQUIRED

    id           CDATA   #REQUIRED

> 

 

    pid          CDATA #REQUIRED

    name      CDATA #REQUIRED

> 

 

    pri          CDATA #REQUIRED

    id           CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    langCDATA #REQUIRED

    iconCDATA #REQUIRED

> 

 

 

MSN Mobile 的 DTD ：

 

 

 

 

 

 

 

 

 

 

 

    siteid       CDATA   #REQUIRED

    siteurl     CDATA   #REQUIRED

    id           CDATA   #REQUIRED

> 

 

    pid          CDATA #REQUIRED

    name      CDATA #REQUIRED

    email       CDATA #REQUIRED

> 

 

    agent      CDATA #REQUIRED

> 

 

    pid          CDATA #REQUIRED

    name      CDATA #REQUIRED

> 

 

    pri          CDATA #REQUIRED

    id           CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    id           CDATA #REQUIRED

> 

 

    langCDATA #REQUIRED

> 

 

 

一般的通知格式：

 

 

 

 

 

 

 

 

 

 

 

 

    ver         CDATA   #IMPLIED

    siteid       CDATA   #REQUIRED

    siteurl     CDATA   #REQUIRED

    id           CDATA   #REQUIRED

> 

 

    pid          CDATA #REQUIRED

    name      CDATA #REQUIRED

    email       CDATA #IMPLIED

> 

 

    agent      CDATA #REQUIRED

> 

 

    pid          CDATA #REQUIRED

    name      CDATA #REQUIRED

> 

 

    pri          CDATA #REQUIRED

    id           CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    url          CDATA #REQUIRED

> 

 

    id           CDATA #REQUIRED

> 

 

    langCDATA #REQUIRED

    iconCDATA #IMPLIED

> 

 

 

如下将给出每种格式的示例，变量部分用
红色标出。

MSN Calendar



" siteurl="http://calendar.msn.com" id="1">/r/n

 

0x00060000
:0x81ee5a43" name="" />

/r/n

 

1
">

/r/n

   

/calendar/isapi.dll?request=action&operation=modify&objectID=1&uicode1=modifyreminder&locale=2052
"/>

/r/n

   

/calendar/isapi.dll?request=action&operation=modify&objectID=1&uicode1=modifyreminder&locale=2052
"/>

" />

/r/n

    2052" icon="/En/img/calendar.png">

/r/n

     
goto club 7. 2002 21:15 - 22:15

/r/n

   

/r/n

 

/r/n



/r/n

The unusual features of this notification type are:

·       The
ver attribute of the
NOTIFICATION element is set to "1".

·       The
email attribute of the
TO element is missing

·       The
VIA and
FROM elements are missing.

·       The
ACTION element comes before the
SUBSCR element

·       There's a
CAT element

·       The
BODY element has an
icon attribute.

MSN Alerts



" siteid="" siteurl="http://alerts.msn.com">/r/n

 

0x0006BFFD
:0x8582C0FB" name=""/>

/r/n

 

1
" id="">

/r/n

   

http://g.msn.com/3ALMSNTRACKING/ToastChange?http://alerts.msn.com/Alerts/MyAlerts.aspx?strela=1
"/>

/r/n

   

http://g.msn.com/3ALMSNTRACKING/ToastAction?http://alerts.msn.com/Alerts/MyAlerts.aspx?strela=1
"/>

/r/n

    3076" icon="">

/r/n

     
utf8-encoded text

/r/n



/r/n

The unusual features of this notification type are:

·       The
ver attribute of the
NOTIFICATION element is set to "2"

·       The
email attribute of the
TO element is missing

·       The
VIA and
FROM elements are missing.

·       The
SUBSCR element comes before the
ACTION element

·       The
CAT element is missing

·       The
BODY element has an
icon attribute.

MSN Mobile



0
" siteid="" siteurl="http://mobile.msn.com/">/r/n

 

" pid="0x00037ffe:0x82f131c1" email="">

/r/n

   

mobile
"/>

/r/n

 

/r/n

 

0x00037ffe:0x82f131c1
" name=""/>

/r/n

 

1
" id="0">

/r/n

   

2wayIM.asp
"/>

/r/n

   

2wayIM.asp
"/>

/r/n

   

"/>

/r/n

    2057">

/r/n

     
Message

/r/n

     
The following mobile instant message could not be delivered to you via Messenger because you were offline.

/r/n

      From:

/r/n

      Message: Message

/r/n

   

/r/n

 

/r/n



/r/n

The unusual features of this notification type are:

·       The
ver attribute of the
NOTIFICATION element is missing.

·       The
TO element has an
email attribute.

·       There are
VIA and
FROM elements.

·       The
ACTION element comes before the
SUBSCR element

·       There's a
CAT element

·       The
icon attribute of the
BODY element is missing.

·       There's an
EMAILTEXT element

6.1.3.
       说明

对于通知中某些部分，我们也不太了解。有些一旦发送到客户端是明确没有用的（如 To 元素）。

 

NOTIFICATION 元素

 

NOTIFICATION 元素是通知文档的根元素。

.ver 属性（可选），大概是用来标识通知类型： MSN Mobile 中不含该元素， MSN Calendar 中值为 1 ， MSN Alerts 值为 2 。

.id 发送的通知的唯一标识。

.siteid 关联站点的唯一标识。

.siteurl 关联站点的 URL 。

 

TO 元素

 

TO 元素用来指定通知发送给谁。

.pid ，其两值用冒号分隔：初始 profile 中的 MemberIdLow 与 MemberIdHigh 。

.name ，你的 passport 。

.email （可选）大概是你离线时发送到的邮件地址。

 

VIA 元素

 

VIA 元素指出通知已经过的设备。 Agent 属性仅看到过 mobile 值，指示通知经过了 MSN Moblie 设备。

 

FROM 元素

 

指示发送通知的联系人。

.pid 属性与 TO 元素中一致。

.name 属性为发送人的护照。

 

MSG 元素

 

MSG 中包含信息数据。

.pri 属性完成未知功能。

.id 消息的唯一标识。实践中，总是与 NOTIFICATION 元素中 id 属性相同。

 

ACTION 元素

 

ACTION 元素包含了行为页的 URL 部分，其中 url 属性是一个相对或绝对 URL 地址。如果为相对地址（如以 http://,ftp://,https:// 等等开端），需要在 URL 前添加 NOTIFICATION 的 siteurl 属性值。

 

SUBSCR 元素

 

SUBSCR 包含预约 URL 的部分。其中 url 属性可谓相对地址或绝对地址，与 ACTION 元素的属性相同。

 

CAT 元素

 

CAT 元素实现了未知功能， id 为某些未知功能的标识码。

 

BODY 元素

 

其中包含了可发送的信息的不同变体。

.lang 属性是消息文本的 locale ID 。

.icon 属性为图标的相对地址，你可能会显示在信息旁，可以为空。

 

TEXT 与 EMAILTEXT 元素

 

这些元素中真正包含了发送的信息。如果联系人在线，信息位于 TEXT 中，否则 EMAILTEXT 元素中的内容需要发送到 TO 元素的 email 属性地址中。

6.1.4.
       如何使用通知

通知实际上就是一个文本信息，一个行为 URL ，一个预定 URL ，和（可选）发送人的邮件地址。“ action ”与“ subscription ” URL 是客户端允许用户访问的 Web 地址。行为 URL 一般包含更多的通知信息，预定 URL 包含预约选项。

TEXT 元素包含发送的消息， FROM 元素的 name 属性包含发件人的地址， URL 被分到几个属性中。

每个 URL 都基于 SUBSCR 或 ACTION 元素的属性值组成。另外 NOTIFICATION 与 MSG 中的 id 属性也是其中一部分。 URL 如下组成：

base_URL¬ification_id=NOTIFICATION_id&message_id=MSG_id&agent=messenger .

For example, a site with a
siteurl of
http://mysite.com , an action URL of
/script.asp , notification ID of
1 , and a message ID of
2 , the target URL would be
http://mysite.com/script.asp¬ification_id=1&message_id=2&agent=messenger .

 

6.2.
        消息

6.2.1.
       消息类型

官方客户端使用了三种标准类型：即时会话 (text) ，键入类型通知与应用程序邀请。每种不同类型的消息都被头部信息中 Content-Type 唯一标识着。客户端可以发送非官方的类型如加密和特色商议等。官方客户端忽略所有非标准类型的消息，因此所有客户端也应该如此。另外，官方客户端忽略畸形消息：如不带 MIME 头的消息。

6.2.2.
       即时消息 (text/plain)

    即时消息，又被称为文本消息，是 MSN 来往间正规的消息类型。他们以 Content-Type: text/plain 或者 Content-Type: text/plain; charset=UTF-8 （指定了不同的编码方式）被发送。

6.2.3.
       键入通知（ text/x-msmsgscontrol ）

键入通知将会发送给其他参与者，告诉他们你正在键入消息。

. 它使用 Content-Type: text/x-msmsgscontrol ，不必携带 charset=UTF-8

. 它的头部包含一个 TypingUser 字段，内容应该为你的账号。

. 主体仅为一个新行 (/r/n)

示例（仅为有效载荷部分，不是 MSG 行）

MIME-Version: 1.0/r/n

Content-Type: text/x-msmsgscontrol

/r/n

TypingUser:

/r/n


/r/n


/r/n

. 如果用户正在键入信息，官方客户端将每隔 5 秒钟发送一个键入通知。

. 如果官方客户端收到一个键入通知，它将指示那个联系人正在键入信息。收到消息后或者 10 秒没有收到新的键入通知的话，这个提示将被取消。

. 如果某人变更了 TypeingUser 字段，官方客户端将出现一个 Bug ，它将显示那个值，而不是你的显示名。

6.2.4.
       应用邀请（ text/x-msmsgsinvite ）

     应用邀请用来邀请联系人加入应用，如文件传输、音频会话、视频会议、 NetMeeting 、远程辅助、白板、游戏等等。邀请使用 Content-Type: text/x-msmsgsinvite; charset=UTF-8 ，字符集不是可选的。

6.2.5.
       非官方的消息类型

    如果你要编写一个自己的 MSN Messenger 客户端，你可以发送任意的消息类型，当然那这些会被官方客户端所忽略。如果要这样做，建议对你的消息类型写一个详细描述，以便其他人也可以使用它。

6.3.
        纯文本消息

6.3.1.
       概述

    文本消息，又称为即时消息，是联系人之间发送的常规信息。发送一个文本消息，指示客户端接收，并显示，可选择携带一些简单格式。

6.3.2.
       消息格式

Content-Type 字段

 

文本消息以
Content-Type: text/plain 发送，默认为 ISO 8859-1 编码。
Content-Type: text/plain; charset=UTF-8 ， UTF-8 编码。如果创建了其他类型的字符集（比如 charset=iso-8859-15 ），官方客户端将不会显示， ISO-8859-1 与 UTF-8 在基础知识的连接节中有描述。

 

X-MMS-IM-Format 字段

 

指出了消息格式，如字体、颜色等。这个字段是可选的。如果忽略，客户端按默认格式显示。

 

Body

 

文本消息的主体就是纯文本 — 没有特殊字符，转移字符等。如果你的客户端收到 ISO 8859-1 格式的信息，可能需要转换为 UTF-8 。

手工添加新行或者空行，需要添加 /r/n ，单个的 /r 或者 /s 将造成不可预知结果。

图释可能会包含在纯文本信息中，他们将以文本形式表现。如笑脸应该为“ :) ”，不需要任何特殊代码。

 

信息示例

 

两行信息及 UTF-8 编码

MIME-Version: 1.0/r/n

Content-Type: text/plain; charset=UTF-8

/r/n

X-MMS-IM-Format: FN=Arial; EF=I; CO=ff0000; CS=0; PF=22

/r/n


/r/n

Hello!

/r

How are you?

ISO 8859-1 编码，两行，没有格式选项，带一个图释

MIME-Version: 1.0/r/n

Content-Type: text/plain

/r/n


/r/n

I'm fine. :)

/r/n

And you?

6.3.3.
       X-MMS-IM-Format 字段

X-MMS-IM-Format 字段值是一列参数。你不要期望这些参数按照固定次序排列，或者包含全部参数。 2003 年夏天的时候，如果 FN 被包含的话，交换板服务器将把它作为第一个，如果不是这样的话，服务器将不发送任何信息并关闭连接。这大概是老版本的官方客户端中字体名有 bug 的原因。

官方客户端总是发送大写的参数名，如果发送小写，或者大小写混杂的参数给官方的话，结果不可预知。但第三方客户端应该大小写都可。

注意：有可能指定字体大小。客户端应该按照用户设置决定字体大小。

 

字体名 (FN)

 

FN 指出了字体的名称，必须为 URL 编码的。如“ MS Sans Serif ”，应该为“
FN=MS%20Sans%20Serif ”，字体名大小写不敏感，但空格必须被 URL 编码。对于其他字符如数字与字母进行编码，结果不可预知。如果客户端不包含指定字体，应该判断 PF 与 CS 参数。基本上，客户端应按照 CS 指定选择可以支持的字体，并且最接近 PF 的指定。如果那些参数都不存在，使用默认字体。

过去使用官方客户端收到消息的字体包含许多 %20 时会有冲突发生。微软已经对 SB 服务器打了补丁，因此如果一个联系人尝试这样做的话，将会被断开连接。

 

效果 (EF)

 

EF 参数指出了可选的风格效果。可能的效果有加粗、斜体、下划线与删除线。每种效果按它的名称的首字符引用。如一段文本需要加粗、斜体。包含参数 EF=IB 或者 EF=BI 。次序不惯间。不知道的效果将被忽略。官方客户端以大写字母发送效果，如果收到小写效果结果不可预知。如果不需要效果，参数为空即可。

 

颜色 (CO)

 

CO 参数指出了字体颜色。许多版本的官方客户端限制你仅能发送一些可选的颜色，实际上指定 1 千 7 百万中颜色是可能的（ 24-bit 颜色）。 CO 字段的值是六个十六进制 BGR 串 (blue-green-red ，与 HTML 标准的 RGB 正好相反 ) 。头两个十六进制的值在 00 到 ff 间，为蓝色的强度，接着是绿色，然后是红色。如要全红的话，就是 CO=0000ff 。

官方客户端总是发送小写十六进制字母，大写也无所谓。官方客户端将外出的信息中删除前置 0 ，如 0000ff 就会变为 ff ，但都是合法的。黑色将被表示为单个 0 。其他情况，如 7 个字符的串，或者异常字符将导致不可预知错误。

 

字符集 (CS)

 

“ character set ”非常不明确。 Content-Type 字段中的 charset=UTF-8 与 X-MMS-IM-Format 字段中的 CS 意义完全不同。

字符集，最为 X-MMS-IM-Format 中的一部分时，指示的是一个字体应该知道如何转换到屏幕显示的字符集。主要应用于 Windows 中，在 Unicode 被广泛应用前的中间产物。一个字体必须支持一种字符集，但可以支持多于一种，如 Wingdings 指示 Symbol 字符集， Verdana 支持 Western ， Greek ， Turkish ， Central European 与 Cyrillic 字符集。关于字符集的说明见 MSDN 页： http://msdn.microsoft.com/library/en-us/gdi/fontext_89gz.asp 。

CS 参数中的字符集用一或两个十六进制数标识（前置 0 被官方客户端去掉并忽略），下面是 Windows 中预置的全部字符集列表：

0
-
ANSI_CHARSET

ANSI characters

1
-
DEFAULT_CHARSET

Font is chosen based solely on name and size. If the described font is not available on the system, Windows will substitute another font.

2
-
SYMBOL_CHARSET

Standard symbol set

4d
-
MAC_CHARSETLT

Macintosh characters

80
-
SHIFTJIS_CHARSET

Japanese shift-JIS characters

81
-
HANGEUL_CHARSET

Korean characters (Wansung)

82
-
JOHAB_CHARSET

Korean characters (Johab)

86
-
GB2312_CHARSET

Simplified Chinese characters (Mainland China)

88
-
CHINESEBIG5_CHARSET

Traditional Chinese characters (Taiwanese)

a1
-
GREEK_CHARSET

Greek characters

a2
-
TURKISH_CHARSET

Turkish characters

a3
-
VIETNAMESE_CHARSET

Vietnamese characters

b1
-
HEBREW_CHARSET

Hebrew characters

b2
-
ARABIC_CHARSET

Arabic characters

ba
-
BALTIC_CHARSET

Baltic characters

cc
-
RUSSIAN_CHARSET_DEFAULT

Cyrillic characters

de
-
THAI_CHARSET

Thai characters

ee
-
EASTEUROPE_CHARSET

Sometimes called the "Central European" character set, this includes diacritical marks for Eastern European countries

ff
-
OEM_DEFAULT

Depends on the codepage of the operating system

不要假定收到消息的客户端会明白所有字符集（ Windows NT 3.51 就包含了极少的字符集）。 MSN Messenger 仅允许你在一个 CS 中指定单个字符集。虽然可以任意指定，但还是建议你选择一种最常用的、可以显示正确的字符集。

 

字库与字间距（ PF ）

 

PF 定义了 FN 参数失败的话使用的字体。经常在客户端没有找到指定字体时使用。值为两位十六进制数，用 Windows API 编程时，在 RichEdit 与 LOGFONT 中是 PitchAndFamily 的值。

头一个数描述了字体库，如下给出了对应列表。 MSDN 中： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_9583.asp 。

0_
-
FF_DONTCARE

指出一个一般库名，
This name is used when information about a font does not exist or does not matter. The default font is used.

1_
-
FF_ROMAN

Specifies a proportional (variable-width) font with serifs. An example is Times New Roman.

2_
-
FF_SWISS

Specifies a proportional (variable-width) font without serifs. An example is Arial.

3_
-
FF_MODERN

Specifies a monospace font with or without serifs. Monospace fonts are usually modern; examples include Pica, Elite, and Courier New.

4_
-
FF_SCRIPT

Specifies a font that is designed to look like handwriting; examples include Script and Cursive.

5_
-
FF_DECORATIVE

Specifies a novelty font. An example is Old English.

第二个数字指出了字间距 — 或者说字间的间隔，或者说可变宽度。

_0
-
DEFAULT_PITCH

Specifies a generic font pitch. This name is used when information about a font does not exist or does not matter. The default font pitch is used.

_1
-
FIXED_PITCH

Specifies a fixed-width (monospace) font. Examples are Courier New and Bitstream Vera Sans Mono.

_2
-
VARIABLE_PITCH

Specifies a variable-width (proportional) font. Examples are Times New Roman and Arial.

PF 示例：

12

Times New Roman, MS Serif, Bitstream Vera Serif

22

Arial, Verdana, MS Sans Serif, Bitstream Vera Sans

31

Courier New, Courier

42

Comic Sans MS

 

右对齐（ RL ）

 

RL 指出了信息是否应该右对齐。为 1 ，则右对齐。如果这个参数值不为 1 ，官方客户端总是忽略该参数。但其他任何值都不会有什么效果，仍保持左对齐。

 

示例

 

·      
X-MMS-IM-Format: FN=MS%20Sans%20Serif; EF=; CO=0; CS=0; PF=22

This

X-MMS-IM-Format
field expresses the MS Sans Serif font with no effects and a black colour.

·      
X-MMS-IM-Format: FN=Comic%20Sans%20MS; EF=S; CO=; CS=0; PF=42

This field expresses the Comic Sans MS font in a dark blue colour, underlined, and bold.

·      
X-MMS-IM-Format: FN=Verdana; CO=ff; EF=UB; PF=22; CS=cc

This field expresses the Verdana font in full red colour, with the strikeout effect, and with a Cyrillic charset. The parameters are in an unusual order, but as long as

FN
is in the front, it's all right.

·      
X-MMS-IM-Format: FN=Courier%20New; EF=; CO=ff00ff; CS=0; PF=31

This field expresses the Courier New font in a bright magenta colour with no effects.

·      
X-MMS-IM-Format: FN=My%20Hebrew%20Font; EF=; CS=b1; PF=00; RL=1

This field expresses a made up font called My Hebrew Font with no specified colour, no effects, a Hebrew charset, and right-alignment.

6.4.
        邀请消息

6.4.1.
       什么是邀请

MSN Messenger 包含一个客户端邀请他们进行频带外的会话机制。如远程协助、 NetMeeting 、文件传输及其他。出于某些原因文件传输的机制与其他邀请类型不同，建议你分开实现。

 

唯一标识

 

唯一标识是一个串唯一标识了某些资源。必须假定同一个标识不会产生两次。 Windows 下，有标准函数产生 Globally Unique Identifiers(GUID) ，格式被严格定义的。然而，这里的标识不必像 GUID 一样—任意串都是可以被接受的，大小写不敏感。如果你没有使用 Windows ，可以把当前时间、网卡的 MAC 地址与随机数，还有你的程序进程 ID 组合为一个标识。

6.4.2.
       文件传输

文件传输出现在官方客户端的版本 3 种，在版本 5 中已经升级，解决了接收进入 TCP 连接有困难的问题（不如在 NAT 防火墙后的那些计算机们）。后续章节中对该协议有详细描述。

 

概述

 

Alice 要发送一个文件给 Bob ，所以她发送一个邀请，这个邀请必须给出文件名及大小。如果 Alice 不能接收进入连接，邀请中应该提及。

Bob 或者接收或者取消文件传输，如果拒绝了，必须给出一个原因（如文件拒绝），如果接受了，由于 Alice 的邀请状态说明她不能接收进入连接，所以他应该在文件传输中作服务器，简单接受就可以了。

如果 Bob 作服务器，商议完毕。否则， Alice 必须发送一个应答接受 Bob 的信息，然后作服务器。

商议最后结束，如果文件传输失败，可能提示超时错误。

指定作服务器的一端必须给出 IP 及端口，且给出本地 IP 及端口。如果 Bob 作服务器，他必须指出 Alice （发送者）将连接到 Bob （接收方）。

 

发送邀请

 

邀请信息以 MSG 命令发送，通过交换板会话， MIME-Version: 1.0 ， Content-Type: text/x-msmsgsinvite; charset=UTF-8 。主体部分为字段集合。通常，字段是任意次序的，不能被识别的字段必须被忽略掉。文件传输中，客户端可能会忽略所有可选字段 — 5.0 以下的官方客户端总是忽略可选字段， 5.0 及以上版本不会这样。除了一个特殊情况：如果你发送了 Connectivity 字段，如果 Sender-Connect 字段存在于应答中的话，就必须进行处理。

官方客户端仅在恰好两人的交换板会话中商议，所以如果邀请者与被邀请者没有共享这样一个会话的话，发送邀请的客户端必须首先创建一个。不必在邀请发送的会话中响应。如，如果 Alice 与 Bob 在一个交换板中， Alice 发送邀请给 Bob ，接着 Carol 进入了这个交换板， Bob 就必须在不同的交换板会话中发送他的应答。

 

协议

 

每个信息包含一个邀请命令，每个命令的次序必须为：

• 1. 邀请者发送INVITE命令
  2. 被邀请者ACCEPT邀请
  3. 如果被邀请者不能提供服务，邀请者ACCEPT
  4. 任一客户端可能发送CANCEL命令，并携带撤销码FTTIMEOUT，如果传输中出现错误的话。如，官方客户端将在30秒内监听接入连接，然后就取消了服务。

头一个信息发送后，任一方都可以在任意时间发送 CANCEL 。其后不应该发送任何信息。

 

命令字段

 

协商中所有信息包含以下字段：

Invitation-Command

消息类型

Invitation-Cookie

1 到 2^32-1 间的随机整数，唯一标识一个协商（ 0 是不合法的）。该值决定了发送 INVITE 的发送方，必须在整个协商中保持一致。

 

INVITE 字段

 

包含以下字段：

Application-Name

类的自然语言描述，可以不同，比如，官方客户端用英语称文件传输为 File Transfer ， Norwegian 中为
Filoverføring ，日语中为
ファイル送信 。这仅应该是为用户描述用 — 如果说应用程序的 GUID 的话，谁会识别呢？

Application-GUID

类的唯一标识。一个类总会有相同的 GUID ，并且不会有第二个类与之相同。严格的说，应该是 CLSID （通常用来标识一个类的 GUID ）。文件传输的 GUID 为 {5D3E02AB-6190-11d3-BBBB-00C04F} ，出于某种原因，官方客户端大小写敏感。

Application-File

发送的文件名

Application-FileSize

要发送的文件的字节长。如果发送中这个值与文件传输中指定值不同，将参照那个值。

Connectivity （可选）

如果客户端知道它不能接收接入连接，它应该发送该字段，并指示值为“ N ”。官方客户端依照初始 profile 决定该值，如果你愿意，也可以让用户自己指定。

 

Cancel 字段

 

CANCEl 命令中只需要一个字段就是 Cancel-Code ，这是撤消的简要原因。你应该看作是任意形式的字符串，官方客户端所使用的有：

FAIL

接收客户端不能识别任意指定的会话协议。

FTTIMEOUT

传输文件时出现错误

OUTBANDCANCEL

发送邀请的交换板窗口被关闭

REJECT

邀请被拒绝

REJECT_NOT_INSTALLED

客户端不支持应用 GUID

TIMEOUT

等待 ACCEPT 超时（或者联系人撤销请求）

 

ACCEPT 字段

 

下面的字段出现在所有的 ACCEPT 命令中

Launch-Application

指示另外的客户端需要（不要）载入一个扩展应用。由于文件传输在官方客户端内部处理，所以这里正常情况下为“ FALSE ”，我们不知道有什么情况需要设置为“ TRUE ”。

提供服务的 ACCEPT 命令应该包含如下字段：

IP-Address

客户端需要连接到的 IP 地址，官方客户端从初始 profile 中得到你的 Internet 网关地址。

IP-Address-Internal （可选）

如果头一个 IP 地址连接失败的话，需要尝试的第二个 IP 地址。最近的版本中官方客户端把你的网卡地址放在此处。

Port

主要的 TCP 监听端口。应该为 6891 。某些版本的官方客户端当你使用了不同地址时行为不一致。与 IP-Address 对应。

PortX （可选）

可选的第二个 TCP 端口。应该为 11178 。这个与 IP-Address-Internal 对应，所以如果你包含 IP-Address-Internal 的话，就需要包含该字段

PortX-Internal （可选）

如果包含该字段，其值必定与 PortX 相同，大概是兼容旧版本的官方客户端吧。

AuthCookie

1 至 2^32-1 间的随机数，标识文件传输会话中发送的文件（一旦有两个文件同时发送的话）

Sender-Connect （可选）

通常，接收文件的计算机连接到发送者方，如果发送者需要连接到接收者（如：发送者处在防火墙后）。

 

邀请示例

 

下面是两个客户端间成功文件传输邀请的示例，并支持改良的邀请方法。

>>> MSG 12 N 294

    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
   
    Application-Name: File Transfer
    Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F}
    Invitation-Command: INVITE
    Invitation-Cookie: 85366
    Application-File: Autoexec.bat
    Application-FileSize: 187
    Connectivity: N

<<< MSG Bob 306

    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
   
    IP-Address: 81.99.77.64
    IP-Address-Internal: 10.5.1.3
    Port: 6891
    PortX: 11178
    AuthCookie:
    Sender-Connect: TRUE
    Invitation-Command: ACCEPT
    Invitation-Cookie:
    Launch-Application: FALSE
    Request-Data: IP-Address:

两个客户端间文件传输成功的邀请，但不支持更新的邀请方法，而且传输出现问题：

>>> MSG 4 N 277

    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
   
    Application-Name: File Transfer
    Application-GUID: {5D3E02AB-6190-11d3-BBBB-00C04F}
    Invitation-Command: INVITE
    Invitation-Cookie: 33267
    Application-File: readme.txt
    Application-FileSize: 60904

<<< MSG Tim 179

    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
   
    Invitation-Command: ACCEPT
    Invitation-Cookie: 33267
    Launch-Application: FALSE
    Request-Data: IP-Address:

>>> MSG 4 N 238

    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
   
    Invitation-Command: ACCEPT
    Invitation-Cookie: 33267
    IP-Address: 10.44.102.65
    Port: 6891
    AuthCookie: 93301
    Launch-Application: FALSE
    Request-Data: IP-Address:

>>> MSG 4 N 151

    MIME-Version: 1.0
    Content-Type: text/x-msmsgsinvite; charset=UTF-8
   
    Invitation-Command: CANCEL
    Invitation-Cookie: 85366
    Cancel-Code: FTTIMEOUT

 

6.4.3.
       其他邀请类型

    本节将讨论除文件传输外，其他邀请的运行机制。官方客户端允许第三方的应用程序注册为邀请类型（如游戏“ MechWarrior Mecenaries ”）。如果你写了一个应用，并希望官方客户端支持你的邀请类型，查阅 MSDN’s Messenger API documentation ： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/messenger/messenger_entry.asp 。

 

概述

 

Alice 想与 Bob 协商一个会话，就需要发送一个邀请，这个邀请必须指出邀请类型（如 voice conversation ），并且能包含 Bob 需要知道的特定信息（如 Alice 的计算机支持的音频会话协议）。

Bob 或者接受或者拒绝邀请。如果接受，应答中必须包含他的 IP 地址，必须包含 Alice 的 IP 地址，并可以包含 Alice 需要的一些信息（如他选择的音频协议）。如果拒绝，应答中必须给出原因（比如语音传输不被支持）。

Alice 接收了 Bob 的应答，并发送信息。她的应答必须包含她的 IP 。

依据邀请类型， Bob 可能会根据上下文发送最终信息。

协商结束。

 

发送邀请

 

每个邀请都作为交换会话中的 MSG 命令发送， MIME-Version: 1.0 ， Content-Type: text/x-msmsgsinvite; charste=UTF-8 。内容主体部分是若干字段，同样没有次序限制，不能识别的字段应该被忽略。客户端必须做好可选字段不存在的准备，与文件传输不同，客户端必须处理可选字段，如果他们被发送的。

官方客户端只在有两个人的交换板会话中进行协商，所以如果邀请者与被邀请者没有共享一个私有会话，发送邀请的客户端就必须首先创建一个。没有必要在发送邀请的会话中应答。如，如果 Alice 与 Bob 在一个交换板中， Alice 发送了一个邀请，这时 Carol 进入了这个交换板， Bob 就必须在另外的交换板会话中进行应答。

如果你希望在同一个会话中邀请两个人，你应该发送两个单独的邀请。

 

协议

 

每条信息包含一个“邀请命令”，必须按以下序列发送：

1 、邀请者发送 INVITE

2 、被邀请者发送 ACCEPT

3 、邀请者打开监听，然后 ACCEPT

4 、邀请者发送一些 Context （仅某些邀请类型时）

第一个消息发送后， CANCEL 可以在任意部分任意时间发送。

 

一般字段

 

所有邀请包含以下字段

Invitation-Command

消息类型

Invitation-Cookie

1 至 2^32-1 之间的整数，唯一表示一个商议（ 0 为非法 Cookie ），该值被发送者的 INVITE 所确定，在整个协商期间内保持一致。官方客户端随意选择 Cookie 。

Session-ID

当前 MSN Messenger 客户端的唯一标识，该值指出了一个特定客户端的特定实例 — 每个客户端每次运行时都会产生一个新会话 ID ，并在整个生存期内使用同一个会话 ID ，直到程序结束。如果客户端退出，然后又重新进入，应该继续使用同一个会话 ID 。

 

INVITE 字段

 

包含以下字段：

Application-Name

类的自然语言描述，可以是不同的，如官方客户端在 English 中称文件传输为 File Transfer ， Norwegian 中称
Filoverføring ，日语中为
ファイル送信 。这仅应该是为用户描述用 — 如果说应用程序的 GUID 的话，谁会知道是什么呢

Application-GUID

类的唯一标识，抛开名称不管，这可以作为以上讨论的任何标识。一个类总会只有一个应用程序 GUID ，不会存在第二个类也使用该 GUID 。严格的说，更应该是 CLSID 。与文件传输不同， GUID 大小写敏感。

Application-URL （可选）

下载指定应用的 URL ，一个应用总会有相同的 Application-URL 。如果 Application-GUID 不能被识别，客户端就需要建议用户防卫该 URL 。注意：绝对不要自动调入该 URL ，因为一个攻击者可能会利用该功能载入一个页，然后利用浏览器的 Bug 。

Session-Protocol

会话协议，应该被客户端所支持，官方客户端仅支持 SM1 。

Context-Data （可选）

特定目的的串（如协商协议的详细资料）

 

CANCEL 字段

 

CANCEL 命令仅需要一个额外字段 Cancel-Code ，其中简要描述了撤销原因，你应该按任意格式的字符串对待，但官方客户端中会使用以下值：

FAIL

接收方不能解析你的邀请信息（如某些特定会话协议）

OUTBANDCANCEL

发送邀请信息的窗口被关闭。

REJECT

拒绝

REJECT_NOT_INSTALLED

应用未安装

TIMEOUT

超时（或者撤销了邀请）

 

第一个 ACCEPT 字段

 

第一个 ACCEPT 命令包含以下字段：

Session-Protocol

选用的会话协议（从 INVITE 消息中的列表中获得）。如果没有可以接受的协议，邀请将以 cancel-code 为 FAIL 被撤消。

Context-Data （可选）

特定目的串（如协商协议的详细资料）

Launch-Application

指示对方需要（不要）调入一个扩展程序。通常为“ TRUE ”，不知道什么时候可以为“ FALSE ”。

Request-Data

这个字段的值必须为“ IP-Address: ”，请求对方发送它的 IP 地址。

IP-Address

将作为客户端的 IP 地址（端口号可选）

 

第二个 ACCEPT 字段

 

包含以下字段

Launch-Application

指示对方（不）调入一个扩展，通常为“ TRUE ”，不知道什么情况可以设置为“ FALSE ”。

IP-Address

将作为服务器的 IP 地址（端口号可选）

 

Context 字段

 

Context 命令中包含：

Context-Data

特定目的串（如协商协议的详细资料）

 

邀请示例

 

下面从被邀请者角度，示范一个成功音频会话邀请过程：

>>> MSG Bob 353/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Application-Name: voice conversation

/r/n

    Application-GUID: {02D3C01F-BF30-4825-A83A-DE7AF41648AA}

/r/n

    Session-Protocol: SM1

/r/n

    Context-Data: Requested:SIP_A,;Capabilities:SIP_A,;

/r/n

    Invitation-Command: INVITE

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {CD482FDC-AE24-3574-C2A5-AD94D1}

/r/n

   

/r/n

<<< MSG 16 N 319/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: ACCEPT

/r/n

    Context-Data: Requested:SIP_A,;

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {A8B34C0E-2EEF-932F-F120-F7492E39CDA9}

/r/n

    Session-Protocol: SM1

/r/n

    Launch-Application: TRUE

/r/n

    Request-Data: IP-Address:

/r/n

    IP-Address: 203.122.147.102

/r/n

   

/r/n

>>> MSG Bob 242/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: ACCEPT

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {CD482FDC-AE24-3574-C2A5-AD94D1}

/r/n

    Launch-Application: TRUE

/r/n

    IP-Address: 203.122.147.102:13455

/r/n

   

/r/n



Connect to 203.122.147.102:13455 . . .
/r/n

下例中，由于被邀请者没有安装音频，音频会话邀请失败：

    MIME-Version: 1.0/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Application-Name: Remote Assistance

/r/n

    Application-GUID: {56b994a7-380f-410b-9985-c809d78c1bdc}

/r/n

    Session-Protocol: SM1

/r/n

    Application-URL: http://www.microsoft.com

/r/n

    Invitation-Command: INVITE

/r/n

    Invitation-Cookie:

/r/n

    Session-ID: {DF93A302-30D2-DF92-C392-FDB9EA}

/r/n

   

/r/n

<<< MSG 7 N 162/r/n

    MIME-Version: 1.0

/r/n

    Content-Type: text/x-msmsgsinvite; charset=UTF-8

/r/n

   

/r/n

    Invitation-Command: CANCEL

/r/n

    Invitation-Cookie:

/r/n

    Cancel-Code: REJECT_NOT_INSTALLED

/r/n

   

/r/n

 

 

6.5.
        邀请类型

6.5.1.
       概述

     许多 Messenger 相关协议被称为邀请，本节描述了协商特定协议时一些邀请类型。协议中需要你发送“ IP-Address: IP:port ”而不是仅仅“ IP-Address: IP ”，其描述为“ IP-Address port ”。

6.5.2.
       共享应用

共享应用是我们不能理解的某种基于 HTTP 的 SOAP 应用。仅针对微软来说，基于某些原因，不带端口号的 IP 地址在第一个 ACCEPT 信息中发送， Context 中也发送同样的 IP ，但带上了端口号。

Application-GUID

{F1B1920C-6A3C-4ce7-B18C-AFAB305FD03D}

Application-URL

http://www.microsoft.com

Context Context-Data

让对方连接用的 IP 及端口号。仅观察到过 10337 端口。

6.5.3.
       Baldur’s Gate 2

在官方客户端中被错拼为 Baulder’s Gate2 ，在互动娱乐中为一个角色扮演游戏。端口号没有在 IP-Address 中指定，但它总是 47624

Application-GUID

{8DAE4336-2B71-11D4-9A6C-00E47}

 

6.5.4.
       MechWarrior Mercenaries

是微软的第一人称射击游戏。

Application-GUID

{41FD0FA-2942-4DC4-B4C5-73D2C55F4C94}

 

6.5.5.
       NetMeeting

MS NetMeeting 是微软提供的音频聊天及共享白板程序。 NetMeeting 使用了 H.323 及 T.120 标准，所以（不要管名称）你可以遵照标准使用任意程序，比如 GnomeMeeting 与 ohphone 支持 H.323 。

协议说明中暗示“ NetMeeting 3.01”，有不同GUID ，但看来没什么不同。

Application-GUID

{44BBA842-CC51-11CF-AAFA-00AA00B6015C}

 

6.5.6.
       远程协助

Windows XP 允许通过官方客户端请求远程协助，这个协议被 XP 的远程协助包所使用，为 RDP5.1 。

Application-GUID

{56b994a7-380f-410b-9985-c809d78c1bdc}

Application-URL

http://www.microsoft.com

Context Context-Data

一个我们不能解释的长串

 

6.5.7.
       音频及视频会话

音频会话及视频会议协商了一个 SIP （ Session Initiation Protocol ）会话。官方客户端使用了内置的 SIP 程序，任何 SIP 程序皆可。 SIP 在 RFC 3261 中定义。音频被引用为“ SIP_A ”，视频被引用为“ SIP_V ”。

Application-GUID

{02D3C01F-BF30-4825-A83A-DE7AF41648AA}

INVITE Context-Data

客户端发送 INVITE 的能力，及对方申请的能力。如音频及视频会话中，应该为“ Requested:SIP_A,SIP_V,;Capabilities:SIP_A,SIP_V,; ”。仅音频的话为“ Requested:SIP_A,;Capabilities:SIP_A,SIP_V,; ”（如果发送端支持视频的话）或者“ Requested:SIP_A,;Capabilities:SIP_A,; ”（如果客户端仅支持音频）。

ACCEPT Context-Data

发送 INVITE 的客户端被请求的能力，如仅音频会话的话，“ Requested:SIP_A,; ”，对于一个音频及视频会话，“ Requested:SIP_A,SIP_V,; ”。

IP-Address port

13455 ， 16253 与 55039 被发现使用过。

 

6.5.8.
       摄像头

摄像头支持（清晰视频聊天）使用了 RFC1889 中定义的“实时协议”。官方的摄像头 GUID 指定中不支持 {
括号。

Application-GUID

2A
23868E-B45F-401d-B8B0-1E16B774A5B7

 

6.5.9.
       白板

    白板是我们不能理解的某种基于 HTTP 的 SOAP 应用。仅针对微软来说，基于某些原因，不带端口号的 IP 地址在第一个 ACCEPT 信息中发送， Context 中也发送同样的 IP ，但带上了端口号。

Application-GUID

{1DF57D09-637A-4ca5-91B9-2C3EDAAF62FE}

Application-URL

http://www.microsoft.com

Context Context-Data

IP address and port (10869) for the other computer to connect to.

 

6.5.10.
    Jedi Knight

Two of Lucasarts' "Star Wars Jedi Knight" games (Jedi Academy and Jedi Outcast) have the same Application-GUID.

Application-GUID

{A5794C17-F586-4941-9906-9AF0F8E62283}

 

6.6.
        文件传输

    虽然文件传输不是 MSN Messenger 协议中的一部分，但在官方客户端中仍被包含并称为“ MSNFTP ”协议。它与 FTP 没有关系，与其他文件传输协议也没有关系。

6.6.1.
       概述

     若干相似条款被 MSNFTP 使用着，这些可能会使你更难理解本节。这里的发送者和接收者分别指的是文件的发送方及接收方。服务器及客户端分别指的是 TCP 连接的建立方及接收方。一个消息被传递，不要同发送一个消息及发送文件混淆。

在请求过程中，消息客户端将决定谁将成为文件传输的服务器及客户端、谁将成为发送者及接收者，被传输的文件叫什么及会话的认证 Cookie 。发送者通常作为服务器，但也可能请求接收者提供服务。

一旦客户端连接服务器， MSNFTP 就像 NS 或 SB 会话中在两个机器间交换命令行。开始，服务器协商协议，接收者给出它的护照及认证 Cookie ，发送方将响应文件大小。然后，发送方将按不定长的二进制块发送文件。接收者可以在任意时间取消传输。

6.6.2.
       建立连接

    在邀请阶段，计算机提供一到两个可连接的 IP 地址及端口。如果仅有一个的话，服务器就会舰艇那个端口，客户端也应该连接到那个端口。如果有两个的话，服务器将监听两个端口，客户端就应该尝试两个地址及端口。一旦连接被建立，两个计算机应该停止尝试建立另外一个端口的连接。

6.6.3.
       二进制数据

本节讨论了二进制数据如何被发送和接收。如果你对二进制已经非常熟了，可以忽略本节。

归根结底，所有计算机的信息都是 0 、 1 序列。一个字节是 8 个 0 、 1 的组合，所以一个字节可以有 256 种（ 2^8 ）不同状态。在基于文本的协议中，如 MSN Messenger ，字节们参照某些标准被解释为字符信息 — 通常为 ASCII 。在一个二进制协议中，字节被解释为其他东西 —　 0 至 255 之间的数字，黑白色间的灰度级别，或者是程序冲突的原因，等等。

最主要的应用是解释为数字，通常为 16 进制而不是 10 进制数。为了方便阅读，这里我们使用的是 10 进制数进行运算。有些程序员习惯用十六进制，因为二进制与十六进制之间转换非常简便。

你应该查看一下编程语言的说明文档，看看是如何处理二进制数据的。许多语言中需要查明描述一个字节与描述一个字符的方式，不要按一种方式处理字节及字符 — 字符“ 0 ”与数值 0 就不相同。 VB 中 Asc(0) 等同于数值 0 ， val(‘0’) 等同于 ASCII 字符 0 。

6.6.4.
       协议 — 正文

协议类似于登录通知服务器的步骤，除了没有事务 ID ，如果任意一方传输了一个非法命令，对方就会关闭连接，也不会传输错误信息。

首先，接收者发送 VER 命令，携带本机所支持的 MSNFTP 协议的版本号，官方客户端仅支持 MSNFTP 。发送者应答 VER 含选定的协议。

然后，接收者传送 USR 加用户名加认证 Cookie ，发送者用 FIL 命令响应并发送文件大小。官方客户端使用邀请阶段使用的大小。

接收者发送 TFR 命令，表示准备好接收了。发送者就发送剩余会话的二进制数据们。

其后，接收者必须发送 BYE 与单个数值参数，参数表示文件传输的结果：

失败，接收者硬盘空间不足

失败，接收者取消传输

失败，发送者取消传输

失败，连接被阻止

成功

成功

作为特例， CCL 应该被发送并且不带任何参数，而不是 BYE 。实践中，仅 BYE 与 CCL 被观察到过。

一旦发送者发送完毕，它应该等待接收者传输一个 BYE 命令，如果发送者一段时间后仍未收到 BYE （官方客户端大约为 1 分钟），它会在会话中传输一个邀请命令“ Invitation-Command: CANCEL ”，并且“ Cancel-Code: FTTIMEOUT ”。然后发送者就可以在任意时间关闭连接了。

6.6.5.
       协议 — 二进制部分

MSNFTP 块由一个头部及一个主体组成。头部指出了文件是否被完全发送，（如果没有的话）块的主体部分的大小，内容包含了指定大小的字节数。

头部为三个字节长，如果文件没有被完全发送，第一个字节将为 0 ，第二个字节为主体长度 — 长度为第二个字节值加上第三个字节 *256 ，所以，如主体中有 2045 个字节（官方客户端的默认长度），第二个字节为 253 ，第三个字节为 7 （ 253+7*256=2045 ）。主体部分包含了指定长度的字节数。一旦文件传输完毕，最后一个块中，第一个字节为 1 ，第二个字节与第三个字节为 0 ，并且主体部分为空。

如泥要传输一个 13 字节长的文件，其中包含“ Hello, world! ”串，整个过程应该是这样的：

1 、产生第一个块

由于有 13 个字节等待传输，因此，头部第一个字节为 0 。

由于文件长度小于 2045 字节，所以仅需要发送一个块，然后计算长度， 13 除以 256 为 0 ，余 13 。所以第二个字节为 13 ，第三个字节为 0 。

文件中的 13 个字节将作为块的主体部分。

第一个块应该是这样的： 0, 13, 0, 72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33

2 、传输第一个块。

3 、检查接收者是否发送了 BYE 或 CCL 信息，如果发送了的话，关闭 Socket 。

4 、产生第二个块

由于有 0 字节剩余，所以为最后一个块

第二个块为： 1, 0, 0

5 、传输第二个块

6 、文件传输完毕。

7 、等待约 1 分钟，看是否接收者是否发送 BYE 或 CCL 命令，然后关闭连接。

6.6.6.
       会话示例

示例中斜体部分表示二进制数据



Incoming Connection on Port: 6891


<<< VER MYPROTO MSNFTP

>>> VER MSNFTP

<<< USR 93301

>>> FIL 13

<<< TFR

>>> 0, 13, 0, 72, 101, 108, 108, 111, 44, 32, 119, 111, 114, 108, 100, 33

>>> 1, 0, 0

<<< BYE

And here is a failed negotiation:



Incoming Connection on Port: 6891


<<< VER MYPROTO



Disconnect


 

6.7.
        错误列表

Below is a detailed list of every error code ever discovered. Some of the commands have never before been encountered, but exist nonetheless. Each error code has details on every way I have seen them used, but it is quite possible that there are missing situations.

200's

200

Invalid syntax

Never before encountered.

201

Invalid parameter

Sent if the command has a parameter that is considered invalid by the server. Setting your status to FLN would be an example.
    >>> CHG 19 FLN 0/r/n
    <<< 201 19/r/n
Also sent if you try to ADD an invalid email address.
    >>> ADD 20 FL a@b a@b/r/n
    <<< 201 20/r/n

205

Invalid principal

Sent if you try to ADD a nonexistent, but valid, account name.
    >>> ADD 21 AL /r/n
    <<< 205 21/r/n

206

Domain name missing

Never before encountered.

207

Already logged in

If the client sends a USR after already logging in, this error will be sent in response.
    >>> USR 20 TWN I /r/n
    <<< 207 20/r/n
    >>> USR 21 TWN S 6b05a0f5b1aa0959e128cfdd513ccf5c/r/n
    <<< 207 21/r/n

208

Invalid principal-name

Sent from the switchboard in reply to a CAL which specifies an invalid account name.
    >>> CAL 2 @@a/r/n
    <<< 208 2/r/n

209

Nickname change illegal

Sent in reply to a REA when there is a blocked word/phrase in the new nickname or when the Passport has not yet been confirmed.
    >>> REA 18 look%20msn/r/n
    <<< 209 18/r/n

210

Principal list full

Sent in response to an ADD command if the FL is already full. The principal will not be added. Currently (as of March 23, 2003), the limit is 150 principals, as doubled from a previous 75.
    >>> ADD 23 FL 0/r/n
    <<< 210 23/r/n

215

Principal already on list

Sent if you try to ADD a principal to a list, but the principal is already in that list.
    >>> ADD 26 AL /r/n
    <<< ADD 26 AL 824 /r/n
    >>> ADD 27 AL /r/n
    <<< 215 27/r/n
Also sent if you try to ADD a principal to your FL in a group that the principal is already in.
    >>> ADD 28 FL 2/r/n
    <<< ADD 28 825 FL 2/r/n
    >>> ADD 29 FL 2/r/n
    <<< 215 29/r/n
Also sent if you try to invite ( CAL ) a principal into a switchboard session that has already been invited and/or is already present.
    >>> CAL 5 /r/n
    <<< CAL 5 RINGING /r/n
    >>> CAL 6 /r/n
    <<< 215 6/r/n

216

Principal not on list

Sent in reply to REM s that try to remove principals that are not in the list. Also sent if you try to remove nonexistent or invalid account names because, naturally, they couldn't be in your list.
    >>> REM 14 FL /r/n
    <<< 216 14/r/n
This error is also sent in reply to invitations to the switchboard ( CAL s) to principals that either have you in their BL or have their BLP settings so that you are automatically in their BL . This is only sent when the principal is on-line, but you're not allowed to know their on-line status.
    >>> CAL 2 /r/n
    <<< 216 2/r/n
Also sent in reply to REA s that try to rename principals that are not in any of your lists.
    >>> REA 48 nickname/r/n
    <<< 216 48/r/n

217

Principal not on-line

This error is sent in reply to invitations to the switchboard ( CAL s) to principals that are currently either offline or appearing offline. This error will also be sent in reply to invitations to nonexistent account names.
    >>> CAL 2 /r/n
    <<< 217 2/r/n
    >>> CAL 3 /r/n
    <<< 217 3/r/n

218

Already in mode

Sent in reply to a GTC or a BLP if it tries to change the mode to the mode it is already in. In other words, if the GTC value is already set to A, and the client sends the GTC command setting it to A again, it will receive this error.
    >>> GTC 15 A/r/n
    <<< GTC 15 150 A/r/n
    >>> GTC 16 A/r/n
    <<< 218 16/r/n

    >>> BLP 17 BL/r/n
    <<< BLP 17 151 BL/r/n
    >>> BLP 18 BL/r/n
    <<< 218 18/r/n

219

Principal is in the opposite list

Send in reply to an ADD that causes the same principal to be in the BL and the AL at the same time. Obviously, that cannot be possible, and the principal will not be added.
    >>> ADD 15 AL /r/n
    <<< ADD 15 AL 108 Mike/r/n
    >>> ADD 16 BL /r/n
    <<< 219 16/r/n

223

Too many groups

Sent if you try to add a group ( ADG ) so that you have more than 30 groups (the maximum). The group with the ID of zero counts toward the limit.
    >>> ADG 38 thirtyfirst%20group 0/r/n
    <<< 223 38/r/n

224

Invalid group

Sent if you try to ADD a principal to your FL with a nonexistent group ID. Also sent in reply to REM s to nonexistent groups. Also sent in reply if you try to remove ( RMG ) or rename ( REG ) a nonexistent group.
    >>> RMG 24 15/r/n
    <<< RMG 24 12065 15/r/n
    >>> ADD 25 FL 15/r/n
    <<< 224 25/r/n
    >>> REM 26 FL 15/r/n
    <<< 224 26/r/n
    >>> RMG 27 15/r/n
    <<< 224 27/r/n
    >>> REG 28 15 New%20Name 0/r/n
    <<< 224 28/r/n

225

Principal not in group

Sent if you try to remove ( REM ) a principal from an existent group that they are not currently in.
    >>> REM 27 FL 3/r/n
    <<< 224 27/r/n

229

Group name too long

Sent if you try to add a group ( ADG ) with more than 61 bytes in the name.
    >>> ADG 50 this%20group's%20name%20is%20sixty%20two%20bytes%20in%20length 0/r/n
    <<< 229 50/r/n

230

Cannot remove group zero

Sent if you try to remove ( RMG ) the group with the ID of zero.
    >>> RMG 28 0/r/n
    <<< 230 28/r/n

231

Invalid group

Never before encountered.

280

Switchboard failed

Never before encountered.

281

Transfer to switchboard failed

Never before encountered.

300's

300

Required field missing

Never before encountered.

302

Not logged in

Never before encountered.

500's

500

Internal server error

When the MSN servers are down, this might be sent in reply to your command to the NS containing your digested password. The official client interprets this as "Service Temporarily Unavailable". This error might also be sent if your account has banned from MSN.
    >>> USR 28 TWN S 1938acd78b5524ce56a0ab6a01f3239/r/n
    <<< 500 28/r/n

501

Database server error

Never before encountered.

502

Command disabled

Sent if you try to use a command associated with an MSN Messenger feature that no longer exists.
    >>> FND 3 fname=Bill lname=Gates city=* state=* country=US/r/n
    <<< 502 3/r/n

510

File operation failed

Never before encountered.

520

Memory allocation failed

Never before encountered.

540

Challenge response failed

Sent in response to a QRY that is invalid. The server will close the connection after sending the error.
    <<< CHL 0 /r/n
    >>> QRY 10 32/r/n
        4f2f5a91b72102cd28355e9fc9000d6e
    <<< 540 10/r/n

600's

600

Server is busy

Never before encountered.

601

Server is unavailable

Can be sent in reply to the initial USR to the NS if the server is somehow "unavailable".
    >>> USR 10 TWN I /r/n
    <<< 601 10/r/n

602

Peer nameserver is down

Never before encountered.

603

Database connection failed

Never before encountered.

604

Server is going down

Never before encountered.

605

Server unavailable

Never before encountered.

700's

707

Could not create connection

Never before encountered.

710

Bad CVR parameters sent

Sent in reply to a CVR if you send an invalid LCID.
    >>> CVR 1 0x0809 winnt 5.1 i386 MSNMSGR 6.0.0602 MSMSGS /r/n
    <<< 710 1/r/n

711

Write is blocking

Never before encountered.

712

Session is overloaded

Never before encountered.

713

Calling too rapidly

When the client repeatedly calls someone who is offline or blocking them, this error message will be sent in response to the commands that the server rejects.
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 216 5/r/n
>>> CAL 5 /r/n
<<< 713 5/r/n

714

Too many sessions

Never before encountered.

715

Not expected

Sent in response to a PRP setting an invalid phone type of three or less characters.
    >>> PRP 30 PHV 555-0690/r/n
    <<< 715 30/r/n
Also sent in response to a change of display name ( REA ) on an unverified Passport account.
    >>> REA 31 newname/r/n
    <<< 715 31/r/n

717

Bad friend file

Never before encountered.

731

Not expected

Sent in response to a badly formatted CVR
    >>> CVR 2 foo/r/n
    <<< 731 2/r/n
    

Server Closes Connection
/r/n

800's

800

Changing too rapidly

When the client tries to change the display name ( REA ) too rapidly, this error message will be sent in response to the commands that the server rejects. This does not affect renaming other principals.
    >>> REA 100 NAME/r/n
    <<< REA 100 2000 NAME/r/n
    >>> REA 101 NAME/r/n
    <<< REA 101 2001 NAME/r/n
    >>> REA 102 NAME/r/n
    <<< REA 102 2002 NAME/r/n
    >>> REA 103 NAME/r/n
    <<< REA 103 2003 NAME/r/n
    >>> REA 104 NAME/r/n
    <<< 800 104/r/n
Also when the client tries to change the status ( CHG ) too rapidly.
    >>> CHG 105 NLN 0/r/n
    <<< CHG 105 NLN 0/r/n
    >>> CHG 106 HDN 0/r/n
    <<< CHG 106 HDN 0/r/n
    >>> CHG 107 NLN 0/r/n
    <<< CHG 107 NLN 0/r/n
    >>> CHG 108 HDN 0/r/n
    <<< CHG 108 HDN 0/r/n
    >>> CHG 109 NLN 0/r/n
    <<< 800 109/r/n

900's

910

Server too busy

When the MSN servers are busy, this might be sent in reply to your command to the NS containing your digested password..
    >>> USR 28 TWN S t=53*1hAu8ADuD3TEwdXoOMi08sD . . . /r/n
    <<< 910 28/r/n

911

Authentication failed

Sent in response to some invalid formats of the USR command to the DS. Also sent if the account name is invalid.
    >>> USR 3 TWN S /r/n
    <<< 911 3/r/n

    >>> USR 4 TWN I passport.com/r/n
    <<< 911 4/r/n
Sent in response to an invalid TWN value sent in the second USR command to the NS. Also sent if the account name is invalid or nonexistent.
    >>> USR 6 TWN S t=some_invalid_value/r/n
    <<< 911 6/r/n
Also sent in response to problems authenticating with the switchboard with USR or ANS .
    >>> USR 1 ..105/r/n
    <<< 911 1/r/n
    >>> ANS 1 . /r/n
    <<< 911 1/r/n

912

Server too busy

Never before encountered.

913

Not allowed when hiding

Sent in reply to commands that are not allowed in the HDN status which the principal is currently in. The only known command that is prohibited when offline is XFR
    >>> XFR 13 SB/r/n
    <<< 913 13/r/n

914

Server unavailable

Never before encountered.

915

Server unavailable

Never before encountered.

916

Server unavailable

Never before encountered.

917

Authentication failed

Never before encountered.

918

Server too busy

Never before encountered.

919

Server too busy

Never before encountered.

920

Not accepting new principals

Never before encountered.

921

Server too busy

When the MSN servers are busy, this might be sent in reply to your command to the NS containing your digested password..
    >>> USR 28 TWN S t=53*1hAu8ADuD3TEwdXoOMi08sD . . . /r/n
    <<< 921 28/r/n

922

Server too busy

Never before encountered.

923

Kids Passport without parental consent

Sent in reply to the second USR to the NS if client is logging in with a Kids Passport without parental consent to chat online.
    >>> USR 29 TWN S t=53*1hAu8ADuD3TEwdXoOMi08sD . . . /r/n
    <<< 923 29/r/n

924

Passport account not yet verified

Never before encountered.

928

Bad ticket

Sent in reply to the second USR to the NS if your ticket is invalid. Mostly seen if you don't handle redirections properly with the login server connection and use an @msn or @hotmail account
    >>> USR 29 TWN S my_invalid_passport/r/n
    <<< 928 29/r/n

 

6.8.
        MSNP10

http://www.hypothetic.org/docs/msn/research/msnp10.php

6.9.
        MSNC1

http://www.hypothetic.org/docs/msn/research/msnc1.php

6.10.
     结束语