J'essaie de concevoir un système pour quelque chose comme celui-ci avec asp.net/c #.
Les utilisateurs paient pour le téléchargement du contenu (fichiers-mp3 / pdfs, doc, etc.). Je dois être en mesure de suivre le nombre d'octets téléchargés par l'utilisateur. Si le nombre d'octets téléchargés correspond au nombre d'octets sur le serveur, je devrais définir un drapeau dans dB (dire que le téléchargement a réussi et les empêche de télécharger le fichier à nouveau / leur demandant de payer pour le téléchargement). Si le téléchargement était incomplet, ils devraient être en mesure de télécharger le fichier à nouveau sans y remédier (puisque le drapeau ne sera pas défini).
Y a-t-il un moyen de garder une trace du nombre d'octets téléchargés avec succès par le client?
Aussi lorsque je vois une taille de fichier dans ma machine WinXP, je vois deux tailles (taille, taille sur disque). Lequel devrais-je envisager? Et va-t-il différer d'un système d'exploitation à un autre?
5 Réponses :
Vous pouvez essayer de rechercher des codes HTTP Reponse (c.-à-d.: 200, 404 etc.) - Le client et le serveur échangeront des en-têtes HTTP afin qu'ils sachent ce qui se passe - vous devriez être capable de les surveiller pour voir si les réponses étaient réussi (pas sûr - mais vous devriez être capable de).
En ce qui concerne la taille du fichier - J'essaierais des expériences sur des fichiers avec des tailles "connues", comparez ce que les journaux HTTP vous disent avec quel fichier explorateur vous dit.
En outre, j'ai vu des outils / wodgets qui signalent le fichier de téléchargement de fichier - vous devriez donc être en mesure d'être en mesure d'être en sens inverse, je suppose. Vous pouvez essayer de rechercher des exemples et des tutoriels de code de téléchargement de fichier - vous pourriez avoir des indications. Je ne peux pas penser à un sommet de ma tête - désolé.
+1 J'ai aussi pensé quelque chose comme ça, mais le peu qui n'est pas clair pour moi, c'est comment vouloir vérifier ceux avec des frais généraux minimes dans toutes les actions. Dans mon cas, j'ai utilisé un ASP.NET MVC ActionResult, pour différentes raisons.
Le navigateur client obtient les codes de réponse. Le serveur envoie les codes de réponse, le code de réponse peut toujours être de 200, mais le client peut se déconnecter lorsque vous téléchargez le fichier, seriez-vous d'accord?
Évidemment, la question avec la recherche de code de téléchargement est que les responsabilités relatives entre le client et le serveur sont inversées - il pourrait donc ne pas être aussi utile, mais à la suite de ce iideas m'a aidé dans le passé.
@RAM: Je serais d'accord. Vous pourriez Jhave la demande initiée par certains code JavaScript - pourriez-vous s'assurer que le téléchargement a réussi en agissant en tant que proxy au nom du processus de sural de sural? Les 2 gros problèmes avec ceux qui sont (1), ce n'est pas une solution simple / bisons, (2), vous devez alors «bloquer» les appels vers les fichiers d'autres sources.
Vous pouvez créer un gestionnaire ASP.NET qui sert le fichier (pour ASP.NET MVC u peut faire une action de résultat à la place ... C'est ce que j'utilise). Assurez-vous qu'il prend en charge des téléchargements résolables.
de la section Vous pouvez suivre les octets servis.
ps. Cela encourt une performance aérienille vs laisse IIS le servent
update 1: J'ai utilisé quelque chose de très semblable à ce http://dotnetslackers.com/articles/aspnet/range-specific-requests-in-asp-net.aspx ... et l'article a une explication assez claire sur ce qui est à l'intérieur. Vous pouvez probablement utiliser celui-ci tel quel, voir l'exemple dans ce poste.
La taille que vous voulez est la taille (pas la taille sur disque). La taille sur le disque comprend un espace supplémentaire qui est repris en ajustant la taille du bloc 4K de la partition. La taille est le nombre exact de bits dans le fichier.
Je ne crois pas qu'il y ait un bon moyen de dire qu'un téléchargement a été terminé. Réponse.TransMitFile est probablement la meilleure méthode d'envoi du fichier de manière sécurisée. Mais je ne crois pas que cela a quelque chose qui vous dira si l'utilisateur a réellement reçu le fichier.
Je ne sais pas sur l'entreprise, cela est à l'appui, mais je ne peux pas penser à une entreprise légitime où les utilisateurs toléreraient un téléchargement unique par modèle d'achat, et avec la lutte contre la mallette du modèle de demande HTTP / intervention standard ne se prêter à faire une convief exceptionnelle du client. Sans parler de ce modèle pourrait être piraté avec précaution en envoyant une réponse échouée sur la réception du dernier paquet.
Je pense qu'utiliser quelque chose comme Windows de téléchargement (2hrs après l'achat), puis verrouiller-le à une adresse IP après la première demande de la même demande et aboutirait à beaucoup moins de problèmes d'utilisateur et d'appels de support. Également à moins que le fichier ait une sorte de DRM strict, permettant à l'utilisateur de continuer à accéder en fonction de leur connexion est probablement le modèle d'entreprise approprié, car une fois qu'ils obtiennent le fichier, ils peuvent le copier autant de fois qu'ils le souhaitent.
Rechercher sur DVD ou Blu-ray, aucune quantité de protection de copie ou de contrôle d'accès ne sauvegardera vos fichiers de pirates, alors rendez-vous facilement des utilisateurs légitimes.
Vous pouvez facilement mesurer les données passées au client dans ASP.NET en supposant que vous remplacez un téléchargement directement contrôlé par IIS, qui irait quelque chose comme ceci: C'est compliqué à Faites ceci 100% fiable de l'ASP, mais cela peut être fait. Vous devez à peu près expliquer tous les points de défaillance possibles et réagir en conséquence. Le problème est toujours - comme une personne mentionnée ci-dessus - qu'il est impossible de savoir que le client a reçu le Les données. Si l'argent est impliqué dans cette transaction, cela peut être un problème vraiment rapidement. Pour cette raison, la meilleure approche serait d'utiliser un client de téléchargement personnalisé, comme celui d'Amazon utilise pour les achats de fichier MP3 . De cette façon, vous ne soumettez pas vous-même vous-même ou vos clients aux aléas de déplacer des morceaux monétisés sur quelque chose d'aussi peu fiable que http.
+1 Downloading côté client personnalisé semble être la seule solution viable.
Lecture du fichier en mémoire, si vous faites beaucoup de ces opérations, cela va causer un énorme problème de performance et ne sera pas bien à l'échelle. Le résultat de cela est que vous lancerez une exception exceptionnelle. Ce que vous voulez faire, c'est utiliser la réponse.Transferfile (nom de fichier à cordes) ou le nom de fichier REPONE.Transfer (nom de fichier de cordes, méthode de décalage long, longue longueur).
Pour faire des octets personnalisés servant comme ceci, vous devrez mettre en œuvre votre propre gestionnaire HTTP.
Ce gestionnaire doit faire ce qui suit:
Vous devez donc gérer les en-têtes HTTP suivants:
expire
accepte-gammes
si-plage
dernier modifié
Si vous recherchez un exemple de mise en œuvre de manutentionnaires HTTP, vérifiez: http://code.google.com/p/talifun-web/wiki
Il possède un gestionnaire de fichiers statiques qui implémente tous les en-têtes HTTP ci-dessus, la mise en cache latérale du client et le serveur et même la compression.
Il existe également un module de journal et un module d'autorisation qui devrait aller très loin dans la manière de mettre en œuvre l'authentification et la journalisation.
Je crois que la taille sur le disque est celle que vous voulez. Bonne question sur la surveillance des téléchargements. Intéressé à voir également les réponses des autres.
Vous pouvez dire que vous avez envoyé les octets. HTTP ne prévoit pas un moyen d'être sûr de 100% qu'ils les ont reçus.
Quand l'utilisateur paie-t-il pour le contenu? Est-ce avant le téléchargement ou après? Parce que si je paye pour certains fichiers, je veux pouvoir le télécharger quand je veux ... environ 2 tailles. Taille de fichier = Longueur de fichier (nombre d'octets dans le fichier) Taille du fichier sur disque = # de clusters que le fichier prend * longueur (cluster) Vous avez besoin d'une taille de fichier, car la taille sur disque dépend du système de fichiers et de la taille du cluster.
Existe-t-il une façon de changer la nature du problème? Je suppose qu'il n'y a aucun moyen d'arrêter quelqu'un de copier le fichier - donc pourquoi restreindre le fichier à un seul téléchargement? Une autre approche pourrait être de rendre le dossier à la disposition des utilisateurs spécifiques de manière unique (comme Ajout d'un GUID) et de faire le téléchargement disponible pour une période limitée? Quelles sont les chances de changer le problème? Pouvez-vous nous dire autre chose sur les contraintes sur la solution?
@Vitaly: Vous payez pour le contenu et une fois que vous avez payé, vous commencerez à télécharger le contenu.
@Adrian: Disons simplement que nous utilisons une sorte de verrouillage numérique en combinaison avec cet ID utilisateur pour utiliser ce fichier. Et oui, je le mettant déjà en place comme GUID. Et une fois téléchargé, si le téléchargement a été réussi et que l'utilisateur souhaite télécharger le contenu, il devra payer à nouveau lorsque le contenu est sensible au temps et sera mis à jour quotidiennement / chaque heure
Vous avez la table de téléchargement dans votre base de données. Lorsque l'utilisateur télécharge la première fois que vous insérez un enregistrement temporel de son IP, le FileID, la commande de la transaction d'achat, alors cet enregistrement est ce qui est vérifié pour ré-autoriser n'importe quel téléchargement ultérieur. Quelque chose comme Select Count () comme Anyrecord de Téléchargements où OrderID = @ OrderId et FileID = @ FileID Si AnyRecord == 0 allecAccessandinserTrecord () sinon checktimewindowAccess () ou quelque chose comme ça.