China DOS Union

Using Linux as a WAP Gateway

1. Introduction to WAP

1.1. The emergence and development of WAP

　　In June 1997, Nokia, Ericsson, Motorola, and Unwired Planet jointly formed the WAP Forum. The purpose of the forum was to bring the massive amount of information and advanced services of the Internet to wireless digital phones and terminals, with the goal of producing a global wireless protocol specification suitable for different wireless network technologies for adoption by industry standards organizations.

　　After the WAP Forum was established, it received an active response from the industry, and people from all sides gathered under its banner. At the beginning of 1998, the WAP specification was officially released. The appearance of WAP brought mobile communications, the fastest-developing part of the telecommunications industry, fully into the world of computer networks, and at the same time pointed out the direction for the future development of the telecommunications industry. It gave the mobile Internet a common standard, signaling the maturity of mobile Internet standards.

　　WAP consists of a series of protocols used to standardize wireless communication devices, such as cellular phones and radio transceivers, and can also be used for Internet access, including e-mail, WWW, Newsgroups, and IRC (Internet Relay Chat). Simply put, the goal of WAP is to bring the massive amount of information and advanced services of the Internet to wireless terminals such as mobile phones. It is optimized for the characteristics of wireless networks such as low bandwidth and high latency, bringing a whole series of Internet protocol specifications into wireless networks. WAP requires support only from mobile phones and WAP proxy servers, and does not require any modifications to existing mobile communication network protocols, so it is suitable for different mobile communication systems such as CDMA, GSM, and IMT－2000. In addition, WAP occupies as few handheld device resources as possible (such as ROM, RAM, CPU, etc.), and makes up for the shortcomings of handheld devices themselves by enhancing network functions. Just as the Web works for the Internet, WAP hides the complexity of GSM at the application layer, leaving users with a friendly and approachable interface.

　　Phones compliant with the WAP standard will be equipped with a browser comparable to a standard Web browser. It uses a card-deck-like working method, and users can browse operator-provided Web services through card decks. The end user first selects a service, and that service downloads a card deck to the mobile phone. Then the user can browse back and forth between cards, make selections and enter information, and then execute the selected operation. The browsed information can be cached for later use, and card decks can also be cached and bookmarked for quick retrieval. Formats for electronic business cards, calendar events, and other types of content will all be supported.

　　The Internet and mobile communications are currently the most dynamic and fastest-growing industries. WAP (Wireless Application Protocol) organically combines mobile communications and the Internet, serving as a bridge between the mobile world and the Internet. Now mobile users can access the Internet anytime and anywhere, and can quickly and securely obtain information from the Internet and corporate intranets, as well as other communication services, from their mobile terminals. WAP has broad market prospects, will certainly develop rapidly, and will greatly change our lives.

　　The most attractive thing about WAP is that no matter when / where / who, information can be obtained at the fastest speed, and WAP terminals are relatively convenient to carry and use. WAP is most suitable for e-commerce, and has already been applied in securities, banking, and other fields, such as mobile stock trading and mobile banking.

1.2. WAP architecture

　　The WAP working model is similar to the WEB working model, as shown below. The mobile terminal sends out a request carrying various parameters (URL, etc.). After parsing it, the gateway sends the corresponding request to the Web server. The server generates the corresponding result by retrieving the parameters and returns it to the proxy gateway. The gateway then decodes and encodes it, sends the result back to the mobile terminal, and one session process is complete. WAP defines a complete set of standard components to implement communication between clients and servers, including standard URLs, standard content formats, and standard transmission methods. WAP and WWW use the same URL to identify content on the server, and this standard has not been changed at all in consideration of compatibility with the current Internet. What differs from WWW are the standards for content presentation formats and file transfer methods, which have been optimized for the characteristics of mobile terminals. WAP uses gateway technology to connect wireless networks and Internet data networks. The gateway must be able to convert the WAP protocol stack to the WWW protocol stack, and also convert content formats, for example from wml to html. This structure ensures that mobile users can use a wide range of Internet resources, while developers of network applications do not need to consider the network or terminal type, giving maximum flexibility and scalability!



　　In a wireless network, a WAP phone communicates with two servers (WAP Proxy Server and WTA Server). The WAP proxy (that is, the WAP gateway) converts WAP protocol requests sent by the WAP phone into WWW protocol requests, and then submits the WWW requests to the Web Server. At the same time, the WAP Proxy also encodes the information returned by the Web Server into a compact binary format recognizable by the WAP phone, and then passes it back to the WAP phone.

　　This model takes great advantage of the existing WWW programming model, and application developers can get many benefits from it, including continuing to use programming models they are already familiar with and being able to use existing tools (such as Web servers, XML tools), etc. In addition, the WAP programming model has also optimized and extended the original WWW programming model for the communication characteristics of the wireless environment.

　　WAP access involves wireless communication networks and Internet/Intranet, while using both the WAP protocol and the TCP/IP protocol, making the WAP gateway the key point of WAP access. Depending on how the WAP gateway is set up, the solutions for building a WAP access platform can generally be divided into two categories: one is for the access unit to directly use the public WAP gateway of the telecommunications department (such as 172 provided by China Mobile); the other is for the access unit to set up its own dedicated WAP gateway. Whether to use the telecommunications department's public WAP gateway or set up a dedicated gateway mainly depends on requirements for timeliness and security. If the requirements are not very high, the public WAP gateway can be used; otherwise, a dedicated gateway should be set up.

　　All major mobile phone manufacturers have their own gateway products. The ones used more often by domestic telecommunications departments are Nokia, Motorola, and Phone.com gateways. Their functions are relatively complete, and their technical support is strong, but their prices are extremely high and beyond what ordinary enterprises can afford. So some WAP enthusiasts began developing WAP gateways on LINUX. The ones done relatively well are the Kannel and 3ui gateways. Among them, the Kannel gateway was the first open-source gateway to obtain WAP Forum WAP1.1 compatibility certification. This article mainly introduces the Kannel WAP gateway.

2. Kannel WAP Gateway

　　The Kannel gateway runs under the Linux platform, is open source, fully supports the WAP1.1 protocol specification, and uses distributed and multithreaded technology. It has fast gateway processing speed, is reliable, easy to maintain, and easy to expand. It implements the WAP standard protocol stack; implements encoding and decoding of WML and WML Script content; supports WBMP to enable graphics display; supports secure connections and non-secure connections; supports persistent connections and temporary connections. It can do load sharing across multiple hosts and has high fault tolerance. On an ordinary PC it can support several hundred concurrent users.

2.1. Installation and configuration

　　The source code can be downloaded from the Kannel website. The latest stable version is 1.0.3, and the development version is 1.1.3. Taking version 1.0.3 as an example, download gateway-1.0.3.tar.gz to the Linux machine. The Kannel gateway requires the xml library; you can download libxml2-2.2.8.tar.gz from the xmlsoft website. Assume the directory is /home/wap. First install the libxml library:

cd /home/wap
tar zxvf libxml2-2.2.8.tar.gz
cd libxml2-2.2.8
./configure
make
make install （this step requires root privileges）

　　Then install the gateway:

cd /home/wap
tar zxvf gateway-1.0.3.tar.gz
cd gateway-1.0.3
./configure
make

　　The technical documents under the doc/arch directory are in fig format and require the fig2dev program. If you do not have this program, compilation will report an error, but that does not matter, because the binary executables we need have already been generated. If you find it troublesome to get an error every time you compile, you can modify the Makefile and remove this part. Or go download fig2dev (I didn't go look for where to get it).

　　Now go to the gw directory and take a look. The programs we need, bearerbox and wapbox, have already been generated. Start bearerbox (./bearerbox &. Ah, the program reports an error: it cannot read the configuration file kannel.conf. What's going on? There is no such file in the gw directory. No problem, just copy wapkannel.conf to kannel.conf (cp wapkannel.conf kannel.conf).

　　 The format of the configuration file kannel.conf is as follows. The specific meanings will be clear if you look at the documentation that comes with Kannel.

group = core
admin-port = 13000
wapbox-port = 13002
admin-password = bar
wdp-interface-name = "*"
#log-file = "/tmp/kannel.log"
#log-level = 0
box-deny-ip = "*.*.*.*"
box-allow-ip = "127.0.0.1"
#admin-deny-ip = ""
#admin-allow-ip = ""
#access-log = "access.log"

group = wapbox
bearerbox-host = localhost
#log-file = "/tmp/wapbox.log"
#log-level = 0
syslog-level = none

　　After starting the gateway (./bearerbox & ; ./wapbox &, you can use it to access wml pages. Hurry up and download an emulator. You can use Nokia Toolkit, Erission WapIDE, UP.SDK, Motorola and other emulators for testing. If you have a WAP phone and the Linux machine with the gateway installed is connected to the Interner, you can dial 172. Set the gateway in the phone to your machine's IP address, and then you can browse the Internet on your phone. The main settings needed on the phone are:

　　Gateway address: xxx.xxx.xxx.xxx （the IP address of your gateway machine）

　　Port number: 9201（general setting） 9200（connectionless mode）

　　Connection type: ordinary phone line

　　Baud rate: 9600

　　Username: wap

　　Password: wap

　　Phone number: 172

　　Homepage: http://wap.china.com (the URL you want to visit)

2.2. Program description

　　The gateway distributes the processing load across multiple hosts and is divided into two modules. The gateway system consists of one bearerbox and one or more wapboxes. bearerbox and wapbox can run on different machines.

2.2.1.bearer box

　　The Bearerbox module connects to the ＣＳＤ router, provides an interface to Wapbox, and implements the ＷＤＰ layer of the ＷＡＰ protocol stack.

　　Bearerbox records the currently running wapboxes, receives UDP packets from the CSD router, routes packets received from the same terminal to the same wapbox, and after receiving the processing result from the wapbox, sends it to the corresponding user terminal.

2.2.2.wapbox

　　The wapbox module implements the upper part of the ＷＡＰ protocol stack. Sessions and transactions belonging to the same transaction are handled by the same wapbox. Wapbox implements the WTLS, WTP, and WSP layers. Wapbox receives HTTP-like requests from the phone, sends the actual HTTP request to the content server, compresses the response data, and sends it back to the terminal.

　　A TCP connection is established between bearerbox and wapbox. bearerbox acts as a server waiting for wapbox to connect. In this way, bearerbox does not need to keep a static wapbox list. It starts with an empty list and waits for wapbox registration. This design makes dynamically adding new wapboxes very convenient: just install one, configure it, and connect it to the corresponding bearerbox.

　　If the TCP connection between bearerbox and wapbox is disconnected, bearerbox will be notified and remove it from its own clients list. After the crashed wapbox is removed from bearerbox's clients list, packets received from terminals that should have been routed to this wapbox are treated as if they were received from a new terminal. This means the wapbox must be able to handle packets that are in the middle of a session.

　　It is also possible that the wapbox is still alive, but can no longer process any messages. To detect this situation, wapbox periodically sends heartbeat packets to bearerbox. If bearerbox fails to receive a heartbeat message, it assumes that the problematic wapbox has crashed but the TCP connection was not broken. bearerbox will disconnect the connection and remove it from the clients list. When the wapbox recovers, it will reopen the connection. The heartbeat message also includes the load of the wapbox, on the basis of which bearerbox performs load balancing.

2.3. Performance test

　　I carried out tests under the following environment. Three PCs were used in total: the CWAP gateway machine, a Web server, and a simulated client machine, connected through a 10M Ethernet. The machine specs were as follows:

　　WAP gateway:

　　Operating system: Linux RedHat7.0

　　CPU: Intel Pentium III

　　Clock speed: 500MHz

　　Memory: 128M

　　Web server:

　　Operating system: Windows 2000

　　CPU: Intel Celeron

　　Clock speed: 500MHz

　　Memory: 64M

　　Simulated client machine:

　　Operating system: Linux RedHat7.0

　　CPU: Intel Celeron

　　Clock speed: 500MHz

　　Memory: 128M

　　Start the gateway programs (bearerbox and wapbox) on the WAP gateway machine. On the simulated client machine, use the test program fakewap (in the test directory) to request the wml page on the Web server through the gateway, and gather data such as response time and number of requests processed per second.

　　The fakewap program uses multithreaded technology and can simulate multi-user concurrency. By default it uses port 9201 (WSP/WTP/WDP). Its usage is fakewap url ... The main options are as follows:

　　-g hostname gateway machine name or IP address (default: localhost)

　　-p port gateway port (default: 9201)

　　-m max total number of requests sent (default: 1)

　　-i interval interval between sending 2 requests (default: 1.0 seconds)

　　-c threads number of concurrent users (default: 1)

　　The test result was: with 100 concurrent users, the gateway response time was within 1 second, and the average number of requests processed per second was about 40. This is sufficient for the vast majority of enterprise applications.