Re: [Maitretarot-devel-fr] sockets, serveurs, fork, POSIX...

[Yves Mettier]

Coucou!

Histoire de pas trop augmenter le nombre de posts, je reponds a celui-ci et au 
precedent.
Olivier, t'inquiete pas, regarde les archives de la liste, on est tous pareils: 
on sait
aussi poster a tort et a travers.

Bref, le protocole est toujours a jour ici:
http://savannah.nongnu.org/cgi-bin/viewcvs/maitretarot/maitretarot/doc/protocol.sgml

Pour generer un truc lisible:
db2html protocol.sgml
db2ps protocol.sgml
db2pdf protocol.sgml
et ainsi de suite, suivant le format que tu desires.


> le lun 03-02-2003 à 23:17, Yves Mettier a écrit :
>> Pour tout ca, ok.
>> Avec tout ce dont tu parles, c'est meme interessant ta solution. Par contre, 
>> ce qui
>> me gene, moi, c'est si le serveur est charge. Une seule socket pour tout le 
>> monde,
>> ca risque pas de deborder?
> Non !

Bon, ok alors.

>
> C'est une question récurrente, et j'y réponds : il n'y a pas QUE UNE socket, 
> mais
> <nombre de clients> descripteurs de flux + 1 socket.
> Il y a la socket sur laquelle tu fais le listen() (pour les gens non 
> connectés qui
> arrivent)
> Il y a N descripteurs de flux, un par client connecté (c'est celui du 
> accept() ). A ce
> niveau, ce n'est pas la socket qui est chargée, puisque le flux est déjà 
> créé, la pile
> TCP fera transiter l'information
> directement.
> De plus, pour le listen, tu as une file d'attente (je crois qu'elle peut 
> monter à
> 255...). Donc p(as|eu) de risque de perdre du monde.

La file d'attente est parametrable dans la config du noyau (mais je ne sais 
plus ou, et
je ne l'ai vu que pour Solaris)
Par ailleurs, pour le nombre de sockets, il faut aussi prendre le nombre maxi de
descripteurs de fichiers.
Bon, ok, c'est les parametres systemes qui vont limiter, pas une histoire de 
charge.

> Il n'y a à mon avis AUCUN problème de charge. C'est juste qu'il risque d'y 
> avoir
> beaucoup de descripteurs de flux (N) mais le logiciel pourrait le limiter
> volontairement... et c'est un pb commun aux versions avec et sans fork() (à 
> 500
> joueurs, on refuse l'entrée ! Na !).

Arf, avec un fork, non, justement, on repart a zero avec le nombre de 
descripteurs de
fichiers (suffit de fermer ce qu'il faut). Pour la file d'attente du listen, 
par contre,
vu qu'il n'y a qu'un seul serveur, c'est vrai que la limite ne change pas, 
qu'on forke
ou non.

> Et puis (le truc qui tue pour dénier le problème de charge) : les
> serveurs DNS de "." supportent plusieurs centaines (voire milliers) de 
> requètes chaque
> seconde, 24h/24.... et ils ne s'en portent pas plus mal. Avant d'en arriver 
> là, il y
> aura certainement des pbs de bande passante, ou autres pour les serveurs de 
> ce jeu. Le
> jour où la charge réseau sera problématique, c'est que les choses auront bien
> avancé... :)

:)

>
>> Mais si y'a pas besoin?
> Si y'a besoin ? ;)
>> La, y'aura pas besoin de communiquer entre chaque serveur.
>> D'un autre cote, avec le fork, en fait, moi, je pars du principe que chaque 
>> groupe
>> de joueurs est bien separe des autres. Il y a autant de salons que de 
>> parties. Toi,
>> au contraire, en me proposant ton select, tu consideres qu'il n'y a qu'un 
>> seul
>> salon, assez grand pour tout le monde.
> Oui, mais on peut faire un découpage "logique" en plus de salons (un pour le 
> tarot, un
> pour la belote, un bar, .... et les joueurs se
> déplacent entre eux) ... En fait, on fait ce qu'on veut.
> C'est juste que sans fork(), on ne s'auto-limite pas puisque les clients 
> peuvent
> circuler/être recyclés partout.

ouaip. convaincu :)

[...]

Yves
-- 
- Homepage - http://ymettier.free.fr - http://www.cmg.com -
- GPG key  - http://ymettier.free.fr/gpg.txt              -
- MyAM     - http://www.freesoftware.fsf.org/myam         -
- GTKtalog - http://www.freesoftware.fsf.org/gtktalog     -