2009-12-24 110 views
8

我想用ASP.net/C#设计一个这样的系统。asp.net文件下载 - 跟踪下载大小

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

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

另外,当我在我的WinXP机器中看到文件大小时,我看到两个大小(磁盘大小,磁盘大小)。我应该考虑哪一个?它会不同于一个操作系统到另一个?

+0

我相信磁盘上的大小是你想要的。有关监控下载的好问题。也有兴趣看到别人的答案。 – 2009-12-24 14:54:48

+1

你可以告诉你发送了字节。 Http并没有提供一种100%确定他们收到它们的方法。 – 2010-01-11 19:35:08

+0

用户何时支付内容?下载之前还是之后?因为如果我支付一些文件,我希望能够下载它时,我想... 约2大小。 文件大小=文件长度(文件中的字节数) 磁盘上的文件大小=文件占用的簇数量*长度(簇) 由于磁盘上的大小取决于文件系统和群集,因此您只需要文件大小尺寸。 – Vitaly 2010-01-11 20:05:55

回答

1

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

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

诗篇。这导致性能开销与让IIS服务它

更新1:我曾经很类似这样http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx东西......和文章有它里面有什么是一个非常明确的解释。您可以按原样使用该文件,请参阅该文章中的示例。

+0

你能指点我一个例子吗? – ram 2010-01-11 20:18:53

+0

@ram只是将其添加为更新。 – eglasius 2010-01-11 21:42:23

1

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

关于文件大小 - 我会尝试对已知大小的文件进行实验,比较Http日志告诉你文件资源管理器告诉你什么。

此外,我还看到了报告文件上传进度的工具/ wodgets - 所以你是对的,你应该能够以相反的方式做到这一点,我想。您可以尝试查看文件上传代码示例和教程 - 您可能会收到一些提示。我无法想到我的头顶 - 对不起。

+0

+1我也曾想过这样的事情,但是对于我来说不太清楚的一点是如何在所有操作中以最小的开销检查那些人。就我而言,我使用了一个asp.net mvc actionresult,原因不同。 – eglasius 2010-01-11 19:58:00

+0

客户端浏览器获取响应代码。服务器发送响应代码,响应代码仍然可以是200,但客户端在下载文件时可能会断开连接,您会同意吗? – ram 2010-01-11 20:07:21

+0

很明显,查看上传代码的问题是,客户端和服务器之间的相对责任是相反的 - 所以它可能没有那么有用,但是之后这些Iideas帮助我。 – 2010-01-11 20:10:39

0

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

我不认为有一种很好的方法可以告诉下载已完成。 Response.TransmitFile可能是安全发送文件的最佳方法。但我不相信它会告诉你用户是否真的接收到这个文件。

我不知道这是支持的业务,但我想不出一个合法的业务,用户可以容忍每个购买模式的单一下载,并且标准HTTP请求/响应模型的含糊不清不适合做一个准确的客户端接收器。更不用说这种模式可以通过发送最后一个数据包的收件人的失败响应来进行黑客入侵。

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

看看DVD或蓝光,没有任何复制保护或访问控制将保存您的文件从海盗,所以让合法用户容易。

7

你可以很容易地测量传递给客户端在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内部可靠%,但它可以完成。你几乎不得不考虑每一个可能的故障点并作出相应的反应。

虽然问题仍然存在 - 就像上面提到的那样 - 知道客户端收到数据是不可能的。如果这笔交易涉及金钱,那可能会很快成为问题。

因此,最好的方法是使用自定义下载器客户端,就像亚马逊用于MP3文件购买的客户端一样。这样你就不会让自己或你的客户置身于一种像HTTP那样不可靠的东西上,将货币化的东西移动到变幻莫测的地步。

+1

+1自定义客户端下载似乎是唯一可行的解​​决方案。 – 2010-01-11 21:59:18

+0

将文件读入内存中,如果您正在执行这些操作,将导致巨大的性能问题,并且不能很好地扩展。这样做的结果是你会抛出OutMemoryException异常。你想要做的是使用Response.TransferFile(string fileName)或Respone.Transfer(string fileName,long offset,long lenght)方法。 – 2010-01-12 01:44:04

1

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

此处理程序应做到以下几点:

  • 在HTTP处理程序执行某种认证的,所以你知道你在和谁打交道。
  • 然后,您将需要为请求的文件和允许下载的文件实施某种记录。
  • 为客户端缓存实施etags和expires标头。
  • 服务器端缓存
  • 放气,gzip压缩
  • 如果你想支持断点续传下载,您将需要实现206所部分缓解。这对于任何类型的流媒体和服务pdf都很重要。

所以,你应该办理下列HTTP标头:

  • ETag的
  • 过期

  • 接受范围,

  • 范围
  • 如果-范围

  • 的Last-Modified

  • 的if-match
  • 如果 - 无 - 匹配
  • 如果-Modified-Since的
  • 如果未修饰的,由于
  • 除非-Modified-Since的

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

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

另外还有一个日志模块和一个授权模块,应该有很长的路要走如何实现身份验证和日志记录。