CLASS POUR TRANSFERER DES FICHIERS VIA WINSOCK AVEC CONTROLES PENDANT LE TRANSFERT

Information sur la source

Catégorie :Réseau & Internet Niveau : Débutant Date de création : 11/04/2005 Vu / téléchargé: 6 210 / 1 592

Auteur : celiphane

Ecrire un message privé

Ce membre participe au partage de revenus publicitaires

Note :

8,50 / 10

Commentaire sur cette source (33)

Ajouter un commentaire et/ou une note

Description

Salut à tous,

suite à mon tutorial sur Winsock, j'ai souvent eu l'impression que sur ce site, les "bonnes" sources mettant en scène les transferts de fichiers via Winsock sont synonymes du Saint-Gral !

Je n'ai pas la prétention de dire que cette class de transfert est le Saint-Gral, toutefois, c'est comme cela que j'envisage, pour ma faible personne, de transférer des fichiers en réseau via Winsock.

Dans l'archive fournie se trouve la dite class ainsi qu'un Form la mettant en jeu, afin de démontrer sommairement son utilisation.

Sachez toutefois :
- qu'elle transfert bien évidement n'importe quel fichier, de n'importe quel taille (j'ai honte d'utiliser cela comme argument tellement cela m'apparait normal, mais vu que c'est souvent annoncé sur les autres sources du même type, je ne veux pas effrayer ceux qui en ont l'habitude ;) )
- le transfert s'effectue par bloc, par tampon donc, dont la taille est paramétrable par argument (je propose tout de même une valeur par défaut, l'argument devenant donc optionnel)
- une vérification sommaire du bloc qui vient d'être transmis est effectué, si bien qu'il n'est écrit dans le fichier de destination par la partie "reception" que si la partie "envoi" l'affirme (sans quoi le bloc est réexpédié, puis soumis à un nouveau contrôle etc..)
- le transfert ne prend pas 100% des ressources machine comme certains nous en agrémente via leur boucle d'envoi / réception
- l'accusé de réception est la méthode utilisée pour faire poursuivre le transfert, et pas le bête doevents qui va toujours finir, via WAN, par engorger le canal de transfert et faire passer des données accolées alors qu'elles n'auraient jamais du l'être (bloc à bloc)

La class est la même pour la partie envoie comme pour la partie réception, voici ses méthodes :

- Recevoir(ByRef ControleWinsock As Winsock, ByVal Fichier As String) As Boolean
- Envoyer(ByRef ControleWinsock As Winsock, ByVal Fichier As String, Optional ByVal TailleTampon As Integer = 4096) As Boolean
- Function ActionEnCours() As TypeAction
- Sub AnnulerAction()

et ses évenements :

- Event EnvoiEnCours(ByVal TotalOctetsEnvoyes As Long)
- Event ReceptionEnCours(ByVal TotalOctetsRecus As Long)
- Event EnvoiTermine(ByVal TotalOctetsEnvoyes As Long)
- Event ReceptionTermine(ByVal TotalOctetsRecus As Long)

Conclusion

J'espère que cela vous servira, en appli comme en pédagogie.
Pour mieux comprendre la partie réseau, référez vous au tutorial Winsock (cliquez sur le lien pour afficher mes autres sources).
Pour mieux comprendre la partie fichier, référez vous au tutorial Fichier (cliquez sur le lien pour afficher mes autres sources).

N'ayant pas testé la class (je l'ai faite pour m'occuper et pour VOUS aider ;) ), je vous serais très reconnaissant de m'annoncer les problèmes que vous rencontrerez.

Bien entendu, si vos commentaires pouvaient également contenir autre chose que des problèmes rencontrés, je vous en serais également gré ;)

@+
Celiphane

Fichier Zip

Pour les "Membres Club", vous pouvez télécharger directement un fichier contenu dans le zip sans télécharger le zip en entier !

ClassTransfert.cls 4 962 octets
Fprinc.frm 9 696 octets
Fprinc.frx487 octets
prjClassTransfert.vbp 724 octets
prjClassTransfert.vbw 88 octets

Télécharger le zip

Sources du même auteur

Toutes les sources de celiphane

Sources de la même categorie

Toutes les sources de la catégorie Réseau & Internet

Commentaires

Commentaire de tbbuim1 le 11/04/2005 10:25:20

Pas mal, ton premier tuto, mais il manque cruellement d'exemple pour les débutants, même si c'est relativement bien expliqué. Celui là a un exemple, cool, mais dommage qu'il ne soit pas en deux parties, client/serveur, encore une fois, ça aurait été mieux pour les débutants. Mais sinon, c'est cool. C'est vrai qu'en regardant les autres sources, je me demandais pourquoi ils n'arrivaient pas à transférer de gros fichiers. lol
Commentaire de celiphane le 11/04/2005 13:14:12

Salut,

le tuto manque d'exemple ? Tu veux surement parler d'archive zip avec une illustration, parce que le tuto est justement entrecoupé d'exemples ;)
D'ailleurs, nombre sont ceux qui en le suivant à la lettre ont compris le winsock... ;) Débutants principalement :)

Cette source ne se veut pas être un exemple à lier avec mon tuto. C'est une class qui montre la bonne méthode pour transférer des fichiers sur des réseaux. Aussi, je ne comprends pas ce que les gens ont à vouloir absolument séparer les fonctionnalités client et serveur : déjà, ici, il n'y a PAS de client ni de serveur ! C'est une class pour transférer des fichiers, elle représente un tout, un protocole qui lui est propre pour d'une part envoyer et d'autre part recevoir. Bon passons. La question ne se pose donc même pas ici.
La vraie question est de savoir pourquoi les applications posées ici en exemple du winsock contiennent toujours 2 projets : le client et le serveur... mais c'est d'un inutile. Seules certaines applications nécessitent cette séparation, par exemple des logiciels de prise de main à distance, ou il n'est intéressant d'installer que la partie serveur chez le "client" (au sens clientèle), car il ne doit pas pouvoir utiliser le client (de l'application ;) ). Les autres séparations sont facilités (mauvaise structure de l'appli, complications fuies par le développeur).

Bon c'est mon avis, ma réaction à ton commentaire, qui quoi qu'il en soit, j'ai eu beaucoup de plaisir à lire. Je te remercie d'avoir testé et commenté ma source.
A bientôt sur nos futurs contributions ;)

@+
Celiphane
Commentaire de tbbuim1 le 11/04/2005 15:00:33

Oui, je parle EVIDEMMENT d'un zip dans le 1er tuto. Même s'il est vrai qu'ya plein de mini exemples...
Ensuite la séparation client/serveur est peut être inutile à tes yeux, en ce qui concerne les miens, je ne vois pas l'utilité de le garder sur une mm appli. qu'elle est l'intéret de se passer un fichier à soi même?! Ceux qui veulent faire des transferts de fichiers, sont, à mon humble avis, des gens qui se connecte à un ordi distant. D'où la constante séparation que tu vois d'habitude... C'est pour ça que je parlais de séparer celui qui envoi de celui qui reçoit... Maintenant, j'aimerais savoir dans quelle autre situation ta classe est utile, quelle est l'utilité de se passer un fichier à soi même, s'il est si inutile de faire une séparation? ça m'intéresse, puisqu'apparemment ça coule de source pour toi, donc éclaires-moi stp
D'autre part, tu parles du "bête DoEvents", pourtant tu en fais usage dans ton code... Il aurait été bien de justifier cette emploi par un commentaire, du coup, on ne voit pas trop pourquoi t'en a mis un, encore une fois c'est juste pour une meilleure compréhension. Ca n'enlève en rien la qualité du travail.
Commentaire de celiphane le 11/04/2005 15:18:57

olala, t'es un parleur toi ;)

je vais préciser ma pensé, et gentiment, parce que tu m'as tout l'air bien agressif non ?? :)

Tu penses trop au niveau utilisation de l'appli... en fait, je comprends pas vraiment comment tu raisonnes ? Tu développes ? A ce que je sache, quand tu fais par exemple une appli que tu vas distribuer, qui sert par exemple QUE à transférer des fichiers, c'est le freeware que les gens vont télécharger pour s'échanger des fichiers. Bon. Ba cette appli doit savoir envoyer ET recevoir des fichiers, par un protocole qu'elle reconnait... c'est ce que cette class fait. Elle t'aide en cela qu'elle est la solution clé en main pour transférer les fichiers. Tu comprends ?

<<qu'elle est l'intéret de se passer un fichier à soi même?!>>
...mais quel est le rapport ??  ;)
Elle sert pas à se passer un fichier à soi même ptdr.
C'est parceque l'exemple fait ça ? Tu comprends pas que c'est un exemple ?   :o)
Bon je suis coupable, j'aurais dû penser avant de poser la source à faire un vrai contexte pour que les débutants comme toi comprennent que ça sert pas à s'envoyer un fichier à soi-même ;)

En fait, tu prends le source comme une appli, alors que ça n'en ai pas une. Cette source, tbbuim1, c'est la class, que tu peux utiliser où tu veux. C'est un objet, le fichier class. Le projet fourni est un exemple pour montrer comment elle s'utilise. (faites des efforts tiens, vous serez récompensé ;-)   ).

C'est mon exemple d'utlisation de class... comment t'expliquer... imagine alors une appli dans laquelle en plus de dire quel fichier envoyer, on donne aussi l'adresse IP à laquelle se connecter... Tiens ba si tu veux, fait un inputbox sur le connect du winsock, et lance 2 fois l'appli, une sur un pc, une autre instance sur un autre... tu vois, ca transfert d'un pc à l'autre lol ;)

heu... je vois pas quoi dire d'autre à part que tu t'embrouilles surement un petit peu :)
Ya pas de mal ;)

Tu veux que je fasse un contexte réel et non pas simplement une démonstration de fonctionnalité, pour que tu vois mieux ? Demande moi, je suis tout disposé à t'aider !

@+
Celiphane

PS: pour le doevents, je l'utilise juste pour permettre au label qui affiche la progression en octets de se rafraichir et donc d'afficher leurs valeurs AVANT que les msgbox n'apparaissant (car elles sont modals). Ca N'A RIEN A VOIR  avec la class, RIEN A VOIR AVEC LE SYSTEME DE TRANSFERT, une fois de plus, c'est JUSTE DANS la feuille qui montre par l'exemple COMMENT utiliser la class... apparament tu n'as pas compris cette source... je pourrais t'expliquer tout ca en détail mais en PV si tu le souhaites ! J'aime bien aider les autres ! J'avoue que les prog de communication en réseaux, c'est un domaine que j'adore expliquer à ceux qui y débute :)
Message-moi !
Commentaire de celiphane le 11/04/2005 15:27:49

<<Maintenant, j'aimerais savoir dans quelle autre situation ta classe est utile, quelle est l'utilité de se passer un fichier à soi même>>

lol, je recite ça juste pour t'expliquer pourquoi je vais faire le nécessaire pour faire enlever les premiers commentaires que nous avons rédigé d'ici quelques jours (celui ci compris)...
Tu comprends, tu es à l'ouest là... la class n'envoie pas un fichier à soi-même, elle gère l'envoie et la réception de fichier, de n'importe qui à n'importe qui... tu as vraiment trop mal interprêté le code source, et les commentaires préjudiciable au contenu d'une source sont malvenus, surtout pour l'auteur de la source ! C'est pas cool :(

;)

T'en fais pas je t'en veux pas du tout, je suis même tout à fait disposé à te filer des coups de main lorsque tu auras des problèmes avec winsock... :-)

@+
Celiphane
Commentaire de celiphane le 11/04/2005 15:45:16

Pis y'a pas de client/serveur, y'a 2 applis qui communiquent via la couche tcp/ip, un point c'est tout.

Après le choix de séparer, c'est un choix de faire une appli qui ne fait qu'une certaine fonctionnalité, et une autre qui fait une autre fonction, le tout en complémentarité l'une de l'autre.

Ca n'a rien à voir avec cette class, rien à voir avec les applis réseau en elle même, mais je retombe la dessus par principe, histoire de te faire comprendre cela, avant que ces messages ne soient effacés, par pédagogie :)

Voilà :)

@+
Celiphane
Commentaire de tbbuim1 le 11/04/2005 16:06:25

hmmm *-) lol Oui j'étais un peu à l'ouest, mais pas agressif du tout. C'est juste que j'ai commencé winsock ya pas très longtemps et qu'en faisant une appli sur la mm machine tout marche à merveille et dès que je fais tourner la mm appli entre 2 machines distantes ça plante de partout! Donc, j'aurais nettement préféré une source avec 2 applis qui utilisent cette classe. Mais bon, jvais me la faire c pas grave.
Merci Celophane
Commentaire de Neo.balastik le 11/04/2005 16:09:06

Bravo ! Source claire et concise.
Commentaire de jack le 11/04/2005 19:14:58 administrateur CS

Salut
J'ai un peu regardé ta source sans faire d'essai.
Quelques remarques (contructives, rassure toi) :
- Quelques fautes d'orthographe à corriger (envoi, verbe transfèrer ...)
- Dans le Wck_DataArrival, tu écris dans ton fichier le contenu de Tampon. Or, cette donnée est connue depuis la derniere réception : Quand tu reçois les octets du fichier, tu te retrouves avec des données dans Tampon .... mais il n'y aura plus d'évènement Wck_DataArrival ... alors les dernières données, pas sûr qu'elles soient enregistrées -- à vérifier
- Quand on utilise l'ouverture de fichier "For Binary", la commandes "Put" est plus adaptée que "Print"
- A vérifier aussi : Tu imposes la longueur de la String de réception "Tampon". Lors de l'écriture de la dernière trame d'octets, est-ce que la fin de fichier est correcte ? Est-ce que le fichier reçu a exactement la même taille que le fichier émis ?
- Ta structure de classe est bonne, mais l'utilisation d'un objet WinSock indirectement est un peu audacieuse. Essaye de transformer ta classe en "Controle Utilisateur" (CU) : dedans, tu colles ton code, et dans la forme du CU, tu mets un Winsock qui appartiendra à ton instance (et pas au projet qui l'appelle)
Commentaire de celiphane le 11/04/2005 21:26:57

héhé, j'aime ce genre de commentaire...

salut jack !

Alors allons-y :

- désolé pour les fautes d'orthographe, c'est pourtant un point auquel j'attache une importance (pas capitale, mais correcte). Je vais quand même avoir le culot de te demander de préciser ce que tu m'annonces, car je ne vois pas de fautes dans "envoi" ni dans "transférer", puisque, pour ta gouverne, cela prend bien un accent aigu. De toute façon, je n'utilise pas d'accent dans le code pur. Maintenant si tu parlais du texte explicatif de la source ci-dessus (ou bien des commentaires), alors soit... peut-être... je ne relirais pas pour si peu. La source en elle même me semble juste. (dis moi sinon, je me ferai une joie de corriger ! merci d'avance)

- Ton histoire de données déjà dans le tampon, je vois que tu t'y connais plus en orthographe qu'en algorithmie ;)
Nan je plaisante, mais avant de dire, essaye donc la source, c'est fait pour et c'est parfaitement géré : cette alternative permet de n'inscrire les données dans le fichier QUE si le contrôle s'est avéré accepté par la partie "envoi", après réception, une sorte de :
A - je te fais parvenir ceci
B - je l'ai bien reçu, voici la preuve que j'en apporte
A - cette preuve est correct, inscrit et voici la suite tant qu'on y est
- ou -
A - cette preuve est fausse, n'inscrit rien, revoici le bloc
- puis ça reprend à -
B - je l'ai bien reçu, voici la preuve que j'en apporte
etc... etc...

- en ce qui concerne l'histoire du binary, là je vais me fâcher, parceque je trouve vraiment incorrect en fait toutes ces critiques sans test préalable : tu aurais dû voir que le "PRINT" sert avec la partie qui reçoit, et que celle ci ouvre le fichier en "OUTPUT". La partie qui envoit, elle, ouvre en "BINARY", et récupère avec "GET"... c'est navrant ce lot de commentaires désobligeant sans compréhension, décidément... mais vous en faites pas, je reste OK envers vous les gars ;)
Sur ce site, c'est le lot de tous de toute façon (toi même tu dois avoir ces cas sur tes propres sources ;) )

- Pour ta demande de savoir si le fichier transmis est bien de la bonne taille... tu me prends pour qui ? un débutant ? Tu penses aussi que j'aurais posté une source qui ne fonctionnerait pas ? Tu ne me connais pas ;)
Bien entendu que cela fonctionne ! hého ;)
Tout ce que tu vois comme étant de possibles erreurs sont en fait, désolé (c'est vrai, vraiment désolé) des choses que tu n'as pas compris, des subtilités qui dépassent ta manière d'observer cette source (du moins dans le survol que tu en as fait)... des fonctions que tu n'as pas correctement interprêtée (le check à la réception par exemple).

- Ma structure de class est bonne oui, et je ne créé que des class, pas de contrôle utilisateur. En revanche, libre à toi de le faire. Ha oui, tes tournures ne sont pas bien choisies : ce n'est pas "peu audacieux" (lol), c'est de l'objet, je ne fais qu'utiliser un pointeur, c'est tout à fait hors d'atteinte d'une qualification qu'on devine dans ton commentaire : de la bidouille ;)
Sache également que le fait de faire un winsock que l'on réclamme à l'utilisateur, tout cela est entièrement voulu : en effet, tu constateras que je ne gère pas la partie connexion dans la class. Ce n'est qu'une class de transfert de fichier, pas un "super-winsock". L'utilisateur (développeur) peut ainsi utiliser la class avec plus de souplesse et de flexibilité qu'un CU. Il utilise le winsock de son choix, le connecte comme il le souhaite, puis le dédie au transfert de fichier lorsqu'il en a envie, pour enfin récupérer son winsock lorsque les évènements lui annoncent la fin du transfert ou bien lorsqu'il le souhaite en appelant la méthode AnnulerAction... mais tester.... tester !!!! :o)
J'oriente tout mes travaux professionnels dans la souplesse et la flexibilité... J'essaye de faire des codes utilisables, et non pas à adapter.

En tout cas, merci pour toutes ces remarques, je reste à ta disposition pour des éclaircissements ou bien des conseils.

@+
Celiphane
Commentaire de celiphane le 12/04/2005 01:40:24

Resalut Jack !

(désolé, tu viens à peine de finir mon roman que je te remets un autre message lol, qu'est ce que je suis méchant... :o) )

Nan, c'est pas grand chose, c'est juste que je viens de relire ton commentaire et un passage m'avais échappé, tu dis :

<<A vérifier aussi : Tu imposes la longueur de la String de réception "Tampon". Lors de l'écriture de la dernière trame d'octets, est-ce que la fin de fichier est correcte ?>>

J'ai mal interprêté plus haut cette partie de ton commentaire et donc du coup, ma justification n'est pas complète, et je m'en excuse.

Donc, pour répondre parfaitement à cet injonction, sache qu'une (petite) fois de plus, tu as mal regardé !

J'impose bien entendu la taille de la trame pendant le transfert (faut bien envoyé quelque chose... cela dit en passant j'impose pas vraiment la valeur, c'est le développeur qui la passe en paramètre... enfin, là n'est pas le problème), mais à chaque "découpage" (on va appeler ça comme ça), tu aurais pu (dû ?) constater qu'un test s'assure du nombre restant d'octets à transférer.

Ainsi, lorsqu'arrive la trame de fin, plus petite que toutes les autres, le tampon est redimensionné à cet effet.

Tu peux constater que je n'ai pas fait de mise à jour de la source hein ! C'est bien des détails qui t'ont échappé ;-)

Bon allez, une fois de plus, je vais quand même m'assassiner : je commente vraiment pas grand chose... l'indentation parfaite ne fait pas... allez : je plaide coupable en partie !

Si en revanche tu as de vraies optimisations à me faire part, je suis preneur ! Dans l'espoir d'avoir ta contribution, merci quand même une fois de plus pour tes remarques qui m'ont permis d'expliquer au grand jour certaines parties non commentées de cette class.

@+
Celiphane, votre dévoué !
Commentaire de celiphane le 15/04/2005 10:04:40

Aucune note ?
Je suis un peu déçu, moi qui pensais depuis tellement longtemps posté ce type de source pour enfin sortir du brouillard tous ceux qui ne savent pas comment vraiment faire un transfert niquel propre...

Pour une fois que j'en prends le temps (bon ok, ça a pas été si long à faire, mais faut se les réserver les 2 heures, surtout quand c'est juste pour faire plaisir à une communauté ;) ), ben j'ai que des retours erronés sans approfondissement... ni note ! bouuuuuu snif ouinnn.

:o)

Bon allez, juste pour ce type de commentaire réclamatif (ça existe pas ce mot ?), y'en a qui vont me mettre des sales notes... j'aurais dû me taire ;-)

Bon prog à tous !
@+
Celiphane
Commentaire de leocat le 18/04/2005 14:28:17

super source! merci de t'interesser aux débutants et de prendre du temps a nous expliquer :) :)
Commentaire de clementpat le 21/05/2005 13:14:41

TRES clair , bien realisé , facile a comprendre , que vouloir de plus 10 10 a+++++
Commentaire de Rama853 le 25/06/2005 17:43:53

superbe source, exactement ce qu'il me fallait ;)
Félicitations !!
Commentaire de clementpat le 22/07/2005 00:16:28

Re ,une question je suis en adsl
j'envoie un film d'un pc a un autre (adsl aussi)
700 Mo environ , il me faut 8 H
d'apres vous ,pour augmenter la vitesse ne faudrait il pas utiliser plusieur Winsock en meme temps :
ex 4 winsock fonctionnant en meme temps
le 1er envoie 25% , le 2em 25% , le 3em 25% et le 4em le reste
ensuite je concatenise le tout .
d'apres vous , cela va augmenter la vitesse d'envoie et reception ?
Commentaire de celiphane le 22/07/2005 08:35:24

Très sincèrement, je ne pense pas.
En effet, étant en ADSL ton download est très rapide et tu crois donc ta connexion également très rapide, mais sache que ton upload lui, reste très faible. Et comme tu dis "j'envoie un film" cela signifie que tu es la seule source d'upload, donc le transfert sera lent et le restera quoi que tu fasses.

Lorsque tu envoies ton film, tout la bande passante upload de ta connexion est exploitée si rien d'autres ne l'utilise en même temps. Si tu mets 2 uploads à la tâche, ils occuperont chacun 50% de ta bande passante d'upload, 33% pour 3 uploads etc... bref le cumul ne dépassera jamais les 100% unique que représente la capacité de ton upload au général, et ça ira toujours à la même vitesse. La différence c'est que tu te seras compliqués la vie ;) !

Avec un client P2P, le transfert de fichier volumineux est plus rapide parcequ'il y a plusieurs sources à l'envoyer en même temps, donc on se retrouve par exemple avec un monsieur A qui donne 100% de son upload pour 50% du fichier et un monsieur B qui donne 100% de son upload pour les 50% restants du fichier. Comme le download de celui qui reçoit est assez conséquent pour supporter le débit total que représente l'upload de A et l'upload de B simultanément, on se retrouve dans ce cas précis avec un transfert à un régime de 200%, donc 2x plus rapide.
Les sources d'uploads se comptant par centaine sur le P2P, inutile de préciser que tu n'obtiendras jamais la même vitesse de transfert de client à client...

@+
Celiphane
Commentaire de clementpat le 22/07/2005 14:10:03

Merci a toi pour ta reponse ,j'ai testé cette nuit de la façon que j'avais evoqué , et en effet la bande passante est divisée par le nombre de connection .là je vais faire un truc pour pouvoir reprendre un chargement apres deconnection ; pour ne pas devoir laisser le pc allumé sans arret, merci a toi pour ton attention .
Commentaire de bastok le 05/09/2005 21:25:17

Bonjour,

Comme vous avez l'air tous porté sur les fautes d'orthographe, je prefere prevenir, il y en aura...

Bref, En ce moment je cherche pas mal à transferer un fichier par winsock, d'une maniere ou d'une autre, cependant, à chaque fois j'ai un probleme, la taille du fichier n'est pas la meme à l'arrivée. Du moins à distance, parceque en local, comme avec ton exemple, alors là c'est le top, tout les fichiers sont entiers, sans soucis, parfait. mais des qu'il sagit de l'envoyer à quelqu'un via le net, là c'est plus pareil. Donc je me suis penché sur ta classe, mais là pareil, en local ca marche, jusque là rien de nouveau, mais en l'adaptant à un programme à distance, là c pire je recois rien. J'ai vraiment besoin d'aide, sinon je vais craquer, je tourne en rond, et j'arrive pas à savoir si c'est Winsock qui me rend fou ou vb.

Si tu as un indice, communique le moi. Merci
Commentaire de celiphane le 05/09/2005 23:34:37

Salut,

la class marche de partout, et vers partout. Ton problème me semble être, comme pour beaucoup qui m'ont contacté en privé, un souci de configuration de routage... il y a quelque part un NAT qui ne fais pas son boulot... parcequ'il n'est pas configuré... voilà l'indice.

Bon courage

@+
Celiphane
Commentaire de clementpat le 06/09/2005 09:42:47

je me suis servi de ce programme , "a distance" en recption et envoie de plusieurs pc differents (windows ME XP)groupe d'explotation idem ou different , je n'ai a ce jour , rencontré aucun probléme.
Commentaire de Jouissance le 13/10/2005 10:30:48

très bon code, et surtout bravo. merci de te soucier des neuneu comme nous.
Commentaire de stomoxe1 le 30/10/2005 13:43:41

Salut a tous j'ai testé ce code avec succes, entre 2 PC sur un même reseau et ça marche nickel.

Pour ceux qui n'aurait pas compris les modifs a faire:
Voila comment Faire les 2 executables pour que ça marche:

Sur le PCN°1(ip=192.168.1.100) celui qui emet le fichier on modifie comme ceci:
  rem Winsock1.LocalPort = 10666
  rem Winsock1.Listen
  rem Winsock2.Connect "localhost", 10666
  Winsock2.Connect "192.168.1.102", 10666 : rem <----- c'est l'ip du PC qui recevra le fichier
  et on utilise que le bouton de droite (Command2) sans oublier de mettre enable=true pour pouvoir cliquer dessus

Sur le PCN°2(ip=192.168.1.102) celui qui recoie le fichier on modifie comme ceci:
  Winsock1.LocalPort = 10666
  Winsock1.Listen
  rem Winsock2.Connect "localhost", 10666
  rem Winsock2.Connect "192.168.1.101", 10666
et on utilise que le bouton gauche pour la reception.

donc maintenant on a nos 2 executables.
Sur le PC2 on lance l'exe
Sur le PC1 on lance l'exe et on voit que les 2 appli sont connectées.
Sur le PC2 on clique sur le bouton gauche...
Sur le PC1 on clique sur le bouton droit...

Et le fichier passe du PC1 au PC2...
N'oublier pas d'autoriser le port 10666 sur vos parfeu...

ça marche super. Felicitation pour cette source très clair
Commentaire de sjmf le 01/03/2006 01:33:17

Merci pour cette classe transfert.
Tu utilises, pour la gestion d'erreur,l'instruction "On Local Error GoTo ..". Je n'ai pas trouvé de documentation sur le mot réservé "Local" au sein de cette structure. Pourrais-tu m'en dire plus?
Encore merci pour ce superbe outil!
Commentaire de sharkus le 13/02/2007 18:21:58

Nickel cette source ;) C'est du bon travail, y'a plus qu'a bien comprendre le fonctionnement et à l'intégrer.
Merci beaucoup 10/10
Commentaire de sharkus le 13/02/2007 19:23:59

Bonsoir,
je viens de regarder un peut le fonctionnement, et dites moi si je me trompe, mais si je veux pouvoir envoyer et recevoir des fichiers sur les 2 PC pas uniquement recevoir de l'un et envoyer de l'autre, il faut bien que j'utilise 2 Winsock sur chaque appli (1 qui envoi et 1 qui reçoi) ?

Merci d'avance, je débute avec les winsock alors soyez indulgent ;)
Commentaire de sharkus le 14/02/2007 16:32:14

Bon en fait je raconte que des conneries, 1 seul winsock est nécessaire de chaque côté pour envoyer et recevoir des données ! Ta source est super bien faite. Petite question sur l'intégrité des données.
Pour contrôler que les données sont bien transmises, tu renvoi à l'expéditeur le 1er et dernier caractère de tampon mais avec ce moyen comment être certain que tous les caractères soit transmis ?
Ne faudrait-il pas envoyer la taille de ce que l'on envoi afin de vérifier lors de la réception que tout est bien là ?
ex : On veut envoyer la chaine suivante : "Coucou j'envoi un test"

wsk.SendData ".22#Coucou j'envoi un test"

lors de la réception on controle la taille:
Si longeur du texte reçu = 22 alors
   envoi confirmation
   ecrit dans le fichier
sinon
   envoi errtransfert
fin

Qu'en pense tu ?
Commentaire de rocker le 09/04/2007 03:17:41

Exelente source, tres utile. Beau travail !

PS: Merci de te soucier des gens qui veulent apprendre :)
Commentaire de miata le 07/08/2007 23:33:27

Aille, j'ai un gros probleme ...

J'utilise ta classe pour faire des envoi en local.
Du pc à lui même pas de probleme.

D'un autre pc (réseau local) à mon pc, sur une image de 105 Ko, j'ai 21 Ko perdu et uen fois j'en ai même eu 3 de trop !! :|

Comment cela ce fait-il ?
J'ai utilisé un Winsock dédié au transfert et mon label qui donne la taille envoyé donne bien 105 ko.
Commentaire de miata le 07/08/2007 23:55:41

En mettant un tampon de 8 ca passe ... mais c'est tres lent :D
Commentaire de miata le 08/08/2007 00:08:27

Oko, pour ceux qui auraiement des problèmes identique ...
j'ai essayé avec plusieurs taille de tampon, ...
4096 et 2048, perte de donnée, mais à partir de 1024, plus aucun probleme !

Merci encore <celiphane> pour tes sources !!
Commentaire de Renfield le 08/08/2007 06:15:00 administrateur CS

utilises la classe Winsock présente sur www.vbip.com, elle est bien plus efficace et sure que ce bon vieux controle Winsock.

voir aussi l'API TransmitFile qui s'appuie sur une connexion winsock dont on passe le handle
Commentaire de miata le 08/08/2007 14:51:59

Je ne sais pas accéder au site :| Erreur 404