FTP Délai d'attente sur NLST lorsque le répertoire est vide

Question

EDIT: J'ai appris que Webmethods utilise en fait NLST, pas la liste, si cela importe

Notre entreprise utilise le serveur d'intégration WebMethods pour gérer la plupart de nos communications sortantes, et ses feuilles de fonctionnalité FTP quelque chose à désirer. Nous avons un problème qui peut être spécifique à WebMethods, mais si quelqu'un peut m'indiquer quel genre de choses pourrait causer cela, je l'apprécierais. Lors de l'interrogation de deux serveurs FTP de nos partenaires, nous nous connectons sans problème, mais lorsque nous effectuons un NLST sur un répertoire vide (pas de fichiers ni de sous-répertoires), il arrive à expiration. L'erreur réelle est:

com.wm.net.ftpCException: [ISC.0064.9010] java.net.SocketTimeoutException: Accept a expiré

Il est d'être jeté lors de l'invocation de la pub.client .ftp: ls service. Je me suis connecté avec un certain nombre de clients FTP sans problème sur les mêmes sites. J'ai utilisé le client FTP par défaut dans Windows, FileZilla et lftp. Tout sans problème. Les serveurs eux-mêmes ne sont pas le même logiciel de serveur FTP d'après ce que je peux dire. L'un est Microsoft FTP, l'autre sur lequel je suis incertain mais n'est certainement pas Microsoft.

Une idée de ce qui pourrait provoquer l'expiration d'un client FTP en attendant une réponse NLST sur un répertoire vide? Les réponses visibles du serveur FTP semblent être les mêmes, mais y a-t-il une différence dans la façon dont NLST répond pour un répertoire vide que je ne connais pas?

Ce problème est cohérent sur ces deux serveurs. Tout fonctionne correctement sur les répertoires avec des fichiers ou des sous-répertoires, mais pas quand ils sont vides.

Des idées ou des instructions seraient appréciées.

Merci!

Eric Sipple

Answer 1

J'ai essayé ceci dans WebMethods IS version 6.5 Mises à jour WmPRT_6-5-1_SP1, IS_6-5_SP3.

Cela a fonctionné parfaitement la première fois.

J'ai activé le débogage sur le serveur FTP (ftpd par défaut de Debian). NLST de WebMethods honore le paramètre actif/passif qui lui est passé.

La commande NLST n'a rien de spécial, ni son comportement correct avec un répertoire vide - si LIST fonctionne, alors RETR, STOR et NLST devraient l'être. Si NLST fonctionne avec un répertoire non vide, il devrait fonctionner avec un répertoire vide.

Donc, je suppose que ce soit:

• Votre version de WM a une mine de bug n'a pas
• Votre serveur FTP a une mine de bug ne
• Il y a un protocole courant loufoque pare-feu dans votre système qui n'aime pas les connecteurs de données FTP sans données.

fournisseurs de pare-feu sont un peu capricieuse en matière de FTP ... Lors des tests avec d'autres clients, assurez-vous qu'il est de la même machine sur laquelle WebMethods Integration Server est en cours d'exécution.

Pour le compte rendu, voici ce qui devrait se produire pour un client actif NLST

• ouvre un socket d'écoute et envoie une commande PORT avec que les détails de socket
• client envoie une commande NLST
• de Connects serveur à la prise d'écoute du client (c'est la prise de données)
• serveur transmet la liste sur la prise de données (dans ce cas, zéro octets)
• serveur ferme la prise de données

... et en mode passif

• client envoie une commande PASV
• serveur ouvre un socket d'écoute et répond avec une réponse PASV contenant ses informations client
• se connecte à l'écoute prise (ce est la prise de données)
• Le client envoie la commande NLST
• Le serveur transmet la liste sur le socket de données (zéro octet à nouveau)
serveur
• ferme prise de données

Answer 2

Je ne suis pas sûr que ce soit le même problème mais j'ai eu des symptômes similaires un certain temps à l'aide il y a un autre client FTP en Java (commons.net). Le problème a été provoqué par le mode actif/passif de la connexion. Je suis désolé, je ne peux pas vous donner plus de détails, c'est tout ce dont je me souviens ... espérons que cette aide.

Answer 3

Guillermo Vasconcelos avait raison dans sa réponse. Il y a deux modes FTP, actif et passif. Le mode par défaut FTP est actif. Active nécessite que le serveur se reconnecte au client sur un port TCP/IP. Cela ne fonctionne pas avec les pare-feu car il y a de fortes chances que ce port soit bloqué ou que vous soyez derrière un routeur avec NAT, non mappé. Si vous utilisez le mode Passif (PASV) à la place, vous ne devriez pas avoir le blocage.

Answer 4

Je vais faire de nouveaux tests avec les paramètres passifs demain quand la maintenance est faite ici, mais je ne suis pas sûr que ce soit le problème. Nous sommes en mesure d'obtenir une liste de répertoires s'il y a des fichiers ou des sous-répertoires dans ce répertoire. Il échoue uniquement lorsque le répertoire sur lequel nous sommes NLST est vide.

La différence active/passive ne se manifesterait-elle que pour un répertoire vide ou existe-t-il une autre possibilité?

Answer 5

FTP exige que le port spécifié et l'une au-dessus être ouverts à travers le pare-feu. Quand j'ai eu des problèmes avec webMethods, c'était parce que le pare-feu n'avait pas le port de retour ouvert.

Howard