asp.net文件下載 - 跟蹤下載大小

我想用ASP.net/C#設計一個這樣的系統。asp.net文件下載 - 跟蹤下載大小

用戶支付下載一些內容（文件 - mp3/PDF，doc等）。我應該能夠跟蹤用戶下載的字節數。如果下載的字節數與服務器上的字節數相匹配，我應該在數據庫中設置一個標誌（告訴下載成功並阻止他們再次下載該文件/要求他們再次爲下載付費）。如果下載不完整，他們應該能夠再次下載文件而無需再次付費（因爲標誌不會被設置）。

有什麼方法可以跟蹤客戶端成功下載的字節數？

另外，當我在我的WinXP機器中看到文件大小時，我看到兩個大小（磁盤大小，磁盤大小）。我應該考慮哪一個？它會不同於一個操作系統到另一個？

來源

2009-12-24 ram

我相信磁盤上的大小是你想要的。有關監控下載的好問題。也有興趣看到別人的答案。 – 2009-12-24 14:54:48

你可以告訴你發送了字節。 Http並沒有提供一種100％確定他們收到它們的方法。 – 2010-01-11 19:35:08

用戶何時支付內容？下載之前還是之後？因爲如果我支付一些文件，我希望能夠下載它時，我想... 約2大小。文件大小=文件長度（文件中的字節數）磁盤上的文件大小=文件佔用的簇數量*長度（簇）由於磁盤上的大小取決於文件系統和羣集，因此您只需要文件大小尺寸。 – Vitaly 2010-01-11 20:05:55

您可以創建一個服務於該文件的asp.net處理程序（對於asp.net mvc，您可以執行結果操作，而不是...這就是我正在使用的）。確保它支持可恢復的下載。

從您可以跟蹤服務的字節。

詩篇。這導致性能開銷與讓IIS服務它

更新1：我曾經很類似這樣http://dotnetslackers.com/articles/aspnet/Range-Specific-Requests-in-ASP-NET.aspx東西......和文章有它裏面有什麼是一個非常明確的解釋。您可以按原樣使用該文件，請參閱該文章中的示例。

來源

2010-01-11 19:53:54 eglasius

你能指點我一個例子嗎？ – ram 2010-01-11 20:18:53

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

您可以嘗試查看HTTP響應代碼（即：200,404等） - 客戶端和服務器將交換http頭，以便他們知道發生了什麼 - 您應該能夠監視這些以查看響應是成功的（不確定 - 但你應該能夠）。

關於文件大小 - 我會嘗試對已知大小的文件進行實驗，比較Http日誌告訴你文件資源管理器告訴你什麼。

此外，我還看到了報告文件上傳進度的工具/ wodgets - 所以你是對的，你應該能夠以相反的方式做到這一點，我想。您可以嘗試查看文件上傳代碼示例和教程 - 您可能會收到一些提示。我無法想到我的頭頂 - 對不起。

來源

2010-01-11 19:51:16

+1我也曾想過這樣的事情，但是對於我來說不太清楚的一點是如何在所有操作中以最小的開銷檢查那些人。就我而言，我使用了一個asp.net mvc actionresult，原因不同。 – eglasius 2010-01-11 19:58:00

客戶端瀏覽器獲取響應代碼。服務器發送響應代碼，響應代碼仍然可以是200，但客戶端在下載文件時可能會斷開連接，您會同意嗎？ – ram 2010-01-11 20:07:21

很明顯，查看上傳代碼的問題是，客戶端和服務器之間的相對責任是相反的 - 所以它可能沒有那麼有用，但是之後這些Iideas幫助我。 – 2010-01-11 20:10:39

你想要的大小是大小（不是磁盤上的大小）。磁盤上的大小包括通過適應分區的4K塊大小而佔用的額外空間。大小是文件中的確切位數。

我不認爲有一種很好的方法可以告訴下載已完成。 Response.TransmitFile可能是安全發送文件的最佳方法。但我不相信它會告訴你用戶是否真的接收到這個文件。

我不知道這是支持的業務，但我想不出一個合法的業務，用戶可以容忍每個購買模式的單一下載，並且標準HTTP請求/響應模型的含糊不清不適合做一個準確的客戶端接收器。更不用說這種模式可以通過發送最後一個數據包的收件人的失敗響應來進行黑客入侵。

我認爲使用諸如下載窗口之類的東西（購買後2小時），然後在第一次請求完成相同的結果並將導致用戶問題和支持調用較少之後將其鎖定到IP。此外，除非文件具有某種嚴格的DRM，否則允許用戶根據其登錄持久訪問很可能是合適的業務模式，因爲一旦他們獲得了文件，他們就可以多次複製它們。

看看DVD或藍光，沒有任何複製保護或訪問控制將保存您的文件從海盜，所以讓合法用戶容易。

來源

2010-01-11 19:57:59

你可以很容易地測量傳遞給客戶端在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那樣不可靠的東西上，將貨幣化的東西移動到變幻莫測的地步。

來源

2010-01-11 21:05:31 kprobst

+1自定義客戶端下載似乎是唯一可行的解決方案。 – 2010-01-11 21:59:18

將文件讀入內存中，如果您正在執行這些操作，將導致巨大的性能問題，並且不能很好地擴展。這樣做的結果是你會拋出OutMemoryException異常。你想要做的是使用Response.TransferFile（string fileName）或Respone.Transfer（string fileName，long offset，long lenght）方法。 – 2010-01-12 01:44:04

要做這樣的自定義字節服務，你需要實現你自己的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頭，客戶端和服務器端緩存，甚至壓縮。

另外還有一個日誌模塊和一個授權模塊，應該有很長的路要走如何實現身份驗證和日誌記錄。

來源

2010-02-22 10:27:09 Taliesin

asp.net文件下載 - 跟蹤下載大小

回答

相關問題