Les forums sont fermés. Ils restent présent pour consultation et archivage.
Vous pouvez désormais poser vos questions directement dans les commentaires en bas de chaque page du site.
Alors n'hésitez pas à participer

recherche pistes pour pbm FTP

Bonjour à tous J'ai besoin de quelques pistes de recherche sur un probleme technique. Mon application envoie des fichiers par FTP à un serveur Windows (NT je crois) sur un site distant d'une autre société. C'est du FTP en mode passif, donc c'est le site distant qui nous attribue le port de données sur lequel les fichiers sont envoyés. Comme on envoie plusieurs centaines, voire milliers, de fichiers chaque jour, ça fait beaucoup de ports. De plus, je sais qu'il y a d'autres applis qui envoient le même genre de flux sur ce même serveur distant. En regardant les logs des transferts, je m'aperçois que lorsque les numéros de ports qui nous sont attribués sont proches les uns des autres ou même consécutifs (genre 1, 2, 3, etc), ces transferts sont très rapides, style 2 ou 3 fichiers par seconde. Dès que ce ports sont éloignés les uns des autres (genre 1, 15, 25 etc), les délais grimpent, chaque fichier prend alors facilement 3 secondes. Quand je dis "délai", c'est le temps constaté dans le log entre l'ordre PUT et le "226 transfer complete". Ce phénomène arrive à n'importe quel moment de la journée, je ne détecte pas de cycle ou de pattern. A quoi cela peut-il être dû ? Une raréfaction des ports dispos sur le site distant, couplé au temps de latence des ports qui empêche leur réutilisation ? Une autre idée ? Sur le trajet, il y a aussi un routeur qui NATte les adresses sur le site distant, mais si cela avait un impact, cela devrait être permanent, non ? Cette augmentation des délais est dûe à FTP lui-même, ou à son implémentation sur Windows ? Toute idée est bienvenue. Merci d'avance

Voilà la réponse (ça pourra servir à d'autres): En fait, ça n'avait rien à voir avec la dispo des ports de données sur le serveur distant. La ligne (Hongrie => Pologne) a été auscultée et il y avait un défaut de routage (ou qqch comme ça) sur le tronçon polonais, et donc ré-émission des paquets en erreur. Après correction par la gestionnaire de la ligne louée, le problème a disparu. La vitesse est maintenant de 4 fichiers par seconde, pour donner un ordre d'idée.