Turning an HTTP Proxy Server into a Wireless Internet Gateway

Turning an HTTP Proxy Server into a Wireless Internet Gateway

Hsing MEI <[email protected]>
Yi-Ming WEN <[email protected]>
Wen-Jou LIN <[email protected]>
Fu Jen Catholic University
Taiwan

Abstract

The Internet and mobile communication are revolutionizing software services and development. The wireless application protocol (WAP) forum proposed a series of protocols on wireless Internet data presentation and transmission. The WAP gateway is the key component standing between the mobile handset and web servers. Accessing the Internet using mobile phones becomes feasible through the WAP gateway. However, a lack of performance models and evaluation tools causes difficulties in analyzing the wireless applications and wireless gateway environment. This paper introduces our experience of turning an HTTP proxy server into a wireless Internet gateway.

Instead of building a WAP gateway from scratch, we transformed an HTTP proxy into a WAP gateway by modifying each of the two systems. The original HTTP proxy was designed and implemented by the object-oriented principles. The converted WAP gateway inherits the structure of HTTP proxy. To have a high-performance WAP gateway, we considered the following issues during the conversion process: (1) the interaction among major components, (2) the requirement of various applications, and (3) the consumption of resources.

Comparing the HTTP with the corresponding WAP wireless session protocol (WSP), the two major improvements of WSP are (1) coded headers, and (2) push operation supporting. WAP uses coded headers to reduce the amount of data that must be transmitted over the air interface. To translate the traditional HTTP requests and replies into the coded forms, a mapping table is required. Because our HTTP proxy server is designed with coded HTTP header to enhance the internal operation speed, by replacing the internal operation code with WSP header code, the mapping table is implemented. Following the newly announced WAP push protocols, the right information will be delivered to the handset on time. To support the push capability, we are analyzing the related protocols and propose a possible push operation sequence. To investigate the performance of the gateway, a WAP test-bed is under development.

Contents

• 1. Background
• 2. Gateway structure
  • 2.1 HTTP proxy operations
  • 2.2 WAP gateway operations
  • 2.3 WAP gateway implementation
    • Dispatch module
    • State module
    • Request thread module
    • Request decoding module
    • Proxy connection module
    • Reply encoding module
    • Example
  • 2.4 Test environment
  • 2.5 Convert HTTP proxy to WAP gateway
• 3. Push operation and WAP test-bed
  • 3.1 Push operation
  • 3.2 WAP test-bed
• 4. Conclusion and future work
• 5. References

1. Background

The number of mobile phone holders has grown significantly in the past few years, and the trend will continue in the coming years. This implies that mobile phones will be a popular client system in the network. Facing such great demands, the WAP forum proposed a series of protocols that permit Internet access through mobile phones[1].

There are two possible ways to access the Internet in a WAP environment: the first way is based on WSP [2]/HTTP exchange via a WAP gateway. The alternative is direct access over pure WSP. Although many WAP protocols have been finalized, some WAP gateway related protocols are still in development.

Instead of building a WAP gateway from scratch, we transformed an HTTP proxy into a WAP gateway by modifying each of the two. The coded header and push operation of WAP are two major improvements over HTTP.

WAP uses coded binary data to improve transmission efficiency. The header and content are compactly compiled. For the traditional HTTP network, the packet header is in string format. In order to adapt to the WAP network, encoding and decoding techniques are required. To translate the traditional HTTP requests and replies to the coded forms, a mapping table is required. Because our HTTP proxy server is designed with a coded HTTP header to enhance the internal operation speed[3], by replacing the internal operation code with WSP header code, the mapping table is implemented.

Push operations deliver the right information to the handset on time. To support the push capability, we are analyzing the related protocols and propose a possible push operation sequence. To investigate the performance of the gateway, a WAP test-bed is under development.

This paper addresses our experience on turning an HTTP proxy into a WAP gateway. Section 2 illustrates the operation sequences of an HTTP proxy and a WAP gateway. The converted gateway architecture is introduced. In Section 3, the push operation of a push proxy gateway (PPG) is proposed. Our test-bed structure is illustrated. Conclusion and future works are given in Section 4.

2. Gateway structure

This section illustrates the structure of a WAP gateway. First, we describe the operation of the HTTP proxy and the WAP gateway. Then, the functionality of each module of the WAP gateway is introduced. Finally, the tasks involved in converting an HTTP proxy into a WAP gateway are discussed.

2.1 HTTP proxy operations

Because of the rapid growth of the Internet population, insufficient network bandwidth has become a major problem. HTTP proxy is the most effective and widely adopted mechanisms to shorten the response time[4][5].

Figure 1. Traditional HTTP Proxy operation.

Figure 1 shows the request and response sequence between a client and web sever through an HTTP proxy. The sequence is consisted of following six steps, as shown by the six labels in the figure.

1. User agent (i.e. client system) sends a request to the proxy.
2. After receiving and interpreting the request, the proxy checks whether the resource has been cached in the disk. If the resource is found and is fresh enough (called a "hit"), then the proxy sends a response to the user agent. A cached resource shortens the request/response sequence.
3. If a cache is not found, the proxy rewrites all or part of the request and forwards the reformatted message to the origin server.
4. The web server receives the request and makes a suitable response.
5. After receiving the response sent by origin server, the proxy caches the message if possible.
6. At last, the proxy sends the response to the user agent.

2.2 WAP gateway operations

In general, a WAP gateway is expected to complete three tasks: header translation, push operation, and content compilation. The header translation allows the client system to access Internet via a different protocol. The push operation allows the server to send the right information to the client. The content compiling compacts the data for low-bandwidth support.

To turn an HTTP proxy into a WAP gateway, header translation is the first task to be done. The push operation will be discussed in Section 3. Content compiling is not addressed in this paper.

In WAP, the WSP headers are defined in binary format, but the HTTP headers are in string type. In order to enable a handset to access the Internet Protocol (IP) network, translation of the coded WSP and traditional HTTP requests and replies is needed.

Figure 2. WAP Gateway operation sequence.

The operation sequence chain between a mobile phone and web server through a WAP gateway is shown in Figure 2, and the six steps listed here are shown as labels in the figure.

1. User agent (i.e. client system) sends a uniform resource locator (URL) request to a WAP gateway following the WSP protocol.
2. The WAP gateway decodes the request massage and translates the request line and request header (in binary format) to HTTP format by a mapping table.
3. The WAP gateway creates a connection to the web server and sends an HTTP request to it.
4. The HTTP request is processed by the web server. If the URL refers to a static file, the Web server fetches the file and gives a response with an HTTP reply header; if the URL refers to a script application, the Web server starts the application.
5. The Web server returns an HTTP reply message, which contains data or results from a script application.
6. The WAP gateway encodes the reply and translates the well-known HTTP formatted reply line and reply header into WSP binary format using the mapping table.
7. The WAP gateway creates a connection, and a WSP response containing the wireless markup language (WML) [6] is returned to the client system.

Notice that the WAP client side environment is different from that of traditional HTTP proxy. The network domain of client system in Figure 2 has been changed to WAP domain, and the protocol used between client and gateway is now WSP. Also, caching is an optional operation in the WAP gateway.

2.3 WAP gateway implementation

This subsection introduces the design and implementation of our WAP gateway. We have finished the header translation part, and the push operation part is designed and ready to be implemented. Thus, we focus the description on the header translation here. Figure 3 shows the our WAP gateway system architecture.

Figure 3. WAP gateway architecture.

The architecture is composed of six modules: Dispatch , State, Request Thread, Request Decode, Proxy Connection, and Reply Encode. The functionality of each module is as follows

Dispatch module

When a client sends a request to our WAP gateway, the gateway establishes a socket connection and puts the socket into a listen queue. The dispatcher itself is a thread, and it keeps a server socket, which can get the socket connection. Then the dispatcher forwards the request by calling RunSet method to record the request's state and start the request thread module.

To allow the gateway to run smoothly even under busy conditions, we set the dispatcher with low priority. This means that CPU spends much more time on handling requests than dispatching them. The CPU can handle numerous input requests smoothly while dispatching fewer requests.

State module

State module is implemented as an object-oriented class. The state binds the resources with the request. It puts the data-gram packet into a PushbackInputStream object from the standard JDK. The state module also handles the request thread, request line, request header, proxy connection, reply line, and reply header for client request tasks.

Request thread module

The major part of the request thread is a run method that accomplishes all tasks from receiving a client request to sending a reply.

These six tasks are part of the thread request module:

1. Parse the request line and decode binary format to string format fitting for HTTP.
2. Parse the request header and decode binary format to well-known header string format fitting for HTTP.
3. Create a connection and sends an HTTP request translation of the WSP request to the Web server from which client originally sent the request and receive the HTTP reply message.
4. Parse the reply line and encode string format to binary format fitting for WSP.
5. Parse the reply header and encode well-known header string format to binary format fitting the WSP.
6. Send a WSP reply to the client.

Request decoding module

The request decoding module includes two parts: request line decoding and request header decoding. The request line parser gets the transaction ID (TID), PDU type, and uniform resource identifier (URI) of the request packet. Then it translates the PDU type to a string format by using a defined mapping table.

The request header parser gets the well-known header values and translates them to the string type header's names by using a defined mapping table. According to those values, the parser calls the corresponding method to get string type header's values.

The mapping table mentioned above can be found in WSP specifications.

Proxy connection module

After the WAP Gateway has decoded a request message, it must forward this request to the original Web server that holds the content. Thus, the WAP gateway connects the Web server using this proxy connection module. This module first gets the resource processed and bound in the state module. Then it connects to the Web server. Finally, the WAP gateway rewrites an HTTP request and sends to the Internet.

Another task of the proxy connection module is writing the response message to the client. When the WAP gateway receives the reply message from the Web server, the WAP gateway encodes the message for WSP adapting. Then, the proxy connection module writes the reply message to the session created by the WAP gateway and the client to finish the primary request.

Reply encoding module

The reply encoding module includes two parts: response status line encoding and response header encoding. The response status line parser gets the version, response status code, and reason of the reply packet. Then it encodes this information in a binary format by using a defined mapping table.

The response header parser gets the string type header's names and translates those to the well-known header values by using a defined mapping table. According to these values, the parser calls the corresponding method to get the binary format header's values.

The mapping table mentioned above can be found in the WAP WSP specifications.

Example

The example below illustrates the translation of headers.

WSP coded data:

01 40 25 68 74 74 70 3a 2f 2f 77 65 63 6f 2e 63 73 69 65 2e 66 6a 75 2e 65 64 75 2e 74 77 2f 69 6e 64 65 78 2e 77 6d 6c 81 ea 81 84 80 94 80 95 80 a1 80 9d a9 4e 6f 6b 69 61 2d 57 41 50 2d 54 6f 6f 6c 6b 69 74 2f 31 2e 33 62 65 74 61 00

Decoded HTTP data:

TID=1 Type=GET URL=http://weco.csie.fju.edu.tw/index.wml Accept-Charset:Somali ,Amharic Accept:application/vnd.wap.wmlc ,application/vnd .wap.wmlscriptc ,image/vnd.wap.wbmp ,image/gif User-Agent:Nokia-WAP-Toolkit/1.3beta

WSP code WSP Value(Hex.) Filed Name HTTP Value

01	0x01	Transaction ID	1
40	0x40	PDU Type	GET
25	0x25	URI Length	37
(The following 37 bytes) 68 74 74 70 3a 2f 2f 77 65 63 6f 2e 63 73 69 65 2e 66 6a 75 2e 65 64 75 2e 74 77 2f 69 6e 64 65 78 2e 77 6d 6c	URI	http://weco.csie.fju.edu.tw/ index.html
81	0x01	Header Name	Accpet-Charset
ea	0x6A	Header Value	Somail
81	0x01	Header Name	Accpet-Charset
84	0x04	Header Value	Amharic
80	0x00	Header Name	Accept
94	0x14	Header Value	application/vnd.wap.wmlc
80	0x00	Header Name	Accept
95	0x15	Header Value	application/vnd.wap.wmlscriptc
80	0x00	Header Name	Accept
a1	0x21	Header Value	image/vnd.wap.wbmp
80	0x00	Header Name	Accept
9d	0x1D	Header Value	image/gif
a9	0x19	Header Name	User-Agent
4e 6f 6b 69 61 2d 57 41 50 2d 54 6f 6f 6c 6b 69 74 2f 31 2e 33 62 65 74 61 00	Header Value	Nokia-WAP-Toolkit/1.3beta.

For this example, a WSP coded header is sent to the WAP gateway. Then the request decode module parses the data and translates them to an HTTP value by using a mapping table.

2.4 Test environment

This subsection explains the current testing environment of our WAP gateway. This testing environment is part of the WAP test-bed.

In the client system, we use the Nokia WAP Toolkit 1.3beta[7], which simulates a mobile phone and supports WAP content development.

The Toolkit can send a request through two different paths: HTTP over TCP, and WSP over UDP. When using HTTP, the Toolkit connects directly to the Web server as a traditional Web connection. When using WSP via the GSM platform, the Toolkit is not a real phone set; thus UDP is chosen to simulate the WAP connection.

On the server side, we use the MS-IIS 4.0 Web server. We put WML/WML-Script[8] contents on the server, and set MIME type to make the Web server aware of the content type. WML/WML-Script contents can be built using the Nokia WAP Toolkit or a pure text editor. The MIME type about WAP content type must follow WAP WSP specifications. The complete WAP test-bed structure is given in Section 3.2.

2.5 Convert HTTP proxy to WAP gateway

An HTTP proxy can be converted to a WAP gateway by adding some mechanisms, as shown in Figure 4.

Figure 4. HTTP Proxy working with WAP

On the client side, a header decoder and a header encoder for protocol translation are attached. On the server side, we add a content compiler for content compacting. When a WSP request is sent to an HTTP proxy, the header decoder converts the request to a normal HTTP one. Then the HTTP proxy does its regular work. After replying with an HTTP response, the content compiler compiles WML/WML-Script decks or cards. Before the reply is sent to the client, the header encoder translates the normal HTTP reply to a WSP reply.

3. Push operation and WAP test-bed

This section proposes a possible push operation sequence and illustrates our test-bed structure in order to examine the performance of the gateway.

3.1 Push operation

A push operation in WAP occurs when a push initiator transmits content to a mobile client[9]. However, the push operation is not directly between the push initiator and the mobile client. The initiator is on the Internet, and the mobile client is in the WAP domain. Thus, the push proxy gateway (PPG) is needed[10].

The Internet-side PPG access protocol is called push access protocol (PAP [11]), which is on top of HTTP. The WAP-side over-the-air (OTA) delivery protocol on top of WSP is called push over-the-air protocol (Push OTA Protocol [12]). These two protocols define the required elements of the push operation.

The push operation sequence is shown in Figure 5:

Figure 5. Push operation with PPG.

1. A push initiator submits a push message to a PPG. The push message is a multipart type, which contains an XML control entity and a content entity and may also contain an RDF-format capabilities entity defined in the user agent profile[13].
2. The PPG can accept or reject the push message. If the PAP push message element is not valid with respect to its document type definition (DTD), the PPG rejects it.
3. The PPG reports the acceptance or rejection result in the response, which is an XML document.
4. The PPG parses the control information of the push message to determine where and how it should deliver.
5. A PI must identify client addresses for submitting. A client address is composed of a client specifier and a PPG specifier. The client specifier is used to find out a target client, and the content is either a user-defined identifier (e.g., e-mail address) or a device address (e.g., phone number). The PPG specifier permits a push message to be routed through the proxy, and the content is a site of PPG. In this step, the PPG parses the client addresses for delivering.
6. The PPG converts the protocols between the Internet and WAP domain.
7. If there is no error, the PPG delivers either confirmed or unconfirmed push primitives. In a confirmed push, an active WSP session, which only the client can create, is required. This situation is also called connection-oriented push. If the PPG gets a connection-oriented push message to a client, and there are no active sessions to that client, the PPG cannot deliver the push message. In order to solve this problem, the PPG sends a request, which contains necessary information for creating a session, to a session initiation application (SIA) on the client side. The SIA determines whether to establish a session or not. Of course, push delivery may also be performed without the use of sessions in a unconfirmed push.
8. When a client receives a pushed message, the application dispatcher in the client parses the push message header to determine its destination application and to run it. If the push delivery method is confirmed push, the client responds with a primitive to acknowledge receiving the PPG's push content.
9. The PPG sends a result notification to inform the PI of the outcome of the push submission. This notification reports whether the push message was sent, delivered, expired, cancelled, or an error occurred.
10. The PI returns a response message to the result notification module. The above two messages are XML documents.

Each step in the above push operation sequence is a required operation. This sequence omits the optional operation part from the WAP push specification.

3.2 WAP test-bed

In order to investigate the performance of our WAP gateway, a WAP test-bed is under development. The test-bed structure is illustrated in Figure 6.

Figure 6. WAP Test-bed

There are two major behaviors in the WAP test-bed: pull and push. In the pull condition, the pull event generator simulates a great number of clients and sends requests to gateway. Then gateway does its regular work and sends response packets to the packet filter. The packet filter records the information about packets such as amount of data. In the push condition, the push event driver starts a scheduled push delivery with push messages according to the subscriber list. After the gateway parses the push messages, the packets are sent to the packet filter. The packet filter classifies these packets and records the related information respectively. Finally, according to the recorded information, the statistic analysis is completed.

4. Conclusion and future work

In this paper, we first convert the internal operation code of our HTTP proxy server to WSP header code and construct a WAP gateway. On the basis of this experience, it seems that turning an HTTP proxy server into a WAP gateway by adding some mechanisms is feasible. Next, a possible push operation sequence is proposed. Finally, the developing WAP test-bed is illustrated.

Now our WAP gateway can conduct protocol translation but it lacks the management and an estimation of running efficiency. Besides, the push operation part is not completed. For future work, we will (1) continue implementing the functionality of our WAP push gateway; (2) complete the WAP test-bed and investigate the gateway performance; (3) estimate the rationality of the proxy caching operation within a WAP gateway.

5. References

1. WAP Forum, "Wireless Application Protocol Architecture Specification", April 1998.
   http://www.wapforum.org/
2. WAP Forum, "WAP Wireless Session Protocol Specification", February 1999.
   http://www.wapforum.org/
3. W. J. Lin, and H. Mei, "A High Performance Java-based HTTP Proxy Server," Proceedings of 1999 Workshop on Distributed System Technologies & Applications, May 1999, pp. 654-663.
4. R. Fielding, J. Gettys, J. Mogul, H. Frystyk and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068, January 1997.
5. Paul S. Hethmon, "Illustrated Guide to HTTP", Manning Publications Co, 1997.
6. WAP Forum, "WAP Wireless Markup Language Specification," November 1999.
   http://www.wapforum.org/
7. Nokia WAP Toolkit SDK 1.3
   http://www.forum.nokia.com/
8. WAP Forum, "WAP WML Script Language Specification," November 1999.
   http://www.wapforum.org/
9. WAP Forum, "WAP Push Architecture Overview," November 1999.
   http://www.wapforum.org/
10. WAP Forum, "WAP Push Proxy Gateway Service Specification," August 1999.
    http://www.wapforum.org/
11. WAP Forum, "WAP Push Access Protocol Specification," November 1999.
    http://www.wapforum.org/
12. WAP Forum, "WAP Push OTA Protocol Specification," November 1999.
    http://www.wapforum.org/
13. WAP Forum, "WAP Push Message Specification," August 1999.
    http://www.wapforum.org/