Difference between revisions of "pCDN:Testplan"

From NMSL
Line 30: Line 30:
 
#*Tracker T2 becomes the primary and P2 downloads file F1 from peer P1 (not from the web server).
 
#*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:
 
#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.
+
#*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, or when the internet connection of the peer is cut:
#When a peer is connected to the network and suddenly all trackers get dead:
+
#*The peer keeps re-trying to connect. When some tracker came up, or when the peer was re-connected to the Internet, the connects to a tracker.
#*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.
 
  
  

Revision as of 13:47, 4 March 2008

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:
    • P2 download F1 from P1.
  8. When a peer is connected to the network and suddenly all trackers get dead, or when the internet connection of the peer is cut:
    • The peer keeps re-trying to connect. When some tracker came up, or when the peer was re-connected to the Internet, the connects to a tracker.


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.
  4. When backup file is transferred to the tracker (that we are currently connected to) and restored, the entire 'content' tab and 'connected peers' tab info is cleared and populated with the latest one.


Geo-Fencing

  1. Groups Tab:
    • Select a row and press DEL key. Check from the database that the selected group is deleted and also all the files corresponding to the group from both 'media' table and 'groups' table (which contains the pair fileid-groupid). Also, note that this selected row is deleted from the table in the UI and also all the files corresponding to the group are deleted from the 'Media Files' tab's table. In addition, the combo box corresponding to 'groupname' in 'Content Importer' tab, is updated respectively, i.e., the deleted group is not present in the combo box list.
    • Select a row and double-click it. Check that it opens up a Policy Window in which the group's policy is displayed in respective fields correctly. After editing, when 'Save' button is pressed, the corresponding group info is updated in the database and also is reflected in the 'Groups Tab'. We must also be able see the difference being reflected in the combo box of the 'Content Importer' tab and also the 'Media Files' tab, especially in the case of name of group being altered.
  2. Media Files Tab:
    • Select a row and press DEL key. Check from the database that the selected file is deleted from the 'media' table and also groups table, the pair groupid-fileid is to be deleted. Also, the file is removed from the table in the UI.
    • Select a row and change the group of a particular file by selecting any other group from the combo box in the third column of the table. That particular change should not only be reflected in the UI but also the database must be updated with the newer group. Check the 'groups' database table to see if groupid corresponding the fileid has changed to the newer one.
  3. New Policy:
    • Fill all respective fields in the Policy Window and press "Save" Button. Check if the database's Policy table is filled with a new entry that has just been inserted. Also, note that the group is inserted in "Groups" Tab. In addition, the combo box in the 'Content Importer' tab is also updated with the new entry. The combo box in the third column of 'Media Files' tab's table is also updated.


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.
  5. Monitor: If a group / file is added / edited / deleted using Content Manager, it is not updated on all the other running monitoring applications.


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