r51due

下面为大家整理一篇优秀的assignment代写范文- Internet and Web Systems，供大家参考学习，这篇论文讨论了一个用java编写的简单web服务器程序的项目，旨在处理各类http请求等相关任务。

We are all familiar with how one accesses a Web server via a browser. The big question is what is going

on under the covers of the Web server: how does it serve data?, what is necessary in order to provide the

notion of sessions?, how is it extended?, and so on.

This assignment focuses on developing an application server, i.e., a Web (HTTP) server that runs Java

servlets, in two stages. In the first stage, you will implement a simple HTTP server for static content (i.e.,

files like images, style sheets, and HTML pages). In the second stage, you will expand this work to emulate

a full-fledged application server that runs servlets. Java servlets are a popular method for writing dynamic

Web applications. They provide a cleaner and much more powerful interface to the Web server and Web

browser than previous methods, such as CGI scripts.

A Java servlet is simply a Java class that extends the class HttpServlet. It typically overrides the doGet

and doPost methods from that class to generate a web page in response to a request from a Web browser.

An XML file, web.xml, lets the servlet developer specify a mapping from URLs to class names; this is

how the server knows which class to invoke in response to an HTTP request. Further details about servlets,

including links to tutorials and an API reference, as well as sample servlets and a corresponding web.xml

file, are available on the course web site. We have also given you code to parse web.xml.

2     Developing   and running  your       code

We strongly recommend that you do the following before you start writing code:

1. Carefully read the entire assignment (both milestones) from front to back and make a list of the

features you need to implement.

2. Think about how the key features will work. For instance, before you start with MS2, go through

the steps the server will need to perform to handle a request. If you still have questions, have a look

at some of the extra material on the assignments page, or ask one of us during office hours.

3. Spend at least some time thinking about the design of your solution. What classes will you need?

How many threads will there be? What will their interfaces look like? Which data structures need

synchronization? And so on.

4. Regularly check your changes into the Git repository. This will give you many useful features,

including a recent backup and the ability to roll back any changes that have mysteriously broken

your code.

We recommend that you continue using the VM image we have provided for HW0. This image should

already contain all the tools you will need for HW1. If you have already checked out the code from your

CIS 455/555: Internet and Web Systems

2/10

Git repository, all you need to do to get the HW1 framework code is open a terminal and run “cd

~/workspace” followed by “git pull”. After this, there should be a new “HW1” folder in the workspace

directory; you can import this folder as a project into Eclipse using the same approach as in HW0.

Of course, you are free to use any other Java IDE you like, or no IDE at all, and you do not have to use any

of the tools we provide. However, to ensure efficient grading, your submission must meet the requirements

specified in 3.5 and 4.7 below – in particular, it must build and run correctly in the original VM image and

have a Maven build script (pom.xml). The VM image, and Maven, will be the ‘gold standard’ for grading.

We strongly recommend that you regularly check the discussions on Piazza for clarifications and solutions

to common problems.

2.1  Testing   your       server

To test your server, you have several options:

• You can use the Developer Tools in Chrome to inspect the HTTP headers. Open the menu, choose

“More Tools”, and click on “Developer tools”. This should pop up a new tab; click on “Network”

to open a list of all the HTTP requests processed by Chrome, click on a request for extra details,

and then click on “Headers” to see the headers.

• If you want to check whether you are using the correct headers, you may find the site websniffer.net

useful.

• You can use the telnet command to directly interact with the server. Just run telnet

localhost 80, type in the request, and hit Enter twice; you should see the server’s response. (If

your server is running on a different port, replace ’80’ with the port number.)

• You may also want to consider using the curl command-line utility to do some automated testing

of your server. curl makes it easy to test HTTP/1.1 compliance by sending HTTP requests that

are purposefully invalid – e.g., sending an HTTP/1.1 request without a Host header. ‘man curl’

lists a great many flags.

• To stress-test your server, you can use Apachebench (the ab command, which is already preinstalled

in the VM). Apachebench can be configured to make many requests concurrently, which

will help you find concurrency problems, deadlocks, etc.

We suggest that you use multiple options for testing; if you only use Firefox, for instance, there is a risk

that you hard-code assumptions about Firefox, so your solution won’t work with Chrome, curl, or ab.

You may also want to compare your server’s behavior with that of a known-good server, e.g., the CIS web

server. Please do test your solution carefully!

3 Milestone   1:    Multithreaded       HTTP/1.1 Server

For the first milestone, your task is relatively simple. You will develop a Web server that can be invoked

from the command line, taking the following parameters, in this order:

1. Port to listen for connections on. Port 80 is the default HTTP port, but it is often blocked by

firewalls, so your server should be able to run on any other port (e.g., 8080)

2. Root directory of the static web pages. For example, if this is set to the directory /var/www, a

request for /mydir/index.html will return the file /var/www/mydir/index.html.

(do not hard-code any part of the path in your code – your server needs to work on a different

machine, which may have completely different directories!)

3/10

Note that the second milestone will add a third argument (see below). If your server is invoked without any

command-line arguments, it must output your full name and SEAS login name.

Your program will accept incoming GET and HEAD requests from a Web browser (such as the Firefox

browser in the VM image), and it will make use of a thread pool (as discussed in class) to invoke a worker

thread to process each request. The worker thread will parse the HTTP request, determine which file was

requested (relative to the root directory specified above) and return the file. If a directory was requested,

the request should return a listing of the files in the directory. Your server should return the correct MIME

types for some basic file formats, based on the extension (.jpg, .gif, .png, .txt, .html); keep in mind that

image files must be sent in binary form — not with println or equivalent — otherwise the browser will not

be able to read them. If a GET or HEAD request is made that is not a valid UNIX path specification, if no

file is found, or if the file is not accessible, you should return the appropriate HTTP error. See the HTTP

Made Really Easy paper for more details.

MAJOR SECURITY CONCERN: You should make sure that users are not allowed to request absolute

paths or paths outside the root directory. We will validate, e.g., that we can’t get hold of /etc/passwd!

3.1  HTTP     protocol version   and features

Your application server must be HTTP 1.1 compliant, and it must support all the features described in

HTTP Made Really Easy. This means that it must be able to support HTTP 1.0 clients as well as 1.1 clients.

Persistent connections are suggested but not required for HTTP 1.1 servers. If you do not wish to support

persistent connections, be sure to include “Connection: close” in the header of the response.

Chunked encoding (sometimes called chunking) is also not required. Support for persistent connections

and chunking is extra credit, described near the end of this assignment.

HTTP Made Really Easy is not a complete specification, so you will occasionally need to look at RFC 2616

(the ‘real’ HTTP specification; http://www.ietf.org/rfc/rfc2616.txt) for protocol details. If

you have a protocol-related question, please make an effort to find the answer in the spec before you post

the question to Piazza!

3.2  Special   URLs

Your application server should implement two special URLs. If someone issues a GET /shutdown, your

server should shut down immediately; however, any threads that are still busy handling requests must be

aborted properly (do not just call System.exit!). If someone issues a GET /control, your server

should return a ‘control panel’ web page, which must contain at least a) your full name and SEAS login, b)

a list of all the threads in the thread pool, c) the status of each thread (‘waiting’ or the URL it is currently

handling), and d) a button that shuts down the server, i.e., is linked to the special /shutdown URL. It

must be possible to open the special URLs in a normal web browser.

3.3 Implementation     techniques

For efficiency, your application server must be implemented using a thread pool that you implement, as

discussed in class. Specifically, there should be one thread that listens for incoming TCP requests and

enqueues them, and some number of threads that process the requests from the queue and return the

responses. We will examine your code to make sure it is free of race conditions and the potential for

deadlock, so code carefully!

We expect you to write your own thread pool code, not use one from the Java system library or an external

library. This includes the queue, which you should implement by yourself, using condition variables to

block and wake up threads. You may not use the BlockingQueue that comes with Java, or any similar

classes.

4/10

3.4  Tips for   testing    and debugging

When you test your solution with Firefox or Chrome, you will sometimes see more than one request, even

if you open only one web page. This is because the browser sometimes checks whether there is an icon

(favicon.ico) for the web page; just handle this additional request as you would handle any other

request. Another common problem when requesting binary files, such as images, is that the file is not

displayed properly or is shown as ‘broken’. Typically, the reason is that your server is sending a few extra

bytes or is missing a few bytes, e.g., due to an off-by-one error; it might also be converting some

character sequences, e.g., a \n to a \r\n. Try saving the file to disk in the browser, and then compare its

length and contents to the original file.

When stress-testing your solution with Apachebench, you may sometimes see some failed connections

(“Connection reset by peer”). To fix this, try turning off any console logging during the stress test, since

this will slow down your server and prevent it from keeping up. You can also increase the second

argument to ServerSocket, which limits the number of connections that can be “waiting” at any given

time. Finally, you may want to try running the following two commands in a terminal:

sudo sh -c ‘echo 1024 > /proc/sys/net/core/somaxconn’

sudo sh -c ‘echo 0 > /proc/sys/net/ipv4/tcp_syncookies’

The first one increases a relevant kernel parameter, and the second disables a defense against denial-ofservice

attacks that is sometimes triggered by the benchmark.

3.5 Requirements

Your solution must meet the following requirements (please read carefully!):

1. Your main class must be called HttpServer, and it must be located in a package called

edu.upenn.cis455.hw1.

2. Your submission must contain a) the entire source code, as well as any supplementary files needed

to build your solution, b) a Maven build script called pom.xml (a template is included with the

code in your Git repository), and c) a README file. The README file must contain 1) your full

name and SEAS login name, 2) a description of features implemented, 3) any extra credit claimed,

and 4) any special instructions for building or running.

3. When your submission is unpacked in the original VM image and the Maven build script is run

(mvn clean install), your solution must compile correctly. Please test this before submitting!

4. Your server must accept the two command-line arguments specified above, and it must output your

full name and SEAS login name when invoked without command-line arguments.

5. Your solution must be submitted using the online submission system (see the link on the course

web page) before the relevant deadline on the first page of this handout. The only exception is if

you have obtainend an extension online (using the “Extend” link in the submission system).

6. You must check your submission into your Git repository after you submit it. Run “git status” in

the workspace directory to check for modifications, use “git add” to add any new files or directories

you created, and then run “git commit” followed by “git push”. Be sure to check whether these

commands actually succeed. If necessary, consult https://git-scm.com/documentation.

7. Your code must contain a reasonable amount of useful documentation.

You may not use any third-party code other than the standard Java libraries (exceptions noted in the

assignment) and any code we provide.

5/10

4     Milestone      2:    Servlet   Engine

The second milestone will build upon the Web server from Milestone 1, with support for POST and for

invoking servlet code. To ease implementation, your application server will need to support only one web

application at a time. Therefore, you can simply add the class files for the web application to the classpath

when you invoke you application server from the command line, and pass the location of the web.xml file

as an argument. Furthermore, you need not implement all of the methods in the various servlet classes;

details as to what is required may be found below.

4.1  The Servlet

A servlet is typically stored in a special “war file” (extension .war) which is essentially a jar file with a

special layout. The configuration information for a servlet is specified in a file called web.xml, which is

typically in the WEB-INF directory. The servlet’s actual classes are typically in WEB-INF/classes.

The web.xml file contains information about the servlet class to be invoked, its name for the app server,

and various parameters to be passed to the servlet. See below for an example:

51due留学教育原创版权郑重声明：原创assignment代写范文源自编辑创作，未经官方许可，网站谢绝转载。对于侵权行为，未经同意的情况下，51Due有权追究法律责任。主要业务有assignment代写、essay代写、paper代写、cs代写服务。

51due为留学生提供最好的assignment代写服务，亲们可以进入主页了解和获取更多assignment代写范文 提供作业代写服务，详情可以咨询我们的客服QQ：800020041。