Changes between Initial Version and Version 1 of NikySandbox/WebExample


Ignore:
Timestamp:
07/02/12 14:17:58 (12 years ago)
Author:
nriga@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • NikySandbox/WebExample

    v1 v1  
     1[[PageOutline]]
     2= Sample Experiment: Writing a Web Server =
     3
     4== Purpose ==
     5
     6The goal of this experiment is to build a functional web server.  This experiment will guide you through you the basics of distributed programming, client/server structures, and issues in building high performance servers. 
     7
     8This experiment is based on a course [http://www.cs.williams.edu/~jeannie/cs339/assignment1/index.html assignment] used at the Distributed Systems Course offered by the [http://www.cs.williams.edu/ Computer Science Department of Williams College] and taught by [http://www.cs.williams.edu/~jeannie/ Professor Jeannie Albrecht].
     9
     10== Prerequisites ==
     11
     12Before beginning this experiment, you should be prepared with the following.
     13
     14 * You have GENI credentials to obtain GENI resources. (If not, see SignMeUp).
     15 * You are able to use '''Flack''' to request GENI resources.  (If not, see [https://www.protogeni.net/trac/protogeni/wiki/FlackTutorial the Flack tutorial]).
     16 * You are comfortable using '''ssh''' and executing basic commands using a UNIX shell.
     17
     18== Setup ==
     19
     20 * Download the attached [attachment:udt.rspec?format=raw rspec file] and save it on your machine. (Make sure to save in raw format.)
     21 * Start Flack, create a new slice, load rspec ''udt.rspec'' and submit for sliver creation (also fine to use omni, if you prefer). Your sliver should look something like this:
     22
     23[[Image(UDTExperimentSliver.png, 50%)]]
     24
     25== Techniques ==
     26
     27You will use the following techniques during this experiment.
     28
     29=== File Transfer Using UDT ===
     30
     31Follow these steps to perform a file transfer using UDT.
     32
     33 * Log into pc1 and pc2 in separate windows.
     34
     35 * On pc1, start a UDT file transfer server, using this command:
     36{{{
     37% pc1:~% /local/udt4/app/sendfile
     38server is ready at port: 9000
     39}}}
     40
     41 * On pc2, start a UDT file transfer client, using this command:
     42{{{
     43pc2:~% /local/udt4/app/recvfile pc1 9000 /local/datafiles/sm.10M /dev/null
     44}}}
     45You should see output like the following in your pc1 window, showing the results of the file transfer. Note the transfer rate.
     46{{{
     47new connection: 192.168.2.2:55839
     48speed = 7.14472Mbits/sec
     49}}}
     50
     51 * There are three data files available for transfer tests: '''/local/datafiles/sm.10M''' is 10MB, '''/local/datafiles/med.100M''' is 100MB, and '''/local/datafiles/lg.1G''' is 1000MB. Leave your transfer server running on pc1, and try transferring each of these files in turn by typing the appropriate commands on pc2. Keep track of the transfer rates in each case.
     52
     53 * You can leave your UDT server running or stop it with ctrl-C.
     54
     55=== File Transfer Using FTP ===
     56
     57Follow these steps to perform a file transfer using FTP.
     58
     59 * For a TCP-based (FTP) transfer, there's already a FTP server running on pc1. Log into pc2, and start an ftp client:
     60
     61(You type ''ftp pc1'', the user name ''anonymous'', and any password you want, although your e-mail address is traditional.)
     62
     63{{{
     64pc2:~% ftp pc1
     65Connected to PC1-lan1.
     66220 (vsFTPd 2.3.2)
     67Name (pc1:mberman): anonymous
     68331 Please specify the password.
     69Password:
     70230 Login successful.
     71Remote system type is UNIX.
     72Using binary mode to transfer files.
     73ftp>
     74}}}
     75
     76 * Still on pc2, request a file transfer. Note the reported file size, transfer time, and transfer rate.
     77
     78{{{
     79ftp> get med.100M /dev/null
     80local: /dev/null remote: med.100M
     81200 PORT command successful. Consider using PASV.
     82150 Opening BINARY mode data connection for med.100M (104857600 bytes).
     83226 Transfer complete.
     84104857600 bytes received in 8.91 secs (11491.9 kB/s)
     85}}}
     86
     87 * You can perform additional transfers with additional get commands. When you're done, exit the ftp client with the quit command.
     88
     89=== Viewing and Adjusting link characteristics ===
     90
     91In this experiment, you'll be changing the characteristics of the link and measuring how they affect UDT and TCP performance.
     92
     93 * Log into your delay node as you do with any other node. Then, on your delay node, use this command:
     94{{{
     95%sudo ipfw pipe show
     96}}}
     97
     98You'll get something like this:
     99{{{
     10060111: 100.000 Mbit/s    1 ms   50 sl. 1 queues (1 buckets) droptail
     101    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
     102BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
     103  0 ip    207.167.175.72/0       195.123.216.8/6        7     1060  0    0   0
     10460121: 100.000 Mbit/s    1 ms   50 sl. 1 queues (1 buckets) droptail
     105    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
     106BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
     107  0 ip   207.167.176.224/0         195.124.8.8/6        8     1138  0    0   0
     108}}}
     109
     110This information shows the internal configuration of the "pipes" used to emulate network characteristics.
     111(Your output may look different, depending on the version of ipfw installed on your delay node.
     112In any case, the information you need is on the first line of output for each pipe.)
     113
     114You'll want to make note of the two pipe numbers, one for each direction of traffic along your link.
     115In the example above, they are 60111 and 60121.
     116
     117There are three link characteristics we'll manipulate in this experiment: bandwidth, delay, and packet loss rate.
     118You'll find their values listed in the ipfw output above.
     119The link bandwidth appears on the first line immediately after the pipe number. It's 100Mbps in the example shown above.
     120The next value shown is the delay, 1 ms in the example above.
     121The packet loss rate (PLR) is omitted if it's zero, as shown above. If non-zero, you'll see something like '''plr 0.000100'''
     122immediately after the "50 sl." on the first output line.
     123
     124It is possible to adjust the parameters of the two directions of your link separately, to emulate asymmetric links.
     125In this experiment, however, we are looking at symmetric links, so we'll always change the settings on both pipes together.
     126
     127Here are the command sequences you'll need to change your link parameters.
     128In each case, you'll need to provide the correct pipe numbers, if they're different from the example.
     129
     130 * To change bandwidth (100M means 100Mbits/s):
     131{{{
     132sudo ipfw pipe 60111 config bw 100M
     133sudo ipfw pipe 60121 config bw 100M
     134}}}
     135
     136 * Request a bandwidth of zero to use the full capacity of the link (unlimited):
     137{{{
     138sudo ipfw pipe 60111 config bw 0
     139sudo ipfw pipe 60121 config bw 0
     140}}}
     141
     142 * To change link delay (delays are measured in ms):
     143{{{
     144sudo ipfw pipe 60111 config delay 10
     145sudo ipfw pipe 60121 config delay 10
     146}}}
     147
     148 * To change packet loss rate (rate is a probability, so 0.001 means 0.1% packet loss):
     149{{{
     150sudo ipfw pipe 60111 config plr .0001
     151sudo ipfw pipe 60121 config plr .0001
     152}}}
     153
     154 * 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.
     155
     156== Experiment Procedure ==
     157
     158 * Set your link parameters to use maximum bandwidth, no delay, no packet loss:
     159
     160{{{
     161sudo ipfw pipe 60111 config bw 0 delay 0 plr 0
     162sudo ipfw pipe 60121 config bw 0 delay 0 plr 0
     163}}}
     164
     165 * Verify with
     166
     167{{{
     168sudo ipfw pipe show
     16960111: unlimited    0 ms   50 sl. 1 queues (1 buckets) droptail
     170    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
     171BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
     172  0 ip    207.167.175.72/0       195.123.216.8/6        7     1060  0    0   0
     17360121: unlimited    0 ms   50 sl. 1 queues (1 buckets) droptail
     174    mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
     175BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
     176  0 ip   207.167.176.224/0         195.124.8.8/6        8     1138  0    0   0
     177}}}
     178
     179Note that bandwidth is set to ''unlimited'', delay to ''0 ms'', and no PLR is shown.
     180
     181 * Using this initial setting, try a few UDT transfers, including the larger files. Now try FTP transfers. Record the transfer sizes and rates.
     182
     183 * Now change the link parameters to reduce the available bandwidth to 10Mbps:
     184
     185{{{
     186sudo ipfw pipe 60111 config bw 10M delay 0 plr 0
     187sudo ipfw pipe 60121 config bw 10M delay 0 plr 0
     188}}}
     189
     190 * Repeat your file transfers with the new settings. As before, note the transfer sizes and rates, as well as the link settings.
     191
     192 * Continue with additional trials, varying each of the three link parameters over a range sufficient to observe meaningful performance differences. Record your data.
     193
     194== What to hand in ==
     195
     196 1. Your raw data and appropriate graphs illustrating changes in performance for the two transfer protocols with differing link parameters.
     197 1. Your analysis. Here are some questions to consider.
     198  a. Does one protocol outperform the other?
     199  b. Under what conditions are performance differences most clearly seen? Why?
     200  c. What shortcomings in the experiment design may affect your results? How might you improve the experiment design?
     201  d. What interesting characteristics of the transfer protocols are not measured in this experiment? How might you design an experiment to investigate these?