Changes between Version 20 and Version 21 of NikySandbox/WebExample

Timestamp:

07/06/12 09:26:25 (12 years ago)

Author:

Mark Berman

Comment:

--

NikySandbox/WebExample

@@ -24 +24 @@
 [[Image(WebsrvExampleSliver.png, 50%)]]
 
-In this setup, there is one host acting as a web server. To test that the webserver is up visit the web page of the Server host. To do this:
-   * either press on the (i) button in Flack and then press the Visit button
-   * or open a web browser and go to the webpage !http://<pcname>.emulab.net, in the above example this would be !http://pc484.emulab.net). 
+In this setup, there is one host acting as a web server. To test that the webserver is up visit the web page of the Server host, use either of the following techniques:
+   * Press on the (i) button in Flack and then press the Visit button, or
+   * Open a web browser and go to the webpage !http://<pcname>.emulab.net. In the above example this would be !http://pc484.emulab.net.
 
 If the installation is successful you should see a page that is similar to this:
@@ -41 +41 @@
   * To '''Stop''' the webserver run:
     {{{
-    sudo /sbin/service httpd stop
+sudo /sbin/service httpd stop
     }}}
     To verify that you have stopped the webserver, try to visit the above web page, you should get an error. 
   *  To '''Start''' the webserver run:
     {{{
-    sudo /sbin/service httpd start
+sudo /sbin/service httpd start
     }}}
 
 === Command Line Web Transfers  ===
 
-Except from using a web browser you can also use command line tools for web transfers. To do this, follow these steps:
+Instead of using a web browser, you can also use command line tools for web transfers. To do this, follow these steps:
  * Log in to `Client1`.
  * You can download the web page using  this command
-   {{{
-   [inki@Client1 ~]$ wget http://server
+{{{
+[inki@Client1 ~]$ wget http://server
 --2012-07-06 04:59:09--  http://server/
 Resolving server... 10.10.1.1
@@ -66 +66 @@
 
 2012-07-06 04:59:09 (120 MB/s) - “index.html” saved [548/548]
-   }}}
-   '''Note:''' In the above command we used `http://server` instead of `http://pc484.emulab.net` so that we can contact the web server over the private connection we have created, instead of the server's public interface. The private connections are the ones that are represented with lines between hosts in Flack. 
+}}}
+   '''Note:''' In the above command we used `http://server` instead of `http://pc484.emulab.net` so that we can contact the web server over the private connection we have created, instead of the server's public interface. The private connections are the ones that are represented with lines between hosts in Flack. When you do load testing on your web server, you should run tests from the two client machines in your test configuration, using the `http://server` address, so that you are testing the performance of your server and not your Internet connection to the lab.
  
  * The above command only downloads the `index.html` file from the webserver. As we are going to see later a web page may include other web pages or objects such as images, videos etc. In order to force wget to download all dependencies of a page use the following options :
    {{{
-   [inki@Client1 ~]$ wget -m -p http://server
+[inki@Client1 ~]$ wget -m -p http://server
    }}}
    This will produce a directory, `server`, with the following data structure. Run:
    {{{
-  [inki@Client1 ~]$ ls server/
+[inki@Client1 ~]$ ls server/
 home.html  index.html  links.html  media  top.html
    }}}
@@ -94 +94 @@
   * Run 
   {{{
-    [inki@server ~]$ ls /var/www/html/
+[inki@server ~]$ ls /var/www/html/
   }}}
   This should give you a similar structure to the directory structure you got when you downloaded the whole site with wget on the previous steps. 
@@ -110 +110 @@
 Forever loop: 
 Listen for connections 
-    Accept new connection from incoming client 
-    Parse HTTP request 
-    Ensure well-formed request (return error otherwise) 
-    Determine if target file exists and if permissions are set properly (return error otherwise) 
-    Transmit contents of file to connect (by performing reads on the file and writes on the socket) 
-    Close the connection (if HTTP/1.0)
+ * Accept new connection from incoming client 
+ * Parse HTTP request 
+ * Ensure well-formed request (return error otherwise) 
+ * Determine if target file exists and if permissions are set properly (return error otherwise) 
+ * Transmit contents of file to connect (by performing reads on the file and writes on the socket) 
+ * Close the connection (if HTTP/1.0)
 
 You will have three main choices in how you structure your web server in the context of the above simple structure: 
 
-1) A multi-threaded approach will spawn a new thread for each incoming connection.  That is, once the server accepts a connection, it will spawn a thread to parse the request, transmit the file, etc. 
-
-2) A multi-process approach maintains a worker pool of active processes to hand requests off to from the main server.  This approach is largely appropriate because of its portability (relative to assuming the presence of a given threads package across multiple hardware/software platform).  It does face increased context-switch overhead relative to a multi-threaded approach. 
-
-3) An event-driven architecture will keep a list of active connections and loop over them, performing a little bit of work on behalf of each connection.  For example, there might be a loop that first checks to see if any new connections are pending to the server (performing appropriate bookkeeping if so), and then it will loop overall all existing client connections and send a "block" of file data to each (e.g., 4096 bytes, or 8192 bytes, matching the granularity of disk block size).  This event-driven architecture has the primary advantage of avoiding any synchronization issues associated with a multi-threaded model (though synchronization effects should be limited in your simple web server) and avoids the performance overhead of context switching among a number of threads.
+ 1. A multi-threaded approach will spawn a new thread for each incoming connection.  That is, once the server accepts a connection, it will spawn a thread to parse the request, transmit the file, etc. 
+ 2. A multi-process approach maintains a worker pool of active processes to hand requests off to from the main server.  This approach is largely appropriate because of its portability (relative to assuming the presence of a given threads package across multiple hardware/software platform).  It does face increased context-switch overhead relative to a multi-threaded approach. 
+ 3. An event-driven architecture will keep a list of active connections and loop over them, performing a little bit of work on behalf of each connection.  For example, there might be a loop that first checks to see if any new connections are pending to the server (performing appropriate bookkeeping if so), and then it will loop overall all existing client connections and send a "block" of file data to each (e.g., 4096 bytes, or 8192 bytes, matching the granularity of disk block size).  This event-driven architecture has the primary advantage of avoiding any synchronization issues associated with a multi-threaded model (though synchronization effects should be limited in your simple web server) and avoids the performance overhead of context switching among a number of threads.
 
 You may choose from C or C++ to build your web server but you must do it in Linux (although the code should run on any Unix system).  In C/C++, you will want to become familiar with the interactions of the following system calls to build your system: socket(), select(), listen(), accept(), connect() .  We outline a number of resources below with additional information on these system calls.  A good book is also available on this topic (there is a reference copy of this in the lab).