趋势百万程序竞赛2004年第二届初赛题目
Trend Micro Programming Contest
2004
Preliminary Stage

(Version 2.5)

1.    Subject
Central Computer Activity Monitor System

2.    Overview
Network administrators manage all computers in their network domain. One of their daily jobs is to ensure every computer is running smoothly without any problem. However, there could be a large number of computers in their network domain. It is difficult to know if there is a computer can’t work properly. They may need to visit computers located in different places to make sure everything is still running.
We want to design a client-server system to ease this effort. When this system is deployed to the computers of a network domain, every client will report its system state to the server regularly. At the server side, network administrators can check the system state of every computer remotely. Watching their network domain becomes an easier job.
To create such a system, at client side, several “probes” must be installed in different positions in OS. These probes monitor system activities such as network packet transferring, CPU usage, file access and so on. Then client sends the intercepted information to the server.
    The server receives activity information from all client computers. At the server’s display, administrators can view the system state of the whole network or any single client computer. The system state is presented in “History List” and “History Diagram”, which is text log and 2D history graph respectively.

3.    System Activities
    System activities mean every activity a computer may do. In our system, the clients are expected to keep a watch on the following system activities, collected their information, and report to the server.
a.    Network packets
Both incoming and outgoing network packets are watched. The information such as protocol, source IP, destination IP, source port and destination port should be collected.
b.    File modification/creation
Modification\deletion of an existing file or creation of a new file are watched. The information of filename and path should be collected.
c.    Process execution
Processes starting, running and terminating are watched. Process name should be collected.
d.    CPU usage
CPU loading is watched. The info of percentage of current CPU usage should be collected.
e.    Sending/Receiving E-mails (SMTP/POP3)
Incoming and outgoing E-mails are watched. The information of number of E-Mails, subjects, sender, recipients and filenames of attached files should be collected.


4.    Probes and Activity Simulator
    To watch the mentioned system activities, “probes” must be implemented and installed on client computers. Legally using free libraries or source codes is allowed, but you must declare it explicitly in your design document.
Your probes are expected to be able to watch the system activities listed in the previous section. It is good if your probes can watch more system activities and collect more detailed information. If you can’t complete all the probes, just try your best.
However, whether you can implement all the requested probes or not, you MUST also implement an “Activity Simulator” for your clients. This Simulator reads an “Activity File” containing a text list of system activities. The data read from Activity File by the Simulator should be treated the same as collected from the probes. In other words, the data is treated “as it really happens on a client computer”. Your client should use the same client-server channel to deliver this info to the server.
    
5.    Format of Activity File
    Before introducing the format, here is a reminder: your probes are NOT RESTRICTED to gather only the information listed below. You can gather any additional information (more detail or even other activities not listed here) you want.
The Activity File is an ASCII plain text file and its data is recorded row by row. One or multiple spaces and\or tabs separate fields in a row. Every row is ended with a new-line.
The first row of Activity File is a “starting time” indicating when the first system activity listed in this file is going to happen. It could be:
Either
A single string of now means “right after this file is opened”, which means the following data will be read without a delay.
Or
A string of HH:MM:SS means local and today’s real world time in the format of hour:minute:second. It must be a time later in today, so it causes a delay before reading all the following data.

Begin from 2nd row to the last row, each row records a system activity as this format:
                seconds     category     category_specific info
<seconds>
Integer. It indicates when a system activity happens or a system state is “polled”.
It is a delay relative to the previous row of system activity. If this is the first system activity in the file, the delay is relative to the “starting time” recorded in the first row. The delay is measured in seconds.

<category>
String. Could be NET, FILE, PROC, CPU or MAIL
    <category_specific info>
It differs by different categories and contains some fields of different attributes. See the following definitions.

Definitions of <category_specific info>
    NET
        <Repeat>
Integer. This field is used to simulate that a number of identical packets with the following attributes are happening.
    <Direction>
        String. IN or OUT
    <Protocol>
            String. Could be one of TCP, UDP, ICMP or OTHER.
        <TCP flag>
            Integer. Mapping to the real “flag” field in TCP protocol. Giving 0 if                 the protocol is not TCP.
        <Address>
            A IPv4 string of the remote address. Ex: 10.1.1.2
        <Port>
            Integer from 0 to 65535. It’s the destination port.
        <Size>
Integer. Size of packet measured in bytes.

FILE
        <action>
            String. “CREATE” “MODIFY” “DELETE”
    <full pathname>
String. The format is “\dir1\dir2\…\dirN\filename” whether you work on Win32&reg; or Unix&reg; platforms. The whole string is enclosed with two “ (double quote) to support spaces in path.

    PROC
        <action>
            String. “START” or “END”
    <application full pathname>
String. The format is “\dir1\dir2\…\dirN\filename” whether you work on Win32&reg; or Unix&reg; platforms. The whole string is enclosed with two “ (double quote) to support spaces in path.

    CPU
        <usage>
            Integer from 0 to 100.

    MAIL
        <subject>
String. The whole string is enclosed with two “ (double quote) to support spaces.
        <sender>
String. The whole string is enclosed with two “ (double quote) to support spaces.
        <recipients>
String. Multiple recipients are separated by “;”. The whole string is enclosed with two “ (double quote) to support spaces.
        <attached filenames>
String. Multiple files are separated by “;”. The whole string is enclosed with two “ (double quote) to support spaces.

This is the content of an example Activity File:
now
0    CPU    0
1    NET        1  OUT  TCP  2  10.1.1.1  23  120
10    FILE    CREATE  “\read me.txt”  
10    PROC    START  “\calculator.exe”  
11    CPU    10
15    MAIL     “hello world”  “John M”  “David C;Peter W”  “a.txt;b.txt,”

6.    History List
The information of system activities sent to the server is recorded as a “History List”. Each row of this list is an item of “when and what happens on which client”.
Some system activities, like network packets transferring, are “events”. They happen in an exact time and this time is recorded with them in the History List.
Other system activities, like CPU usage, are more like “states”. They are continuous and do not happen at a point in time. So the common approach is using a “polling” technique to monitor the state change. These activities are recorded with the time when they are polled.

7.    History Diagram
    In addition to History List that is shown in texts, “History diagram” organizes and shows information in graphics. The performance monitor tool included in Windows&reg; is an example: System activity statistics are shown in a 2D diagram with horizontal axis representing “past time” and vertical axis representing a “count”. Every diagram is updated periodically, which is expected to be not slower than every 30 seconds and faster is better. The diagram draws a statistical curve so administrators could see the change of every type of system activities.
The “scales” of the both axes must be able to set reasonably to show statistics values. You may either design an “auto scaling” feature or provide controls for users to adjust scales. For the horizontal axis representing “past time”, at least, your UI must be able to display the information of past 10 minutes.
It’s better to provide some “filters”. Only the activities matching the filter are counted. For example, users can choose only to watch a certain network protocol, packets to a certain destination, file access under system folders and etc.
Using single or multiple graphs to show the system activities is both fine. There is no explicit requirement besides mentioned items - Just design in an ideal way and let users can watch the state easily.

An example of History Diagram: Performance Tool in Microsoft Windows&reg;

8.    Functionality of the Server UI
The server UI must be able to show History Diagrams and History List of the current state. Also, it must be able to show a list of all connected clients and provide selection function on these clients.
If no client is selected, History Diagrams are calculated by the data coming from all the connected clients. If a certain client is selected, History Diagrams are calculated by the data of that client only. The same logic applies to History List.
You may add extra functions freely. You can design UI in any style, which is able to provide the mentioned functionalities.

9.    Testing Environments
We provide the following testing environments for you.

Hardware
Pentium-III class machines with 256MB RAM. We may test on at least 2 machines.
Software
Windows&reg; 2000 Pro SP4 + MSDE&reg; + Sun JRE&reg; 1.4.2_05 + .NET&reg; 1.1
or
Red Hat&reg; 9.0 + MySQL&reg; + Sun JRE&reg; 1.4.2_05
Please choose one in your manual.
All OS and software will be installed with default settings and default components.
You can’t request us to install any other commercial software. If you want to use other free software, you must bundle it in your package and provide clear installation procedures in your document.
For Windows Java programmers:
Microsoft&reg; has declared they no more support Java&reg;. If you want to use Microsoft JVM&reg;, only the version bundled with Windows 2000&reg; is available for you. Or, we will additionally install Sun JRE 1.4.2_05 on our testing computers. Please specify clearly which one you want to use and teach testers how to run your Java programs in your documents.
Network
The testing environment is a closed, pure LAN environment, and each machine has an internal IP. All operating systems are installed with default protocols. No firewalls or routers are present in the environment.


10.    Requirement of Your Software Package
We provide a FTP server for uploading your files. Every team has a home directory on the FTP server. Please carefully follow the rules in this section to name and organize your directories and files.

a.    Directory structures
You must create 3 directories named “document”, “program” and “source” under your root directory, and classify all your files into them. You may create more sub-directories in any name under these 3 directories. But don’t create other directories under the root directory.

b.    Documents
You must provide the following 4 documents with the given filenames. Please put them in the directory named “document” and add proper extension filenames like .doc or .html according to the document format you choose.
manual            
A document written in plain text, HTML, Word or PDF.
The first section must introduce the installation procedures clearly and correctly. You must write the software requirement and step-by-step installation procedures. You will lose the contest if our testers can’t set up your programs and get them running. So please confirm your installation procedures are correct.
The latter sections must introduce the usage of your programs. Remind again, please write it clearly.
design            
A document written in plain text, HTML, Word or PDF.
It describes the architecture of your design. If you borrow any public libraries or source codes, write all of them down explicitly. If you are found that you miss something, you will be disqualified from the competition.
build
A document written in plain text, HTML, Word or PDF.
This document describes the detailed procedures of how to build executable programs from your source codes. In the building process, Windows&reg; programmers may use Microsoft Visual Studio 6&reg; “workspace” files, and Linux&reg; programmers may provide “Makefile”. But you should still write necessary information in this document to help testers to build your programs.
filelist
A document written in plain text.
This document is a complete list of all files you sent to our FTP server. You must list full pathname, file size, and last modified time in this list. We use this file to check if you uploaded all the files for this contest.

c.    Programs
Put all your binary programs and installer (if you have) in the directory named “program”. Our testers should be able to begin the installation from this directory.

d.    Source codes
Put all your source codes into the directory named “source”. Don’ forget to write procedures of how to build your codes into programs in the document named “build”.

e.    Installation
Your installer or installation procedures should put executable programs into the following directory if there is no special assignment:
        For Windows&reg;:
            C:\CCAMS
        For Unix&reg;:
            /home/<current user>/CCAMS
After installation is completed, the executable programs should be put in the installation directory. Don’t forget to teach users how to use them in the document named “manual”.

11.    Other Requirements
a.    No restriction about programming languages.
b.    No explicit UI requirement about the client. You could design it in a hidden style or provide some controls. But your programs should not interact with the user at the client side too frequently.
c.    Naturally, the server UI could be a normal application. But we don’t stop you from using web UI or other ways if you can implement it ideally.

12.    Scoring
Scoring is based on the following items. There are a total of 190 points.
a.    Functionality (100)
How many probes have you done?
Are the probes implemented with proper mechanism?
Do they work well?
How much information can they get?
Do History Diagrams and History List show correct results?
b.    Performance (40)
Can information display quickly on the server?
How much resource do the client and server use?
c.    UI (30)
Are History Diagrams and History List shown in an ideal way?
Is the UI friendly and nice?
Is the whole system easy to use?
d.    Installation (10)
Are the installation process smooth?
e.    Document (20)
Is the description clear?
Is the design well described?
Does the manual cover all things users need to know?

13.    How We Test
We will generate system activities by using Activity Simulator and testing tools, then see if History List and History Diagrams on the server UI show expected results.

评论