Project 5 - A Mobile Network Simulator

Due - Wednesday, December 12, 2007

The goal of this project is to give you more experience with linked lists and queues. You will use real data to implement a program that simulates basic message delivery in mobile networks. Your program will take as input actual traces of the on/off patterns of several laptops (henceforth referred to as nodes). It will also take as input synthetic data representing messages each node must send to the other nodes and the amount of time it takes to send each message. The output of your program will be a record of when each message transfer was successfully completed, for each interrupted transfer the time at which the interrupt occurred, and a list of the transfers that did not complete during the simulation period.

Examples

Trace File Processing

Your simulator will take as input N trace files, where N is the number of nodes being simulated. The files will be named node1.dat, node2.dat...nodeN.dat and will be stored in the directory where the program is run. Rather that pass N as a parameter to your program, your program will use the java.io.File class (see the isDirectory method and the list method) to dynamically determine the number of nodes being simulated.

Each trace file will contain several lines where each line is of the form time state. Time tells you the time at which the node changed state and state tells you the new state of the node. For example, 12 on indicates that the node turned on at time 12. Similarly, 52 off indicates that the node turned off at time 52. You may assume that each file is sorted by time.

Your program will preprocess the files and store the data in a linked list that you have implemented. The data portion of each list node will contain a time and all of the events that happen at that time. For example, if node 1 turns on at time 15 and node 2 turns off at time 15, the linked list will contain one node containing time 15 and <node 1 turns on, node 2 turns off>. Note that several events may occur during each time slot. Also note that you will need to design an appropriate class(es) to represent this data.

Once you have preprocessed the data, your simulator can easily determine the time of the next event(s) by retrieving the data from the first node in your list of events. At the bottom of this page, you will find several sample trace files.

Message Queues

Your simulator will also take as input N files containing synthetic data you will use to initialize your message queues. The files will be named node1.config, node2.config...nodeN.config and will also be stored in the directory where your program is run. See the discussion of Trace File Processing for hints on how to find these files.

Each config file will contain several lines where each line is of the form destination_node transfer_time. The destination_node is the receiver of the message and the transfer_time is the total number of time units it will take to transfer the message. You will implement a queue class and, for each node (the source), you will create a queue and enqueue an object (containing the destination node and transfer time) for each message represented in the node's config file. You will find several sample config files at the bottom of this page.

Simulation

The main logic of your simulator will start at time 0 and will process events until there are no more on/off events. The two primary events are (1) a node turns on (goes online) and (2) a node turns off (goes offline). However, you will also have to determine, based on the simulation time and the state of each node in the network, whether any of the following events occur:

Message Transfer Rules

  1. A node may send only 1 message at a time.
  2. There is no limit to the number of messages a node may simultaneously receive.
  3. If a transfer is interrupted, it must start again from the beginning at the next transfer attempt.
  4. If the front message in a node's message queue cannot be sent because the destination is offline, the node will dequeue the front message, enqueue at the rear of the queue, and try the next message. A node will continue to do this until it identifies a message that can be sent or it determines that none of the messages in its queue can be sent at the current time.

Output

The output of your program will be a log of the completed transfers, interrupts, and undelivered messages. Undelivered messages are the messages that remain in the source node's message queue at the end of the simulation run. The completed transfers will be logged in the form time: Completed from: source_node_id to: destination_node_id (example 18: Completed from: 2 to: 0). The interrupts will be logged in the form time: Interrupt from: source_node_id to: destination_node_id (example 31: Interrupt from: 0 to: 1). The undelivered messages will be logged in the form Incomplete transfer from: source_node_id to: destination_node_id. Below, you will find complete samples including .dat files, .config files, and output files. As part of your testing procedure, run your program on the sample input and compare your output to the sample output files. You may want to familiarize yourself with the Linux tool diff for this purpose

Samples

Each zip file below contains the .dat files, .config files, and output for a run of the simulator.

sample1.zip

sample2.zip

sample3.zip

sample4.zip

The zip file below contains several node.dat files you may use for testing.

data.zip

The python file below contains a small python program you can use to generate new config files.

generateconfig.py

A demonstration is not required for this project. However, I will award extra credit to students who make an appointment on or before December 12 to demonstrate a complete, working program.

Due 5:00PM, Wednesday, December 12, 2007

  1. Complete and submit your working code. Send me an email when you have submitted your code and I will respond to confirm that I have received your electronic submission. You do not need to submit a hard copy for this project.
  2. Make sure that each function is well documented. Your documentation should specify the type and function of the input parameters and output.
  3. Run your program on a variety of inputs ensuring that all error conditions are handled correctly.
Note: No portion of your code may be copied from any other source including another text book, a web page, or another student (current or former). You must provide citations for any sources you have used in designing and implementing your program.
Sami Rollins