Le 23 mars 2010 16:45, Pascal Hambourg
<pascal.mail@plouf.fr.eu.org> a écrit :
Samuel Cifuentes-Favini a écrit :
>
> Voici le résultat de la capture sur la machine ubuntu pour laquelle le
> lancement de l'appli est quasi instantanné
>
> désolé, c'est un peu long....
Non, deux fois moins que le message en HTML précédent.
ok, ok..... ^^
> filtrage : ip.addr==192.168.80.150
J'avais demandé pas de filtrage.
[...]
> voici maintenant meme resultat sur la SID
> le lancement de l'appli est indiqué à la trame 65017.027...
> meme "serveur" (192.168.80.150)
> client en 192.168.84.102
> meme filtrage, apparition de l'appli à la trame commençant par 206,
La différence avec la trace prédédente, ce sont ces requêtes inverses
DNS et mDNS répétées émises par le serveur 192.168.80.150 entre
l'établissement de la connexion MySQL et l'envoi du message d'accueil
(greeting) par le serveur. On ne voit pas les éventuelles réponses à ces
requêtes DNS et mDNS, et on peut penser que leur absence est
probablement la cause du délai.
(Il y a aussi des paquets qui appartiennent à d'autres connexions MySQL
apparemment plus anciennes, et un broadcast NTP qui passait par là mais
n'a rien à voir a priori).
Un détail me chagrine : les captures ont été faites sur le client à
chaque fois, et non sur le serveur ?
exact, sur chacun des clients en effet
Mais dans ce cas, je ne m'explique
pas comment on voit les requêtes DNS envoyées par le serveur MySQL
192.168.80.150 à destination de 192.168.65.100 (qui doit correspondre à
un serveur DNS),
en effet, moi non plus. Le fait que le client (je dis bien le client et non le serveur) abrite un proxy squid pourrait-il expliquer ça ?
oui, 65.100 est un DNS
le client n'est pas censé les voir sauf si le client et
le serveur sont connectés en coaxial ou par un hub au lieu d'un switch.
ça, je ne me l'explique pas en effet . c'est bien un switch
Il serait intéressant de refaire les mêmes captures sur le serveur cette
fois, et sans filtrage, pour voir les requêtes et les réponses DNS et
mDNS. Si le serveur envoie des requêtes inverses pour l'adresse IP d'un
client mais pas pour l'autre, c'est peut-être qu'une adresse figure dans
le fichier /etc/hosts du serveur mais pas l'autre. Il devrait suffire de
l'ajouter.
bonne idée, je vais regarder le /etc/hosts
Archive: 4BA8E227.6060801@plouf.fr.eu.org" target="_blank">http://lists.debian.org/4BA8E227.6060801@plouf.fr.eu.org