3,035
edits
Changes
no edit summary
== Abstract ==
Bouncer uses MySQL to organize the Mozilla mirror network. Its primary responsibility is to know what mirrors are supposed to contain what files and periodically query their availability. Based on this knowledge, accumulated by a "sentry" script, Bouncer redirects simple user requests to appropriate mirrors based on a random seed that is affected by the mirror's relative bandwidth capabilities.
In short, Bouncer is a smarter way to use an extended mirror network to help users get what they need.
It contains three main pieces:
* Admin tools to manage the mirror network
* Sentry; a daemon that queries mirrors for available files and updates their status in the Bouncer database
* Bouncer; a singular file responsible for taking arguments and redirecting users to the appropriate location
== History ==
Bouncer went live at 2pm, November 9th, 2004 and has been serving files since. It was originally developed as a backup plan, but was pushed to production when the demand for Firefox 1.0 overloaded the existing mirror network. Utilizing secondary mirrors through Bouncer helped keep downloads flowing in the wake of Mozilla's largest release to date.
Bouncer was originally developed at Oregon State University by Scott Kveton and Mike Morgan. The intent was to help the Mozilla community meet its growing demands.
Additional development on Bouncer has continued into 2005. K Lars John, a developer at the Oregon State University Open Source Lab, has made great contributions to the project by assisting with database improvements and the migration of Sentry from Perl to Python. He has helped make Sentry a multi-threaded daemon that will scale much better for an increased mirror network hosting a greater number of projects/files.
== Status ==
Bouncer 1.0 is currently directing users to the latest Firefox and Thunderbird releases through the mirror network. Bouncer 2.0 is nearing the final stages of development and should be deployed before Firefox 1.0.1 is released.
== Roadmap ==
=== Bouncer 1.0 ===
* Basic administrative tools
** OS
** Products
** Regions
** Mirrors
** Users
** File Locations
* Sentry
** Basic Perl script to query all locations on all mirrors
** Failed requests would be flagged and would be removed from rotation
* Bouncer Script Parameters
** OS
** Product
** Language
* Known Issues
** Languages; offered as a pass-thru but there was no support for it on the database side of things because it was added post-development
** Versions; 1.0 offers only the latest releases
** Sentry; only queries HTTP mirrors
** Sentry; does not check MD5 sums
Bouncer 1.0 was a great start, but lacked some functionality due to time constraints. Since 1.0 we have had improved communications, and developed a solid plan to fix known issues and secure the overall application.
1.0 is a temporary solution to aid Mozilla in a time of growth. It will evolve with time and improve itself through the combined efforts of the community.
=== Bouncer 2.0 ===
* Administrative changes
** MD5, SHA1 key storage
** Mirror contact information added
** Mirror policy reviewed and updated
** Versions
** Languages
** Improved database structure (denormalized a bit)
* Sentry
** Converted to Python
** Multi-threaded
** Scalability improved
** Actually downloads file and checks MD5, SHA1
* Bouncer
** Added optional Version parameter; defaults to latest version by date
** Added full language support based on modified DB and admin capabilities
* Development Model
** Integration with Mozilla CVS tree
** Adoption of build process and other Mozilla standards
This first joint effort provides better overall security and granularity. It fixes Language and Version gaps and provides better assurance through improved file checking (MD5,SHA1).
Second priorities were improved statistical tools for generating trend reporting. That was not completed, but will be addressed in 3.0.
=== Bouncer 3.0 ===
* Build Features
** Possible automation with build process to streamline releases
** Queue of upcoming releases for build engineers to manage availability of binaries on mirror network
* Improved reporting tools based on download counts and apache logs (stored in separate db)
* UMO
** Possible integration with AUS, PFS, or other update services to leverage mirror network capabilities
** Advanced signing for improved security
The future of Bouncer depends on the development of UMO and what role people see it playing in relation to Mozilla's update service. It will continue to distribute binaries through the mirror network, but how it can better fit into Mozilla's workflow has yet to be determined. We are working on figuring out how it can help automate and combine builds, updates, etc. The best is yet to come.
Bouncer uses MySQL to organize the Mozilla mirror network. Its primary responsibility is to know what mirrors are supposed to contain what files and periodically query their availability. Based on this knowledge, accumulated by a "sentry" script, Bouncer redirects simple user requests to appropriate mirrors based on a random seed that is affected by the mirror's relative bandwidth capabilities.
In short, Bouncer is a smarter way to use an extended mirror network to help users get what they need.
It contains three main pieces:
* Admin tools to manage the mirror network
* Sentry; a daemon that queries mirrors for available files and updates their status in the Bouncer database
* Bouncer; a singular file responsible for taking arguments and redirecting users to the appropriate location
== History ==
Bouncer went live at 2pm, November 9th, 2004 and has been serving files since. It was originally developed as a backup plan, but was pushed to production when the demand for Firefox 1.0 overloaded the existing mirror network. Utilizing secondary mirrors through Bouncer helped keep downloads flowing in the wake of Mozilla's largest release to date.
Bouncer was originally developed at Oregon State University by Scott Kveton and Mike Morgan. The intent was to help the Mozilla community meet its growing demands.
Additional development on Bouncer has continued into 2005. K Lars John, a developer at the Oregon State University Open Source Lab, has made great contributions to the project by assisting with database improvements and the migration of Sentry from Perl to Python. He has helped make Sentry a multi-threaded daemon that will scale much better for an increased mirror network hosting a greater number of projects/files.
== Status ==
Bouncer 1.0 is currently directing users to the latest Firefox and Thunderbird releases through the mirror network. Bouncer 2.0 is nearing the final stages of development and should be deployed before Firefox 1.0.1 is released.
== Roadmap ==
=== Bouncer 1.0 ===
* Basic administrative tools
** OS
** Products
** Regions
** Mirrors
** Users
** File Locations
* Sentry
** Basic Perl script to query all locations on all mirrors
** Failed requests would be flagged and would be removed from rotation
* Bouncer Script Parameters
** OS
** Product
** Language
* Known Issues
** Languages; offered as a pass-thru but there was no support for it on the database side of things because it was added post-development
** Versions; 1.0 offers only the latest releases
** Sentry; only queries HTTP mirrors
** Sentry; does not check MD5 sums
Bouncer 1.0 was a great start, but lacked some functionality due to time constraints. Since 1.0 we have had improved communications, and developed a solid plan to fix known issues and secure the overall application.
1.0 is a temporary solution to aid Mozilla in a time of growth. It will evolve with time and improve itself through the combined efforts of the community.
=== Bouncer 2.0 ===
* Administrative changes
** MD5, SHA1 key storage
** Mirror contact information added
** Mirror policy reviewed and updated
** Versions
** Languages
** Improved database structure (denormalized a bit)
* Sentry
** Converted to Python
** Multi-threaded
** Scalability improved
** Actually downloads file and checks MD5, SHA1
* Bouncer
** Added optional Version parameter; defaults to latest version by date
** Added full language support based on modified DB and admin capabilities
* Development Model
** Integration with Mozilla CVS tree
** Adoption of build process and other Mozilla standards
This first joint effort provides better overall security and granularity. It fixes Language and Version gaps and provides better assurance through improved file checking (MD5,SHA1).
Second priorities were improved statistical tools for generating trend reporting. That was not completed, but will be addressed in 3.0.
=== Bouncer 3.0 ===
* Build Features
** Possible automation with build process to streamline releases
** Queue of upcoming releases for build engineers to manage availability of binaries on mirror network
* Improved reporting tools based on download counts and apache logs (stored in separate db)
* UMO
** Possible integration with AUS, PFS, or other update services to leverage mirror network capabilities
** Advanced signing for improved security
The future of Bouncer depends on the development of UMO and what role people see it playing in relation to Mozilla's update service. It will continue to distribute binaries through the mirror network, but how it can better fit into Mozilla's workflow has yet to be determined. We are working on figuring out how it can help automate and combine builds, updates, etc. The best is yet to come.
