The Bearer Box
This section explain how the bearer box works: its internal architecture with messages, message queues, thread structure, heartbeats inside the box, and how communication between internal and external modules happens. At the moment, the bearerbox implements only UDP as a bearer for the WAP protocol stack. In the future, it will support SMS messages as well. The bearerbox already implements the necessary SMS center connections, but they are used for SMS gateway functionality only, and are thus ignored for this thesis. (This is true in spite of an implemented WAP Push. Using SMS as a pull bearer requires reassembly of SMS messages and routing them to one of wapboxes.)
The bearerbox receives UDP messages from the phones, sends them to wapboxes, receives reply messages from the wapboxes, and sends the corresponding UDP messages to the phones. Since there can be several wapboxes connected to a single bearerbox, the bearerbox needs to route the UDP packets so that all packets from the same phone are sent to the same wapbox. In practice, the routing problem is simplified so that all packets from the same IP number go to the same wapbox, even though it is not guaranteed that the IP number hasn’t been assigned to a new phone. Phones are allocated IP numbers dynamically - when they make the data call, they get an IP number, and when they terminate the call, the IP number is released and can be allocated to the next caller. Thus, it might make sense for the bearerbox to know when a WAP session or transaction is finished so that when the new phone uses the same IP number, it can be assigned to a different wapbox with a lower load. In practice, however, this is unlikely to have much benefit, so the added complexity is useless. It will be added, of course, if benchmarks later show it to be useful.
The bearerbox uses several internal threads and message queues. Figure 4-4 shows their structure. There can be multiple UDP sockets open, since the WAP protocol uses different UDP port numbers to identify the type of message: whether the message is for a session mode transaction or a sessionless transaction, whether it uses the security layer, etc. The bearerbox has a separate thread of type udp_receiver for each such UDP socket. That thread reads the UDP packets, converts them to message objects used internally within Kannel, and puts those into the incoming_wdp queue. All udp_receiver threads use the same queue.
The wdp_to_wapboxes thread removes the messages from the incoming_wdp queue and routes them to the correct wapbox. Each wapbox is represented inside the bearerbox by a separate message queue and two threads: boxc_sender and boxc_reader. The wdp_to_wapboxes thread thus moves messages from the incoming_wdp queue to the wapbox specific queues. The boxc_sender thread removes the messages from the wapbox specific queue and sends them to the wapbox proper via a network connection.
The message traffic in the other direction is a mirror image. The boxc_reader thread reads messages from the wapbox, via the network connection, and puts them in the outgoing_wdp queue. The wdp_router thread removes the messages from that queue and puts them in the queue specific for the socket, so that they will be sent from the correct port. The udp_sender thread then removes messages from the socket specific queue, converts them into UDP packets, and sends those to the phones.
Multiple queues within the bearerbox were used because routing can change at any time. If a wapbox disappears, all messages waiting to be sent to it should be sent to other wapboxes instead, so that they can be dealt with in a useful manner
Social Plugin