IcmpSendEcho et FTPutFile

Version imprimable

12/02/2010, 16h01
thibaud

IcmpSendEcho et FTPutFile

BOnjour,

Je cherche à uploader un fichier tout en vérifiant la disponibilité de mon serveur. Pour cela j'utilise deux threads, un premier envoyant de façon reguliere un IcmpSendEcho avec un timeout de 3secondes et un thread contenant l'envoi du fichier avec FTPPutFile. J'ai l'impression que mon IcmpSendEcho ne reçoit pas de réponse ou n'envoi pas sa requête tant que le FTPPutFile n'est pas terminé. Comment puis je faire pour m'assurer que les deux fonctionnent bien en parallèle?

Merci d'avance de vos réponses.

THibaud.
12/02/2010, 17h11
3DArchi

Salut,
Tu peux avoir un filtrage ICMP ou côté serveur ou côté client. As-tu déjà fait un test uniquement avec le send echo pour voir déjà si ça passe ?
12/02/2010, 17h24
thibaud

Le send echo fonctionne bien quant il est tout seul ou que la durée du transfert est inférieure au timeout.
J'ai tenté de faire la même chose mais en faisant le send echo sur une machine différente de celle sur laquelle j'ai le FTP et j'ai eu le même résultat.
J'imagine que c'est du côté de mon client que je ne récupère pas l'information, mais je ne m'y connais pas assez.

J'ai oublié de préciser que je suis sur "Windows CE 5" et que j'ai ce problème sur une connexion RTC et sur une connexion GPRS même si je ne pense pas que cela joue beaucoup.
12/02/2010, 18h01
3DArchi

Salut,
Tu peux sniffer le réseau pour voir si le reply arrive bien mais que ton client ne le traite pas ?
[EDIT] Après, je ne connais pas Windows CE, c'est peut être lié à l'OS ?
12/02/2010, 18h10
thibaud

comment je peux sniffer le réseau?

A priori c'est le fait que je sois en train d'uploader qui fait que je ne vois pas la réponse. Ce qui voudrait dire que je ne peux pas faire deux chose en parallèle lorsque je manipule une connexion FTP....
12/02/2010, 18h21
Mac LAK

Citation:

Envoyé par thibaud

J'ai oublié de préciser que je suis sur "Windows CE 5" et que j'ai ce problème sur une connexion RTC et sur une connexion GPRS même si je ne pense pas que cela joue beaucoup.

Tu n'as pas pensé que ta bande passante montante pouvait, tout simplement, être totalement saturée par le transfert FTP ?

Essaie de faire la même chose avec un FTPGetFile à la place, ou encore un simple FtpFindFirstFile / InternetFindNextFile (listing) en boucle... Si ton "ping" passe, cela renforce la possibilité d'une surcharge de la bande passante.
12/02/2010, 18h35
thibaud

La bande passante... je n'y avait pas penser! je vais faire le test sur un ftpgetFile.
SI c'est le cas, il y a moyen de limiter la bande passante utilisé par le FTP afin d'etre sur de pouvoir lire le retour de l'echo??
12/02/2010, 18h58
3DArchi

Citation:

Envoyé par Mac LAK

Tu n'as pas pensé que ta bande passante montante pouvait, tout simplement, être totalement saturée par le transfert FTP ?

L'ADSL nous fait perdre les bons réflexes :aie: Vu comme ça, ça devient plus évident :ccool:
12/02/2010, 19h03
Mac LAK

Citation:

Envoyé par thibaud

La bande passante... je n'y avait pas penser! je vais faire le test sur un ftpgetFile.

T'inquiètes pas, j'y ai pensé parce que j'ai déjà rencontré le problème une fois et que je m'étais arraché les cheveux pour comprendre... ;) Sur un PC normal avec une connexion Ethernet, c'est quelque chose qui arrive rarement, du moins au point de bloquer toutes les autres communications. C'est plus fréquent en embarqué.

Citation:

Envoyé par thibaud

SI c'est le cas, il y a moyen de limiter la bande passante utilisé par le FTP afin d'etre sur de pouvoir lire le retour de l'echo??

Pas certain, du moins, pas avec cette fonction, je pense... Peut-être en réglant les QoS de ton WinCE, si tu as la fonctionnalité, et encore...

Tu peux habituellement simuler ça avec une "vraie" socket, en ralentissant la vitesse à laquelle tu récupères / injecte les données de ladite socket : au bout d'un temps assez court, tu vas saturer le buffer associé à cette socket, et donc ralentir soit les émissions, soit empêcher les ACK TCP de partir (ce qui va faire arrêter / ralentir le serveur). Mais avec FTPPutFile, la seule action possible serait au niveau d'une callback InternetStatusCallback, et ça ne semble pas avoir une granularité assez fine pour "bloquer" le thread lorsque les données sont émises trop vite.

La seule autre piste que je vois, c'est de tenter de truander le lpszLocalFile en lui passant, par exemple, un pipe que tu alimenterais via un thread, qui lui limiterait la vitesse des données émises... Mais c'est pas gagné d'avance, je ne suis même pas certain que la fonction saura ouvrir correctement ce "fichier".

Dernière solution, implémenter le bout de protocole FTP requis toi-même (ou utiliser une librairie dont tu as les sources) de façon à pouvoir limiter l'upload. Dans un premier temps, essaie déjà avec le FTPGetFile (si ta connexion est full-duplex) et le listing "en boucle" (qui va laisser des "trous" dans la BP) de façon à isoler le problème à coup sûr.
12/02/2010, 19h17
thibaud

Merci pour toutes ces informations :) je dois avouer que la partie synchronisation est toujours un peu magique pour moi :)

Alors le test sur un FTPGetFile ne génère pas le même blocage, mon sendecho lit bien les réponses.(enfin le plus souvent, mais celà marche plus souvent que sur le putfile)
JE fais un sendecho toutes les 2 secondes avec un timeout de 5secondes et je télécharge des fichiers de plus de 700ko (je verrais bien la tête de mon patron lorsqu'il verra la facture data à la fin du mois)
J'utilise ma connexion FTP en mode passif.
Je n'ai ni le niveau pour faire le bout de protocole en FTP ni le temps pour m'y pencher :p. Il va falloir que je tente de comprendre les autres solutions que tu as évoqué avec le callback et l'histoire du Pipe pour ralentir....
Je confirme qu'avec l'adsl on oublie vite ces problématique, le même logiciel sur une connexion ethernet fonctionne nickel! (même OS, même machine)
13/02/2010, 18h43
Mac LAK

Citation:

Envoyé par thibaud

Merci pour toutes ces informations :) je dois avouer que la partie synchronisation est toujours un peu magique pour moi :)

De rien. De quelle synchro exactement parles-tu ?

Citation:

Envoyé par thibaud

Alors le test sur un FTPGetFile ne génère pas le même blocage, mon sendecho lit bien les réponses.(enfin le plus souvent, mais celà marche plus souvent que sur le putfile)

Bon, donc, c'est bel et bien un problème de saturation de bande passante. C'est déjà pas si mal, au moins, tu peux justifier le problème devant ton patron, et l'expliquer au vu de la BP très limitée d'une connexion GPRS.

Citation:

Envoyé par thibaud

JE fais un sendecho toutes les 2 secondes avec un timeout de 5secondes et je télécharge des fichiers de plus de 700ko

Je pense à quelque chose : pendant le put, la connexion est en mode TCP complet, donc elle gère les déconnexions.
En conséquence, peut-être peux-tu te passer complètement d'envoyer ce ping pendant le transfert, non ? S'il y a un souci, TCP prendra le relais et t'indiquera que la connexion a foiré : il te suffit de voir comment régler le timeout de la connexion, ni plus, ni moins. Une fois le transfert terminé, tu peux recommencer les ping.

Donc, si tu peux régler le timeout de ton transfert FTP, ton problème est résolu : tu surveilles la connexion avec un timeout de 5 secondes, et au final on se contrefiche un peu du "comment" tant que ça marche, non ? :mrgreen:

Citation:

Envoyé par thibaud

Je confirme qu'avec l'adsl on oublie vite ces problématique, le même logiciel sur une connexion ethernet fonctionne nickel! (même OS, même machine)

Bof : si tu veux rigoler un peu, la dernière fois, j'ai rencontré le problème sur une liaison Ethernet gigabit... C'est plutôt que l'ADSL se connecte à des serveurs "lents" (enfin, très chargés plutôt), donc le flux de données a beau être important, il est souvent en deçà de la BP disponible.

Essaie un jour de taper dans un serveur avec un très gros débit (pour ma part, j'ai pu provoquer le souci sur les serveurs de Microsoft et d'Intel), et lance un très gros téléchargement... Ensuite, essaie de surfer sur le net en même temps et d'avoir les pages en moins de 20 secondes ! ;) Toi, tu as un timeout de 5 secondes (le net, c'est souvent 30 secondes), donc c'est "normal" que ça foire.

Après, je reconnais que dans une communication point à point, on voit désormais rarement le souci. Par contre, ça arrive assez souvent quand tu bosses sur des éléments qui centralisent un grand nombre de transmissions, dans le genre serveur ou routeur.
15/02/2010, 16h05
thibaud

Citation:

Envoyé par Mac LAK

De rien. De quelle synchro exactement parles-tu ?

Désolé, dans mon logiciel la synchro c'est la partie ou je me connecte à mon serveur pour échanger des informations :)

Citation:

Envoyé par Mac LAK

Bon, donc, c'est bel et bien un problème de saturation de bande passante. C'est déjà pas si mal, au moins, tu peux justifier le problème devant ton patron, et l'expliquer au vu de la BP très limitée d'une connexion GPRS.

C''est en effet une bonne raison :)

Citation:

Envoyé par Mac LAK

Je pense à quelque chose : pendant le put, la connexion est en mode TCP complet, donc elle gère les déconnexions.
En conséquence, peut-être peux-tu te passer complètement d'envoyer ce ping pendant le transfert, non ? S'il y a un souci, TCP prendra le relais et t'indiquera que la connexion a foiré : il te suffit de voir comment régler le timeout de la connexion, ni plus, ni moins. Une fois le transfert terminé, tu peux recommencer les ping.

Donc, si tu peux régler le timeout de ton transfert FTP, ton problème est résolu : tu surveilles la connexion avec un timeout de 5 secondes, et au final on se contrefiche un peu du "comment" tant que ça marche, non ? :mrgreen:

J'y avais penser, auquel cas je pourrais régler le timeout sur la même durée que le Ping (moins de 5 secondes) car du coup si j'ai pas de donner sur le FTP c'est qu'il y a de fortes chances pour que mon ping ne passe pas non plus. POur le timeout de la connexion c'est un paramètre dans les methodes FTP de windows ce.

Citation:

Envoyé par Mac LAK

Bof : si tu veux rigoler un peu, la dernière fois, j'ai rencontré le problème sur une liaison Ethernet gigabit... C'est plutôt que l'ADSL se connecte à des serveurs "lents" (enfin, très chargés plutôt), donc le flux de données a beau être important, il est souvent en deçà de la BP disponible.

Essaie un jour de taper dans un serveur avec un très gros débit (pour ma part, j'ai pu provoquer le souci sur les serveurs de Microsoft et d'Intel), et lance un très gros téléchargement... Ensuite, essaie de surfer sur le net en même temps et d'avoir les pages en moins de 20 secondes ! ;) Toi, tu as un timeout de 5 secondes (le net, c'est souvent 30 secondes), donc c'est "normal" que ça foire.

C'est un bon test à faire pour une illustration

Je vais faire mes tests avec le ping stoppé pour la partie FTP et l etimeout de 5 secondes sur ce dernier.

Merci pour les informations en tout cas :)
15/02/2010, 16h10
Mac LAK

Citation:

Envoyé par thibaud

POur le timeout de la connexion c'est un paramètre dans les methodes FTP de windows ce.

Si c'est bien toi qui a la maîtrise de ce bout de code, alors tu as effectivement la solution.

Citation:

Envoyé par thibaud

Je vais faire mes tests avec le ping stoppé pour la partie FTP et l etimeout de 5 secondes sur ce dernier.

OK, tiens-nous au courant. N'oublie pas de bien tester si, pendant le transfert FTP, la déconnexion se "voit" bien en 5 secondes maximum : c'est crucial quand même, car si ta connexion TCP ne fonctionne pas correctement, la solution tombe à l'eau.
16/02/2010, 16h02
thibaud

Mauvaise nouvelle : le paramètre de timeout n'est pas pris en compte il s'agit d'un bug connu dans la DLL fourni par microsoft...
16/02/2010, 16h06
Mac LAK

Citation:

Envoyé par thibaud

Mauvaise nouvelle : le paramètre de timeout n'est pas pris en compte il s'agit d'un bug connu dans la DLL fourni par microsoft...

Yahou.... Je suppose, bien sûr, que tu n'as pas la possibilité d'avoir un correctif sur le sujet ?

Sinon : quel est le timeout utilisé par TCP lors du transfert FTP ? Peux-tu l'influencer en modifiant les timeouts généraux de ta plate-forme ?
16/02/2010, 16h14
thibaud

si il y a un correctif je ne l'ai pas trouvé :(

Les timeouts généraux de ma plateforme... je trouve ça où?
16/02/2010, 16h36
Mac LAK

De mémoire, c'est réglé dans Platform Builder...
16/02/2010, 16h46
thibaud

arf je ne suis pas maitre de la partie création de l'os :p donc pas d'accès au platform builder.
17/02/2010, 11h41
Mac LAK

Pas dans la m...., tiens...

Bon : vu que je trouve quand même étrange que, dans le royaume des callbacks et évènements qu'est Windows, il soit impossible de surveiller / contrôler un minimum un transfert FTP, j'ai fouillé consciencieusement MSDN pour trouver le "pourquoi du comment"... Et j'ai trouvé : FtpPutFile n'est qu'un raccourci "pratique", mais ce n'est pas la fonction primaire !! Et c'est pareil sur Windows desktop et embedded.

Donc : remplacer ton FtpPutFile par FtpOpenFile, puis une boucle sur InternetWriteFile de façon à avoir un peu de contrôle sur l'écriture... Cela pourra t'éviter d'avoir à tester la bidouille du pipe.

Normalement, comme tu devrais avoir des commutations de contexte entre ton thread ICMP et ton thread FTP (surtout si tu rends le ICMP plus prioritaire que le FTP), tu devrais pouvoir insérer des pings pendant le transfert... Et donc, résoudre ton problème.
17/02/2010, 13h01
thibaud

merci pour ta recherche tu auras ete plus efficace que moi lol je vais tester cette solution.
17/02/2010, 20h37
Mac LAK

De rien... Mais je suis presque certain que la phrase citée ci-dessous n'existait pas il y a peu de temps :

Citation:

Envoyé par MSDN

An application that needs to send file data only, or that requires close control over the file transfer, should use the FtpOpenFile and InternetWriteFile functions.

J'avais regardé il y a un mois ou deux, et j'aurais vu une telle mention (j'avais le problème de pouvoir interrompre un transfert FTP) : cela a dû être rajouté, ou alors j'avais pioché sur une page d'aide différente (offline peut-être ?) qui ne le mentionnait pas.