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 _______________________________________________ gull mailing list [EMAIL PROTECTED] http://lists.alphanet.ch/mailman/listinfo/gull
