Changes between Version 20 and Version 21 of NikySandbox/WebExample


Ignore:
Timestamp:
07/06/12 09:26:25 (7 years ago)
Author:
Mark Berman
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NikySandbox/WebExample

    v20 v21  
    2424[[Image(WebsrvExampleSliver.png, 50%)]]
    2525
    26 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:
    27    * either press on the (i) button in Flack and then press the Visit button
    28    * 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).
     26In 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:
     27   * Press on the (i) button in Flack and then press the Visit button, or
     28   * Open a web browser and go to the webpage !http://<pcname>.emulab.net. In the above example this would be !http://pc484.emulab.net.
    2929
    3030If the installation is successful you should see a page that is similar to this:
     
    4141  * To '''Stop''' the webserver run:
    4242    {{{
    43     sudo /sbin/service httpd stop
     43sudo /sbin/service httpd stop
    4444    }}}
    4545    To verify that you have stopped the webserver, try to visit the above web page, you should get an error.
    4646  *  To '''Start''' the webserver run:
    4747    {{{
    48     sudo /sbin/service httpd start
     48sudo /sbin/service httpd start
    4949    }}}
    5050
    5151=== Command Line Web Transfers  ===
    5252
    53 Except from using a web browser you can also use command line tools for web transfers. To do this, follow these steps:
     53Instead of using a web browser, you can also use command line tools for web transfers. To do this, follow these steps:
    5454 * Log in to `Client1`.
    5555 * You can download the web page using  this command
    56    {{{
    57    [inki@Client1 ~]$ wget http://server
     56{{{
     57[inki@Client1 ~]$ wget http://server
    5858--2012-07-06 04:59:09--  http://server/
    5959Resolving server... 10.10.1.1
     
    6666
    67672012-07-06 04:59:09 (120 MB/s) - “index.html” saved [548/548]
    68    }}}
    69    '''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.
     68}}}
     69   '''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.
    7070 
    7171 * 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 :
    7272   {{{
    73    [inki@Client1 ~]$ wget -m -p http://server
     73[inki@Client1 ~]$ wget -m -p http://server
    7474   }}}
    7575   This will produce a directory, `server`, with the following data structure. Run:
    7676   {{{
    77   [inki@Client1 ~]$ ls server/
     77[inki@Client1 ~]$ ls server/
    7878home.html  index.html  links.html  media  top.html
    7979   }}}
     
    9494  * Run
    9595  {{{
    96     [inki@server ~]$ ls /var/www/html/
     96[inki@server ~]$ ls /var/www/html/
    9797  }}}
    9898  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.
     
    110110Forever loop:
    111111Listen for connections
    112    Accept new connection from incoming client
    113    Parse HTTP request
    114    Ensure well-formed request (return error otherwise)
    115    Determine if target file exists and if permissions are set properly (return error otherwise)
    116    Transmit contents of file to connect (by performing reads on the file and writes on the socket)
    117    Close the connection (if HTTP/1.0)
     112 * Accept new connection from incoming client
     113 * Parse HTTP request
     114 * Ensure well-formed request (return error otherwise)
     115 * Determine if target file exists and if permissions are set properly (return error otherwise)
     116 * Transmit contents of file to connect (by performing reads on the file and writes on the socket)
     117 * Close the connection (if HTTP/1.0)
    118118
    119119You will have three main choices in how you structure your web server in the context of the above simple structure:
    120120
    121 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.
    122 
    123 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.
    124 
    125 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.
     121 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.
     122 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.
     123 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.
    126124
    127125You 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).