The Monitor source is available here.

Grading Policy:

It might make sense to read the rest of this page and then return here to see the grading policy. This grading policy applies to the project only. Students should read this carefully and make suggestions for refinement until they are comfortable that they completely agree with and understand the policy and they believe there will be no surprises at grading time.

My grading objective to assign high grades to students who have mastered the Java language and have demonstrated an ability to use many of its features creatively and effectively. If all students have mastered the language then all students get high grades. A student is not competing against any other student for a grade.

More is not better. A lot of bad code is no substitute for a small amount of good code. Using all features of Java does not insure a high grade. Using a subset of features well is preferred to sloppy use of many features. If you are using a feature where another would be more appropriate, some points will be lost.

High grading does not depend at all on the amount of wealth accumulated by an individual's system. Nor is it heavily dependent on strategies employed for acquiring wealth. There are some required elements that must appear in your submission in order to get a high grade. There are also some optional elements that help secure a high grade. The required elements are as follows: your system must be able to locate the Monitor, and other systems. It must be able to send and receive messages formatted below (don't look - it's not there yet). It must be able to provide for secure transmission of messages. It must make an attempt at preventing an intruder from gaining access to sensitive information. Optionally, a system may attempt to seek and succeed in finding, at least in some cases, information related to the wealth of other systems; a system may "plant" Java code on another system and run it. Any creative tricks will be appreciated as well.

Rationale:

This will use just about every aspect of the material learned especially networking and security.

Objective:

Each student is to design and build a Java system which attempts to accumulate a maximum amount of wealth through communications with other student systems and a monitor system maintained by the instructor and an aid. At 11:59PM, Wednesday, 11 June 2008, these systems will be ranked according to total accumulated wealth and results posted.

The Gory Details:

The full technical details of the game are in the Protocol document. What follows in this document is simply a general overview of the game.

General Description:

Wealth is measured in units called Rupyulars. Wealth is distributed by the monitor every three hours to participating systems as raw resources (each having a unit value in Rupyulars) or Rupyulars themselves. There are six kinds of resources and three kinds of products that may be manufactured from the resources. The resources are: oil, steel, plastic, copper, glass, and rubber. The products are: weapons, computers, and vehicles. A system's wealth can be increased (or perhaps decreased) by

1. Constructing finished products from the raw resources,
2. Making deals with other systems to exchange resources, products, or Rupyulars,
3. Stealing items of wealth from other systems,
4. Making war with another system,
5. Trading on the Monitor's open market.

Monitor:

The monitor is maintained by the instructor and an aid and has numerous important functions as follows:

1. It keeps track of who is alive (registered).
2. It keeps track of who owns what. Its database of wealth distribution is official. It keeps track of legitimate transactions and determines the winner and spoils in case of war.
3. It approves all communications. One reason for this is to slow down transaction rates to prevent network overload. A second reason is to be sure that the Monitor's database is always official.
4. Unwanted finished products and resources may be traded to the Monitor. Prices, in such cases, are determined solely by the Monitor, and the Monitor will not reveal what costs it requires. Players must simply try to see if the Monitor is willing to trade.
5. A system may attempt to read information about another system through the Monitor (an attempt may also be made to get a dim-witted system to divulge such information, independent of the Monitor). The more computers a system has, the better chance it has of obtaining secrets. The more security a system has, the better chance it has of protecting its secrets. A system may use computer resources to get a chance at guessing another system's secrets.

Player Systems:

Player systems do not always have to be running. However, they must be running for at least one hour in each three hour period to receive their share of resources in that period. When they are running, they will operate from a port on a .uc.edu address. Every time a system starts it must register with the monitor. A system may start, stop, and change ports many times during the day. This might be advantageous when hiding from an aggressive "power." Changes to this information are communicated by means of commands issued to the monitor. A system may be started on a different machine and a different port each time it goes on-line. However, there should only be one system per Player on-line at a time. This is enforced by the registration process: the monitor only allows transactions with the most recently registered port and address for a given user.

Although it is possible to use the Monitor without encryption, we strongly encourage that all transactions be encrypted using encryption facilities provided. If not, they could be intercepted by a "sniffer" and the contents used to fool the monitor into moving wealth around from one system to another or to determine resources, products, weapons, etc.

War Rules:

The following are the rules for waging, winning, and losing a war.

1. System A declares war on System B by making a request through the monitor. The monitor checks that System B is on-line in the location that System A indicated. If so, 1) approval is granted to System A and System B is notified and 2) System A and System B determine how many units of weapons, and vehicles are to be used for the war. If not, System A looses 10% of the weapons and vehicles that System A committed to the war as a penalty for not knowing where System B really was.
2. A war consists of a series of one or more battles. Battles are carried out periodically by the Monitor. Neither system can go off-line once a war begins. Doing so results in forfeit and transfer of wealth to the opponent.
3. For weapons to count in a battle, each must have a vehicle to transport it. If either side runs out of vehicles or weapons, that side looses.
4. Outcome of battles is somewhat random: the probability of winning is directly related to the amount of weapons fighting in that battle. The number of weapons that fight in a given battle is the minimum of the number of vehicles and the number of weapons currently available in the war.
5. After each battle, both sides loose some of the weapons and vehicles committed to the war. However, the losing side will have substantially greater losses.
6. Battles continue until a truce is negotiated, or one side has no more vehicles and/or weapons committed to the war.
7. Once one side is defeated, the victor is permitted to "pillage". The victor receives any remaining resources that the loser committed to the war, as well as some percentage of the loser's current wealth.

Trade Rules:

Systems may trade resources with each other as much as they would like. Systems may also trade with the Monitor. The Monitor does not necessarily have any resources at all, but it frequently has certain resources available. Trades with the Monitor are done with what the Monitor considers "fair market value", plus a percentage commission. This means that the Player is required to try different values of trades out until it finds one that the Monitor accepts.

Cracking Rules:

Cracking can be done in two ways. One way is to use the Player's computer resources and the various crack commands in the protocol.

The other way in which Players may "crack" another Player's system is by impersonating the Monitor. Learning how to do this is left as an exercise to the player.

Wealth Calculation:

Every possible resource you hold has a value in rupyulars. That includes computers, vehicles, and weapons, as well as all the raw materials. In other words, it includes everything mentioned in PLAYER_STATUS output.

One rupyular is always worth one rupyular.

All the other resources have a value relative to rupyulars. The value is determined by the total of that item that are in the "world".

For example, if everyone has 1000 oil units each and only 10 rupyulars each, one unit of oil is worth much less than one rupyular. If no one has any computers, they are worth many, many rupyulars.

Note that the equations for calculating the relative value of something in rupyulars are complex. However, you can be sure that a *major* factor is the total sum of all those resources in the system (aka world). (Also, note that the Monitor holds some resources in an "open market", which also counts towards the total count in the system.)

Transactions:

Systems may communicate with each other through the Monitor to exchange resource, products, and Rupyulars. Such communication proceeds according to the published protocol.

Miscellany:

Please bear in mind that this notice is public and can be read by millions of people all over the world, especially mischievous devils who love to make people's lives miserable. Therefore, you should expect attacks from outside the class! Try to make your code as secure as possible to prevent this. By the same token, we will try to make the Monitor as invulnerable to such attacks as possible. Some outside crackers may figure out ways to break systems or the Monitor and may attempt to seek extortion or even sell the secrets to members of the class. Anyone receiving such outside information will be fined 1000 Rupyulars on the spot. If it is discovered that some damage is done because some class member's system willfully gave information to an outside party, that class member will immediately receive a grade of F and this grade will be irrevocable. The FBI may also be called. They seem to be actively pursuing such abuses these days. Most importantly: this is an educational exercise only and no malicious intentions of any participant will be tolerated for a minute.

Permission is granted to make and distribute verbatim copies of this document materials provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided also that they are marked clearly as modified versions, that the authors' names and title are unchanged (though subtitles and additional authors' names may be added), and that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.