Bonsoir Frédéric,
Frédéric a écrit :
> Bonjour,
>
> Est-ce que quel'qu'un pourrait m'expliquer le dialogue tcpdump joint (entre
> la machine 192.168.173.205 et le device 192.93.249.108) ?
Les 3 premiers échanges sont normaux, il s'agit d'une connexion TCP/IP
banale, avec échange de données et de ACK.
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.
> 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.
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.
> 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.
> 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.
> Merci de vos lumières.
De rien,
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
