[gull] Les requêtes DNS

[Marc SCHAEFER]

On Sun, Sep 12, 2004 at 02:18:14PM +0200, Arnaud Burlet wrote:
> Dans ce cas, une table de question est nécessaire uniquement si les requêtes 
> se font par UDP (ce qui est le cas si je me souviens bien de ce fil de 
> discussion) ?

Ca dépend. Le client (BIND) peut aussi gérer plusieurs questions via TCP
en parallèle sur un ou plusieurs serveurs BIND.  Il peut le faire soit
via des threads (nouveau), ou classiquement via select() et une table
de questions, ou une combinaison des deux.  jJ n'ai pas regardé la
source.

> La page socket(7) n'est pas compétement claire par rapport à ce cas, mais j'ai 
> essayer de faire 2 socket() TCP puis sur chacune des bind() sur un meme tuple 
> (port local, adresse locale), le bind() fonctionne pour les 2 socket. C'est 
> le second connect() qui échoue...

Si je fais:

   xterm1% netcat -p 5555 -l
   xterm2% netcat -p 1024 localhost 5555
   xterm3% netstat -n | grep 5555
   tcp        0      0 127.0.0.1:5555          127.0.0.1:1024 ESTABLISHED 
   tcp        0      0 127.0.0.1:1024          127.0.0.1:5555 ESTABLISHED
   xterm3% netcat -p 1024 192.168.1.1 22
   <blabla>
   xterm4% netstat -an | grep 1024
   tcp        0      0 192.168.1.168:1024      192.168.1.1:22 ESTABLISHED 
   tcp        0      0 127.0.0.1:5555          127.0.0.1:1024 ESTABLISHED 
   tcp        0      0 127.0.0.1:1024          127.0.0.1:5555 ESTABLISHED 

et maintenant:
   xterm4% netcat -p 1024 192.168.1.1 25
   xterm5% netstat -an | grep 1024
   tcp        0      0 192.168.1.168:1024      192.168.1.1:22 ESTABLISHED 
   tcp        0      0 127.0.0.1:5555          127.0.0.1:1024 ESTABLISHED 
   tcp        0      0 127.0.0.1:1024          127.0.0.1:5555 ESTABLISHED 
   tcp        0      0 192.168.1.168:1024      192.168.1.1:25 ESTABLISHED 

et enfin:
   xterm5% netcat -p 1024 192.168.1.1 25

j'obtiens:

   connect(3, {sin_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("192.168.1.1")}}, 16) = -1 EADDRNOTAVAIL (Cannot assign requested address)

Donc, effectivement, j'ai eu tort. Un client peut bind(2)er sur le même
numéro de socket, voire la même adresse IP, tant que le tuple
(port local, port distant, adresse locale, adresse distante) est unique
pour TCP.

L'erreur se fait au connect(2) car le tuple n'est complètement connu que
là.

D'ailleurs, avec SO_REUSEADDR plusieurs serveurs peuvent écouter sur le
même socket (un est activé à chaque nouvelle connexion, dans un ordre à supposer
aléatoire).