Designing the web server simulator: helpful hints and information

 

1. Start with the applet. You will need a Start button, a textarea for output, a textfield to display the clock value (initially 0), plus textfields for each of the following integer inputs. Each has a default value which should be displayed in the field, but which can be changed by the user.

  1. maximum time between web page requests in milliseconds (default 50)
  2. minimum web page size in bytes (default 500)
  3. maximum web page size in bytes (default 8000)
  4. transmission capacity in bits per second (default 1544000)
  5. length of simulation run in seconds (default 60)

2. The key applet component will be the Start button's action listener. It will first need to get all the input fields (1a through 1e) and convert them to integers, using code similar to that from the BagApplet in Homework 3, e.g.

try
{
	String userInput = targetText.getText( );
	int whatever = Integer.parseInt(userInput);
	.....
}
catch (NumberFormatException e)
{
	feedback.append("invalid input.\n");
	targetText.requestFocus( );
	targetText.selectAll( );
} 

3. After capturing all the inputs, the Start button's action listener then needs to create a Simulation object and call its run method. It should pass the following values to the run method as parameters:

  1. through f. the five user inputs listed in 1a through 1e above plus minimum time between arrivals (fixed at 1 millisecond). To avoid "unit confusion" later on, I strongly recommend converting all time units to microseconds and all size units to bits. This will make life easier for the run method!! Leave the transmission capacity in bits per second (this is universal standard).
  1. a reference to the clock display textfield.
  2. a reference to the simulation output textarea.

4. Steps 2 and 3 are all that the Start button's action listener needs to do.

5. Turn your attention next to the Simulation class. Its constructor will create the clock, FEQ (which is a PrioQueue), and transmission port objects. It should also create all required Statistic objects, described in item 10 below. (This is a design choice; all of these things can alternatively be done in the run method. Doing them in the constructor forces the client to create a new Simulation object for each simulation run -- this will happen in the Start button's action listener anyway). Subsequently, all activities will be coordinated by its run method. Run is described in the next several items.

6. The actions of the run method are described in item 5 under Program Structure in the assignment. These are repeated in greater detail below. I strongly recommend you write the run method to expect all time parameters to be in microseconds (see #3 above) and all size parameters to be in bits. By doing this, time units at the user interface level can be modified without affecting any internal software component.

7. Run has two preliminary tasks to perform.

  1. One is to schedule the end of the simulation! The ending time was passed as a parameter (see item 3 above), so all it needs to do is create a SimEvent object with that time and type 0 then insert it into the FEQ.
  2. The other is to schedule the first web page request. You will need to determine the time at which this request will occur, then create a SimEvent object with that time and type 1 and insert it into the FEQ. To determine arrival time, you need to get a randomly-generated number which is no less than the minimum (1000 microseconds) and no greater than the maximum (set by user, default 50,000 microseconds).

8. Here is a way to generate integer random values within a specified range. Call the low end of the range min and the high end max. There are a couple ways to do this; I’ll recommend the following: create a Random object, then use its nextInt(int N) method to get random values. This will return an integer in the range 0 through N-1. Your code then should look something like this:

ArriveTime = clock.getTime() + randu.nextInt(max-min+1) + min;

(the +1 will assure that the highest value added to the current clock value is actually max and not max-1). For step 7b, the clock will have value 0, but for subsequent arrivals it will not (see step 12 below).

 

9. Simulation activity is ultimately controlled by the run method’s loop. Each loop iteration will follow this sequence:

  1. Do FEQ.getFront() to remove and return the first SimEvent from the Future Events Queue. Note: this queue should never be empty, but if it is, treat it just like a type 0 SimEvent.
  2. Set the simulation clock variable to the time value stored in the SimEvent object. Display the updated clock value on the user interface.
  3. If the SimEvent is of type 0, exit the loop.
  4. If the SimEvent is of type 1, execute the code to handle a web page request arrival.
  5. If the SimEvent is of type 2, execute the code to handle a web page transmission completion.

I strongly suggest that d and e be designed as two private methods in the Simulation class called arrival and completion. This will reduce the length of the run method.

 

10. After exiting the loop, output simulation results to the textarea. The assignment describes the results in items 1 through 4 under Simulation Output. You will need several Statistic objects. These should be declared as instance variables of the Simulation class and created in its constructor (or alternatively in run). One Statistic object will be needed to record delay times, one will be needed to record web page size for all requested pages, and one will be needed to record web page size for all transmitted pages (these last two will not be the same if requests are still waiting to be transmitted when simulation stops).

11. Steps 7 through 10 describe what the run method of the Simulation class does.

12. The Simulation class's arrival method handles arrivals to new web page requests. It will follow this sequence:

  1. Create a new Entity object to represent the request. Web page request processing and retrieval are assumed to instantaneous (for this assignment), so we will prepare the Entity object for transmission. This object requires both the current clock time and the size of the web page. Since I recommended that the page size range min to max be converted to bits, the page size in bits should be randomly generated using the randu.nextInt(max-min+1) + min technique. Collect the page size Statistic.
  2. Check to see if the Transmission Port object is busy or idle. It will be initialized to idle by its constructor (which was called by Simulation constructor in step 5). Perform step c if it is idle and step d if it is busy.
  3. If the Transmission Port is idle, then the web page can be transmitted immediately. Set its status to busy, then schedule transmission completion. Create a SimEvent and give it type 2, the calculated completion time, and a reference to the Entity created in step a. Completion time will be current clock time plus the number of microseconds needed to transmit the file (based on file size and transmission rate). Collect the delay time Statistic (see step 10). In general, the value to collect is current clock time minus the clock time the entity was created. In this case the value is zero but in general it is not (see step 13d below). Then insert the SimEvent into the FEQ.
  4. If the Transmission Port is busy, insert the Entity object (created in step a) into the Transmission port's queue.
  5. Finally, create a new SimEvent object to represent the next web page request, and insert it into the FEQ. It is imperative that each arrival schedule its successor; otherwise the simulation will stop after the first request has been completed! The first arrival was generated before the control loop was entered, and this is described in steps 7b and 8 above. Since this is done in two different places, you should define a private method to perform it.

 

13. The Simulation class's completion method handles the completion of a web page transmission. It will follow this sequence:

  1. The SimEvent object that triggered this method has a reference to an Entity object. Get the web page size from that Entity object and collect it into the transmission Statistic (see step 10).
  2. Check to see whether the transmission port's queue is empty or not. Perform step c if it is empty and step d if it is not.
  3. If the transmission port's queue is empty, set the port's status to idle.
  4. If the transmission port's queue is not empty, get the first Entity from the queue then follow the same process as step 12c (to schedule its completion). Since this is done in two different places, you should define a private method to perform it.

 

That should just about cover it. Not in every detail, but in great detail.

To reiterate the default input parameters which were not included on the original handout.
1. Time between web page requests, in milliseconds. Low end of the range is fixed at 1 and default for high end of the range is 50.
2. Size of the page requested, in bytes. Default range is from 500 to 8000.
3. Transmission capacity, in bits per second. Default value is 1,544,000.
4. Time period to be simulated, in seconds. Default value is 60.

You can estimate transmission port utilization from this. Given the default values, there will be a web page request about once very 25 milliseconds, or 40 requests per second. An average request will be for about 4250 bytes, which is 34000 bits. So the demand on the system will be for about 40*34000 = 1,360,000 bits per second. Utilization should then be about 1,360,000/1,544,000 = 0.881 or just over 88%. This is pretty high, so expect significant queueing!

 

NOTE: The design described here is not an ideal object-oriented design because there is a higher degree of coupling between objects than necessary. One example is the simulation's run method displaying the clock value to the user interface each time the clock is updated. Ideally, the simulation's run mechanism would be isolated from the user interface. This can be done but it complicates the system structure somewhat. There is already enough complexity in this project!


[ Assignments | CSC 132 | Peter Sanderson | Computer Science | SMSU ]


Last reviewed: 30 November 2000

Peter Sanderson ( PeteSanderson@smsu.edu )