This chapter describes the internal workings of the bearerbox: communication with SMSCs and UDP routers, internal major modules and data structures, threads, routing, error handling in routing, how it deals with the client box registrations and errors with client connections, and queueing of messages inside the bearerbox. The bearerbox connects to the SMSCs in the configuration, and accepts UDP packets at a suitable port. It checks whether SMS messages are normal ones or WDP packets. It routes stuff to appropriate boxes, taking care of load balancing. It keeps unsent messages in queues (incoming and outgoing), in case of traffic jams. It keeps track of the other boxes (lets them register, notices when connections break, keeps track of heartbeats). The bearerbox is implemented with several threads and lists to simplify program design and to increase efficiency. All distinct parts are encapsulated in separate modules which do not interact, thus making it easier to modify and upgrade things. SMSC module handles all connections with SMS centers, building up the connections, sending and receiving any SMS messages and closing the connections. It also does the required WDP assembly/disassembly when SMS is the WAP bearer (this is under development) UDP sender/receiver module receives and sends all WDP packets which are transferred via UDP packets. WAPbox connection module acts as a server for WAPboxes, allowing them to contact and sending and receiving messages. SMSbox connection module acts as a server for SMSboxes, allowing them to contact and sending and receiving messages. HTTP administration module acts as user interface for Kannel. It listens to HTTP commands to suspend, resume and to shutdown the gateway. It is only module calling back the main core of the gateway. Core module starts up each distinct module and is only module calling functions in various other modules. After it has started up the system, it waits until the gateway shuts down. Data flow in bearerbox is handled with 4 queues, which are seen by all the modules who would ever need them. This way each module does not need to know anything else about other modules, it simply waits for messages to arrive to queue it is listening to and if the queue is killed, it knows that the system is shutting down and continues the avalanche. Incoming SMS is a message queue for non-WAP SMS messages. These messages are received by the SMS Center module, which then puts messages into incoming SMS queue, from which the SMSbox connection module reads them. Outgoing SMS is a message queue read by the SMS Center module. SMSbox connections add any received messages to that queue, and SMS Center module routes them into proper SMS Center connection. Likewise, any WAP messages to be sent as SMS are first deassembled by the SMS Center module and then added to outgoing SMS queue, to be handled like any other messages. Incoming WDP is a queue for WAP packets, which have already been reassembled by the SMS Center module or directly received by the UDP sender/receiver module. This queue is read by a router in WAPbox connection module, which routes messages to WAP boxes which are connected to the bearerbox. Outgoing WDP is a queue for messages arriving from WAP boxes. Unlike other queues, it is listened in core module, which then routes messages either to UDP sender/receiver module or to SMS Center module for deassembly and SMS sending. As the bearerbox is started up, it reads the configuration from a file and then starts up any required systems. If any SMS centers are to be listened, it starts SMS Center module and SMSbox connection listener from the box connection module. In addition, if requested, it also starts WAPbox connection listener. Likewise, if the bearerbox is configured to listen to UDP packets, it starts up the UDP sender/receiver module and WAPbox connection module (if it has not yet already). In any case, the HTTP administration module is started up, to wait for requests from user. Bearerbox is shut down via ctrl-C from keyboard, SIGINT or SIGTERM signal from terminal or other process or by sending a shutdown command via HTTP administration interface. The shutdown is started by commanding SMS Center module and UDP sender/receiver module to begin it. These modules stop receiving any new messages from external systems and receive their producer status from incoming SMS and WDP queues. The avalanche continues in the box connections, which note after they have emptied incoming SMS and WDP queues that there are no more any producers for the queues, and so they send a closing command to connected SMS and WAP boxes. Likewise they remove their producer status from outgoing SMS and WDP queues. As outgoing message queues empty, SMS Center and UDP sender/receiver module notice that there are no producers anymore, so they close their sending parts, too, and die off. After all message receiver/sender and routing threads and modules have died, the main core thread wakes up from its sleep and sets status to dead, which exits HTTP administration and any remaining threads, if there are any. And after they have exited, the main core thread releases all reserved memory areas and exits, killing the program.