The following should provide a good start to review for the exam:

1. Review the questions from the midterm review
2. What are the performance advantages and disadvantages of PERL CGI, Ruby on Rails and PHP?
3. Why do you see cookies used with Rails and PERL CGI?
4. What are some reasons for using the Model View Controller architecture?
5. What are some reasons for using Ruby on Rails?
6. What are some reasons for using PHP ?
7. What are some reasons for using PERL CGI ?
8. Why is regular expression syntax included in PHP, PERL and RUBY?
9. You had the opportunity to include semaphores in your web server lab to control access to the thread pool. What symptoms would you expect if the semaphore code was not working?
10. Review Model-View-Controller
11. Review AJAX. How does AJAX work? What are the necessary pieces? How do AJAX requests differ from other requests?
12. Be able to create an ER diagram and convert it to a description of the necessary relational database tables.
13. How do you convert objects to relational database tables? What are the advantages and disadvantages of each approach?
14. How do you preserve state in HTTP?
15. Be able to answer the question in the Ruby on Rails tutorial
16. Understand the basics of Ruby on Rails and Active Record
17. Understand Peer-to-Peer concepts and the main systems (napster, gnutella, bittorrent) and how they differ.

This post is password protected. To view it please enter your password below:

Password:

• Why would you want to use a public key system instead of a symmetric key?
• Why would you want to use a symmetric key system instead of a public key?
• Given p=5, q=11, e=23, d=7, encrypt the message=”6″.
• Given p=5, q=11, e=23, d=7, decrypt the cyphertext=”6″.
• Given p=5, q=11, e=3, find the decryption key.
• Outline the steps necessary to set up a SSL session.

Queuing Theory

• You know that the user tolerance for delay in displaying a web page is 8.3 seconds. You are launching a new product and expect to have 1000requests/minute during the peak of your offering. You have a cluster of web servers using DNS round robin load balancing. The service time for each request averages .9 seconds with a standard deviation of .85 seconds. You currently have a cluster of 18 web servers dedicated to your service.
  1. What is the utilization of each server?
  2. What is the mean response time for a request?
  3. What is the standard deviation of the response time?
  4. How much time does each request spend waiting in the queue?
  5. How many requests are waiting in the queue at any time?
  6. What is the 90th percentile of the response time (90% of the requests will be satisfied in less than what time)?
  7. How many servers would you need to have 90% of the requests satisfied in less than 8.3 seconds?
• You are serving MP3 files to the web from your office in Los Angeles. You have a customer in New York City that is complaining about his response time. He claims that the average time for him to download a 1.5MByte MP3 file is 50 seconds. His connection to the Internet is a 256Kbps DSL line. Your connection to the Internet is a 50Mbps T3(DS3) line. The speed of light is approximately 2*10^8m/sec and LA-NY = 2800 miles=4480km). The latency through the protocol stack on each end is 100usec. The peak utilization of your web server is 84% and your average service time is .4 seconds.
  1. What is the total latency for this connection?
  2. How long does it take for the file to be sent through the bottleneck bandwidth?
  3. What is the response time of the server?
  4. Why is the customer experiencing this long response time?
  5. What one thing could you change that would cause the greatest improvement in download time?
  6. What would the download time be with this improvement?
• Did you complete the student rating for the class  at https://studentratings.byu.edu/?

There are several things you should think about when selecting a technology for developing web applications:

• Performance – interpreted languages may seem slower, but since the database will be the bottleneck for many applications, the raw speed possible may be less important.
• Model View Controller Architecture – There are frameworks that will help you to use good design principles. It is worth it to use a system where it is difficult to write bad code.
• Library Availability – You dont want to write all of the code yourself
• Documentation – And more importantly, working examples are important
• Maturity – you dont want to pick something that is going to fade away as quickly as it appears, on the other hand, you shouldnt stick with bad technology just because it has been around for a while.
• Language Features – Object oriented, ORM database encapsulation
• Maintanence – Most of your effort will be spent here, so it should be easy to maintain and easy to have other people maintain.
• Culture – To some extend, the culture of the community is important. Are programmers willing to share, help each other? Is it an open source project?

Here are some comparisons of different technologies

• Php vs Rails vs Java
• PhP vs JSP vs ASP vs Coldfusion ..
• PhP vs Perl vs asp vs jsp
• Scripting Languages
• Overview
• Jobs

1. First, acclimate yourself to the ruby programming environment. Run through the Ruby on Rails slides, and look at examples. A quick reference can be found at http://www.zenspider.com/Languages/Ruby/QuickRef.html. For more specific socket programming questions, look at https://www6.software.ibm.com/developerworks/education/l-rubysocks/l-rubysocks-a4.pdf… it’s really good and is fairly comprehensible.
2. Next, download these sample scripts and play around with them. Note that the function of these sample scripts is not the same as the ones required for lab 5.

First, implement the functionality that communicates with the chat server: the user interface.
The instant messaging client has two components: the chat component and the user interface component. The chat component runs a threaded server that accepts incoming chat connections and manages a list of all active sockets. The user interface component runs in a separate thread; it accepts commands typed by the user and then contacts either a server or another peer, as appropriate.
--Lab Writeup
This part of the lab will be loosely based on the code in client-tcp.rb (from the sample scripts above). If you look at that script, you will notice that the business part of the script begins at line 46. On line 49, it sends text from user input (data=gets) to the client using the client.send command. Then, it waits to receive something from the client with the client.recv command, and displays it.
Astute observers will notice that the interface component functions in a very similar manner, except that instead of sending the text entered in by the user, it translates the input by the users into ims commands and sends them to the chat server. For example, when the user types “create [user] [password]“, a message containing “ims [version] create [user] [password]” is sent to the server.
Initially, the interface component can run in the main thread, although it will need to eventually run in its own thread.
If you want some hands-on experience with a real-life chat server, start up client-tcp.rb, passing in paintball as the host, and 6666 as the port. When you try to type stuff, it should return an error with a description. You should be able to log on and off, as well as view other users by using the ims commands. Note: Make sure you log out before you kill the script that communicates with the server.
[superman@skating echo]$ ./client-tcp.rb -s paintball -p 6666
bleh
error: not registered (ims [version] register [address] [port])
ims 1 register 2 3
OK
bleh
error: not logged in (ims [version] login [user] [password])
ims 1 login u p
error: user does not exist
ims 1 create user1 password1
OK
bleh
error: not logged in (ims [version] login [user] [password])
ims 1 login user1 password2
error: passwords do not match for user
ims 1 login user1 password1
OK
bleh
error: unrecognized command
ims 1 who
users user1
ims 1 info user1
user1 2 3
ims 1 logout
OK
ims 1 who
error: not logged in (ims [version] login [user] [password])

You can also test your interface component on this server.

Your implementation of the interface component might look like this:

// establish connection with server on paintball
// while(forever)
//      read a command in from the standard in
//      switch on the input to determine what to send to the server
//      send message to server
//      display an error message if there was an error

When you send the server a register message, you will need to send him a host and a port. You can get the hostname of the machine you are running on and generate a random port number. See http://stackoverflow.com/questions/200484/how-do-you-find-a-free-tcp-server-port-using-ruby/200590 for an example of how to get an available port.

require 'socket'

hostname = Socket.gethostname
randnum = 1000 + rand(10000);

puts "hostname is ",hostname,"random ",randnum,"\n"

3. Next, implement the client component that interacts with other clients.
   The instant messaging client has two components: the chat component and the user interface component. The chat component runs a threaded server that accepts incoming chat connections and manages a list of all active sockets. The user interface component runs in a separate thread; it accepts commands typed by the user and then contacts either a server or another peer, as appropriate.
--Lab Writeup
   This part of the lab is a little more difficult. The finished product relies on threading, with a similar design as your web server for the previous labs. One thread will listen for new connections, and as connections are received, they are stored in some sort of data container. Instead of reading from the connection, writing a document, and closing the connection as you did in your previous web server implementation, you will need to keep the connections open, so you can read and write to them.
   Several components in server-tcp.rb from the sample code above will be useful in listening and receiving connections.
   When implementing the client component, start without threads. A simple implementation could look like this:

   // set up the connection
   // listen on the connection
   // wait for a new incoming connection
   // while(forever)
   //     read from the socket
   //     display the message
   //     get a new message from the command line
   //     write message back to socket

   This implementation should be able to accept a connection with one socket and communicate with it.

   When that works, move on to multi-threading. A possible implementation could look like this:

   global variable $socks (in ruby, global variables are marked with a '$')
   IOMethod
   // while(forever)
   //     Read from all sockets in $socks (hint: look at the select() method)
   //     Display messages
   //     Write unwritten input to $socks
   
   Main method
   // start thread running IOMethod
   // set up socket and listen on it
   // while(forever)
   //     wait for a new connection
   //     add it to $socks
   

   This version should be able to accept multiple connections simultaneously.

4. After implementing both of these parts, they are ready to be combined into the complete chat client. One problem you will have to solve is how to send the right user input to the server via the interface component, and the rest of it to the IO component. The rest of the combination is mostly straightforward.

   You can test your clients by using the chat server on paintball.

5. The chat server is kindof a beast. It basically just parses user input. You shoudn’t have too many problems with the server, although it might take a while. Just follow the steps outlined in the lab specs.

And that’s how to do this lab, in 5 easy steps. Let me know if you have any questions, if you find any errors in this document, or if you have any additional suggestions that might be helpful for others.
-Kendell

This post is password protected. To view it please enter your password below:

Password: