On Friday 10 September 2004 14:00, Julien Escario wrote:
> .. si le serveur envoie des requ�tes depuis le port 53, cela signifie
> qu'il tourne forcement en root non ?
Uniquement pour faire le "bind". Apres, il a le "socket" a disposition pour le
process. Les droits d'acces ne sont verifier que pour les "system calls" qui
y sont confrontes. Soit, en grande majorite, des commandes du style open().
Les fonctions read(), write(), close(), select() n'en ont pas besoin
puisqu'elle manipulent un "file descriptor" pour lequel les droits d'acces
ont deja ete verifies. Ce qui fait que, dans le cas de "named", le "bind" est
fait en "root", puis le UID du process est change.
> Pomment un serveur peut-il utiliser le m�me port pour envoyer et recevoir
> des requ�tes ?
Un socket, comme un fichier, permet d'ecrire et de lire.
> cela signifie qu'il ne peut faire une requ�te et en
> recevoir une en m�me temps ?
Pas "vraiment" en meme temps... quoique... Par defaut, named essaie de
determiner le nombre de CPUS (y compris les dual-core) afin de determiner le
niveau de "threading" qu'il peut se permettre. Dans ce cas, et puisque
select() est "tread-safe", il est parfaitement possible d'envoyer une requete
et d'en recevoir une en meme temps. Ceci n'est donc pas valable sur un
machine n'ayant qu'un seul CPU (quoique... mais entrer dans les details nous
ferait trop deriver).
> Une requ�te DNS implique un temps de timeout,
UDP...
> si le c�t� client tombe sur un temps de r�ponse long, le c�t� serveur ne
> plus r�pondre pendant quelqeus secondes ??? ca me parait g�nant ...
Non, voir l'explication ci-dessus.
> Cela, je veux bien admettre qu'il puisse ouvrir un port privil�gi� en
> root, switcher en user et l'utiliser. Donc pourquoi pour envoyer aussi des
> requ�tes ?
e depuis un AUTRE port (non
> privil�gi�) ?
Oui, un seul process en mode 'root' s'occupe d'obtenir le socket, puis
celui-ci "fork" N process (dependant de son niveau de threading) qui heritent
du socket; mais apres avoir change son UID.
Daniel
_______________________________________________
gull mailing list
[EMAIL PROTECTED]
http://lists.alphanet.ch/mailman/listinfo/gull
