Discussion :

[thibaud]

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.

[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 ?

[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.

[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 ?

[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....

[Mac LAK]

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.

[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??

[3DArchi]

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 Vu comme ça, ça devient plus évident

[Mac LAK]

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é.

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.

[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)

[Mac LAK]

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 ?

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.

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 ?

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.

[thibaud]

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

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

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 ?

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.

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

[Mac LAK]

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.

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.

[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...

[Mac LAK]

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 ?

[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ù?

[Mac LAK]

De mémoire, c'est réglé dans Platform Builder...

[thibaud]

arf je ne suis pas maitre de la partie création de l'os :p donc pas d'accès au platform builder.

[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.

[thibaud]

merci pour ta recherche tu auras ete plus efficace que moi lol je vais tester cette solution.