pCDN:Testplan

Client

1. Download several new podcasts from the web servers (make sure the media/ directory contains no media files before this test).
2. Download new podcasts from several pCDN senders.
3. Download podcasts that were downloaded before (and still in media/ directory).
4. Reduce the harddisk quota using user interface to 50 MB, and download several podcasts.
5. Reduce the memory quota to 4 MB, and download several podacsts.
6. Download new podcasts from several senders and unplug the Ethernet cable from one of the senders.
7. Download new podcasts from several senders and unplug the Ethernet cables from all of the senders.
8. Download new podcasts from several senders and unplug the Ethernet cable from the receiver.
9. Manually truncate the media files in media/ directory, and download that file from the podcast client.
10. Manually truncate the media files in media/ directory, and request that file from another pCDN client.
11. Download several new podcasts using a pCDN client behind a NAT box. Check whether the IP/port are correctly reported at the pCDN server. Also try to use this pCDN client as the sender.
12. Download several new podcasts using a pCDN client on a machine with multiple IPs. Use user-interface to select an outgoing IP. Then, change the NICs' IP addresses, and see whether the pCDN client continues work after reboots.

Server

Note: In case a tracker gets disconnected, re-connection suffices (e.g., re-plugging the cable if the cable was unplugged). There is no need to re-start the tracker.

1. When trackers are up and connected to each other:
   • peers download files from each other as expected.
2. Have a peer download podcasts, and then bring the current primary tracker down (or unplug its network cable):
   • No problem. The peer communicates with the next tracker after a few seconds.
3. (i) Have a peer join the network when some trackers are down, or (ii) After the peer joined the network (primary tracker is T1 for example), bring T1 down and have the peer request some files:
   • No problem. Peer connects to the next tracker to join/request.
4. Re-plug the network cable of a tracker that was the primary and has been disconnected from the network since we unplugged its cable:
   • The trackers gets working properly, becomes primary, and receives the most recent database file from the tracker who was the primary during the absence (cable-unplugged) period.
5. A tracker T1, who is prior to T2 for being the primary, has been down/disconnected and is just started/re-connected. When a peer (who is now connected to T2) requests to download a file:
   • T2 leads the peer to T1 and the peer immediately connects to T1 to ask where to download the file from.
6. Have a peer P1 download a file F1, wait until the backuping moment (when the primary tracker T1 pushes his recent database to others), and bring the primary tracker down after that:
   • Tracker T2 becomes the primary and P2 downloads file F1 from peer P1 (not from the web server).
7. Tracker T1 was the primary, but is down/disconnected now and tracker T2 is the current primary. Peer P1 downloads file F1. T1 comes back and becomes the primary, so T2 immediately pushes the most recent database to T1. Then, peer P2 requests to download F1:
   • If T1 was brought down by Ctrl+C and is started again now: P2 download F1 from P1.
   • If T1 was disconnected by unplugging its network cable: when P2 now requests the file, the balloon “Sorry, you are not permitted to download the file” is shown (XXX).
8. When a peer is connected to the network and suddenly all trackers get dead:
   • The peer keeps re-trying to connect. Thus when some tracker came up, the peer connects to it.
9. Run trackers T1 and T2, where T1 is the primary, and a peer is connected to the network. Stop T1, so T2 becomes the primary, and the peers connects to T2 after a short time. Start T1 again. Now, for a few seconds T2 still thinks he is the primary. Immediately unplug T2’s cable.
   • T1 knows himself as the primary and the peer downloads files through T1.
   • T2 after some seconds knows that he is the primary. The peer is able to download files through T2.

Known Issues

1. Server: the keep-alive interval must not be smaller than the time it takes to transmit the database file from one tracker to another. For example, wil a value of "1 minute" for that interval, if the size of the database file gets in orders of some hundred megabytes or some gigabytes (i.e., some millions of users), that interval must be increased to "10 minutes" or so.
2. Client: The preferences frame silently rejects settings that are out of supported ranges. For example, max memory usage below 4 MB will be rejected without giving any warning. Due to the limitation of Java class and display space, we plan to address this in the new GUI design.
3. Client: When a receiver loses its Internet connection, the pCDN client does not return a proper error code to podcast clients, such as iTunes. Instead, we wait until iTunes times out.
4. Server: Server would crash (XXX need to validate this), if the RDBMS goes off-line.

• The following are also posted to Bugzilla (can be removed from here, but not suggested):

1. Client: When we stop downloading a file in iTunes, the pCDN client still continues downloading.
   • A user might have stopped the download in order to save his bandwidth for some other applications, but the pCDN client prevents that saving.
2. Server: Each tracker has a file settings.ini, which must be the same for all trackers. Having this file in a centralized manner, such as on a file server, may be helpful, because modification of that file on some tracker may cause improper functioning of the entire system.
3. The directory containing media files a peer has stored gets larger and larger by time. There should be a mechanism to delete unnecessary ones. [Cheng 08/03/01, There is a max disk usage setting in client GUI, which will remove the least recently received files. Note that, however, the recency is not persistent, so the received time of each files got lost after rebooting pCDN clients.]