загрузка файла asp.net - отслеживать размер загружаемого файла

Question

Я пытаюсь спроектировать систему для чего-то подобного с ASP.net/C#.

.

Пользователи платят за скачивание некоторого контента (файлы - mp3s / PDF, doc и т. Д.). Я должен иметь возможность отслеживать количество байт, загруженных пользователем. Если количество загруженных байтов совпадает с количеством байтов на сервере, я должен установить флаг в БД (сообщающий, что загрузка прошла успешно, и запретить им снова скачивать файл / попросить снова оплатить загрузку). Если загрузка была неполной, они должны иметь возможность загрузить файл снова, не заплатив за него снова (поскольку флаг не будет установлен).

Есть ли способ отслеживать количество успешно загруженных клиентом байтов?

Также, когда я вижу размер файла на моей машине с WinXP, я вижу два размера (размер, размер на диске). Какой из них я должен рассмотреть? И будет ли он отличаться от одной ОС к другой?

Answer 1

Вы можете легко измерить данные, передаваемые клиенту в ASP.NET, при условии, что вы замените прямую IIS-контролируемую загрузку своей собственной, что будет выглядеть примерно так:

while (context.Response.IsClientConnected) {

    bytesRead = ReadFileChunkAsByteArrayWIthOffsetOrWhatever(buffer, offset);

    context.Response.OutputStream.Write(buffer, 0, bytesRead);
    context.Response.Flush();

    offset += bytesRead;

    if (bytesRead != bufferSize)
        break;
}

Сложно сделать это на 100% надежным изнутри ASP, но это можно сделать. Вы в значительной степени должны учитывать каждую возможную точку отказа и реагировать соответствующим образом.

Тем не менее, проблема, как уже упоминалось выше, в том, что невозможно узнать, что клиент получил данные. Если в эту транзакцию вовлечены деньги, это может стать проблемой очень быстро.

По этой причине наилучшим подходом будет использование клиентского загрузчика, подобного тому, который Amazon использует для покупок файлов MP3. Таким образом, вы не подвергаете ни себя, ни своих клиентов капризам превращения монетизированных битов в нечто столь же ненадежное, как HTTP.

Answer 2

Чтобы сделать пользовательское обслуживание байтов таким образом, вам потребуется реализовать собственный обработчик http.

Этот обработчик должен делать следующее:

• Внедрите некоторую аутентификацию в обработчике http, чтобы вы знали, с кем имеете дело.
• Затем вам нужно будет выполнить какую-то регистрацию запрошенных файлов и файлов, которые можно загружать.
• Реализация заголовков etags и expires для кэширования на стороне клиента.
• Кэширование на стороне сервера
• Сжать, сжатие gzip
• Если вы хотите поддерживать возобновляемую загрузку, вам нужно будет реализовать 206 частичных ответов. Это важно для любого вида потоковой передачи и обслуживания PDF-файлов.

Таким образом, вы должны обрабатывать следующие http-заголовки:

• ETag

• * 1025 Истекает *

• Accept-Изменяется

• Диапазон

• If-Range

• Last-Modified

• If-Match
• If-None-Match
• If-Modified-Since
• If-Unmodified-С
• Если только-Modified-Since

Если вы ищете пример реализации обработчиков http, проверьте: http://code.google.com/p/talifun-web/wiki

Он имеет статический обработчик файлов, который реализует все вышеупомянутые http-заголовки, кэширование на стороне клиента и на стороне сервера и даже сжатие.

Существует также модуль журнала и модуль авторизации, который должен пройти долгий путь, как реализовать аутентификацию и ведение журнала.

Answer 3

вы можете создать обработчик asp.net, который обслуживает файл (для asp.net mvc вы можете вместо этого выполнить действие результата ... это то, что я использую). Убедитесь, что он поддерживает возобновляемую загрузку.

от вы можете отслеживать обслуживаемых байтов.

Ps. это влечет за собой снижение производительности по сравнению с предоставлением IIS

обновление 1: Я использовал нечто похожее на это http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx ... и в статье есть довольно четкое объяснение того, что внутри. Вы, вероятно, можете использовать его как есть, см. Пример в этом посте.

Answer 4

Вы можете попытаться просмотреть коды ответа HTTP (например, 200, 404 и т. Д.) - клиент и сервер будут обмениваться заголовками http, чтобы они знали, что происходит, - вы должны иметь возможность отслеживать их, чтобы увидеть, были ли ответы успешно (не уверен - но вы должны быть в состоянии).

Что касается размера файла - я бы попробовал поэкспериментировать с файлами «известных» размеров, сравнить то, что в журналах Http сообщается, с тем, что сообщает файловый проводник.

Кроме того, я видел инструменты / wodgets, которые сообщают о ходе загрузки файла - так что вы правы, вы должны иметь возможность сделать то же самое в обратном направлении, я думаю. Вы можете попробовать посмотреть примеры кода и руководства по загрузке файлов - вы можете получить некоторые подсказки. Я не могу думать ни о чем из головы - извините.

Answer 5

Размер, который вы хотите, - это размер (а не размер на диске). Размер на диске включает в себя дополнительное место, которое занято, вписываясь в размер блока 4К раздела. Размер - это точное количество бит в файле.

Я не верю, что есть хороший способ сказать, что загрузка была завершена. Response.TransmitFile, вероятно, лучший способ для безопасной отправки файла. Но я не верю, что в нем есть что-то, что скажет вам, действительно ли пользователь получил файл.

Я не знаю о бизнесе, который это поддерживает, но я не могу придумать легитимного бизнеса, в котором пользователи допускали бы одну загрузку для каждой модели покупки, а со стандартностью HTTP-модели запросов / ответов это невозможно. Вы можете сделать точный приемник на стороне клиента. Не говоря уже о том, что эту модель можно легко взломать, отправив ошибочный ответ при получении последнего пакета.

Я думаю, что использую что-то вроде окна загрузки (через 2 часа после покупки) и затем блокирую его на IP после того, как первый запрос достигнет того же результата и приведет к гораздо меньшим проблемам пользователей и звонкам в службу поддержки. Кроме того, если файл не имеет какой-либо строгой DRM, предоставление пользователю постоянного доступа на основе его логина, скорее всего, является подходящей бизнес-моделью, потому что, получив файл, он может скопировать его столько раз, сколько пожелает.

Посмотрите на DVD или Blu-Ray, никакие средства защиты от копирования или контроля доступа не спасут ваши файлы от пиратов, поэтому упростите работу для законных пользователей.