(I'm very tired and stupid so bear with me) – If the module could use the downloadables table used by Sentry, it could minimize queries needed to 2 (one to get the built URL, one to increment the count for that file->mirror mapping). Since that count cascades, stats would be preserved without needed extra queries.

One thing to discuss is how, given different mirror structures and different nomenclature, the bouncer will be able to interpret incoming paths and link them to a corresponding entry in downloadables.

Are we going to query for a match on everything past the mirror's base URL? It would just require some slight changes in how sentry populates downloadables. Given this scenario, the bouncer script could grab the downloadable row, which right now would contain:

• downloadable_id
• mirror_id
• file_id
• downloadable_url

It could instead contain:

• downloadable_id
• mirror_id
• file_id
• mirror_url

downloadable_url gets nuked because it is already being received by the apache module, and has been used as the search key. mirror_url gets passed back as the accountable server address for that particular file. downloadable_id can then be used to update the downloadable_count field for comprable statistics to what we have now.

So, to get the downloadable_id (and the correct mirror_url based on Sentry's findings):

           
SELECT
    downloadables.mirror_id,
    downloadables.file_id,
    downloadables.downloadable_url
FROM
    downloadables
INNER JOIN
    files
ON
    downloadables.file_id = files.file_id
INNER JOIN
    mirrors
ON
    downloadables.mirror_id = mirrors.mirror_id
WHERE
    downloadables.downloadable_url='{$url}' AND
    downloadables.downloadable_active='1' AND
    mirrors.mirror_active='1' AND
    mirrors.mirror_admin_disable!='1'
ORDER BY
    RAND()*(1/mirrors.mirror_rating)

Then to increment the count:

           
UPDATE
    downloadabes 
SET 
    downloadable_count=downloadable_count+1 
WHERE 
    downloadable_id='{$downloadable_id}'