SI 540: Fall 1999

HW 11 Solution Set

due December 13

Last modified 12/13/99 --PR
Class home page

You can do this assignment in pairs, but not in groups larger than two.

Readings

Explore the interactive map of On-campus "backbone" nodes. Find it by clicking on the "Map of On-campus connections" link from the ITD Backbone web page. Note that SI connects through c-UGLI. Click on things on the map to see current status.  SI subnet IP addresses begin with 141.211.202  and 141.211.203 (there may be more that I don't know about).

Text exericses

(4 points) Suppose a piece of mobile code (e.g., a Java Applet) is totally untrusted (you don't know who created it or what it does), so you want to restrict its capabilities (run it in a sandbox). Consider restrictions on the following types of operations and indicate, first, what bad actions by the mobile code might be eliminated, and then indicate what legitimate purposes of  mobile code might be eliminated.

• Network access
• File system access
• Method invocation on other, non-mobile objects residing permanently on your computer
• Method invocation on other, mobile objects

Clarifications sent out by email:

4) With the restriction in part d, the code that is executing on your machine will be unable to invoke methods of any other objects that do not reside permanently on your machine. For example, these might be other objects that were just downloaded from another machine and are executing locally, or even objects that are executing on other machine.

The key to this question is to understand what a sandbox does: it prevents the execution of certain kinds of operations by certain pieces of code. It's not a virus checker that scans for certain bad things and then lets the code execute freely if no bad things are found.

• Network access
• Dangerous actions prevented: sending private information from your computer to another; launching an attack on another computer that appears to come from you; sending an email message that appears to come from you.
• Legitimate purposes prevented: connecting to another server to fetch some useful information (e.g., you might like to download a game applet that then connects to a game server).
• File system access
• Dangerous actions prevented: deleting your work; filling up your hard disk with junk;
• Legitimate purposes prevented: persisent data storage (saving work that you do inside the applet).
• Method invocation on other, non-mobile objects residing permanently on your computer
• Dangerous actions prevented: bypassing any of the restrictions above, if the local objects are not subject to the same restrictions that the mobile code is subject to.
• Legitimate purposes prevented: the local objects may do something useful! The solution is to allow invocation of methods of local objects, but execute in the same sandbox.
• Method invocation on other, mobile objects
• Dangerous actions prevented: for mobile objects downloaded to the local machine, they'll execute in the same sandbox, and hence pose no new dangers, so this restriction doesn't prevent any dangerous actions. For remote objects, remote method invocation is a form of communication, so restricting remote method invocation prevents the same dangers as restricting other network access. 
• Legitimate pruposes prevented: the objects may so something useful.

(1 point) Can a packet-filtering firewall filter block all Java programs from passing through? Why or why not?

No. As discussed in class, the TCP packets would have to be reassembled into complete messages in order to determine that Java programs were being sent.

Point of clarification for your future reference. In everyday language, people refer to "the firewall" more generically to mean the packet filter (what I call the firewall) plus a bastion host that is running a proxy server. The packet filter may permit communication from outside the organization with only the bastion host. The bastion host may be configured to act as a proxy for internal computers trying to communicate with the outside world. The proxy server works at the "application layer" rather than the "network layer" and hence can do things like block email from certain people or do virus checking on file attachments or prevent Java programs from being downloaded from Web sites.

3 points free on this homework!

(2 points) Explanation Exercise

Explain to someone the idea of atomic transactions and how to achieve atomicity in transaction processing.

Ungraded Questions (We won't cover the material until next Monday)

Solutions will be provided next Monday

E15.7 For the bookselling application we've used throughout the course, describe how transaction processing could make the application more robust and easier to develop. In particular:

• Define no more than two or three atomic transactions that would be useful (and specify the component actions of each transaction).
• Describe how the application would deal with an abort of each kind of transaction.
• Describe a couple of ways in which the application would be less reliable or more difficult to develop if did not use transaction processing.

• Define no more than two or three atomic transactions that would be useful (and specify the component actions of each transaction).
• 
  Actually, I'll give just one. Fulfilling an order, which involves:
   

  charging the customer's credit card
  shipping the books
  marking the order as fulfilled in the database

• Describe how the application would deal with an abort of each kind of transaction.
• 
  The resource manager for each of the resources will need to be able to roll things back to their original state, which means:

  --credit the customer's credit card (the credit card company doesn't have a way to do a pre-commit, so you have to actually charge the card and then issue a credit if the transaction aborts)
  --don't ship the books (the resource manager would only pre-commit if it was sure the order could be fulfilled, but wouldn't send the books until the commit phase).
  --unmark the order as fulfilled in the database.

• Describe a couple of ways in which the application would be less reliable or more difficult to develop if did not use transaction processing.

• 
  Without transaction processing for order fulfillment, there would be more instances of books shipped without payments received, or charges without books being received, or double shipping of certain books (Last semester, a student mentioned his experience receiving multiple shipments from a mail-order computer company, where they had lost track of what they'd shipped).

E16.4: platform independence

a. To support write-once, run-anywhere, the middleware will need to provide, on every different platform, a version of an interpreter or compiler for some common language (the language in which things will be written once). This provides OS platform independence, as long as the common language is used for programming (think JAVA here).

b. To support RMI on remote objects on different platforms, where objects on both platforms use an ORB from the same vendor, the middleware ORB will need to be implemented on both platforms and will need some inter-ORB communication protocol (but the protocol can be proprietary to the vendor). This provides OS platform independence but not ORB vendor independence.

c. To support RMI on remote objects on different platforms, where the objects use ORBs from different vendors, the middleware ORB will need some common inter-ORB communication protocol that is used by both vendors. This provides independence of ORB platforms in addition to OS platform independence.

E17.10b: scalability (Do this for the bookselling application only)

The two important tasks that users do are browsing and ordering. Once orders are placed, they need to be fulfilled. Scalability refers to the ability to handle more customers just by adding extra equipment. That is, by adding more equipment (servers, warehouses, etc.), the bookseller should be able to increase throughput, without increasing the blocking rate (inability to connect to server) or task completion time (server response time) perceived by customers.

For browsing and handling orders, one difficulty will be load balancing among the Web servers. All the techniques discussed in class and in the supplemental reading might be appropriate.

Since the Web servers need to access a shared database that keeps track of inventory, etc., there may be a bottleneck in processing transactions. The database could be partitioned (e.g., inventory seperate from recommendations) in order to increase throughput. But to be really scalable, we'd like to replicate the database. With replicated databases, there is a problem with keeping all the copies synchronized: when one copy is updated, they must all be updated. Two-phase commit to assure atomic writes to all the copies of the database would help, but there are more sophisticated techniques that could be explored as well.

You can read more about scalability and load balancing in this article from InternetWorld that Darren Gergle found.