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

[Olivier Péningault]

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 ! 

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.
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 !).
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.

> Et j'en profite pour utiliser cette comparaison et reformuler ma crainte: 
> est-ce que si
> y'a trop de monde le salon va pas etre trop petit?
répondu...

> Bah tu m'as pas vraiment convaincu, mais n'ayant pas de solution vraiment 
> bien pour mon
> idee, je suis pas vraiment convaincu par mon idee non plus.
> Ce qui me convainc peut-etre le plus, c'est que si tu fais le squelette, y'a 
> plus qu'a
> continuer. Alors que si on continue a reflechir, ca fait pas avancer le 
> probleme,
> surtout que tout le monde s'est plus ou moins deja exprime sans apporter de 
> solution.
> 
> Donc tu proposes une solution et tu l'implementes, que demander de mieux? Je 
> suis
> convaincu :)
Cooool ;)

> Le seul truc qui me gene, c'est combien de connexions on peut accepter...
répondu

 
> Dans ton code, loupe pas les trucs que j'ai deja ecrit ici, si ca peut 
> t'avancer:
> http://savannah.nongnu.org/cgi-bin/viewcvs/maitretarot/libmaitretarot/src/libmt_protocol_utils.c?rev=1.1&content-type=text/vnd.viewcvs-markup
> 
> Et pour le protocole de communication, l'as-tu bien repere sur le CVS, dans
> maitretarot/doc? C'est ce fichier, protocol.sgml, qui est le plus a jour. 
> Mais il est un
> peu bordelique encore.
Non, pas vu, mais je vais aller le voir, ...

> Philippe, tu peux faire un petit peu de menage dedans? Sinon, je m'en occupe 
> a partir de
> vendredi prochain.
... et de toutes façons, je vois ça demain avec Philippe sur notre canal
habituel... :)

a+

olivier