Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
[vb.net] Créer fichier temporaire lors envoi de fichier
Salut,
J'ai créer un programme permettant d'envoyer des fichiers par sockets mais je voudrais savoir si il était possible de créer des fichiers temporaires de telle sorte à pouvoir reprendre le transfert si on a annulé ou si il y a eu un problème.
Comment s'y prendre aussi ?
Merci
Salut.
Normalement si tu passes tes fichiers par sockets tu commences par le transformer en tableau de bytes ? Dans ce cas il te suffit de sotcker les nombres de bytes déjà envoyé.
Lors de la reprise il suffit de reprendre la ou on en ai.
Evidement de l'autre coté il faut enregistrer dans un fichier binaire ce qui a déjà été transféré
Exact, j'avais cette idée mais le problème est que si jamais l'utilisateur annule le transfert, comment etre sur que les 4096 octets (car j'envois par packet de 4096) ont bien été recu par le client ?
Car le truc de prendre la taille de chaque fichier temporaire pour récupérer l'index du stream c'est galère...
Methode d'envoi :
J'ouvre le fichier sur le serveur
j'envoi par packet de 4096 bytes au client
Creation d'un new fichier sur le client
Le client recoi les bytes et les ecrit directement dans le fichier
A la fin du transfert, il ferme le fichier
En algorithmique distribuée
quand A envoie des données à B
B doit acquiescer (ACK) en envoyant à A le nombre de bytes reçus
donc si ton tranfert est annulé
tu sais, par le dernier ACK de B
combien de bytes ont été effectivement reçus.
C'est une posibilité mais dans mon programme, je n'envoi pas la confirmation de reception des données car j'envoi les données en synchrome (socket.send) et donc la parti serveur attent que les données soient bien recues avant de continuer à envoyer. Donc je peux pas récupérer le nombre de bytes envoyés !
...
Ca fait bien longtemps que je n'ai pas codé en sockets, mais :
* la lecture de données sur une socket te renvoie le nombre de bytes lu au niveau du client.
* donc tu peux récupérer ce nombre pour savoir la quantité d'octets reçus, et les stocker chez ton client dans un fichier temporaire.
* Si ton téléchargement s'interromp, pas de pb.
* Si il reprend, alors ton serveur doit demander au client combien d'octets il a déjà reçu, et quand il a la réponse, il n'a plus qu'à relancer le téléchargement là où il en était.
=====================
Sinon, plus bas niveau, il me semble, à la lumière de mes vieux cours de réseau, que TCP-IP prévois déjà ce genre de confirmations en envoyant des ACK au serveur. Tu peux essayer de chercher à ce niveau là, je peux rien t'affirmer.
Si la recherche n'aboutie pas, à ta place, j'irai voir les sources d'eMule, qui lui gère très bien ce genre de problématiques. (ouais c'est pas du .Net, mais ton problème est un problème d'algo distribuée, pas de langage)
Ah mais oui... chui con moi...Envoyé par Aspic
Bah si le send attend que les données soient reçues, tu sais à tout moment combien d'octets il y a chez le client. La voilà la partie gérée par TCP/IP
Il est où le pb maintenant ?
oui c'est vrai lol c'est avec socket.beginsend que c'est pas gérér et il faut envoyer une confirmation...
Donc en gros, A = serveur et B = client
B prend un fichier sur A
B crée un fichier "temporaire" ou il va ecrire les bytes recu et A s'occupe de l'envoi. Du coté de B, je vais créer une variable qui va récupérer le nombre de byte transférés et l'écrire ds un fichier. B annule son transfert Donc j'envoi à A le nombre de byte deja recu puis A redemarre le transfert à NbreByteDejaRecu + 1 et réouvre l'autre ficheir "temporaire" ou il avais deja commencé à write les bytes !
Ca passera à ton avis ? c'est pas un peu lourd ?!
Pourquoi faire un fichier pour stocker le nb d'octets reçus ?
Tu l'as déjà ! C'est la taille de ton fichier temporaire
* on est d'acord que c'est au moment de redémarrer le transfert que B envoie le nb d'octets déjà reçus ?
* on est d'accord que le fichier temporaire il est chez B ?
(c'est pour être sûr, ta phrase est un peu ambigue)
Ca me semble être la meilleur façon de procéder (si tu évites le stockage inutile du nombre de bytes reçus)
Sinon ouais, t'as aussi l'autre façon qui consiste à stocker le nb de bytes envoyés chez A, mais ça me semble moins bien.
* Si le transfert ne reprend jamais, au bout d'un moment tu va te retrouver avec une tetrachiée de fichiers temporaires pour les transferts jamais finis. Faudra faire le ménage régulièrement, et si le process qui fait le ménage tombe, c'est la merde donc il te faut une appli pour monitorer ce process, et donc une personne pour aller vérifier régulièrement que le process tourne bien, et si le mec se fait virer faut former son successeur, etc...
* Si B reprend son transfert beaucoup plus tard et que ton fichier temporaire a été nettoyé sur A, bah t'es obligé de tout recommencer.
* Bref dans le temps c'est quand bien pas terrible.
Alors que si tu stockes seulement sur B, le client il sait qu'il a des transferts pas finis, il les reprend quand il veut, et s'il n'en eut plus, il flingue juste le fichier temporaire et basta. Pas de résidus qui trainent.
A mon humble avis, c'est comme ça que fonctionnent les (bons) logiciels de P2P.
lol oui tu as raison je test et je t'informe ! Bien vu c'ets un logiciel de P2P que j'ai crée lol
Sans blague ??????
ca aurais pu etre un simple logiciel de transfert de fichier pour un client et un seul serveur..
bon ca marche j'ai utiliser un fichier texte pour stocker quelques infos et c'est bon mais c'est assez lourd comme code (j'ai été obligé de créer une nouvelle soket car mon serveur est multiclient et donc si j'utilise la meme socket et que un client fait un transfert normal et l'autre client faite une reprise de transfert et bah ca va planter car les procédure de transfert ne sont pas les memes !)
++ Merci
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager