E-Mail:
Get our new Windows 7 eBook (PDF) for $7 with 70+ Tips. Download Now!

Build a push proxy gateway on Linux

  • No Related Post

Considering building your own push proxy on a Linux box? Then you might want to read this first. This article from IBM lays it all out for you so that you can get this proxy off of the ground right the first time. Well thought out and pretty easy to follow, I have to give them a thumbs up on the quality of this how-to article.

Introduction
This article continues where the developerWorks’ article Build a WAP gateway on Linux left off. In that article, I described how to install and configure the open source Kannel gateway and make it act as a Wireless Application Protocol (WAP) gateway. In this article, I discuss how to make the Kannel gateway serve as a push proxy gateway (PPG). I discuss the PPG core group settings and the push initiator (PI) interface settings in the Kannel configuration file. I also discuss how to run the PPG and how to set up a test environment for it.

Basic overview of push
A push mechanism is the delivery of unsolicited information to a mobile device. The process does not require user interaction. The WAP push system consists of a push initiator on the Internet that serves as the source of the information. The PI communicates with the PPG using a special protocol called Push Access Protocol (PAP) over HTTP. On the other side, the PPG communicates with the mobile device using another protocol called Over-The-Air (OTA). OTA can work on top of the Wireless Session Protocol (WSP) (in WAP 1.x) or WHTTP (in WAP 2.0). The PPG and the WAP gateway can be separate or combined into a single component.

The OTA protocol can support a number of bearers. They can be SMS, circuit switched, or packet switched.

Before continuing, let’s quickly discuss push contents. The information conveyed by push is actually contained in an XML file that consist of three different entities:

* Control entity: This part of the push contains the basic information and fields. The fields can include recipient address, expiry time, bearer type, delivery attempt time, and a URL to which a response is to be sent if delivery confirmation is requested by the push initiator.
* Content entity: This is the actual data that is received by the mobile device. The various content types are Service Indication (SI), Service Load (SL) and Cache Operation (CO).
* Capability entity: This entity determines the type of mobile device that is to be served. This is determined by WAP user agent profiling. The sender can indicate the hardware vendor and browser version and type of the intended recipients. This capability entity is then matched at the PPG to see which devices are compatible with the requested capability. If there is a match, the content is delivered by the PPG to that specific device.

What Do You Think?

 
35 queries / 0.425 seconds.