Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
Dev_PC a exprimé avec précision :Salut Romain,
le mode 'passif' est désactivé comme signalé puisque toutes les
connexions en upload effectuées par les programmes de mes utilisateurs
le sont avec login et mot de passe.
D'où ma question dans la réponse précédente à 'phig', est-ce que je
dois malgré tout activer ce mode ?
Non, tu confonds mode ACTIF/PASSIF et utilisation de compte anonyme ou non.
Ta connexion est initiée en mode passif (vu que le serveur répond : 200
Switching to Binary mode. 200 PORT command successful. Consider using
PASV.).
Essaye d'utiliser le mode actif dans FTPConnecte (paramètre "type de
connexion")
A+
Dev_PC a exprimé avec précision :
Salut Romain,
le mode 'passif' est désactivé comme signalé puisque toutes les
connexions en upload effectuées par les programmes de mes utilisateurs
le sont avec login et mot de passe.
D'où ma question dans la réponse précédente à 'phig', est-ce que je
dois malgré tout activer ce mode ?
Non, tu confonds mode ACTIF/PASSIF et utilisation de compte anonyme ou non.
Ta connexion est initiée en mode passif (vu que le serveur répond : 200
Switching to Binary mode. 200 PORT command successful. Consider using
PASV.).
Essaye d'utiliser le mode actif dans FTPConnecte (paramètre "type de
connexion")
A+
Dev_PC a exprimé avec précision :Salut Romain,
le mode 'passif' est désactivé comme signalé puisque toutes les
connexions en upload effectuées par les programmes de mes utilisateurs
le sont avec login et mot de passe.
D'où ma question dans la réponse précédente à 'phig', est-ce que je
dois malgré tout activer ce mode ?
Non, tu confonds mode ACTIF/PASSIF et utilisation de compte anonyme ou non.
Ta connexion est initiée en mode passif (vu que le serveur répond : 200
Switching to Binary mode. 200 PORT command successful. Consider using
PASV.).
Essaye d'utiliser le mode actif dans FTPConnecte (paramètre "type de
connexion")
A+
Le 06/01/2011 16:22, Romain PETIT a écrit :Dev_PC a exprimé avec précision :Salut Romain,
le mode 'passif' est désactivé comme signalé puisque toutes les
connexions en upload effectuées par les programmes de mes utilisateurs
le sont avec login et mot de passe.
D'où ma question dans la réponse précédente à 'phig', est-ce que je
dois malgré tout activer ce mode ?
Non, tu confonds mode ACTIF/PASSIF et utilisation de compte anonyme ou
non.
Ta connexion est initiée en mode passif (vu que le serveur répond : 200
Switching to Binary mode. 200 PORT command successful. Consider using
PASV.).
Essaye d'utiliser le mode actif dans FTPConnecte (paramètre "type de
connexion")
A+
c'est ca. en fait, ftp utilise _toujours_ deux ports. le premier, 21, gère
la connexion et les messages. le deuxième est 20, mais
le deuxieme est initié en fonction du client ( si il est derrière un
routeur ou pas). le mode passif sur le serveur est utilisé dans le cas ou
les deux machines ne sont pas accessible directement ( tous les ports).
c'est pas très clair, mais j'ai mis logntemps à bien comprendre le
fonctionnement...
donc il y a 3 cas :
serveur pas routeur ------ client pas routeur // ca marche a tous les
coups ( commande sur 21, data sur 20 à l'initiative du serveur.
serveur pas routeur ------- client routeur // c'est le serveur qui recois
les connexions, pas besoin de PASV ca marche normalement a tout les coups
commandes sur 21 date sur 20 ouvert à l'initiative du client
serveur routeur ------- c'est le serveur qui recoit les connexions, PASV
coté serveur OBLIGATOIRE . nat du port 20 et 21 du routeur vers serveur
_ET_ une plage pour le mode PASV (idem du routeur vers serveur).
Le problème est donc clairement du coté de ton serveur.
dans ton cas la solution devrait être la suivante :
sur le serveur, forcer le mode passif _et_ spécifier l'adresse IP publique
, puisque c'est le serveur qui envoie les infos PASV
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)
donc UNE IP!
et forcer le mode passif de windev.
Le pb, c'est qu'il semblerait que le FTP de ton NAS est un peu "léger".
(lire
http://stx.lithium.com/t5/BlackArmor-NAS-Network-Storage/BlackArmor-NAS-110-Connects-via-FTP-No-Directory-Listings/m-p/45057
"BlackArmor software does not allow for the use of Passive mode for FTP
service. Passive mode is needed for running the server behind a NAT
router. So BlackArmor FTP service will not work behind a router in theory,
and will only work with direct connections in Active mode."
trois solutions:
- mettre un vrai serveur FTP sur un pc et sauvegarder sur le NAS (
filezilla serveur, par ex)
-utiliser un NAS avec un vrai serveur FTP ( buffalo, DLINK, NETGEAR
etc...)
-utiliser le mode DMZ de ton routeur ( si il a) et toutes les connexions
par défaut entrante pointent vers ton NAS ( bof!)
my 2 cents...
Le 06/01/2011 16:22, Romain PETIT a écrit :
Dev_PC a exprimé avec précision :
Salut Romain,
le mode 'passif' est désactivé comme signalé puisque toutes les
connexions en upload effectuées par les programmes de mes utilisateurs
le sont avec login et mot de passe.
D'où ma question dans la réponse précédente à 'phig', est-ce que je
dois malgré tout activer ce mode ?
Non, tu confonds mode ACTIF/PASSIF et utilisation de compte anonyme ou
non.
Ta connexion est initiée en mode passif (vu que le serveur répond : 200
Switching to Binary mode. 200 PORT command successful. Consider using
PASV.).
Essaye d'utiliser le mode actif dans FTPConnecte (paramètre "type de
connexion")
A+
c'est ca. en fait, ftp utilise _toujours_ deux ports. le premier, 21, gère
la connexion et les messages. le deuxième est 20, mais
le deuxieme est initié en fonction du client ( si il est derrière un
routeur ou pas). le mode passif sur le serveur est utilisé dans le cas ou
les deux machines ne sont pas accessible directement ( tous les ports).
c'est pas très clair, mais j'ai mis logntemps à bien comprendre le
fonctionnement...
donc il y a 3 cas :
serveur pas routeur ------ client pas routeur // ca marche a tous les
coups ( commande sur 21, data sur 20 à l'initiative du serveur.
serveur pas routeur ------- client routeur // c'est le serveur qui recois
les connexions, pas besoin de PASV ca marche normalement a tout les coups
commandes sur 21 date sur 20 ouvert à l'initiative du client
serveur routeur ------- c'est le serveur qui recoit les connexions, PASV
coté serveur OBLIGATOIRE . nat du port 20 et 21 du routeur vers serveur
_ET_ une plage pour le mode PASV (idem du routeur vers serveur).
Le problème est donc clairement du coté de ton serveur.
dans ton cas la solution devrait être la suivante :
sur le serveur, forcer le mode passif _et_ spécifier l'adresse IP publique
, puisque c'est le serveur qui envoie les infos PASV
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)
donc UNE IP!
et forcer le mode passif de windev.
Le pb, c'est qu'il semblerait que le FTP de ton NAS est un peu "léger".
(lire
http://stx.lithium.com/t5/BlackArmor-NAS-Network-Storage/BlackArmor-NAS-110-Connects-via-FTP-No-Directory-Listings/m-p/45057
"BlackArmor software does not allow for the use of Passive mode for FTP
service. Passive mode is needed for running the server behind a NAT
router. So BlackArmor FTP service will not work behind a router in theory,
and will only work with direct connections in Active mode."
trois solutions:
- mettre un vrai serveur FTP sur un pc et sauvegarder sur le NAS (
filezilla serveur, par ex)
-utiliser un NAS avec un vrai serveur FTP ( buffalo, DLINK, NETGEAR
etc...)
-utiliser le mode DMZ de ton routeur ( si il a) et toutes les connexions
par défaut entrante pointent vers ton NAS ( bof!)
my 2 cents...
Le 06/01/2011 16:22, Romain PETIT a écrit :Dev_PC a exprimé avec précision :Salut Romain,
le mode 'passif' est désactivé comme signalé puisque toutes les
connexions en upload effectuées par les programmes de mes utilisateurs
le sont avec login et mot de passe.
D'où ma question dans la réponse précédente à 'phig', est-ce que je
dois malgré tout activer ce mode ?
Non, tu confonds mode ACTIF/PASSIF et utilisation de compte anonyme ou
non.
Ta connexion est initiée en mode passif (vu que le serveur répond : 200
Switching to Binary mode. 200 PORT command successful. Consider using
PASV.).
Essaye d'utiliser le mode actif dans FTPConnecte (paramètre "type de
connexion")
A+
c'est ca. en fait, ftp utilise _toujours_ deux ports. le premier, 21, gère
la connexion et les messages. le deuxième est 20, mais
le deuxieme est initié en fonction du client ( si il est derrière un
routeur ou pas). le mode passif sur le serveur est utilisé dans le cas ou
les deux machines ne sont pas accessible directement ( tous les ports).
c'est pas très clair, mais j'ai mis logntemps à bien comprendre le
fonctionnement...
donc il y a 3 cas :
serveur pas routeur ------ client pas routeur // ca marche a tous les
coups ( commande sur 21, data sur 20 à l'initiative du serveur.
serveur pas routeur ------- client routeur // c'est le serveur qui recois
les connexions, pas besoin de PASV ca marche normalement a tout les coups
commandes sur 21 date sur 20 ouvert à l'initiative du client
serveur routeur ------- c'est le serveur qui recoit les connexions, PASV
coté serveur OBLIGATOIRE . nat du port 20 et 21 du routeur vers serveur
_ET_ une plage pour le mode PASV (idem du routeur vers serveur).
Le problème est donc clairement du coté de ton serveur.
dans ton cas la solution devrait être la suivante :
sur le serveur, forcer le mode passif _et_ spécifier l'adresse IP publique
, puisque c'est le serveur qui envoie les infos PASV
227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)
donc UNE IP!
et forcer le mode passif de windev.
Le pb, c'est qu'il semblerait que le FTP de ton NAS est un peu "léger".
(lire
http://stx.lithium.com/t5/BlackArmor-NAS-Network-Storage/BlackArmor-NAS-110-Connects-via-FTP-No-Directory-Listings/m-p/45057
"BlackArmor software does not allow for the use of Passive mode for FTP
service. Passive mode is needed for running the server behind a NAT
router. So BlackArmor FTP service will not work behind a router in theory,
and will only work with direct connections in Active mode."
trois solutions:
- mettre un vrai serveur FTP sur un pc et sauvegarder sur le NAS (
filezilla serveur, par ex)
-utiliser un NAS avec un vrai serveur FTP ( buffalo, DLINK, NETGEAR
etc...)
-utiliser le mode DMZ de ton routeur ( si il a) et toutes les connexions
par défaut entrante pointent vers ton NAS ( bof!)
my 2 cents...
Bonjour,
Il y a sûrement un fichier Log qui trace ce qui se passe sur le serveur
Ftp.
Pour Filezilla par exemple, c'est dans "ProgramFilesFilezilla
ServerLogsFilezilla Server.log"
Tu y trouveras peut être des réponses.
Bon courage,
Victor
"Dev_PC" a écrit dans le message de
news: 4d23632c$0$14257$Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
clients, des fichiers vers un serveur de stockage
en ligne. Les fichiers à transférer sont préalablement copiés dans un
répertoire tampon d'un disque de la machine client,
compressés, cryptés, et enfin, expédiés.
Avant de commencer le transfert proprement dit, je lance une routine
automatique en thread, qui génère une commande
"NOOP" toutes les 10 secondes, afin de veiller à ne jamais perdre le
dialogue avec le serveur.
Tout se déroule bien chez certains, mais chez d'autres, un message
d'erreur apparaît, à chaque tentative, mais pas
forcément au même moment chez le même utilisateur...
Cela peut parfois être après seulement quelques fichiers transférés, ou
bien alors après plusieurs centaines...
Je reproduis ci-dessous le message qui ne me dit rien, n'étant pas un
grand "forcené" du FTP.
Si ce message est plus explicite pour quelqu'un du forum, je le remercie
anticipativement de bien vouloir orienter ma
recherche de solution dans la bonne voie.
A noter aussi :
j'ai désactivé, sur une telle machine client, où je teste sur site par
TeamViewer, l'anti-virus et le pare-feu.
Cette machine de client est sous XP Pro SP3.
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
Impossible de créer le fichier
/utilisateur//repertoire/toto.doc.zip.acr ou de
l'ouvrir en
écriture.
La dernière réponse du serveur est : 200 Switching to Binary mode.
200 PORT command successful. Consider using PASV.
Code erreur : 100016
Niveau : erreur non fatale (EL_ONRETURN)
Code d'erreur système : 12002
Dump de l'erreur du module 'WD150COM.DLL' (15.00Gst).
Informations de débogage :
Fonction (10,1)
Informations supplémentaires :
<//
Ensuite viennent encore les références de la pile mentionnant la
procédure, le n° de ligne où survient le problème,
etc...
Merci d'avance de toute aide quelconque.
Amicalement,
Marc :-(
Bonjour,
Il y a sûrement un fichier Log qui trace ce qui se passe sur le serveur
Ftp.
Pour Filezilla par exemple, c'est dans "ProgramFilesFilezilla
ServerLogsFilezilla Server.log"
Tu y trouveras peut être des réponses.
Bon courage,
Victor
"Dev_PC" <Marc_Lekine_SansCeci@hotmail.com> a écrit dans le message de
news: 4d23632c$0$14257$ba620e4c@news.skynet.be...
Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
clients, des fichiers vers un serveur de stockage
en ligne. Les fichiers à transférer sont préalablement copiés dans un
répertoire tampon d'un disque de la machine client,
compressés, cryptés, et enfin, expédiés.
Avant de commencer le transfert proprement dit, je lance une routine
automatique en thread, qui génère une commande
"NOOP" toutes les 10 secondes, afin de veiller à ne jamais perdre le
dialogue avec le serveur.
Tout se déroule bien chez certains, mais chez d'autres, un message
d'erreur apparaît, à chaque tentative, mais pas
forcément au même moment chez le même utilisateur...
Cela peut parfois être après seulement quelques fichiers transférés, ou
bien alors après plusieurs centaines...
Je reproduis ci-dessous le message qui ne me dit rien, n'étant pas un
grand "forcené" du FTP.
Si ce message est plus explicite pour quelqu'un du forum, je le remercie
anticipativement de bien vouloir orienter ma
recherche de solution dans la bonne voie.
A noter aussi :
j'ai désactivé, sur une telle machine client, où je teste sur site par
TeamViewer, l'anti-virus et le pare-feu.
Cette machine de client est sous XP Pro SP3.
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
Impossible de créer le fichier
/utilisateur/son_nom@nummachine/repertoire/toto.doc.zip.acr ou de
l'ouvrir en
écriture.
La dernière réponse du serveur est : 200 Switching to Binary mode.
200 PORT command successful. Consider using PASV.
Code erreur : 100016
Niveau : erreur non fatale (EL_ONRETURN)
Code d'erreur système : 12002
Dump de l'erreur du module 'WD150COM.DLL' (15.00Gst).
Informations de débogage :
Fonction (10,1)
Informations supplémentaires :
<//
Ensuite viennent encore les références de la pile mentionnant la
procédure, le n° de ligne où survient le problème,
etc...
Merci d'avance de toute aide quelconque.
Amicalement,
Marc :-(
Bonjour,
Il y a sûrement un fichier Log qui trace ce qui se passe sur le serveur
Ftp.
Pour Filezilla par exemple, c'est dans "ProgramFilesFilezilla
ServerLogsFilezilla Server.log"
Tu y trouveras peut être des réponses.
Bon courage,
Victor
"Dev_PC" a écrit dans le message de
news: 4d23632c$0$14257$Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
clients, des fichiers vers un serveur de stockage
en ligne. Les fichiers à transférer sont préalablement copiés dans un
répertoire tampon d'un disque de la machine client,
compressés, cryptés, et enfin, expédiés.
Avant de commencer le transfert proprement dit, je lance une routine
automatique en thread, qui génère une commande
"NOOP" toutes les 10 secondes, afin de veiller à ne jamais perdre le
dialogue avec le serveur.
Tout se déroule bien chez certains, mais chez d'autres, un message
d'erreur apparaît, à chaque tentative, mais pas
forcément au même moment chez le même utilisateur...
Cela peut parfois être après seulement quelques fichiers transférés, ou
bien alors après plusieurs centaines...
Je reproduis ci-dessous le message qui ne me dit rien, n'étant pas un
grand "forcené" du FTP.
Si ce message est plus explicite pour quelqu'un du forum, je le remercie
anticipativement de bien vouloir orienter ma
recherche de solution dans la bonne voie.
A noter aussi :
j'ai désactivé, sur une telle machine client, où je teste sur site par
TeamViewer, l'anti-virus et le pare-feu.
Cette machine de client est sous XP Pro SP3.
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
Impossible de créer le fichier
/utilisateur//repertoire/toto.doc.zip.acr ou de
l'ouvrir en
écriture.
La dernière réponse du serveur est : 200 Switching to Binary mode.
200 PORT command successful. Consider using PASV.
Code erreur : 100016
Niveau : erreur non fatale (EL_ONRETURN)
Code d'erreur système : 12002
Dump de l'erreur du module 'WD150COM.DLL' (15.00Gst).
Informations de débogage :
Fonction (10,1)
Informations supplémentaires :
<//
Ensuite viennent encore les références de la pile mentionnant la
procédure, le n° de ligne où survient le problème,
etc...
Merci d'avance de toute aide quelconque.
Amicalement,
Marc :-(
Le 04/01/2011 19:13, Dev_PC a écrit :Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
...
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
....
Des fois... faut pas chercher à comprendre.
T'as une exception qui est générée ? tu la catch dans un "quand exception"
et tu refais un essai
Le 04/01/2011 19:13, Dev_PC a écrit :
Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
...
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
....
Des fois... faut pas chercher à comprendre.
T'as une exception qui est générée ? tu la catch dans un "quand exception"
et tu refais un essai
Le 04/01/2011 19:13, Dev_PC a écrit :Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
...
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
....
Des fois... faut pas chercher à comprendre.
T'as une exception qui est générée ? tu la catch dans un "quand exception"
et tu refais un essai
Salut Patrice,
je crois que cela correspond à ce que j'ai tenté, en renvoyant le
programme (par un GOTO) sur la ligne du source ayant généré l'erreur,
après l'affichage de cette dernière.
Comme signalé, cela m'amène un autre message d'erreur, qui mentionne
l'impossibilité de se placer dans un répertoire '.' ...
Merci quand même de ton idée.
Amicalement,
Marc ;-)
"patrice" a écrit dans le message de
groupe de discussion : 4d261e2d$0$18773$Le 04/01/2011 19:13, Dev_PC a écrit :Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
...
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
....
Des fois... faut pas chercher à comprendre.
T'as une exception qui est générée ? tu la catch dans un "quand
exception" et tu refais un essai
Salut Patrice,
je crois que cela correspond à ce que j'ai tenté, en renvoyant le
programme (par un GOTO) sur la ligne du source ayant généré l'erreur,
après l'affichage de cette dernière.
Comme signalé, cela m'amène un autre message d'erreur, qui mentionne
l'impossibilité de se placer dans un répertoire '.' ...
Merci quand même de ton idée.
Amicalement,
Marc ;-)
"patrice" <p.labracherie_nospam_@free.fr> a écrit dans le message de
groupe de discussion : 4d261e2d$0$18773$426a74cc@news.free.fr...
Le 04/01/2011 19:13, Dev_PC a écrit :
Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
...
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
....
Des fois... faut pas chercher à comprendre.
T'as une exception qui est générée ? tu la catch dans un "quand
exception" et tu refais un essai
Salut Patrice,
je crois que cela correspond à ce que j'ai tenté, en renvoyant le
programme (par un GOTO) sur la ligne du source ayant généré l'erreur,
après l'affichage de cette dernière.
Comme signalé, cela m'amène un autre message d'erreur, qui mentionne
l'impossibilité de se placer dans un répertoire '.' ...
Merci quand même de ton idée.
Amicalement,
Marc ;-)
"patrice" a écrit dans le message de
groupe de discussion : 4d261e2d$0$18773$Le 04/01/2011 19:13, Dev_PC a écrit :Salut et meilleurs voeux à toutes et tous,
J'utilise les commandes FTP pour uploader, depuis les machines de
...
Message d'erreur obtenu :
-------------------------
//>
Que s'est-il passé ?
....
Des fois... faut pas chercher à comprendre.
T'as une exception qui est générée ? tu la catch dans un "quand
exception" et tu refais un essai
Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
Le 24/01/2011 14:30, Dev_PC a écrit :Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
il me semblait t'avoir répondu à ce sujet....
le problème vient certainement de ton serveur FTP. tu est en passv
derrière un routeur, donc dès que le nat du port 20 est occupé par un
autre transfert, ca ne fonctionne plus. C'est pas plus compliqué que ca.
Solution: utiliser un _vrai_ serveur ftp qui gere le passv en natif ( cf
posts précédents:
news://news.skynet.be:119/4d26e1a4$0$13577$ )
Cordialement,
Le 24/01/2011 14:30, Dev_PC a écrit :
Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
il me semblait t'avoir répondu à ce sujet....
le problème vient certainement de ton serveur FTP. tu est en passv
derrière un routeur, donc dès que le nat du port 20 est occupé par un
autre transfert, ca ne fonctionne plus. C'est pas plus compliqué que ca.
Solution: utiliser un _vrai_ serveur ftp qui gere le passv en natif ( cf
posts précédents:
news://news.skynet.be:119/4d26e1a4$0$13577$426a74cc@news.skynet.be )
Cordialement,
Le 24/01/2011 14:30, Dev_PC a écrit :Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
il me semblait t'avoir répondu à ce sujet....
le problème vient certainement de ton serveur FTP. tu est en passv
derrière un routeur, donc dès que le nat du port 20 est occupé par un
autre transfert, ca ne fonctionne plus. C'est pas plus compliqué que ca.
Solution: utiliser un _vrai_ serveur ftp qui gere le passv en natif ( cf
posts précédents:
news://news.skynet.be:119/4d26e1a4$0$13577$ )
Cordialement,
Salut Phig,
Effectivement, tu m'avais bien décrit le phénomène, mais lorsque j'ai
essayé de changer le mode de travail du serveur, et d'établir les
connexions selon cet autre mode, cela ne marchait alors plus du tout...
(!) Je rappelle donc mon peu de compétences en FTP...
Et c'est pourquoi, ne parvenant pas à mettre en oeuvre le fonctionnement
de cette façon, je suis revenu au mode de transfert 'actif', qui
fonctionnait 'bien' hormis la déconnexion (évidemment!), et ai finalement
"contourné" le problème de la façon décrite aujourd'hui.
Merci toujours de ton aide précieuse.
Amicalement,
Marc ;-))
"phig" <"phig at free point fr"> a écrit dans le message de groupe de
discussion : 4d3d9a9c$0$1184$Le 24/01/2011 14:30, Dev_PC a écrit :Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
il me semblait t'avoir répondu à ce sujet....
le problème vient certainement de ton serveur FTP. tu est en passv
derrière un routeur, donc dès que le nat du port 20 est occupé par un
autre transfert, ca ne fonctionne plus. C'est pas plus compliqué que ca.
Solution: utiliser un _vrai_ serveur ftp qui gere le passv en natif ( cf
posts précédents:
news://news.skynet.be:119/4d26e1a4$0$13577$ )
Cordialement,
Salut Phig,
Effectivement, tu m'avais bien décrit le phénomène, mais lorsque j'ai
essayé de changer le mode de travail du serveur, et d'établir les
connexions selon cet autre mode, cela ne marchait alors plus du tout...
(!) Je rappelle donc mon peu de compétences en FTP...
Et c'est pourquoi, ne parvenant pas à mettre en oeuvre le fonctionnement
de cette façon, je suis revenu au mode de transfert 'actif', qui
fonctionnait 'bien' hormis la déconnexion (évidemment!), et ai finalement
"contourné" le problème de la façon décrite aujourd'hui.
Merci toujours de ton aide précieuse.
Amicalement,
Marc ;-))
"phig" <"phig at free point fr"> a écrit dans le message de groupe de
discussion : 4d3d9a9c$0$1184$426a74cc@news.free.fr...
Le 24/01/2011 14:30, Dev_PC a écrit :
Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
il me semblait t'avoir répondu à ce sujet....
le problème vient certainement de ton serveur FTP. tu est en passv
derrière un routeur, donc dès que le nat du port 20 est occupé par un
autre transfert, ca ne fonctionne plus. C'est pas plus compliqué que ca.
Solution: utiliser un _vrai_ serveur ftp qui gere le passv en natif ( cf
posts précédents:
news://news.skynet.be:119/4d26e1a4$0$13577$426a74cc@news.skynet.be )
Cordialement,
Salut Phig,
Effectivement, tu m'avais bien décrit le phénomène, mais lorsque j'ai
essayé de changer le mode de travail du serveur, et d'établir les
connexions selon cet autre mode, cela ne marchait alors plus du tout...
(!) Je rappelle donc mon peu de compétences en FTP...
Et c'est pourquoi, ne parvenant pas à mettre en oeuvre le fonctionnement
de cette façon, je suis revenu au mode de transfert 'actif', qui
fonctionnait 'bien' hormis la déconnexion (évidemment!), et ai finalement
"contourné" le problème de la façon décrite aujourd'hui.
Merci toujours de ton aide précieuse.
Amicalement,
Marc ;-))
"phig" <"phig at free point fr"> a écrit dans le message de groupe de
discussion : 4d3d9a9c$0$1184$Le 24/01/2011 14:30, Dev_PC a écrit :Salut chacune & chacun,
Voilà ce qu'il en résulte, au final :
- Plusieurs PC différents connaissent le même souci de déconnexion
évoqué ci-dessus
- Aucune liaison entre ces diverses configurations ne ressort : Windows
divers, pare-feux et anti-virus divers, FAI divers, etc...
- Une même machine connaît le souci de façon 'aléatoire' : parfois pas,
parfois oui, et si oui, sur n'importe quel fichier à transmettre, pas
forcément toujours le même...
Donc, puisqu'il paraît peu probable de résoudre le souci en traitant sa
cause, j'ai finalement opté pour traiter l'effet :
- lors d'une rupture du dialogue entre l'utilisateur et le serveur, la
connexion est complètement fermée, rétablie, et le fichier qui était 'en
cours d'essai' de transfert au moment de la rupture est repris pour
tenter de le renvoyer. La liste des fichiers restant encore à émettre
est ensuite continuée d'être parcourue, jusqu'à sa fin.
Le phénomène peut alors se reproduire, il réinstaure le même suivi que
lors du premier 'raté'.
Comme cela, évidemment, ça marche, mais je ne peux toujours pas
expliquer pourquoi une rupture de communication survient à un moment
quelconque... et ça, j'aime pas... ;-((
Merci à tous ceux qui ont participé à ce fil en me fournissant soit
leurs expériences, soit leurs idées.
Marc :-)
il me semblait t'avoir répondu à ce sujet....
le problème vient certainement de ton serveur FTP. tu est en passv
derrière un routeur, donc dès que le nat du port 20 est occupé par un
autre transfert, ca ne fonctionne plus. C'est pas plus compliqué que ca.
Solution: utiliser un _vrai_ serveur ftp qui gere le passv en natif ( cf
posts précédents:
news://news.skynet.be:119/4d26e1a4$0$13577$ )
Cordialement,