1. Accueil
  2. Delphi / Pascal
  3. Sources Delphi / Pascal
  4. Sources Réseau & Internet
  5. Transfert de fichier (udp+tcp)

Transfert de fichier (udp+tcp)

Soyez le premier à donner votre avis sur cette source.

Vue 15 537 fois - Téléchargée 2 105 fois

Télécharger le projet
Commenter

Description

Le principe est de transfert des fichiers du client vers le serveur.
Pour lutter contre la lenteur du protocole TCP j'ai utiliser le protocole UDP pour envoyer le gros des information qui est contrôler par un peu de dialogue en TCP.
(Tester seulement sur Delphi 7.0)
Pour TCP j'ai utiliser ClientSocket et ServerSocket (plus installer sur delphi 7.0 a rajouter, on trouve pas mal d'info pour sa sur internet)
Pour UDP j'ai malheureusement utiliser un composants indy.... En effet après plusieurs essai de divers composant que j'ai pas réussi a faire marcher j'ai été obliger de me rabattre sur les composants indy.
Pour le contrôle des réception en UDP j'ai utiliser MD5 (voir dans UnitVerif.pas c'est l'adaptation d'une source de "f0xi", merci a lui): http://www.delphifr.com/codes/MD5-API-CELEBRE-ALGORITHME-HACHAGE-SOUS-DELPHI_40137.aspx

Je remercie aussi "AccessToYou" qui m'a fait découvrir les Packet Record bien pratique http://www.delphifr.com/codes/TRANSFERT-FICHIERS-SOCKETS_32793.aspx

Pour simplifier tout sa j'ai fais deux composants, un client et un serveur.
Par contre je me suis pas casser la tête à les enregistrer pour avoir un vrai composants que l'on peut poser sur la fiche.

On peut donc utiliser ses composant sans comprendre (Niveau Débutant). Mais bon comprendre c'est toujours mieux (Niveau Initié). Je suis d'ailleurs d'accord pour répondre a toutes les questions.

Source / Exemple : 


Serveur plus simple que celui du zip:
(si vous voulez pas vous embêté ce serveur laissera tout les fichier ce transférer dans le dossier ou se trouve l'exe sans tenir l'utilisateur informer de l'avancement.)

uses UnitServerTrsFl;

var ServerTrsFl1: TServerTrsFl;

procedure TForm1.FormCreate(Sender: TObject);
begin
  ServerTrsFl1:=TServerTrsFl.Create(Self);
  ServerTrsFl1.Open(45666,45666,ExtractFilePath(Application.ExeName));
end;

procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  ServerTrsFl1.Free;
end;

Conclusion :


Donc voila si on veut regler plus finement les transfert on peut modifier IRep de UnitD.pas (attention mettre le meme pour le fichier du client et du serveur)
On peut modifier le sleep dans Unitth.pas du client.

J'ai essayer de bien commentez ma source (j'y suis pas habituer) par contre je suis désolé mais je n'est fait aucun effort pour l'orthographe des commentaires alors bonne chance si vous les lisez.

Pour le futur: (évolutions possibles)
-> Calcul de la vitesse de téléchargement
-> Vérification a la fin du transfert par un hachage md5 du fichiers final que l'on compare a celle du client.
-> Amélioration de NumConnection (ne plus faire simplement une incrmentation pour qu'on ne puisse pas deviner le suivant (pr qu'on ne puisse pas injecter des bloc qui ne font pas partit du fichier), peut etre l'inclure ds bSecure en rajoutant 4 bytes au buffer avant le hachage + verifiaction de l'ip)
-> Envoi de fichiers dans l'autre sens, du serveur vers le client.

PS: j'attends vos commentaires
Télécharger le projet

Codes Sources

A voir également

Ajouter un commentaire Commentaires
cs_zibong
Messages postés
35
Date d'inscription
mardi 27 juillet 2004
Statut
Membre
Dernière intervention
21 juillet 2008
 1
21 juil. 2008 à 20:08
Il faut obligatoirement changer le sleep du thread dans unitTh.pas et le mettre a 44 (ms). sinon on fait déconnecter la connexion internet du client (bogue pas présent pour les transfert sur un réseau local). Ouai ta raison c'est pas une bonne idée l'UDP car j'arrive seulement a la vitesse de transfert d'msn (la honte...) mais bon rien de perdu sa me fait toujours une expérience de l'UDP dont je pourrait me servir avec utilité la prochaine fois.

En conclusion, pour l'instant j'ai toujours reçu les fichier en bon états donc je pense que le logiciel marche, mais bon il est pas optimiser. (la chance d'erreur est je pense qu'un buffer corrompu envoyer en UDP et le même hachage md5 que le bon buffer = chance d'erreur faible)

merci pour ton commentaire.
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
 38
21 juil. 2008 à 18:00
UDP doit etre utiliser pour les données non sensible.
par exemple les informations de deplacement d'un joueur sur une map de jeux, les interractions etc.
L'utilisation d'UDP inclus, vulgairement, que l'on autorise la perte de donnée. ce qui n'est pas "imaginable" dans le transfer de fichier.

TCP quand a lui possede un mecanisme qui verifie chaque paquet transmit et reçus. il se base sur CRC32 qui est amplement suffisant pour cela.
le hash md5 ne se fera qu'a la fin du fait de la lenteur du calcul du hash.
ensuite, pour assurer un bon transfer, il faut conserver l'offset de copie en cours du fichier. cela assure la possibilité de reprendre le telechargement la ou il s'est arrété.
cela inclus donc de lire le fichier dans l'ordre, par buffer de X octets (le dernier buffer sera forcement plus petit que les autres).
cs_zibong
Messages postés
35
Date d'inscription
mardi 27 juillet 2004
Statut
Membre
Dernière intervention
21 juillet 2008
 1
20 juil. 2008 à 21:45
>>>UDP : il y a peu de choses sur le sujet et cela a posé beaucoup de problème à plus d'un.
J'ai moi même eu du mal a trouver des infos ce que j'ai trouver:
c'est ce que j'ai fais ds ma source mais j'ai aussi trouver un truc en plus (avec indy): lorsque le client envoi quelque chose au serveur, le client peut recevoir une réponse avec "reponse:=idUdpCLient1.ReceiveString();" du côté serveur pour répondre: ds l'événement Read du server udp on a la variable ABinding et bien il suffit de repondre comme sa: "idUdpServer.Send(Abinding.PeerIP,Abinding.PeerPort,'ta reponse');"

>>>*Le fait de mélanger les composants TSocket et Indy. Tu aurais pu tres bien implanté le TCP avec ces derniers.
En fait je dois l'avouer, j'aime pas indy mais bon j'ai rien trouver d'autre. Plutôt que de faire TCP avec indy je préfèrerai faire UDP autrement.

>>>Les composants TSocket sont officiellement considérés comme mauvais par Borland
J'ai jamais eu de problème avec eux contrairement aux composants indy

>>>l'UDP n'est pas concu à la base pour transférer des fichiers
Avec mon programme je veut allier la vitesse de UDP avec la sureté de TCP. au lieu d'envoyer 1000 octet par TCP, j'envoie 1000 octet par UDP et 8 par TCP.

>>>Je conclurais en disant que la différence de vitesse de données entre UDP et TCP n'est pas aussi flagrante que cela.
Faudra que je fasse une comparaison notamment avec la source de foxi cité au debut.
Francky23012301
Messages postés
400
Date d'inscription
samedi 6 août 2005
Statut
Membre
Dernière intervention
11 février 2016
 1
20 juil. 2008 à 21:18
Salut,

N'ayant plus Indy je n'ai pas pu tester ton source : Mais j'ai regardé le contenu.

Alors déjà je te félicite car c'est bien codé (Indentation, nommage des composants, des variables ect ect) et c'est vachement lisible. Je te félicite pour le fait de proposer un source sur l'UDP : il y a peu de choses sur le sujet et cela a posé beaucoup de problème à plus d'un.

Je note pas ne pouvant pas tester mais ca mérite un bon 8/10.

Il y a deux choses qui me gène (désolé) :

*Le fait de mélanger les composants TSocket et Indy. Tu aurais pu tres bien implanté le TCP avec ces derniers.
Ca fait un peu fouillie de mélanger les 2 (Enfin ca n'engage que moi ;) ).

Dernière remarque sur le sujet : Les composants TSocket sont officiellement considérés comme mauvais par Borland : Mieux vaut pas les utiliser.

*Seconde chose qui me chagrine : l'UDP n'est pas concu à la base pour transférer des fichiers. Il en résulte que tu as été obligé d'utiliser TCP pour combler ces lacunes. Conséquence tu perds une bonne partie de la vitesse de transfert des données, qui est justement une spécificité de l'UDP, à cause des vérifications que tu es obligé de faire par la suite.

Je conclurais en disant que la différence de vitesse de données entre UDP et TCP n'est pas aussi flagrante que cela.
L'UDP ne devrait être utilisé uniquement dans des cas vraiment particulier à cause de ces faiblesses.

Alors apres le TCP,l'UDP et le TUDP à quand un ZibongDP ^^ ?
S'inscrire maintenant

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.

Du même auteur (cs_zibong)