Difference between revisions of "pCDN:Testplan"

Revision as of 23:50, 29 February 2008

Client

Download several new podcasts from the web servers (make sure the media/ directory contains no media files before this test).
Download new podcasts from several pCDN senders.
Download podcasts that were downloaded before (and still in media/ directory).
Reduce the harddisk quota using user interface to 50 MB, and download several podcasts.
Reduce the memory quota to 4 MB, and download several podacsts.
Download new podcasts from several senders and unplug the Ethernet cable from one of the senders.
Download new podcasts from several senders and unplug the Ethernet cables from all of the senders.
Download new podcasts from several senders and unplug the Ethernet cable from the receiver.
Manually truncate the media files in media/ directory, and download that file from the podcast client.
Manually truncate the media files in media/ directory, and request that file from another pCDN client.
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.
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.

When trackers are up and connected to each other:
- peers download files from each other as expected.
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.
(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.
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.
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.
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).
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).
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.
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

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.
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.
Server: Server would crash (XXX need to validate this), if the RDBMS goes off-line.
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.
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.
The directory containing media files a peer has stored gets larger and larger by time. There should be a mechanism to delete unnecessary ones.

@@ Line 12: / Line 12: @@
 # 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.
 # 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 ==
-# Have a client doing podcast, then reboot the primary tracker --> continuation of podcast, at most with a short pause.
+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.
-#*done
-# Have a client join the network right after a tracker is rebooted --> no problem.
+# When trackers are up and connected to each other:
-#*done
+#*peers download files from each other as expected.
-# Bring Tracker1 and Tracker2 down, and have a new peer join the network --> fail! (why?!!)
+# Have a peer download podcasts, and then bring the current primary tracker down (or unplug its network cable):
-#*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.
+#*No problem. The peer communicates with the next tracker after a few seconds.
-#**Fixed!
+#(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:
-# 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.
+#*No problem. Peer connects to the next tracker to join/request.
-# (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.
+#Re-plug the network cable of a tracker that was the primary and has been disconnected from the network since we unplugged its cable:
-# 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.
+#*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.
-#* Works, but JoinAckMsg is not received at client's side.
+#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:
-# 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.
+#*T2 leads the peer to T1 and the peer immediately connects to T1 to ask where to download the file from.
-#* Works, but JoinAckMsg is not received at client's side.
+#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:
-# Disconnect / Unplug Primary server from network and check if peers connect to next tracker.
+#*Tracker T2 becomes the primary and P2 downloads file F1 from peer P1 (not from the web server).
-#* Works
+#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 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.
+#*If T1 was brought down by Ctrl+C and is started again now: P2 download F1 from P1.
-#* Works
+#*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).
-# 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.
+#When a peer is connected to the network and suddenly all trackers get dead:
-#* Done
+#*The peer keeps re-trying to connect. Thus when some tracker came up, the peer connects to it.
+#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.
@@ Line 39: / Line 43: @@
 # 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.
 # Server: Server would crash (XXX need to validate this), if the RDBMS goes off-line.
-# 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.
+#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.
+#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.
+#The directory containing media files a peer has stored gets larger and larger by time. There should be a mechanism to delete unnecessary ones.