Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

CSCI 204: Discrete Event Simulation Assignment for CS II, Assignments of Computer Science

An assignment for csci 204 students to design and implement a discrete event-driven simulation of an all-in-one-server web, ftp, and email server. Students are required to use a queue adt, document their work, and practice teamwork. The simulation involves generating and processing different types of events, maintaining an event list, and collecting statistics on waiting times and request counts.

Typology: Assignments

Pre 2010

Uploaded on 08/18/2009

koofers-user-lqn
koofers-user-lqn 🇺🇸

10 documents

1 / 4

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Assignment 4, Final Project CSCI 204: Introduction to Computer Science II
Assignment 4: Discrete Event-Driven Simulations
April 9th, 2007
1 Objectives
Use a Queue ADT
Use software tools: JavaDoc
Write documentation: technical specification
Revise your work
Practice basic team work
2 Important Dates
Phase 1 due Monday 4/16 at 5pm
Phase 2 due Monday 4/23 at 5pm
Phase 3 due Tuesday 5/1 at 5pm
Since you are asked to implement different portions of the project in different phases, all three phases are required.
3 Overview
In a team of three or two, write a program to simulate the behavior of a web server with a waiting queue. The simulation
here is a Discrete Event Driven Simulation. The simulation is based on events happening in the system over time.
The web server tosimulate is called All-In-One-Server, orAIOS, which provides webservice, ftp service, and email
service over the Internet.
The AIOS waits for requests for service over the Internet. When a service request arrives, it can be one of three
types, WEB, FTP, or EMAIL. A WEB service takes a random amount of time between 3 to 5 minutes to complete;
an FTP service takes a random amount of time between 5 to 10 minutes to complete; while an EMAIL service takes
a random amount of time between 4 to 7 minutes to complete. The inter-arrival times between the WEB, FTP and
EMAIL traffic are random values of 10 to 28 minutes, 15 to 30 minutes, and 20 to 30 minutes, respectively. The FTP
and EMAIL do not generate other consecutive requests when they finish service. The WEB service, however, will
generate a new WEB service request with a probability of 30%, a new FTP service request with a probability of 20%,
and a new EMAIL service request with a probability of 15%. Note that a second-round WEB service will not generate
any further requests. You will need to make these two types of WEB events as different ones. One may generate further
service request, let’s call it WEB. One doesn’t, let’s call it WEBS for stop. The AIOS server can only service one
request at a time. If the server is servicing a request while another request arrives, the newly arrived request has to be
put into a waiting queue. When finishing serving a request, if any requests are waiting in the queue to be serviced, the
web server takes the first one off the queue and continues to serve the requests. If the waiting queue is empty, the web
server will be set idle.
The statistics your program need to collect include average waiting time, maximum waiting time, and counts for
each type of the service requests. The simulation will stop when the server has serviced 5,000 or more requests (all
types combined).
4 Some Technical Details
We will discuss some details here in this section.
Assigned April 9th, 2007
pf3
pf4

Partial preview of the text

Download CSCI 204: Discrete Event Simulation Assignment for CS II and more Assignments Computer Science in PDF only on Docsity!

Assignment 4: Discrete Event-Driven Simulations

April 9th, 2007

1 Objectives

  • Use a Queue ADT
  • Use software tools: JavaDoc
  • Write documentation: technical specification
  • Revise your work
  • Practice basic team work

2 Important Dates

  • Phase 1 due Monday 4/16 at 5pm
  • Phase 2 due Monday 4/23 at 5pm
  • Phase 3 due Tuesday 5/1 at 5pm

Since you are asked to implement different portions of the project in different phases, all three phases are required.

3 Overview

In a team of three or two, write a program to simulate the behavior of a web server with a waiting queue. The simulation here is a Discrete Event Driven Simulation. The simulation is based on events happening in the system over time. The web server to simulate is called All-In-One-Server, or AIOS, which provides web service, ftp service, and email service over the Internet. The AIOS waits for requests for service over the Internet. When a service request arrives, it can be one of three types, WEB, FTP, or EMAIL. A WEB service takes a random amount of time between 3 to 5 minutes to complete; an FTP service takes a random amount of time between 5 to 10 minutes to complete; while an EMAIL service takes a random amount of time between 4 to 7 minutes to complete. The inter-arrival times between the WEB, FTP and EMAIL traffic are random values of 10 to 28 minutes, 15 to 30 minutes, and 20 to 30 minutes, respectively. The FTP and EMAIL do not generate other consecutive requests when they finish service. The WEB service, however, will generate a new WEB service request with a probability of 30%, a new FTP service request with a probability of 20%, and a new EMAIL service request with a probability of 15%. Note that a second-round WEB service will not generate any further requests. You will need to make these two types of WEB events as different ones. One may generate further service request, let’s call it WEB. One doesn’t, let’s call it WEBS for stop. The AIOS server can only service one request at a time. If the server is servicing a request while another request arrives, the newly arrived request has to be put into a waiting queue. When finishing serving a request, if any requests are waiting in the queue to be serviced, the web server takes the first one off the queue and continues to serve the requests. If the waiting queue is empty, the web server will be set idle. The statistics your program need to collect include average waiting time, maximum waiting time, and counts for each type of the service requests. The simulation will stop when the server has serviced 5,000 or more requests (all types combined).

4 Some Technical Details

We will discuss some details here in this section.

4.1 Discrete Event Driven Simulation

Discrete event driven simulation is based on the sequence of events that take place in the system. The basic idea is that the simulation maintains an event list that keeps the events in the order of their event time , the time the event is supposed to take place. The simulation proceeds by taking the event off the event list in order and processing it. When processing an event, a new event might be generated and inserted into the event list, depending on the type of the event being processed. The event list is typically implemented as a priority queue where the nodes in the list in the queue are ordered by event time. A simulation program can be initialized in different ways. In this project, we take the approach we discussed in the class. A sequence of initial events are first generated and placed in the event list. This sequence of events may include three types of events, WEB, FTP and EMAIL. What you can do is first generate a sequence of initial WEB events, then a sequence of initial FTP events, followed by a sequence of EMAIL events. Once these initial events are generated, the simulation starts the processing of these events until the simulation time is exhausted. While processing events, new events may be generated. The new events could be more of the request, e.g. a WEB-COMPLETE event may generate more FTP request; or the new events could be of the type completing a request, e.g. WEB-COMPLETE, FTP-COMPLETE, and EMAIL-COMPLETE. If the current event is FTP-COMPLETE or EMAIL-COMPLETE, no new events will be generated. The main simulation loop will look as follows.

generate initial events (requests) and insert these events into the event list; while (the event list is not empty and the simulation time is not exhausted) { retrieve the first event from the event list; set the simulation time to be the event time; remove the first event from the event list; switch event type case WEB : processWEBevent; break; case WEBS: processWEBSevent; break; case FTP : processFTPevent; break; case EMAIL: processEMAILevent; break; case WEB_CMPL: processWEBComplete; break; case FTP_CMPL: processFTPComplete; break; case EMAIL_CMPL: processEMAILComplete; break; end switch end while }

When processing a new request event, the program checks to see if the server is busy. If the server is not busy, the newly arrived request will receive service right away. Note that in this example, receiving service doesn’t actually do much except printing out a piece of information indicating the simulation is processing a request event at a particular time, and the simulation will schedule a finishing event for this request. Here scheduling an event means inserting an event of a particular type (some type of completing event) into the event list according to the time the event is to take place. Note when inserting the completing event into the event list, there could be many requesting events that are

8 What To Hand In

You may use any existing classes and objects that you worked with in the labs or in the previous projects.

8.1 Phase 1

Design the major objects and methods for your program. Use both CRC cards which describe the name, the respon- sibilities, the knowledge, and the collaborators of the object. Then convert these into UML diagrams. You can use either a software tool such as dia to draw the diagram or hand-drawing the diagram. Specifically you should design the following classes

  1. Event and its derived classes, RequestingEvent and CompletingEvent which describe the characteristics of the events
  2. EventList where all the events are maintained
  3. WebServer who serves various requests
  4. Simulation where the simulation actions take place

8.1.1 Phase 1 Handin

Submit the following items per team.

  • Team meeting minutes.
  • One set of CRC cards describing the above objects
  • One set of UML (dia or neatly hand-drawn) with all methods and member data
  • Technical specification with all major methods (include pre-conditions, post-conditions, inputs, output, and pur- pose) and all major data structures.

8.2 Phase 2

You should implement the event list, the FTP requesting and FTP COMPLETING event, and the general simulation scheme. You should be able to execute the simulation with only the FTP requesting and completing events. Note that this would be almost identical to what the bank simulation does. Submit the following items per team.

  • Team meeting minutes.
  • Complete, well-documented program in paper form. No JavaDoc in paper form is needed.
  • Complete, well-documented program in electronic form, along with generated JavaDoc files.

8.3 Phase 3

Submit the following items per team.

  • Team meeting minutes.
  • Complete, well-documented program in paper form.
  • Complete, well-documented program in electronic form, along with generated JavaDoc files. Each individual team members please turn in a description of how you worked on your team. Estimate how much time you put into the team project. This can be a few paragraphs, no more than a page. Please use a word processing software to write this description.