In this chapter we discuss the design concepts for the wireless Ad Hoc Pocket PC Instant Messenger application. First, we show the system classes developed and data flow between these classes. Second, we show how we use XML-based data structures to represent data packets exchanged between Pocket PCs. Third, we show how to use the design concept of XML "topology" configuration files to represent the relative physical locations of Pocket PCs for ease of testing and validating the application. Finally, design considerations are given for the graphical user interface on Pocket PC.

4.1 System Architecture
4.2 XML-Based Data Structure for Packet Representation
4.3 Network Topology Design
4.4 User Interface Consideration

4.1 SYSTEM ARCHITECTURE

4.1.1 Basic Architecture of the Program

The basic architecture of the application is similar to Lam (2002) C# implementation for the PC version. The whole architecture of Pocket PC Ad Hoc Instant Messenger is very simple, involving three classes:

1. TcpUdpServer - this class handles all the UDP server functionalities, like listening to connections and receiving UDP messages;
2. TcpUdpClient - this class handles all the client functionalities including sending UDP Packets;
3. WinChatFormLibrary - this class handles all the User Interface with Windows Form Controls, and also acts as a middle agent for the communication between TcpUdpClient and TcpUdpServer. Users use GUI to initialize sending packets, and also use the GUI to handle and display the received packets.

4.1.2 System Data Flow

Awareness Stage. First, at the beginning of the application, each Pocket PC tries to broadcast its information (Pocket PC ID, IP Address, to the Path reach other Pocket PCs, busy status, neighbor status, etc) to other Pocket PCs. If we consider the network topology as Diagram 4.1, then the "Awareness" process is illustrated in the Diagram 4.2.

Diagram 4.1 Nodes Network Topology

In the "Awareness" process, when Pocket PC node A joins the existing session of a wireless Ad Hoc network consisting of nodes B and C, the following steps would happen (in the following, we ignore the broadcasting packets sent to itself, because we will ignore those packet in the program anyway):

Diagram 4.2 Awareness Process

1. The user interface begins the broadcast by calling TcpUdpClient, a process this is started when the user clicks "Start" to join and search and join the session.
2. TcpUdpClient broadcasts the "Awareness" Packet to other nodes using the UDP client-send function. Because A can reach Node B when B's TcpUdpServer receives the Packet.
3. B's TcpUdpServer notifies its user interface class, so now B's "Buddy" list adds Node A.
4. B's WinChatFormLibrary will notify TcpUdpClient to re-broadcast the packet.
5. Since B can reach both A and C, B's TcpUdpClient sends the packet to A's and C's TcpUdpServer at the same time.
6. Node A will handle the Packet from A's TcpUdpServer. Now since A's ID in the Packet's Original sender ID, A will ignore the packet; Node C will update its "Buddy' list, and also will notice that A is not its neighborhood node.
7. Node C asks its TcpUdpClient to re-broadcast the Packet;
8. One of C's Packets now will reach B again; other Packet will reach other nodes.
9. B will notify its User Interface (WinChatFormLibrary). Now since B's ID is already on the Packet Path, B will just ignore it. Otherwise, it ill cause infinite broadcast loop.
   

This process not only can happen during the startup stage, but also we can set a timer such that this process will re-broadcast in fixed time interval (for example, every 20 seconds). The basic steps are pretty much the same.

Route Request Stage. Suppose that now A have both B and C as its "Buddy". Although we can use the route path information obtained during the "Awareness" stage, we still want to implement this step for the reason that the path could be changed after "Awareness" stage. Also, route request is an important component of DSR protocol.
Diagram 4.3 displays this process. The following steps happen during "Route Request" (we ignore the broadcasting packets sent to node itself):

Diagram 4.3 Route Request Process

1. A's user interface (WinChatFormLibrary) begins the broadcast by calling TcpUdpClient, which is started when the user selects one "Buddy" and click "Chat" to search for a route to reach the selected "Buddy".
2. TcpUdpClient broadcasts a "Route Request" Packet to other nodes using the UDP client-send function. Because A can reach Node B, B's TcpUdpServer receives the Packet.
3. B's TcpUdpServer will notify its user interface class. If B is A's intended chat buddy, then a route request process stops here; If not, B puts its ID in the Packet Path field.
4. Otherwise, B will help A's request by re-broadcasting the packet to other nodes.
5. Since B can reach both A and C, B's TcpUdpClient sends "Route Request" Packet to A's and C's TcpUdpServer at the same time.
6. Node A will handle the Packet from A's TcpUdpServer. Since A's ID in the Packet's Original sender ID, A will ignore the packet; If Node C is the A's intended chat "Buddy', C adds itself ID in the Path. The "Route Request" process stops here.

Route Reply Stage. Suppose that now C gets the "Route Request" packet, as well as the request from A to chat with C. C can send back the "Route Reply" Packet with information whether C wants to chat with A or not, as well as the Route information back to A. Even C does not want to chat with Node A, Node A can still receive a reply packet with the path from A to C (in this case, it is A->B->C). Because C already has the Path from A to C, Node C can just use the reverse path to piggyback the "Route Reply" packet without using broadcasting. Here are the steps (Diagram 4.4):

Diagram 4.4 Route Reply Process

7. Node C decides whether to accept A's request or not, and put this information in the Packet. Also, node C uses the reverse Path information during "Route Request"(C->B->A); node C can decide the next Node to send Packet to is Node B.
8. C's TcpUdpClient directly sends a Packet to B's TcpUdpServer.
9. B Checks the Packet information. Since the destination is not B, B needs to re-direct the packet to the next node. B checks the reverse Path gain, and knows that the next node is A.
10. B's WinChatFormLibrary will notify its TcpUdpClient.
11. B's TcpUdpClient directly sends a Packet to A's TcpUdpServer.
12. A receives the packet, and now A gets the route path to C. Also, based on node C's response, A decides to launch a Chat interface or not.
    

Chat Stage. Suppose that now Node A gets the "Route Reply" packet with the Path information (A->B->C). A can just utilize this path information to chat with C. Node A will put its message payload in the packet. Here are the steps (Diagram 4.5):

Diagram 4.5 Chat Process

13. Node A puts the payload in the "Chat" Packet. Also, node A uses the route path to decide the next Node to send the Packet to is B. A's WinChatFormLibrary will notify its TcpUdpClient to send the Packet.
14. A's TcpUdpClient directly sends a Packet to C's TcpUdpServer.
15. B Checks the Packet information. Since the destination is not B, B needs to re-direct the packet to the next node. B checks the Path gain, and the next node is C.
16. B's WinChatFormLibrary will notify its TcpUdpClient to forward the Packet.
17. B's TcpUdpClient directly forwards the Packet to C's TcpUdpServer.
18. C receives the packet and displays A's Message payload d in the Chat interface. If C wants to chat with A, the same steps apply to the Node C.

Hang-up Stage. Suppose that now Node A wants to "Hang-up" the chat session. Node A will send a "Hang-up" packet to C. The process is the same as the "Chat" stage. The only difference is the Packet Type. When C receives it, instead of displaying message payload, C will be notified that A wants to terminate the session.

4.2 XML-BASED DATA STRUCTURE FOR PACKET REPRESENTATION

We use Extended Markup Language (XML) to represent the "Awareness", "Route Request", "Route Reply", "Chat" and "Hang-up" packets. Microsoft Compact Framework has an XML class that can parse and create XML-based packets easily.

4.2.1 Awareness Packet

An Awareness Packet has 7 nodes; here is the XML structure of Awareness Packet:

First Child node is the "Type"; the value is "Alive" for all awareness packets. "OIP" is the original IP address of the sender. "OID" is the first sender's ID who sends the packet. "CID" is the current ID in the broadcasting path. "Busy" describes the status of the original node; the value can be "Busy" or "Free". If the packets are sent from its neighbor, then "Neighbor" is "Yes ", otherwise, it is "No". "Online" describes the original sender's current online status, either "On" or "Off". "Path" records the broadcasting path the packet has gone through during the broadcasting.

4.2.2. Route Request Packet

A Route Request Packet has 5 children nodes. First Child node is the "Type"; the value is "Request" for all Route Request packets. "OID" is the first sender's ID who sends the packet. "CID" is the current ID in the broadcasting path, while "DID" is the destination ID. "Path" records the broadcasting path the packet has gone through during the broadcasting route discovery. "BPath" is the reverse path for route discovered. Here is the XML structure of Awareness Packet:

	<Packet> <Type>Request</Type> <OID>A</OID> <CID>B</CID> <DID>C</DID> <Path>A;B;</Path> <BPath>B;A;</BPath> </Packet>
Diagram 4.7 Route Request Packet

4.2.3. Route Reply Packet

A Route Reply Packet has 7 children nodes. First Child node is the "Type"; the value is "Reply" for all Route Request packets. "OID" is the first sender's ID who sends the packet. "CID" is the current ID in the broadcasting path, while "DID" is the destination ID. "Path" records the broadcasting path the packet has gone through during the broadcasting route discovery. "BPath" is the reverse path for route discovered. "Status" displays the original node busy or free status. "Accept" will provide whether original node accept Chat request or not.

4.2.4 Chat Packet

A Chat Packet is similar to a Route Request Packet except that the "Type" is "Chat" and there is an additional "Payload" node. The "Payload" node is the place to store the chat payload message.

4.2.5 Hang-up Packet

A Han-up Packet is similar to a Route Request Packet except that the "Type" is "Hangup".

4.3 NETWORK TOPOLOGY DESIGN

The 802.11b standard is aimed at the wireless Local Area Network (WLAN) market, and allows connections across ranges as great as 100 meters, depending on power level. Although this is good news for end user, it is bad news for testing our wireless Ad Hoc Pocket PC Instant Messenger application. For example, if we want to test the route request and reply capability of the application, because all Pocket PC can reach each other within 100 meters, then it is quite a challenge to test the application.

Instead of hard coding the network logic into the programming application, we design a configuration file that represents the network topology. During the application initiation stage, each Pocket PC reads from the configuration file into memory, thus holding the network topology information in the memory for all future references. Then during the data flow, even node A can reach C directly, we can use the topology information to block or ignore the data flow directly between Node A and Node C. The benefit of using a configuration file also includes flexibility of modification. We can modify the configuration file to reflect the network changes to meet our testing needs.
Because of Microsoft .Net platform's support of XML parse and creation, in this project XML-based configuration files are used to represent the network topology. We discuss two examples of XML configuration files and their corresponding network topologies.

Diagram 4.11 illustrates a network topology and its corresponding XML configuration files. In this case, A and C must use one other node to reach each other, B and D also need another node.

	<?xml version="1.0"?> <configure> <A>B;C;</A> <B>A;C;</B> <C>B;D;</C> <D>C;D;</D> </configure>
Diagram 4.11 Three Hops Topology and XML file

Diagram 4.12 illustrates a network topology and its corresponding XML configuration files. In this case, A and D must use two nodes (B and C) to reach each other.

	<?xml version="1.0"?> <configure> <A>B;</A> <B>A;C;</B> <C>B;D;</C> <D>C;</D> </configure>
Diagram 4.12 Four Hops Topology and XML file

4.4 USER INTERFACE CONSIDERATION

Transitional Windows Graphical User Interface (GUI) implements the "Form" concept. Software applications cerate or destroy Forms for users' interactions. During the design and implementation of the User Interface on Pocket PC, we find that Multiple Forms application does not achieve good performance. The original design uses two Forms: Buddy List Form and Chat interface Form. We find that when we switch between two Forms, Pocket PC does not promptly paint the screen due to its low CPU computing power and small memory capability.

Based on this finding, we put both screens on the same User Form, with each screen being controlled by one Panel control. Depending on the user interaction, a Panel control would display at a proper position on the Pocket PC screen, while the other Panel control just hides itself. By using this approach, we dramatically reduce the delay between two screens. Here is the screenshot of the user interface design (Diagram 4.13):

Diagram 4.13 One Form User Interface Approach

Another consideration for the User Interface is the use of .Net Framework's MessageBox API. We uncover that MessageBox has a bug in the project implementation. Usually in a Windows environment, Call MessageBox API will display a MessageBox on top of the Forms. While in Pocket PC, this API will display at the bottom of the Form sometimes, thus causing confusion and error. We solve this problem by designing our own "MessageBox" using the same technique described before. Just use another Panel control to construct a group of Window controls to represent the "MessageBox".