status.txt

Jade Cheng
ICS 451
Assignment 2

[STATUS]
The program works, and I implemented some additional functionality: an !info
command and logging capabilities.  

Info
------------------------------------------------------------------------------
When the program runs, it waits for requests from the command line.  If
the user types "!info" it will display information about the state of the
program to standard output.

For example, in the following, I start p2p on port 50000.  I started another
instance on port 50001 that sent out a listing message with "file1" in it.
Then I have the first instance search for "foo" and "bar" and then display
information using the "!info" command.  The strange numbers like
"1238401475.485245" are the timevals for when the items were added or last
accessed in the various caches.  Five seconds later, the requests
timed out and the "content not found" messages appear.  Finally, I typed
"!quit" to terminate the program.

        bash-2.03$ ./p2p 50000
        Logging to '/home/26/yucheng/public_html/p2p-log'...

        Jade p2p

          Type '!quit' to quit.
          Type '!info' to display information.
          Type anything else to make a request.

        (p2p) foo
        Searching for foo...

        (p2p) bar
        Searching for bar...

        (p2p) !info
        Local Content
        ----------------------------------------
        Empty

        Data Cache
        ----------------------------------------
        Empty

        Content Directory
        ----------------------------------------
        [1]        127.0.0.1:50001 file1                1238401475.485245

        Peers
        ----------------------------------------
        Empty

        Request
        ----------------------------------------
        [1] foo                  1238401478.399099
        [2] bar                  1238401479.849376

        (p2p)
        content not found (foo)

        (p2p)
        content not found (bar)

        (p2p) !quit
        bash-2.03$

Logging
------------------------------------------------------------------------------
If the user puts the path to a log file in the p2p configuration folder, p2p
will use this file to log additional information about the UDP communication.
The log file setting is stored here:

        bash-2.03$ mkdir ~/.p2p
        bash-2.03$ echo /home/26/yucheng/public_html/p2p-log > ~/.p2p/logfile

When the program starts, it will display information about this log setting.

        bash-2.03$ ./p2p 50000
        Logging to '/home/26/yucheng/public_html/p2p-log'...
        :

If the log file is not avaiable, it will print an error message.  For example,

        bash-2.03$ ./p2p 50000
        Log setting not found in '/home/26/yucheng/.p2p/logfile'.
        :

Each time the program writes to the log, the process ID and time is written
before the log data.  This makes it easy to see which instance of the program
is logging what data.  For example,

        p2p (pid = 2929) at Sun Mar 29 22:17:19 2009
        -------------------------------------------------------------------------------

The log for the TRY message provides a good example of how things work.  Below
is the log for a series of transactions from three instances of p2p with
process ids of 3088, 3098, and 3099.

PID 3088 was started first:

        bash-2.03$ ./p2p 50000

PID 3098 was started second:

        bash-2.03$ ./p2p 50002 127.0.0.1/50000

PID 3099 was started third:

        bash-2.03$ ./p2p 50001 127.0.0.1/50000 file1

Listing messages from PID 3098 and PID 3099 appear first in the log.  Then
PID 3098 asked for file1.  PID 3088 responded with a TRY message.  Then PID
3098 asked for file1 from PID 3099.  PID 3099 responsded with a DATA message.

        p2p (pid = 3098) at Sun Mar 29 22:21:00 2009
        -------------------------------------------------------------------------------
        Sending to 127.0.0.1:50000
          { cc 4c 00 00 }
          {  ?  L  ?  ? }


        p2p (pid = 3088) at Sun Mar 29 22:21:00 2009
        -------------------------------------------------------------------------------
        Receiving from 127.0.0.1:50002
          { cc 4c 00 00 }
          {  ?  L  ?  ? }


        p2p (pid = 3099) at Sun Mar 29 22:21:03 2009
        -------------------------------------------------------------------------------
        Sending to 127.0.0.1:50000
          { cc 4c 00 01 66 69 6c 65 31 00 }
          {  ?  L  ?  ?  f  i  l  e  1  ? }


        p2p (pid = 3088) at Sun Mar 29 22:21:03 2009
        -------------------------------------------------------------------------------
        Receiving from 127.0.0.1:50001
          { cc 4c 00 01 66 69 6c 65 31 00 }
          {  ?  L  ?  ?  f  i  l  e  1  ? }


        p2p (pid = 3098) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Sending to 127.0.0.1:50000
          { cc 52 66 69 6c 65 31 00 }
          {  ?  R  f  i  l  e  1  ? }


        p2p (pid = 3088) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Receiving from 127.0.0.1:50002
          { cc 52 66 69 6c 65 31 00 }
          {  ?  R  f  i  l  e  1  ? }


        p2p (pid = 3088) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Sending to 127.0.0.1:50002
          { cc 54 66 69 6c 65 31 00 00 01 7f 00 00 01 c3 51 }
          {  ?  T  f  i  l  e  1  ?  ?  ?    ?  ?  ?  ?  Q }


        p2p (pid = 3098) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Receiving from 127.0.0.1:50000
          { cc 54 66 69 6c 65 31 00 00 01 7f 00 00 01 c3 51 }
          {  ?  T  f  i  l  e  1  ?  ?  ?    ?  ?  ?  ?  Q }


        p2p (pid = 3098) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Sending to 127.0.0.1:50001
          { cc 52 66 69 6c 65 31 00 }
          {  ?  R  f  i  l  e  1  ? }


        p2p (pid = 3099) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Receiving from 127.0.0.1:50002
          { cc 52 66 69 6c 65 31 00 }
          {  ?  R  f  i  l  e  1  ? }


        p2p (pid = 3099) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Sending to 127.0.0.1:50002
          { dd 66 69 6c 65 31 00 00 12 54 68 69 73 20 69 73 20 66 69 6c 65 20 6f 6e 65 2e 0a }
          {  ?  f  i  l  e  1  ?  ?  ?  T  h  i  s     i  s     f  i  l  e     o  n  e  .  ? }


        p2p (pid = 3098) at Sun Mar 29 22:21:11 2009
        -------------------------------------------------------------------------------
        Receiving from 127.0.0.1:50001
          { dd 66 69 6c 65 31 00 00 12 54 68 69 73 20 69 73 20 66 69 6c 65 20 6f 6e 65 2e 0a }
          {  ?  f  i  l  e  1  ?  ?  ?  T  h  i  s     i  s     f  i  l  e     o  n  e  .  ? }

After testing with some of my classmates' programs, I allowed one exception to
the protocol.  I'm ignoring extra bytes at the end of messages as long as the
beginning parts of the messages parse correctly.  For example dcolton's p2p
sends this data message,

p2p (pid = 4187) at Sun Mar 29 22:55:17 2009
-------------------------------------------------------------------------------
Receiving from 127.0.0.1:5000
  { dd 66 69 6c 65 2e 74 78 74 00 00 10 54 68 69 73 20 69 73 20 61 20 66 69 6c 65 0a 0a 00 00 00 ... 00 }
  {  ?  f  i  l  e  .  t  x  t  ?  ?  ?  T  h  i  s     i  s     a     f  i  l  e  ?  ?  ?  ?  ? ...  ? }

There were 16 valid bytes of data but more than 200 bytes of zeros were sent
after the end of the valid data.

Valid HTML 4.01 Valid CSS