Ich versuche ein System für so etwas mit ASP.net/C # zu entwerfen.
Die Benutzer zahlen für das Herunterladen von Inhalten (Dateien - mp3s / PDFs, doc etc). Ich sollte in der Lage sein, die Anzahl der vom Benutzer heruntergeladenen Bytes zu verfolgen. Wenn die Anzahl der heruntergeladenen Bytes mit der Anzahl der Bytes auf dem Server übereinstimmt, sollte ich ein Flag in der DB setzen (um zu melden, dass der Download erfolgreich war und sie daran hindert, die Datei erneut herunterzuladen / zu bitten, den Download erneut zu bezahlen). Wenn der Download unvollständig war, sollten sie in der Lage sein, die Datei erneut herunterzuladen, ohne sie erneut zu bezahlen (da das Flag nicht gesetzt wird).
Gibt es eine Möglichkeit, die Anzahl der erfolgreich vom Client heruntergeladenen Bytes zu verfolgen?
Auch wenn ich auf meinem WinXP-Rechner eine Dateigröße sehe, sehe ich zwei Größen (Größe, Größe auf der Festplatte). Welchen sollte ich beachten? Und wird es sich von OS zu OS unterscheiden?
Sie können einen asp.net-Handler erstellen, der die Datei bedient (für asp.net mvc können Sie stattdessen eine Ergebnisaktion ausführen ... das ist es, was ich benutze). Stellen Sie sicher, dass es fortsetzbare Downloads unterstützt.
von dem Sie die Bytes gedient verfolgen können.
Ps. Dies verursacht einen Leistungs-Overhead im Gegensatz zu IIS, der es bereitstellt
update 1: Ich habe etwas verwendet, das diesem Ссылка ... und der Artikel hat eine ziemlich klare Erklärung, was drin ist. Sie können das wahrscheinlich verwenden, wie es ist, siehe das Beispiel in diesem Beitrag.
Sie können Daten, die an den Client in ASP.NET übergeben werden, leicht messen, vorausgesetzt, Sie ersetzen einen direkten IIS-gesteuerten Download durch Ihren eigenen, was etwa so aussehen würde:
%Vor%Es ist kompliziert, dies innerhalb von ASP zu 100% zuverlässig zu machen, aber es kann gemacht werden. Sie müssen ziemlich genau jeden möglichen Fehlerpunkt berücksichtigen und entsprechend reagieren.
Das Problem ist jedoch immer noch - wie oben erwähnt - dass es unmöglich ist zu wissen, dass der Client die Daten erhalten hat. Wenn Geld in diese Transaktion involviert ist, kann das schnell ein Problem werden.
Aus diesem Grund wäre es am besten, einen benutzerdefinierten Downloader-Client zu verwenden, wie ihn Amazon für den Kauf von MP3-Dateien verwendet. Auf diese Weise unterwerfen Sie sich selbst oder Ihre Kunden nicht den Launen, monetäre Bits über etwas zu bewegen, das so unzuverlässig ist wie HTTP.
Sie könnten versuchen, HTTP-Antwortcodes zu suchen (zB: 200, 404 usw.) - der Client und der Server werden HTTP-Header austauschen, damit sie wissen, was vor sich geht - Sie sollten diese überwachen können, um zu sehen, ob die Antworten waren erfolgreich (nicht sicher - aber Sie sollten in der Lage sein).
In Bezug auf die Dateigröße - Ich würde versuchen, Experimente mit Dateien mit "bekannten" Größen, vergleichen Sie, was die Http-Protokolle Ihnen sagen, was Datei-Explorer Ihnen sagt.
Ich habe auch Tools / Woddts gesehen, die den Datei-Upload-Fortschritt melden - also hast du recht, du solltest in der Lage sein, dasselbe in umgekehrter Richtung zu tun, denke ich. Sie könnten versuchen, Code-Beispiele und Tutorials zum Hochladen von Dateien zu betrachten - Sie könnten einige Hinweise bekommen. Ich kann mir nichts von meinem Kopf vorstellen - Entschuldigung.
Um ein benutzerdefiniertes Byte-Serving wie dieses zu tun, müssen Sie Ihren eigenen HTTP-Handler implementieren.
Dieser Handler sollte Folgendes tun:
Sie sollten also die folgenden http-Header behandeln:
läuft ab
Akzeptieren-Bereiche
Wenn-Bereich
Zuletzt geändert
Wenn Sie nach einer Beispielimplementierung von HTTP-Handlern suchen, gehen Sie folgendermaßen vor: Ссылка
Es hat einen statischen Datei-Handler, der alle oben genannten HTTP-Header, clientseitiges und serverseitiges Caching und sogar Komprimierung implementiert.
Es gibt auch ein Protokollmodul und ein Autorisierungsmodul, die einen langen Weg in die Implementierung von Authentifizierung und Protokollierung einschlagen sollten.
Die gewünschte Größe ist die Größe (nicht die Größe auf der Festplatte). Die Größe auf der Festplatte enthält zusätzlichen Speicherplatz, der durch Anpassung an die 4K-Blockgröße der Partition belegt wird. Die Größe ist die genaue Anzahl der Bits in der Datei.
Ich glaube nicht, dass es einen guten Weg gibt zu sagen, dass ein Download abgeschlossen wurde. Response.TransmitFile ist wahrscheinlich die beste Methode, um die Datei sicher zu senden. Aber ich glaube nicht, dass es etwas gibt, das Ihnen sagen wird, ob der Benutzer die Datei tatsächlich erhalten hat.
Ich weiß nichts über das Geschäft, das dies unterstützt, aber ich kann mir kein legitimes Geschäft vorstellen, bei dem Nutzer einen einzigen Download pro Kaufmodell tolerieren würden, und das mit dem Standard-HTTP-Anfrage / Antwort-Modell nicht bietet sich an, einen genauen Client-Seitenempfänger zu machen. Ganz zu schweigen davon, dass dieses Modell durch das Senden einer fehlgeschlagenen Antwort beim Empfang des letzten Pakets leicht gehackt werden könnte.
Ich denke, wenn ich etwas wie Download-Fenster verwende (2 Stunden nach dem Kauf) und es nach der ersten Anfrage auf eine IP-Adresse sperre, würde das dasselbe Ergebnis und viel weniger Benutzerprobleme und Support-Anrufe zur Folge haben. Auch wenn die Datei kein stringentes DRM enthält, ist es wahrscheinlich das entsprechende Geschäftsmodell, dass der Benutzer den Zugriff basierend auf seiner Anmeldung persistent hält, denn sobald er die Datei erhalten hat, kann er sie beliebig oft kopieren.
Betrachten Sie DVD oder Blu-Ray, keine Menge an Kopierschutz oder Zugriffskontrollen speichert Ihre Dateien vor Piraten, also machen Sie es legitimen Benutzern leicht.
Tags und Links asp.net http file httphandler httpmodule