Changes between Version 15 and Version 16 of NikySandbox/WebExample


Ignore:
Timestamp:
07/06/12 07:05:30 (12 years ago)
Author:
nriga@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • NikySandbox/WebExample

    v15 v16  
    9393  * Login to the `Server` host
    9494  * Run
    95     {{{
    96     [inki@server ~]$ ls /var/www/html/*
    97     }}}
    98    
     95  {{{
     96    [inki@server ~]$ ls /var/www/html/
     97  }}}
     98  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.
    9999
    100 You should also note that since index.html is the default file, web servers typically translate "GET /" to "GET /index.html".  That way index.html is assumed to be the filename if no explicit filename is present.  This is also why the two URLs http://www.cs.williams.edu and http://www.cs.williams.edu/index.html return equivalent results.
     100You should also note that since index.html is the default file, web servers typically translate "GET /" to "GET /index.html".  That way index.html is assumed to be the filename if no explicit filename is present.  This is also why the two URLs http://server (or http://pc484.emulab.net) and http://server/index.html  (or http://pc484.emulab.net/index.html) return equivalent results.
    101101
    102102When you type a URL into a web browser, the server retrieves the contents of the requested file.  If the file is of type text/html and HTTP/1.0 is being used, the browser will parse the html for embedded links (such as images) and then make separate connections to the web server to retrieve the embedded files.  If a web page contains 4 images, a total of five separate connections will be made to the web server to retrieve the html and the four image files.
    … …  
    104104Using HTTP/1.0, a separate connection is used for each requested file. This implies that the TCP connections being used never get out of the slow start phase. HTTP/1.1 attempts to address this limitation. When using HTTP/1.1, the server keeps connections to clients open, allowing for "persistent" connections and pipelining of client requests. That is, after the results of a single request are returned (e.g., index.html), the server should by default leave the connection open for some period of time, allowing the client to reuse that connection to make subsequent requests. One key issue here is determining how long to keep the connection open. This timeout needs to be configured in the server and ideally should be dynamic based on the number of other active connections the server is currently supporting. Thus if the server is idle, it can afford to leave the connection open for a relatively long period of time. If the server is busy servicing several clients at once, it may not be able to afford to have an idle connection sitting around (consuming kernel/thread resources) for very long. You should develop a simple heuristic to determine this timeout in your server.
    105105
    106 For this assignment, you will need to support enough of the HTTP/1.0 and HTTP/1.1 protocols to allow an existing web browser (Firefox) to connect to your web server and retrieve the contents of the Willams CS front page from your server.  (Of course, this will require that you copy the appropriate files to your server's document directory.) Note that you DO NOT have to support script parsing (php, javascript), and you do not have to support HTTP POST requests. You should support images, and you should return appropriate HTTP error messages as needed.
     106For this assignment, you will need to support enough of the HTTP/1.0 and HTTP/1.1 protocols to allow an existing web browser (Firefox) to connect to your web server and retrieve the content offered now by the Apache server from your server. Note that you DO NOT have to support script parsing (php, javascript), and you do not have to support HTTP POST requests. You should support images, and you should return appropriate HTTP error messages as needed.
    107107
    108108At a high level, your web server will be structured something like the following:
    … …  
    126126
    127127You 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).
    128 
    129 In this experiment, you'll be changing the characteristics of the link and measuring how they affect UDT and TCP performance.
    130 
    131  * Log into your delay node as you do with any other node. Then, on your delay node, use this command:
    132 {{{
    133 %sudo ipfw pipe show
    134 }}}
    135 
    136 You'll get something like this:
    137 {{{
    138 60111: 100.000 Mbit/s    1 ms   50 sl. 1 queues (1 buckets) droptail
    139     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
    140 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
    141   0 ip    207.167.175.72/0       195.123.216.8/6        7     1060  0    0   0
    142 60121: 100.000 Mbit/s    1 ms   50 sl. 1 queues (1 buckets) droptail
    143     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
    144 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
    145   0 ip   207.167.176.224/0         195.124.8.8/6        8     1138  0    0   0
    146 }}}
    147 
    148 This information shows the internal configuration of the "pipes" used to emulate network characteristics.
    149 (Your output may look different, depending on the version of ipfw installed on your delay node.
    150 In any case, the information you need is on the first line of output for each pipe.)
    151 
    152 You'll want to make note of the two pipe numbers, one for each direction of traffic along your link.
    153 In the example above, they are 60111 and 60121.
    154 
    155 There are three link characteristics we'll manipulate in this experiment: bandwidth, delay, and packet loss rate.
    156 You'll find their values listed in the ipfw output above.
    157 The link bandwidth appears on the first line immediately after the pipe number. It's 100Mbps in the example shown above.
    158 The next value shown is the delay, 1 ms in the example above.
    159 The packet loss rate (PLR) is omitted if it's zero, as shown above. If non-zero, you'll see something like '''plr 0.000100'''
    160 immediately after the "50 sl." on the first output line.
    161 
    162 It is possible to adjust the parameters of the two directions of your link separately, to emulate asymmetric links.
    163 In this experiment, however, we are looking at symmetric links, so we'll always change the settings on both pipes together.
    164 
    165 Here are the command sequences you'll need to change your link parameters.
    166 In each case, you'll need to provide the correct pipe numbers, if they're different from the example.
    167 
    168  * To change bandwidth (100M means 100Mbits/s):
    169 {{{
    170 sudo ipfw pipe 60111 config bw 100M
    171 sudo ipfw pipe 60121 config bw 100M
    172 }}}
    173 
    174  * Request a bandwidth of zero to use the full capacity of the link (unlimited):
    175 {{{
    176 sudo ipfw pipe 60111 config bw 0
    177 sudo ipfw pipe 60121 config bw 0
    178 }}}
    179 
    180  * To change link delay (delays are measured in ms):
    181 {{{
    182 sudo ipfw pipe 60111 config delay 10
    183 sudo ipfw pipe 60121 config delay 10
    184 }}}
    185 
    186  * To change packet loss rate (rate is a probability, so 0.001 means 0.1% packet loss):
    187 {{{
    188 sudo ipfw pipe 60111 config plr .0001
    189 sudo ipfw pipe 60121 config plr .0001
    190 }}}
    191 
    192  * You can combine settings for bandwidth, delay, and loss by specifying more than one in a single ipfw command. We'll use this form in the procedure below.
    193 
    194 == Experiment Procedure ==
    195 
    196  * Set your link parameters to use maximum bandwidth, no delay, no packet loss:
    197 
    198 {{{
    199 sudo ipfw pipe 60111 config bw 0 delay 0 plr 0
    200 sudo ipfw pipe 60121 config bw 0 delay 0 plr 0
    201 }}}
    202 
    203  * Verify with
    204 
    205 {{{
    206 sudo ipfw pipe show
    207 60111: unlimited    0 ms   50 sl. 1 queues (1 buckets) droptail
    208     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
    209 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
    210   0 ip    207.167.175.72/0       195.123.216.8/6        7     1060  0    0   0
    211 60121: unlimited    0 ms   50 sl. 1 queues (1 buckets) droptail
    212     mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
    213 BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
    214   0 ip   207.167.176.224/0         195.124.8.8/6        8     1138  0    0   0
    215 }}}
    216 
    217 Note that bandwidth is set to ''unlimited'', delay to ''0 ms'', and no PLR is shown.
    218 
    219  * Using this initial setting, try a few UDT transfers, including the larger files. Now try FTP transfers. Record the transfer sizes and rates.
    220 
    221  * Now change the link parameters to reduce the available bandwidth to 10Mbps:
    222 
    223 {{{
    224 sudo ipfw pipe 60111 config bw 10M delay 0 plr 0
    225 sudo ipfw pipe 60121 config bw 10M delay 0 plr 0
    226 }}}
    227 
    228  * Repeat your file transfers with the new settings. As before, note the transfer sizes and rates, as well as the link settings.
    229 
    230  * Continue with additional trials, varying each of the three link parameters over a range sufficient to observe meaningful performance differences. Record your data.
    231 
    232 == What to hand in ==
    233 
    234  1. Your raw data and appropriate graphs illustrating changes in performance for the two transfer protocols with differing link parameters.
    235  1. Your analysis. Here are some questions to consider.
    236   a. Does one protocol outperform the other?
    237   b. Under what conditions are performance differences most clearly seen? Why?
    238   c. What shortcomings in the experiment design may affect your results? How might you improve the experiment design?
    239   d. What interesting characteristics of the transfer protocols are not measured in this experiment? How might you design an experiment to investigate these?