asp.net 文件下载 - 跟踪下载的大小

发布于 2024-08-16 08:49:06 字数 318 浏览 6 评论 0原文

我正在尝试使用 ASP.net/C# 设计一个类似的系统。

用户付费下载一些内容(文件 - mp3/PDF、doc 等)。我应该能够跟踪用户下载的字节数。如果下载的字节数与服务器上的字节数匹配,我应该在 DB 中设置一个标志(告诉他们下载成功并防止他们再次下载文件/要求他们再次支付下载费用)。如果下载不完整,他们应该能够再次下载该文件而无需再次付费(因为不会设置该标志)。

有什么方法可以跟踪客户端成功下载的字节数吗?

另外,当我在 WinXP 计算机中看到文件大小时,我会看到两个大小(大小、磁盘上的大小)。我应该考虑哪一个?一个操作系统与另一个操作系统之间会有不同吗?

I am trying to design a system for something like this with ASP.net/C#.

The users pay for downloading some content (files- mp3s/PDFs,doc etc).I should be able to track the number of bytes downloaded by the user. If the number of bytes downloaded match the number of bytes on the server, I should set a flag in DB (telling that the download was successful and prevent them from downloading the file again/asking them to pay for the download again). If the download was incomplete, they should be able to download the file again without paying for it again(since the flag will not be set).

Is there any way to keep track of the number of bytes successfully downloaded by the client ?

Also when I see a file size in my WinXP machine, I see two sizes(size,size on disk). Which one should I consider ? And will it differ from one OS to another ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

困倦 2024-08-23 08:49:06

您可以轻松地测量在 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;
}

在 ASP 中使其 100% 可靠很复杂,但可以做到。您几乎必须考虑每个可能的故障点并做出相应的反应。

但问题仍然是 - 正如上面有人提到的 - 不可能知道客户端收到了数据。如果这笔交易涉及金钱,那么很快就会成为一个问题。

因此,最好的方法是使用自定义下载客户端,例如 Amazon 用于购买 MP3 文件的客户端。这样,您自己或您的客户就不会因为通过像 HTTP 这样不可靠的东西传输货币化位而受到变幻莫测的影响。

You can easily measure data passed to the client in ASP.NET assuming you replace a direct IIS-controlled download with your own, which would go something like this:

while (context.Response.IsClientConnected) {

    bytesRead = ReadFileChunkAsByteArrayWIthOffsetOrWhatever(buffer, offset);

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

    offset += bytesRead;

    if (bytesRead != bufferSize)
        break;
}

It's complicated to make this 100% reliable from within ASP, but it can be done. You pretty much have to account for every possible failure point and react accordingly.

The problem though is still - as someone mentioned above - that it's impossible to know that the client received the data. If money is involved in this transaction, that can get to be a problem really quickly.

For that reason, the best approach would be to use a custom downloader client, like the one Amazon uses for MP3 file purchases. That way you're not subjecting either yourself or your customers to the vagaries of moving monetized bits over something as unreliable as HTTP.

戴着白色围巾的女孩 2024-08-23 08:49:06

您可以创建一个为该文件提供服务的 asp.net 处理程序(对于 asp.net mvc,您可以执行结果操作......这就是我正在使用的)。确保它支持可断点下载。

您可以从中跟踪所服务的字节。

诗。与让 IIS 提供服务相比,这会产生性能开销

更新 1: 我使用了与此非常相似的东西 http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx ...以及文章对里面的内容有非常清楚的解释。您可能可以按原样使用该版本,请参阅该文章中的示例。

you can create an asp.net handler that serves the file ( for asp.net mvc u can do a result action instead ... this is what I'm using). Make sure it supports resumable downloads.

from the you can track the bytes served.

Ps. this incurs a performance overhead vs. letting IIS serve it

update 1: I used something pretty similar to this http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx ... and the article has a pretty clear explanation on what's inside it. You probably can use that one as is, see the example in that post.

征棹 2024-08-23 08:49:06

您可以尝试查看 HTTP 响应代码(即:200、404 等) - 客户端和服务器将交换 http 标头,以便他们知道发生了什么 - 您应该能够监视这些代码以查看响应是否成功(不是当然 - 但你应该能够)。

关于文件大小 - 我会尝试对“已知”大小的文件进行实验,将 Http 日志告诉您的内容与文件资源管理器告诉您的内容进行比较。

另外,我见过报告文件上传进度的工具/wodgets - 所以你是对的,我想你应该能够反向执行相同的操作。您可以尝试查看文件上传代码示例和教程 - 您可能会得到一些提示。我一时想不出任何办法——抱歉。

You could try looking into HTTP reponse codes (i.e: 200, 404 etc) - the client and server will be exchanging http headers so that they know what's going on - you should be able to monitor these to see if the reponses was successful (not sure - but you should be able to).

With regards to file size - I would try experiments on files with 'known' sizes, compare what the Http Logs tell you with what file explorer tells you.

Also, I've seen tools/wodgets that report file upload progress - so you're right you should be able to to the same in reverse, I guess. You could try looking at file upload code examples and tutorials - you might get some hints. I can't think of any off the top of my head - sorry.

花间憩 2024-08-23 08:49:06

要执行这样的自定义字节服务,您需要实现自己的 http 处理程序。

该处理程序应执行以下操作:

  • 在 http 处理程序上实现某种身份验证,以便您知道您正在与谁打交道。
  • 然后,您需要对请求的文件和允许下载的文件实施某种日志记录。
  • 为客户端缓存实现 etag 和过期标头。
  • 服务器端缓存
  • Deflate、gzip 压缩
  • 如果要支持可断点下载,则需要实现 206 部分响应。这对于任何类型的流媒体和 pdf 服务都是至关重要的。

因此,您应该处理以下http标头:

  • ETag
  • Expires

  • Accept-Ranges

  • Range
  • If-Range

  • Last-Modified

  • If-Match
  • If-None-Match
  • If-Modified-Since
  • If-Unmodified-Since
  • Until-Modified-Since

如果您正在寻找 http 处理程序的示例实现,请查看:
http://code.google.com/p/talifun-web/wiki

它有一个静态文件处理程序,可实现上述所有 http 标头、客户端和服务器端缓存甚至压缩。

还有一个日志模块和一个授权模块,它们应该对如何实现身份验证和日志记录有很大帮助。

To do custom byte serving like this, you will need to implement your own http handler.

This handler should do the following:

  • Implement some kind of authentication on the http handler, so you know who you are dealing with.
  • Then you will need to implement some kind of logging for files requested and files allowed to be downloaded.
  • Implement etags and expires headers for client side caching.
  • Server side caching
  • Deflate, gzip compression
  • If you want to support resumable downloads, you will need to implement 206 partial responses. This is essential for any kind of streaming and serving pdfs.

So you should be handling the following http headers:

  • ETag
  • Expires

  • Accept-Ranges

  • Range
  • If-Range

  • Last-Modified

  • If-Match
  • If-None-Match
  • If-Modified-Since
  • If-Unmodified-Since
  • Unless-Modified-Since

If you are looking for a sample implementations of http handlers check out:
http://code.google.com/p/talifun-web/wiki

It has a static file handler that implements all the above http headers, client side and server side caching and even compression.

There is also a log module and an authorization module that should go a long way into how to implement authentication and logging.

Oo萌小芽oO 2024-08-23 08:49:06

您想要的大小是大小(而不是磁盘上的大小)。磁盘大小包括因适应分区的 4K 块大小而占用的额外空间。大小是文件中的确切位数。

我不认为有一个好的方法来判断下载是否已完成。 Response.TransmitFile 可能是安全发送文件的最佳方法。但我不相信它有任何信息可以告诉您用户是否确实收到了该文件。

我不知道它所支持的业务,但我想不出一个合法的业务,用户会容忍每次购买一次下载的模型,并且由于标准 HTTP 请求/响应模型的模糊性,不适合制作一个准确的客户端接收器。更不用说这个模型很容易通过在收到最后一个数据包时发送失败的响应而被黑客攻击。

我认为使用下载窗口(购买后 2 小时)之类的东西,然后在第一个请求后将其锁定到 IP 将实现相同的结果,并导致更少的用户问题和支持电话。此外,除非文件具有某种严格的 DRM,否则允许用户根据其登录进行持久访问很可能是合适的业务模型,因为一旦他们获得文件,他们就可以根据需要多次复制该文件。

看看 DVD 或蓝光光盘,再多的复制保护或访问控制也无法保护您的文件免遭盗版,因此请让合法用户的事情变得简单。

The size you want is the size (not the size on disk). Size on disk includes extra space that is taken up by fitting into the 4K block size of the partition. The size is the exact number of bits in the file.

I don't believe there is a good way to tell that a download has been completed. Response.TransmitFile is probably the best method for sending the file securely. But I don't believe it has anything that will tell you if the user actually recieved the file.

I don't know about the business this is supporting, but I can't think of a legitimate business where users would tolerate a single download per purchase model, and with the abiguity of the standard HTTP request/response model does not lend itself to making an accurate client side reciever. Not to mention this model could be eaisyly hacked by sending a failed response on reciept of the last packet.

I think using somthing like download windows (2hrs after purchase) and then lock it to an IP after the first request would accomplish the same result and result in alot less user issues and support calls. Also unless the file has some sort of stringent DRM, allowing the user persisten access based on their loggin is most likely the appropriate business model, because once they get the file they can copy it as many times as they like.

Look at DVD or Blu-Ray, no amount of copy protection or access controls will save your files from pirates, so make things easy for legitimate users.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文