Welcome, Guest
  • Author Topic: Determining bandwidth(Internet speed)  (Read 1104 times)

    kani

    • Jr. Programmer
    • **
    • Posts: 75
      • View Profile
      • ClipsID
      • Email
    Determining bandwidth(Internet speed)
    « on: 12/11/04, 09:43 »
    hi,
    I stream video files from the server, i would like to find the internet speed of the user viewing the video, inorder to avoid streaming by some very slow users.

    Please help ::)
    kani

    vesa kortelainen

    • Global Moderator
    • Systems Administrator
    • *****
    • Posts: 3450
      • View Profile
    Re:Determining bandwidth(Internet speed)
    « Reply #1 on: 12/11/04, 10:11 »
    I found this from google's cache (the original site has removed) here

    Quote

    he first thing we need to build our bandwidth detector is a SWF of suitable size to test download time.
    This SWF can be of any size but make sure it is not too small (say less than 5k) or else the detection will not be accurate enough, or too large (over 100k) because analog line users will have to wait too long. I suggest a SWF of about 30-40k size. The SWF only needs to contain some media to set its file size such as a sound or bitmap graphic.

    Our next step is to create a bandwidth calculation function that takes into consideration the overhead generated by IP packet headers. Our function will return a bandwidth connection speed in kilobits per second. The function determines how much time elapsed between beginning download and end of SWF download and converts this to seconds which takes takes care of the "per seconds" part. It converts the size of the SWF into kilobits and adjusts for IP packed header size.

    /*
    Calculate approximate kbps after test swf loads
    */
    function getkbps(startTime,sizeInBytes) {
    elapsedTimeMS = getTimer() - startTime; // time elapsed since start loading swf
    elapsedTime = elapsedTimeMS/1000; //convert to seconds
    sizeInBits = sizeInBytes * 8; // convert Bytes to bits,
    sizeInKBits = sizeInBits/1024; // convert bits to kbits
    kbps = (sizeInKBits/elapsedTime) * 0.93 ; // IP packet header overhead around 7%
    return Math.floor(kbps); // return user friendly number
    }

    For most users each packet is 576 bytes. This includes 40 bytes for the header data. So each packet contains 536 bytes of data from the file and 40 bytes of extra header data (536 + 40 = 576). The lager the file, the more packets and consequently more header data. So for each packet we have an extra 40 bytes. Above, you may have noticed that the function multiplies the kbps by 0.93. Where did the 0.93 come from? If we consider that each packet contains roughly 7% header data, (40/576 = 0.69444 or ~7%) then we can deduce that all packets together add 7% to the bandwidth. By multiplying 0.93 we reduce the bandwidth to indicate the throughput for the actual file we are loading.

    Next we can set up a movie clip in our main movie and attach ActionScript to execute the getkbps( ) function when the SWF is completely loaded. For this example, I included the getkbps( ) in the onClipEvent(load) event of the movie clip. This code will wait until the SWF begins to load before setting the timer. We do this to avoid adding extra time caused by server latency which might throw off our bandwidth calculation.

    onClipEvent(enterFrame){
    // do not execute code until SWF begins to load
    if(this._url != _root._url){
    if(typeof start == "undefined") {start = getTimer( );} // set start time once
    if(this.getBytesLoaded() < this.getBytesTotal()){ // not yet loaded
    _root.statusmsg = "Checking Bandwidth";
    }
    if(this.getBytesLoaded( ) == this.getBytesTotal( )){ // swf loaded call getkbps()
    _root.statusmsg = "Bandwidth = " + getkbps(start,this.getBytesTotal()) + " kbps";
    _root.gotoAndStop(2); // move playhead to a different frame
    }
    }
    }

    Finally we load the SWF. Getting back to our original set of issues, this is where we workaround the browser caching problem. There is no consistent way to prevent a browser from caching a SWF. Instead we trick the browser into thinking it is always loading a new SWF. We do this by appending the current date measured in milliseconds since the epoch (begriming of computer time around 1971) at the end of the SWF's url each time we attempt to load it. This unique number makes the url different each time and causes the browser to think the SWF is a new file even though it is only the data in the url that is changing. I placed the following code in the onClipEvent(load) event along with the getkbps( ) function.

    /*
    Load test.swf with a unique time to work around browser caching.
    Browser will always load a new copy of SWF because url is different each time.
    */
    now = new Date(); // create date object
    nocacheStr = "?" + now.getTime();
    this.loadMovie("test.swf" + nocacheStr);

    The code above sends a url like test.swf?100020345 to the server. The server returns test.swf and the extra data, which causes the browser to think the test.swf is a newly downloaded file. We can view your cache directory when you test the example to verify that the browser is downloading a new copy of the SWF each time we run the example.