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

1. Have a client doing podcast, then reboot the primary tracker --> continuation of podcast, at most with a short pause.
   • done
2. Have a client join the network right after a tracker is rebooted --> no problem.
   • done
3. Bring Tracker1 and Tracker2 down, and have a new peer join the network --> fail! (why?!!)
   • we ran 3 trackers, A, B, and C respectively. Then we brought A down, started a client (that successfully joined), stopped B (client could still successfully download new medias) so the primariness was given to C, and then we started B again. After that, we unplugged C 's cable (instead of pressing Ctrl+C on its console, so now B does not instantly understand about C 's failure). What we expect is: client must still be able to download new files (via B), and B must understand that it is the primary now.
     • Fixed!
4. Compare the response (in the log file) of query messages that are sent to all trackers right before and right after the backuping moment --> no difference in the two responses of the primary tracker, and a same update in responses from the rest of the trackers.
5. (Tracker1 is initially the primary tracker) Have a client frequently send join messages to Tracker1 and Tracker2, then reboot Tracker1 and monitor JoinAck messages of Tracker2. Do the same thing with Tracker2 after it is selected as the primary (after Tracker1 went down) --> the primary tracker indicated in the JoinAck messages must get updated properly.
6. Stop Primary server and check if the next alive one in the tracker-list takes up as primary and also connect to all the peers by sending JoinAckMsg.
   • Works, but JoinAckMsg is not received at client's side.
7. Disconnect / Unplug the Primary server from the network and check if the next alive one in the tracker-list takes up as primary and also connect to all the peers by sending JoinAckMsg.
   • Works, but JoinAckMsg is not received at client's side.
8. Disconnect / Unplug Primary server from network and check if peers connect to next tracker.
   • Works
9. If one of the non-primary servers crashes, it is not an alarm, but check that after every Backup Interval, the backup file is being passed consistently from the primary server to the next alive one and restored correctly.
   • Works
10. Server: If a server is unplugged from the network, if it becomes the server again after connecting back, check if the database operations fail. It should reconnect to the database.
    • Done

Known Issues

1. 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.
2. 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.
3. Server: Server would crash (XXX need to validate this), if the RDBMS goes off-line.
4. Server: if primary and secondary trackers, which are the only know ones to a client at the very beginning, are down, a new client can not join the network even though some trackers are still up.