Simple Wireless Ad Hoc Distributed Network

R. Gill

I . Design Brief The scenario for this system is a (real!) remote encampment in northern Scandinavia. The encampment can only be reached by helicopter, and is serviced by three private helicopter companies providing access to the nearest town. Visitors and residents can book passage in or out of the encampment through any helicopter company. The number of seats on a helicopter flight is very limited and the companies are collectively responsible for satisfying demand, and must load-share as necessary. You have to design, build, test and demonstrate a distributed booking system for the helicopter companies. The focus of the project is on choosing an appropriate organization of the system and suitable algorithms for ticket booking and cancellation. The prototype implementation should use only sockets for communication between the parts of the system and should be written in Java. Your design may ignore security and availability concerns specifically you may assume that nodes and disks do not fail but you should allow for the possibility of communication failure. You need only provide a rudimentary user interface. However, in designing the system you should also consider that such a system might have to scale to support different deployments. 2. Description of the Functional and Technical Architecture The distributed network architecture is an ad hoc architecture based on the basic service set (BSS) of a wireless LAN modular paradigm; each module consisting of a server object and server object database, and a server client/s object. In such a network, wireless modules can form a network without the need of an access point (AP).

Figure 1. Wireless Ad hoc Network architecture

3. Overall System Flow In essence, the system comprises of multiple client-server modules each of which pass commands to all other connected client-server modules. Any query (command) passed to a server is also passed to all servers in the network; each server can receive commands and pass information to and from either clients or servers.

Figure 2. Overall System flow of events and processes

4. Functional Components

4.1 ticketClient functional components. Each client runs a ticketClient object jar file, and a configuration.txt file to provide module specific connection information, the configuration.txt file contains the IP and port number information for that particular module to which that ticketClient object and clientServer is assigned to.

Figure 3. ticketClient and ticketServer object functional components.

4.1.1 ticketClient Server Object (ticketClient jar, and config.txt file) The ticketClient Server Object is a java jar .exe file whose function is primarily that of providing a GUI interface for data input, data display, connection to the ticketServer object to which it is assigned to, generating random booking codes, and initiating the overall system flow process by sending commands to the ticketServer Object (See Figure 2). The config.txt file simply contains a single IP address and port number specific to the module, this provides a unique identity for the ticketServer Object. The ticketClient Server object file is replicated in all modules; a config.txt file is also replicated in all modules; however each config.txt file contains a different IP address and port for the module. (See Figure 3.) 4.1.2 ticketServer Server Object (ticketServer jar, serverlist.txt, and database) The ticketServer Object is a ticketServer jar .exe file whose function is to receive commands from the ticketClient. Depending upon the command, the ticketServer interrogates its own database for flight destinations and inserts or delete reservations, in parallel the ticketServer sends the same commands to other connected module ticketServer objects, thereby the command is only executed by the ticketServer module to which the command applies to. The serverlist.txt file contains the module Name, IP address and port number of all modules in the network. The ticketServer jar .exe uses the serverlist.txt data when sending commands to the network. The database is a simple MS Access database containing three tables. A system table containing the location of the module; a route table listing destinations of the module; and a reservation table containing booking information. Each database is replicated in all modules, however the location in the system table, and the destination in the route table varies. In effect the location and destination data are the starting location and ending destination of each flight for a particular module. 5. Message Passing The network behaviour and design is defined by a 12 stage message passing sequence between ticketClient and ticketServer/s, as graphically depicted in Figure 5. Each message passed incorporates 1-3 or 1-4 of the following sequence: 1. 2. 3. 4. ticketClient sends a command to ticketServer ticketServer acts on that command by initiating ticketServer functions ticketServer passes the same command to other connected ticketServers data/reponse from ticketServer and other connected ticketServers is passed to ticketClient as a consolidated response.

(See Figure 4)

Figure 4 Message Passing Sequence

Twenty three possible message passing events take place in the system as shown in Figure 5.

Figure 5. Message passing events and commands.

6. Mode of Communication Data is sent around the network as tokenised string packets, governed by the OSI Network Layer. These packets require path determination and logical addressing (IP) information, furnished by the Data Link / Network layer and serverlist.txt, config.txt files, respectively. The packets are tokenised for easier management of string bytes (words) for display in graphs and GUI text fields, and database query formation. 7. Multithreading and Sockets Multithreading is achieved by the ticketServer that implements as runnable public void run ( ). The run ( ) executes independently in each clientThread, thereby creating new instances for each clientThread. The run ( ) reads and processes commands from either other ticketServers or ticketClients. The socket is a piece of abstraction software used to represent the terminals between two entities (machine/node) in a network, for a given connection then, there exists a socket on each entity. Using Java a socket is created to make a connection between entities, with accompanying InputStream and OutputStream (or with convertors, Reader and Writer, respectively) from the socket to be able to treat the connection as an IO (input/outut) stream object. There are two stream;based socket classes: a ServerSocket at the server used to listen for incoming connections, and a Socket at the client used to initiate a connection. Once a client makes a socket connection the ServerSocket returns a corresponding server side socket using an accept ( ), through which direct communication may take place, at this point a socket to socket connection exists and both ends may be treated the same way, as they are in effect the same. Once the socket to socket connection is make, getInputStream ( ) and getOutput ( ) are used to produce corresponding InputStream and OutputStream objects from each socket. The function of the serversocket, then is to wait until another network entity connects to it, then to return an actual socket, in effect to create a socket when a network entity attempts to make a connection.The listening and established sockets are associated with the same serversocket, where the listening socket does not actually actually accept data in the form of packets, only requests for new connections. When creating a serversocket only port number is required, on creating a socket however both IP address and port number is required, in most cases the accept ( ) contains this information. 8. Scalability The network is easily scalable in 5 simple steps, extra modules can be added by 1) Replicating ticketClient and ticketServer and database components. 2) Assigning a module identity (location to database system table) 3) Assigning IP Address and Port to config.txt. 4) Adding Server Name, IP address, Port to serverlist.txt. 5) Replacing all serverlist.txt with new serverlist.txt. (For database management higher volume relational databases may be substituted for MS access. ) The combination of hashtables, map and linkedlist at the ticketClient provides for speed when accessing high data volume from multiple remote locations (nodes). The nature of this system

is such that it may be deployed in other booking arenas (such as theatre tickets, online stores etc, simply by manipulating the database tables to list different products, and performing different linkedlist searches. Full source code is available on request.

APPENDICES

APPENDIX I

Development Tools: Netbeans IDE 6.9.1, Sun Micro Systems. Access Database, Microsoft. Del Lattitude E5510, 2.27Ghz, 32bit. I3CPU.

ticketClient Class Diagram

ticketClient Class Diagram