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.

Admin Tools

Server Statistics

1. When a peer joins the network, there are (max) 3 updates that happen in the UI:
   • Bottom of the screen: '#Peers' increase by 1 after MainData Update interval, which is set at the time of Login.
   • Connected Peers tab: The country the peer belongs to is inserted into the left table if the country is not already there in the left table. When that country is clicked, all the peers that belong to that country along with city and region details are shown in the right table. Also, note that the number of peers respective to the country also increment
   • Content tab: If that peer has files, these files are inserted into the left table (if these are not already there) and the peer info is added to the corresponding file. When one clicks on a particular file, all those peers containing that file are shown in the right table.
2. When a peer leaves the network, there are (max) 3 updates that happen in the UI:
   • Bottom of the screen: '#Peers' decrease by 1 after MainData Update interval, which is set at the time of Login.
   • Connected Peers tab: The peer is deleted from the respective country's right table and if the corresponding country has no peers, the country will be deleted from the left table. Also, note that the number of peers respective to the country also decrement.
   • Content tab: This particular peer's record is coloured grey in the right table for every file (present in the left table) it contains.
3. When a peer downloads a file, 'Content' tab is updated by inserting file info in the left table if it is not already there and then to the corresponding file's right table, this peer info is added.

Content Importer

1. Select a group from the combo box and enter a feed URL and output feed filename and press "Import and Convert" button.
   • Success: A dialog pops up saying that these files are imported into the database. Check in the database's 'Media' table that these files are imported and also 'Groups' table being populated with the corresponding fileid and groupid information. Also, these files are inserted into the 'Media Files' tab's table pointing to respective group. Check the output file is created with http://localhost being inserted for every URL within that feed file.
   • Failure: A dialog pops up saying that these files could not be imported into the database. Check if database is the same as before.
2. Select a group from the combo box and enter a non-feed URL and press "Import".
   • Success: A dialog pops up saying that these files are imported into the database along with output URL. Check in the database's 'Media' table that this file is imported and also 'Groups' table being populated with the corresponding fileid and groupid information.
   • Failure: A dialog pops up saying that these files could not be imported into the database. Check if database is the same as before.
3. Try pressing "Import and Convert" button with atleast any one of the Feed-URL fields unfilled/empty, a dialog box is shown with a message that both the fields are to be filled.
4. Try pressing "Import" button with non-feed URL field unfilled/empty, a dialog box is shown with a message that the field is to be filled.

User Administration

1. Add a new user and check if it is inserted into the database and also in the table shown below.
2. Change the privilege level of a user using the combo box in the table and check if it is reflected in the database.
3. Select a row in the table and press DEL key. The row must get deleted from the database and also the table.

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.]