|Advanced Programming Concepts||Spring 2008|
Due: Finals Week
Submit solution to firstname.lastname@example.org
The Monitor source is available here.
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.
This will use just about every aspect of the material learned especially networking and security.
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.
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
The monitor is maintained by the instructor and an aid and has numerous important functions as follows:
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.
The following are the rules for waging, winning, and losing a war.
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 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.
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.)
Systems may communicate with each other through the Monitor to exchange resource, products, and Rupyulars. Such communication proceeds according to the published protocol.
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.