On Saturday 15 September 2007 00:55, Olivier Allard-Jacquin wrote:
> Les 3 premiers échanges sont normaux, il s'agit d'une connexion TCP/IP
> banale, avec échange de données et de ACK.
Oui ; c'est la première commande envoyée (le device en question est un
contrôleur d'axes industriel de la société Galil), qui demande un
postionnement. C'est elle qui bloque la commande suivante.
> Juste une remarque quand même : 192.93.249.108 écoute sur son port
> TCP/5000. Or, ce port ( http://www.grc.com/port_5000.htm ) est réservé à
> ce que l'on appelle le Universal Plug and Play. Il ne faudrait pas
> qu'une autre machine du réseau qui envoie des paquets UPnP ne s'amuse
> les envoyer paquets sur 192.93.249.108, sinon ton programme risque de ne
> pas comprendre. Les machines qui font du UPnP sont généralement du
> Windows.
Ah, faudra qu'on voit ça. Peut-être est-ce fait exprès ?
> > Lorsque le device est occupé, il ne renvoie pas d'ACK sur la commande
> > suivante. Est-ce normal ?
>
> Tout dépend de ce que tu appelles "normal". Si je ne dis pas de bêtise,
> la pile IP de 192.93.249.108 ne renverra de ACK que lorsque le programme
> (qui tourne derrière le port 5000) aura lu le paquet de la 4ème ligne.
> Or, de ce que tu dis, le programme fait autre chose, et il ne répondra
> au paquet 4 que 2 secondes plus tard, environ.
>
> Je dirais que le programme en question est peut-être mono-thread, et
> donc qu'il a une boucle qui attend des données TCP (celles qui viennes
> de 192.168.173.205), puis qu'il fait un traitement. Le dit traitement
> est peut-être assez long, et donc il fait attendre la pile TCP pour la
> récupération du paquet suivant (le 4ème).
>
> Si le programme avait été multi-thread, il aurait put être conçu sous
> la forme de 2 threads: Un qui lit les données de la pile IP, au fur et à
> mesure. Puis il les stock dans un tableau, une pile, etc... Et l'autre
> thread ferait des traitement sur les paquets, au fur et à mesure que le
> tableau/pile se rempli.
Effectivement, pour le moment, on n'a utilisé qu'une seule tâche
utilisateur (on peut en avoir 8) pour notre programme embarqué ; mais on
pensait que la com TCP/IP tournait forcément dans son propre thread, ce
qui ne semble pas être le cas. Une solution sera donc de découper la com
et l'asservissement dans 2 tâches utilisateur...
> D'un autre coté, d'après les adresses IP qui sont complètement
> différentes, il est possible que 192.168.173.205 et 192.93.249.108 ne
> soient pas sur le même réseau, et qu'ils soient séparés par un
> routeur/passerelle (Linux ? ;)). Auquel cas, il est possible que ce
> composant actif soit défectueux, et que ce soit lui qui ne transmette
> pas un paquet. Pour le prouver, il faudrait faire une capture IP des 2
> cotés en même temps, et de comparer les résultats.
On va aussi vérifier ça, car il y a bien un routeur entre les deux. Mais je
doute qu'il soit défectueux (ça se saurait vite ; l'ILL est assez
performant à ce niveau).
> > Il ne répond qu'une fois qu'il a terminé la
> > commande (l'ordi a eu le temps d'envoyer 3 fois le paquet !).
>
> Je pense que 192.168.173.205 a dû estimer la vitesse de réponse de
> 192.93.249.108, très rapide en temps normal (voir paquets 1 et 2). Et
> donc que pour le 4ème paquet, il s'attend a avoir une réponse aussi
> vite. Ne la voyant pas apparaître assez rapidement, il "s'acharne" à
> renvoyer le paquet, car il suppose que le 4ème paquet (puis les paquets
> 5 et 6) se sont perdus en chemin.
Pigé.
> > Et ensuite, qu'est-ce donc que ces trames avec 'TCP Keep-Alive' ?
>
> http://cybertiggyr.com/gene/tka/
>
> C'est une option que le développeur choisit lorsqu'il écrit un
> programme utilisant une pile TCP. La pile (de l'OS donc), se charge
> d'envoyer à intervalle régulier un paquet "keep alive", afin de vérifier
> que la machine en face est toujours présente.
>
> Cela a un intérêt, c'est que le programme peut savoir très vite si la
> machine en face a disparu du réseau, au lieu d'attendre un timeout IP.
> Je verrais bien ce genre de chose dans des protocoles très sécurisé, qui
> sont supposé se déconnecter au moindre soupçon de connexion perdu
> (remplacement de la machine client "officiel", par une autre, illicite).
>
> Par contre, le problème c'est si la qualité du réseau est moyenne :
> Dans ce cas, le programme coupera intempestivement la connexion, même
> pour un simple retard de transmission.
Mais on dirait que lcarte carte moteur envoie systématiquement se paquets
avec cette option (les lignes 9 et 10 sont la réponse à la 2ème commande).
Ensuite, il envoie effectivement de nouveaux paquets avec 'TCP
Keep-Alive', mais très rapprochés (0.001 s, si je ne me gourre pas)... Ce
qui prouve que le routeur fonctionne bien, car la réponse de l'ordi a bien
été envoyée entre les 2.
--
Frédéric
http://www.gbiloba.org
