Discussion :

[Haknaton]

Bonjour,

J'ai choisi de programmer un petit jeu simple en tcp. J'ai fait la version solo et je voudrais le passer en multi-joueurs.

J'ai réussi à faire une découverte des serveur situé sur le lan à l'aide de socket udp multicast. tout va bien.

Je cale au modèle de thread à adopter durant la phase de jeu. Le client devrait dès le début de la partie en attente d'un évènement de la part du serveur MAIS pouvoir lui signaler des évènement de sa partie qd il arrive. IDEM pour le serveur. Le serveur fait donc office de "duplicateur" de paquets et tout le monde attend tout le monde et on cause qui veut quand on veut.

J'hésite:
Un Thread, Une seule socket avec lecteur & émission sur la même mais un select sur la réception serait bloquant.
Deux Thread, Une seule socket avec lecture sur un thread & écriture sur l'autre.
Deux thread, deux sockets connectées chacune client-serveur et serveur-client

J'espère que je ne me suis pas trop contredis. Je connais mes fonctions réseaux mais je n'ai jamais appris à les utiliser dans un modèle valable.

Je suis donc à la recherche d'inspiration.

Merci

PS: j'ai déja lu les 2-3 liens de référence réseau souvent donnés sur ce forum.

[LinuxUser]

Personnellement je n'aurais pas utilisé de thread mais plutôt un tableau de descripteur de sockets.

[Emmanuel Delahaye]

Personnellement je n'aurais pas utilisé de thread mais plutôt un tableau de descripteur de sockets.

et select() ?

[Haknaton]

Je vais essayer de reformuler ma question car je suis toujours dans le flou total et je n'arrive pas à coder une seule ligne.

J'aimerais que mon client et mon serveur puissent s'échanger des informations sans avoir le stupide jeu de Question -> Attendre la réponse.....
J'aimerais que mon client soit à la en attente de tout ce qui peut venir et qu'il aie la capacité d'informer le serveur d'un évènement.

Si je suis sur un sélect pour voir ce qui arrive. Je vais avoir difficile de réagir à ce qui se passe. Je pensais donc utiliser 2 threads sur la même socket. Est-ce fesable ? faut-il un mutex ? Ou alors faut-il une socket d'écoute et une socket d'envois ?

Je dois avouer que je suis bien perdu même en ayant relu 5x le tuto de emdel.

J'ai recherché je ne trouve que des tutos où on explique le principe de "question réponse" alors que moi je voudrais une gestion d'évènement

[LinuxUser]

et select() ?

Oui avec select, puis FDISSET etc....

[Haknaton]

Maieuhhh pourquoi les discutions de débutant comme les miennes sont toujours remplies de réponses réponses techniques entre membres éclairés qui n'apportent rien à la compréhension de celui qui a posé la question....

Les fonctions ne m'interessent pas, je sais ouvrir le man. Je cherche une manière, une modèle, un principe qui marche et que me permette de solutionner mon problème...

Je reformule. Je ne vois pas comment attendre sur une socket et pouvoir écrire dessus a part en utilisant des threads. D'où la question qui suit dois-je utiliser un mutex pour partager une socket entre deux threads. Et est-ce que deux thread peuvent utiliser la même socket l'un en lecture et l'autre en écriture simultanément ?

Dans l'attente d'une réponse.

[Emmanuel Delahaye]

Je reformule. Je ne vois pas comment attendre sur une socket et pouvoir écrire dessus a part en utilisant des threads.

OK. C'est une façon simple de traiter le problème.

D'où la question qui suit dois-je utiliser un mutex pour partager une socket entre deux threads.

Non.

Et est-ce que deux thread peuvent utiliser la même socket l'un en lecture et l'autre en écriture simultanément ?

Oui.

[souviron34]

Je reformule. Je ne vois pas comment attendre sur une socket et pouvoir écrire dessus a part en utilisant des threads.

très simple : en utilisant les sockets asynchrones...