Wap push Access Protocol (PAP)-open source code

Document directory

• Source code:

Recently, due to some project reasons, we need to implement the wappush function. I wanted to be lazy and search the Internet to see if there is any suitable content. I had to write one by myself.

The content of the PAP protocol is not complicated. It is an extension of the HTTP protocol. net httpwebrequest class library can easily implement the PAP communication layer. the remaining work is the combination of the content of the PAP protocol. The PAP protocol mainly has four methods and one interaction method, namely:

• Submit a push submit a push information

• Cancel a push cancels a push message

• Query for status of a push query the status of submitted push information

• Query for wireless device capabilities query wireless device capabilities

 

To receive the sending result notification message returned by the PPG (push Proxy gateway), you need to provide a callback address for the PPG to send the notification response. The relationship between Pi (push initiator) and PPG is as follows:

The PI and PPG communicate with each other using the PAP protocol. The PPG calls the air protocol and transmits it to the mobile phone.

　　

Pi sends a wappush message, and the interaction process between PI and PPG

1. Pi initiates a push request

2. The PPG returns a response packet.

3. PPG pushes wappush to Mobile Terminal

4. Mobile Terminal response receiving result

5. PPG pushes the final sending result to the PI end

6. The PI returns a response packet to the PPG to complete the entire sending process.

For cancel a push, query for status of a push, query for wireless device capabilities, these three methods are interaction between PI and PPG, that is, the way to initiate a request and get a response. Therefore, no detailed description is provided.

Message Body format

The message body of the PAP protocol submits requests in multi-segment mode, that is, the Content-Type type is "multipart/related", to the specific information, refer to rfc2387. the whole pap protocol package contains three structures:

• Control entity: provides some control commands

• Content entity: Provides transmitted content information

• Capabilities entity: provides the capability configuration information supported by terminals.

In addition to pushing messages, only the control entity package is used for other request methods. All three types of packages are mime-type. The following is the specific format of a request package.

Content-Type: multipart/related; boundary = asdlfkjiurwghasf;
Type = "application/XML"

-- Asdlfkjiurwghasf
Content-Type: Application/XML

<? XML version = "1.0"?>
<! Doctype pap public "-// wapforum // DTD pap 2.0 // en"
Http://www.wapforum.org/DTD/pap_2.0.dtd"
[<? WAP-Pap-ver supported-versions = "2.0, 1. *"?>]>
<Pap>
... Control for PPG ..
</Pap>

-- Asdlfkjiurwghasf
Content-Type: text/vnd. WAP. Si

... Service indication push message example ..

-- Asdlfkjiurwghasf
Content-Type: Application/XML

... Assumed client capabilities ..

-- Asdlfkjiurwghasf --

Introduction to control entities

The definition of a control object is as follows:

<! Element PAP (push-message
| Push-Response
| Cancel-message
| Cancel-Response
| Resultnotification-message
| Resultnotification-Response
| Statusquery-message
| Statusquery-Response
| Ccq-message
| Ccq-Response
| Badmessage-response)>
<! ATTLIST pap
Product-name CDATA # implied
>

It supports a total of 11 control commands, which must be placed under the PAP node, such:
<Pap>
<Push-message.../>
</Pap>

The following 11 control commands are supported:

Push-message: pi-> PPG, initiate a push request
Push-response: PPG-> pi. Results of the PPG response to the push request
Cancel-message: pi-> PPG, cancels the message request
Cancel-response: PPG-> Pi, PPG response to the cancellation request
Resultnotification-message: PPG-> Pi, result reminder message, which is sent by the notification address provided when the PPG calls the PUSH message.
Resultnotification-response: pi-> PPG. The PI side sends a message response to the results of the PPG.
Statusquery-message: pi-> PPG, status query message, query the current status of the sent message
Statusquery-response: PPG-> pi. Response Results of the PPG to the query request
Ccq-message: pi-> PPG, initiates a terminal capability query request
Ccq-response: Response Results of PPG-> PI and PPG for terminal capability Query
Badmessage-response: PPG-> pi. When the PPG receives an error request packet, it returns the response information.

 

Introduction to push-message

The structure is defined as follows:

<! Element push-message (address +, quality-of-service? )>
<! ATTLIST push-message
Push-id cdata # required
Replace-push-id cdata # implied
Replace-method (pending-only | all) "all"
Deliver-before-timestamp % datetime; # implied
Deliver-after-timestamp % datetime; # implied
Source-reference CDATA # implied
PPG-policy-requested-to CDATA # implied
Progress-notes-requested (true | false) "false"
>

<! Element address empty>
<! ATTLIST address
Address-value CDATA # required
>

<! Element Quality-of-Service empty>
<! ATTLIST Quality-of-Service
Priority (high | medium | low) "medium"
Delivery-method (confirmed | preferconfirmed
| Unconfirmed | notspecified) "notspecified"
Network CDATA # implied
Network-required (true | false) "false"
Bearer CDATA # implied
Bearer-required (true | false) "false"
>

The push-message node is the control node that pushes a message. It has multiple attributes and its meaning is as follows:

Push-ID: the ID of the push flow, which is created and managed by the PI end and must be globally unique. The response package and notification package are returned Based on the ID to determine the request.
Replace-push-ID: Replace the push ID, which refers to the old pushid that has been replaced. It is mostly used to replace the New message to submit but not send the message.
Replace-method: the replacement method. The options pending-only and all are optional. "All" indicates that all the recipients of the old message are replaced, and "pending-only" indicates that the receiver that may be canceled is replaced.
Deliver-before-timestamp: End Time of sending. if the message is not sent after the specified time, the message is not sent. The format is standard UTC time: yyyy-mm-ddthh: mm: SSZ.
Deliver-after-timestamp: the start time of the message. The message must start at the specified time. The format is standard UTC time: yyyy-mm-ddthh: mm: SSZ.
Source-Reference: The text name of the content provider. PPG Gateway may need this parameter to determine PI permissions and capabilities.
PPG-policy-requested-to: URL address of the request for sending the result response from PPG
Progress-notes-requested: whether to include processing log information in the response package
The address node must be included in the push-message node. If there are multiple recipients, add multiple address nodes. The address-value is the actual Receiving address, it can be a logical address. The specific format is roughly as follows:
Wappush = 12345678/type = PLMN@ppg.operator.com

The Quality-of-Service Node must also be placed under the push-message node, which describes various sending attributes of the current message, such as priority, network usage, and bearer body, different networks may have different parameters. Contact the corresponding carrier.

Specific parameter description can refer to the standard documentation: wap-247

 

Introduction to push-Response

<! Element push-response (Progress-Note *, response-result)>
<! ATTLIST push-Response
Push-id cdata # required
Sender-address CDATA # implied
Sender-name CDATA # implied
Reply-time % datetime; # implied
>

Push-response is the response packet structure returned by the PPG after the PI submits the push-message to the PPG. It has four attributes:

Push-ID: Related push-ID
Sender-address: the sender address, which is generally the PPG address.
Sender-name: the name of the sender, usually the name of The PPG.
Reply-time: response time, standard UTC time

The progress-note node is not described much. It is a log processing node.

The response-result node contains the response result of the sent message, which is defined as follows:

<! Element response-result empty>
<! ATTLIST response-Result
Code CDATA # required
Desc CDATA # implied
>
The Code is the response result. For details, refer to the instructions in the standard documentation. The DESC is the corresponding description.

The structure of several other requests is relatively simple and is not described here. Refer to the standard documentation.

 

HTTP request processing instructions

The PAP protocol is based on the HTTP protocol. Therefore, to create a pap protocol, you only need to initiate an HTTP request. The following is a piece of sending code:

 

Code
// Pap request
Httpwebrequest paprequest = (httpwebrequest) httpwebrequest. Create (config. serviceurl );
Paprequest. method = "Post ";
Paprequest. contenttype = "multipart/related; type = application/XML; boundary =" + irequest. boundary;
Paprequest. headers. Add ("Authorization", config. encpass );

Byte [] papdata = rqeuestobj. getbytes (config. ENC );

Stream requeststream = paprequest. getrequeststream ();
Requeststream. Write (papdata, 0, papdata. Length );
Requeststream. Close ();

Httpwebresponse response = (httpwebresponse) paprequest. getresponse ();
Streamreader sr = new streamreader (response. getresponsestream (), config. ENC );
Ret = replacexml (Sr. readtoend ());
Sr. Close ();

Mainly set several attributes: method, contenttype, and authorization. If the first two attributes are not described, authorization indicates authentication information. Some PPG gateways do not need authentication information, so you can ignore this attribute. The value of the authentication attribute is a base64 encoded string in the format of base base64string.

The username and password are written in this format: Username: password. encode the string and put it behind the base. Indicates the basic base64 authentication string. I will not explain any other code: You can refer to the source code.

Source code:

Currently, only functions such as parsing and generation of the PAP Protocol are implemented, and queue control and traffic control of data transmission are not implemented. These functions need to be further improved. If you are interested in improvement, I hope to submit it to the project too :)

: Http://paplib.codeplex.com/