2010-02-24 14 views
6

Tengo un sitio de alojamiento de archivos y los usuarios obtienen una recompensa por las descargas. Así que quería saber si hay alguna manera de poder rastrear si el visitante descargó todo el archivo para que no haya descargas parciales falsas solo por recompensas.Archivo de seguimiento descarga completa

Gracias.

+0

¿Cómo se supone que esos archivos son grandes? Kb? ¿Megabyte? <100 Mb? – Strae

+0

DK-Wamp dijo: "¿Puedo obtener más detalles sobre este tema? // Intenté utilizar este script pero no funcionó para mí .((() Sé que es un tema antiguo, pero espero encuentra una solución. " – Veedrac

Respuesta

1

Si pudieras controlar los códigos de respuesta HTTP devueltos por tu servidor web y vincularlos a las sesiones que los generaron, estarías en el negocio.

Un código de respuesta de 206 muestra que el sistema entregó parte de la información pero no toda. Cuando el fragmento final del archivo se apaga, no debe tener un código de respuesta de 206.

Si puede vincular esto a las sesiones de usuario colocando el código de la sesión dentro de la URL, podría dar puntos basados ​​en un simple agregación de registro.

+0

¿Puede mostrarme algún ejemplo de su uso? – Shishant

+0

No tengo ningún registro de Apache a la mano. ¿Tiene un fragmento de una transferencia de archivos de sus registros que puede publicar? Filtrarlo por un archivo y una dirección IP para obtener solo las entradas correspondientes. Dependiendo de su formato de registro, debería ser relativamente fácil encontrar la entrada que es la última página del archivo. – TheJacobTaylor

1

Implementé una solución similar en un sitio web de alojamiento de archivos.

Lo que quiere hacer es utilizar la función de devolución de llamada register_shutdown_function que le permite detectar el final de la ejecución de un script php independientemente del resultado.

Luego desea tener su archivo en una ubicación no accesible en la web de su servidor (s), y hacer que sus descargas pasen por php: la idea es que usted quiere poder rastrear cuántos bytes se han pasado a el cliente.

Aquí está una manera básica de la aplicación (por ejemplo :)

<?php 
register_shutdown_function('shutdown', $args); 

$file_name = 'file.ext'; 
$path_to_file = '/path/to/file'; 
$stat = @stat($path_to_file); 

//Set headers 
header('Content-Type: application/octet-stream'); 
header('Content-Length: '.$stat['size']); 
header('Connection: close'); 
header('Content-disposition: attachment; filename='.$file_name); 

//Get pointer to file 
$fp = fopen('/path/to/file', 'rb'); 
fpassthru($fp); 

function shutdown() { 
    $status = connection_status(); 

    //A connection status of 0 indicates no premature end of script 
    if($status == 0){ 
    //Do whatever to increment the counter for the file. 
    } 
} 
>? 

es evidente que hay maneras de mejorar, así que si usted necesita más detalles u otro comportamiento, por favor hágamelo saber!

+1

Esto matará apache con archivos grandes ... – Strae

+0

Sí, tienes razón, depende en gran medida del uso del sitio. En nuestra aplicación, solíamos canalizar todas las descargas de archivos a través de php porque también usábamos para autenticar el usuario, y estrangular el ancho de banda. El punto es que teníamos servidores dedicados para servir esos archivos, alimentando servidores de almacenamiento back-end que ejecutaban lighttpd. Redujimos la huella de Apache mediante la compilación personalizada y la desactivación de todos los módulos esenciales. aproximadamente 130 descargas simultáneas/servidor en más de 35 interfaces, para un rendimiento total de 2 .3Gbps ... –

Cuestiones relacionadas