分类:
2010-05-03 21:58:28
彩信的架构。彩信和其它WAP应用的架构差不多,都要经过WAP Gateway中转。要注意的是彩信并非直接投递给接收方,而是像邮件一样,先发送给一个中间服务器MMS Proxy-Relay。MMS Proxy-Relay暂时保存彩信,然后通过push协议给彩信接收方发送一个通知,彩信接收方收到通知后从MMS Proxy-Relay上获取彩信内容。MMS Client和WAP Gateway之间用WAP传输协议传输,而WAP Gateway和MMS Proxy-Relay之间走传统的TCP/IP协议。
彩信的交互过程。对彩信客户端实现者来说,我们主要关心:彩信发送方与MMS Proxy-Relay之间的交互和彩信接收方和MMS Proxy-Relay之间的交互,这包括下列几个过程。
l 发送过程。这是彩信发送方把彩信发送给MMS Proxy-Relay的过程,MMS Proxy-Relay在收到彩信后会给发送方一个确认消息。
l 通知过程。为了把彩信投递给接收方,MMS Proxy-Relay要通过PUSH协议给接收方发送一条彩信通知消息,这个消息通常是一条特殊短信,里面包含彩信的位置URL。
l 彩信回执。当MMS Proxy-Relay成功的通知彩信接收方后,它会给彩信发送方发送一个消息表明彩信投递成功。
l 彩信阅读回执。彩信阅读回执是一条新彩信,它的传递过程和普通彩信没有什么差别,只是不能再有阅读回执。
彩信的PDU。PDU即协议数据单元,对应前面每种消息的消息格式。彩信的PDU和HTTP协议极为类似,当然相对来说要简单多了。它定义了一些常用的消息域,有的消息域是公有的,每种消息都可以使用,有的消息域是专用的,只有特定的消息才能使用。除了常用的消息域外,也可以自定义消息域,自定义消息域以X-打头,但不能以X-Mms-打头。常用的消息域如:
l X-Mms-Message-Type
l X-Mms-Transaction-ID
l X-Mms-MMS-Version
l Date
l From
l To
l Cc
l Bcc
l Subject
l X-Mms-Message-Class
l X-Mms-Expiry
l X-Mms-Delivery-Time
l X-Mms-Priority
l X-Mms-Sender-
l Visibility
l X-Mms-Delivery-Report
l X-Mms-Read-Reply
l Content-Type
PDU的类型有:
l 发送请求。m-send-req
l 发送确认。m-send-conf
l 彩信通知。m-notification-ind
l 通知回应。m-notifyresp-ind
l 获取彩信回应。m-retrieve-conf
l 接收确认。m-acknowledge-ind
l 彩信回执。m-delivery-ind
获取彩信只是一个普通的HTTP GET请求,而没有专门的PDU。
彩信的PDU编码。彩信PDU在语义上与HTTP协议类似,但是其编码方式并不一样,为了充分利用带宽,彩信PDU采用二进制方式编码。其编码规则很简单,预定义的消息域的KEY都有唯一的单字节编码,如:
Key |
编码 |
Bcc |
0x01 |
Cc |
0x02 |
Content-Location |
0x03 |
Content-Type |
0x04 |
Date |
0x05 |
Delivery-Report |
0x06 |
Delivery-Time |
0x07 |
Expiry |
0x08 |
From |
0x09 |
Message-Class |
0x0A |
Message-ID |
0x0B |
Message-Type |
0x0C |
MMS-Version |
0x0D |
Message-Size |
0x0E |
Priority |
0x0F |
Read-Reply |
0x10 |
Report-Allowed |
0x11 |
Response-Status |
0x12 |
Response-Text |
0x13 |
Sender-Visibility |
0x14 |
Status |
0x15 |
Subject |
0x16 |
To |
0x17 |
Transaction-Id |
0x18 |
|
|
而消息域的Value部分,如果只有几个固定的可选值,这几个值也用单子节的编码,由于这些值只出现在特定的上下文中,所以无需要全局唯一。