[gull] Les requêtes DNS

Arnaud Burlet arnaud_oss at bluewin.ch
Sun Sep 12 14:19:02 CEST 2004


On Sunday 12 September 2004 12.19, Marc SCHAEFER wrote:
> On Sun, Sep 12, 2004 at 11:17:49AM +0200, Arnaud Burlet wrote:
> > et dans le cas d'un serveur dns qui fait (admettons) deux requêtes
> > simultanées (depuis 2 threads ou process différents) vers le même serveur
> > dns, on a le cas :
> >     1.2.3.4:53 <----->> 4.3.2.1:53 (pour une premiere requête)
> >     1.2.3.4:53 <----->> 4.3.2.1:53 (pour une seconde requête)
> > est-ce possible ?
>
> Même si le serveur et le clients sont multi-thread (et sous UNIX ils
> seront plutôt single-threaded et multiplexés avec select(2)), un socket
> donné (bind(2) à un port local) est un descripteur qui délivre des
> données (TCP) ou des données délimitées par datagramme (UDP) de façon
> séquentielle (voir plus bas sur l'atomicité de write(2) et de send(2)
> selon POSIX).
>
> Il n'y aura jamais simultanéité pour un seul socket.  Il y aura
> peut-être un `dispatcher' au niveau du serveur DNS, s'il est
> multithreadé: la réception sera single-threaded, le traitement
> parallèle. Si le client utilise un port statique (genre 53) plutôt qu'un
> port fantôme > 1023, il doit gérer en interne une table de question et
> gérer les réponses en fonction.  C'est le cas de BIND9.
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) ?


Je parlais d'utiliser deux socket TCP différents pour cette opération, donc 
deux fois les appels suivants:

socket()
bind() (à un port local)
connect()
accept() (de la part de la partie serveur)


> Pour TCP, c'est différent. Une requête sera précédée d'une ouverture à 3
> phases de connexion, et la réponse suivie d'une fermeture de connexion.
>
> En théorie on peut donc effectuer deux opérations successives dans la
> mesure où la connexion est bien fermée correctement entre deux.
Successive, bien sur, il s'agissait de savoir si le cas de deux connections 
TCP/IP simultanées telle que je le décrivait pouvaient être possible.

> > - deux clients qui se connectent à ce serveur avec chacun le même port
> > TCP comme source.
>
> impossible (voir plus bas).
>
> > Tout fonctionne jusqu'à l'appel connect() du deuxième client qui échoue,
> > errno indiquant : "Cannot assign requested address".
>
> Il y a ici un bind(2) implicite qui échoue forcément. Un seul processus
> peut bind(2)er sur tuple (port local, adresse locale).
je ne suis pas sur !
d'après socket(7), en utilisant SO_REUSEADDR, plusieurs socket peuvent 
bind(2)er sur un meme tuple (port local, adresse locale), pour autant 
qu'aucune d'elles soient en mode listen().
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...

> Le seul cas qui peut aboutir à un partage d'un socket: si ce processus
> lance des fils (fork(2)), ils peuvent partager le socket, mais il y aura
> sérialisation (write(2) ou send(2) sont atomiques: l'atomicité signifie,
> sous POSIX, que s'il n'est pas possible d'envoyer p.ex. 1024 bytes
> maintenant, on envoie ce qu'on peut à TCP et write(2) retourne moins de
> bytes que prévu. Il faut donc boucler. Cela est vrai pour tous les
> périphériques de type caractère, les tty, etc).
Oui!

> > Ce n'est pas clair dans ce message d'erreur, mais on peut en déduire
> > qu'une connection est bien identifiée par
> >     (addresse source, adresse destination; port source, port destination)
>
> En fait ici, ce qui coince c'est la partie locale (port source, adresse
> source).
Je pense que c'est faux, cf mon expérience plus haut

> > Si je reviens à mon exemple en-dessus, un serveur dns a donc un mécanisme
> > qui empèche ce type de situation, ou qui les détecte ?
>
> Cette situation ne se produit pas.
Ne se produit pas car les serveurs DNS utilisent de l'UDP pour faire ce 
travail (ce que tu as expliqué au début, plus haut) ?


Arnaud



More information about the gull mailing list