Turning an HTTP Proxy Server into a Wireless Internet Gateway

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

Abstract

The Internet and mobile communication are revolutionizing software servicesand development. The wireless application protocol (WAP) forum proposed aseries of protocols on wireless Internet data presentation and transmission.The WAP gateway is the key component standing between the mobile handset andweb servers. Accessing the Internet using mobile phones becomes feasiblethrough the WAP gateway. However, a lack of performance models and evaluationtools causes difficulties in analyzing the wireless applications and wirelessgateway environment. This paper introduces our experience of turning an HTTPproxy server into a wireless Internet gateway.

Instead of building a WAP gateway from scratch, we transformed an HTTP proxyinto a WAP gateway by modifying each of the two systems. The original HTTPproxy was designed and implemented by the object-oriented principles. Theconverted WAP gateway inherits the structure of HTTP proxy. To have ahigh-performance WAP gateway, we considered the following issues during theconversion process: (1) the interaction among major components, (2) therequirement 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) pushoperation supporting. WAP uses coded headers to reduce the amount of data thatmust be transmitted over the air interface. To translate the traditional HTTPrequests and replies into the coded forms, a mapping table is required. Becauseour HTTP proxy server is designed with coded HTTP header to enhance theinternal operation speed, by replacing the internal operation code with WSPheader code, the mapping table is implemented. Following the newly announcedWAP push protocols, the right information will be delivered to the handset ontime. To support the push capability, we are analyzing the related protocolsand propose a possible push operation sequence. To investigate the performanceof 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 fewyears, and the trend will continue in the coming years. This implies thatmobile phones will be a popular client system in the network. Facing such greatdemands, the WAP forum proposed a series of protocols that permit Internetaccess through mobile phones[1].

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

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

WAP uses coded binary data to improve transmission efficiency. The headerand content are compactly compiled. For the traditional HTTP network, thepacket header is in string format. In order to adapt to the WAP network,encoding and decoding techniques are required. To translate the traditionalHTTP 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 enhancethe internal operation speed[3], by replacing the internaloperation code with WSP header code, the mapping table is implemented.

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

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

2. Gateway structure

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

2.1 HTTP proxy operations

Because of the rapid growth of the Internet population, insufficient networkbandwidth has become a major problem. HTTP proxy is the most effective andwidely 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 websever 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 theresource has been cached in the disk. If the resource is found and is freshenough (called a "hit"), then the proxy sends a response to the user agent. Acached resource shortens the request/response sequence.
3. If a cache is not found, the proxy rewrites all or part of the request andforwards 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 themessage 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: headertranslation, push operation, and content compilation. The header translationallows the client system to access Internet via a different protocol. The pushoperation allows the server to send the right information to the client. Thecontent compiling compacts the data for low-bandwidth support.

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

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

Figure 2. WAP Gateway operation sequence.

The operation sequence chain between a mobile phone and web server through aWAP gateway is shown in Figure 2, and the six steps listed here are shown aslabels 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 lineand 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 HTTPrequest to it.
4. The HTTP request is processed by the web server. If the URL refers to astatic file, the Web server fetches the file and gives a response with an HTTPreply header; if the URL refers to a script application, the Web server startsthe application.
5. The Web server returns an HTTP reply message, which contains data orresults from a script application.
6. The WAP gateway encodes the reply and translates the well-known HTTPformatted reply line and reply header into WSP binary format using the mappingtable.
7. The WAP gateway creates a connection, and a WSP response containing thewireless markup language (WML) [6] is returned to the clientsystem.

Notice that the WAP client side environment is different from that oftraditional HTTP proxy. The network domain of client system in Figure 2 hasbeen changed to WAP domain, and the protocol used between client and gateway isnow 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 isdesigned and ready to be implemented. Thus, we focus the description on theheader translation here. Figure 3 shows the our WAP gateway systemarchitecture.

Figure 3. WAP gateway architecture.

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

Dispatch module

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

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

State module

State module is implemented as an object-oriented class. The state binds theresources with the request. It puts the data-gram packet into aPushbackInputStream object from the standard JDK. The state module also handlesthe 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 alltasks 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 fittingfor HTTP.
2. Parse the request header and decode binary format to well-known headerstring format fitting for HTTP.
3. Create a connection and sends an HTTP request translation of the WSPrequest to the Web server from which client originally sent the request andreceive the HTTP reply message.
4. Parse the reply line and encode string format to binary format fitting forWSP.
5. Parse the reply header and encode well-known header string format to binaryformat fitting the WSP.
6. Send a WSP reply to the client.

Request decoding module

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

The request header parser gets the well-known header values and translatesthem to the string type header's names by using a defined mapping table.According to those values, the parser calls the corresponding method to getstring 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 thisrequest to the original Web server that holds the content. Thus, the WAPgateway connects the Web server using this proxy connection module. This modulefirst gets the resource processed and bound in the state module. Then itconnects to the Web server. Finally, the WAP gateway rewrites an HTTP requestand sends to the Internet.

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

Reply encoding module

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

The response header parser gets the string type header's names andtranslates those to the well-known header values by using a defined mappingtable. According to these values, the parser calls the corresponding method toget the binary format header's values.

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

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 6564 75 2e 74 77 2f 69 6e 64 65 78 2e 77 6d 6c 81 ea 81 84 80 94 80 95 80 a1 809d a9 4e 6f 6b 69 61 2d 57 41 50 2d 54 6f 6f 6c 6b 69 74 2f 31 2e 33 62 65 7461 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 codeWSP Value(Hex.)Filed NameHTTP Value010x01Transaction ID1400x40PDU TypeGET250x25URI Length37(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 7477 2f 69 6e 64 65 78 2e 77 6d 6cURIhttp://weco.csie.fju.edu.tw/
index.html810x01Header NameAccpet-Charsetea0x6AHeader ValueSomail810x01Header NameAccpet-Charset840x04Header ValueAmharic800x00Header NameAccept940x14Header Valueapplication/vnd.wap.wmlc800x00Header NameAccept950x15Header Valueapplication/vnd.wap.wmlscriptc800x00Header NameAccepta10x21Header Valueimage/vnd.wap.wbmp800x00Header NameAccept9d0x1DHeader Valueimage/gifa90x19Header NameUser-Agent4e 6f 6b 69 61 2d 57 41 50 2d 54 6f 6f 6c 6b 69 74 2f 31 2e 3362 65 74 61 00Header ValueNokia-WAP-Toolkit/1.3beta.

For this example, a WSP coded header is sent to the WAP gateway. Then therequest decode module parses the data and translates them to an HTTP value byusing 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 contentdevelopment.

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 Webserver 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 WAPconnection.

On the server side, we use the MS-IIS 4.0 Web server. We putWML/WML-Script[8] contents on the server, and set MIME typeto make the Web server aware of the content type. WML/WML-Script contents canbe built using the Nokia WAP Toolkit or a pure text editor. The MIME type aboutWAP content type must follow WAP WSP specifications. The complete WAP test-bedstructure 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 protocoltranslation are attached. On the server side, we add a content compiler forcontent compacting. When a WSP request is sent to an HTTP proxy, the headerdecoder converts the request to a normal HTTP one. Then the HTTP proxy does itsregular work. After replying with an HTTP response, the content compilercompiles 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 ourtest-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 amobile client[9]. However, the push operation is not directlybetween the push initiator and the mobile client. The initiator is on theInternet, and the mobile client is in the WAP domain. Thus, the push proxygateway (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 therequired 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 amultipart type, which contains an XML control entity and a content entity andmay also contain an RDF-format capabilities entity defined in the user agentprofile[13].
2. The PPG can accept or reject the push message. If the PAP push messageelement is not valid with respect to its document type definition (DTD), thePPG rejects it.
3. The PPG reports the acceptance or rejection result in the response, whichis an XML document.
4. The PPG parses the control information of the push message to determinewhere and how it should deliver.
5. A PI must identify client addresses for submitting. A client address iscomposed of a client specifier and a PPG specifier. The client specifier isused to find out a target client, and the content is either a user-definedidentifier (e.g., e-mail address) or a device address (e.g., phone number). ThePPG specifier permits a push message to be routed through the proxy, and thecontent is a site of PPG. In this step, the PPG parses the client addresses fordelivering.
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 pushprimitives. In a confirmed push, an active WSP session, which only the clientcan create, is required. This situation is also called connection-orientedpush. If the PPG gets a connection-oriented push message to a client, and thereare 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 containsnecessary information for creating a session, to a session initiationapplication (SIA) on the client side. The SIA determines whether to establish asession or not. Of course, push delivery may also be performed without the useof sessions in a unconfirmed push.
8. When a client receives a pushed message, the application dispatcher in theclient parses the push message header to determine its destination applicationand to run it. If the push delivery method is confirmed push, the clientresponds 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 thepush 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. Theabove two messages are XML documents.

Each step in the above push operation sequence is a required operation. Thissequence 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-bedis 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 thepull condition, the pull event generator simulates a great number of clientsand sends requests to gateway. Then gateway does its regular work and sendsresponse packets to the packet filter. The packet filter records theinformation about packets such as amount of data. In the push condition, thepush event driver starts a scheduled push delivery with push messages accordingto the subscriber list. After the gateway parses the push messages, the packetsare sent to the packet filter. The packet filter classifies these packets andrecords the related information respectively. Finally, according to therecorded information, the statistic analysis is completed.

4. Conclusion and future work

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

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

5. References

1. WAP Forum, "Wireless Application Protocol ArchitectureSpecification", 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 HTTPProxy 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", ManningPublications 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," November1999.
   http://www.wapforum.org/
10. WAP Forum, "WAP Push Proxy Gateway ServiceSpecification," 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," August1999.
    http://www.wapforum.org/