Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2296 connectés 

  FORUM HardWare.fr
  Programmation
  C++

  Clients/serveur, conseils de conception

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Clients/serveur, conseils de conception

n°257929
R3g
fonctionnaire certifié ITIL
Posté le 30-11-2002 à 20:53:56  profilanswer
 

Voila je me lance dans la programmation d'un petit jeu en réseau.
En gros j'ai un serveur qui gère le déroulement du jeu, et un certain nombre de clients qui ne sont en fait que des interfaces utilisateurs distantes.
Les clients envoient au serveur les entrées de l'itilisateur, et le serveur envoie au client l'état de l'aire de jeu pour qu'ils la redessinent.
Il y a donc un certain nombre de contraintes :
- le serveur peut accepter un nombre indeterminé de clients.
- de nouveaux clients peuvent se joindre à la partie à n'importe quel moment.
- le client, comme le serveur, sont susceptibles d'envoyer des messages à l'autre à n'importe quel moment. Aucun des deux ne sait quand il est susceptible de recevoir un message de l'autre, et ils sont susceptibles de s'envoyer des messages en même temps.
- les communications se font par messages prédéterminés, qui sont en fait des structs qui ont toutes la même taille, avec un identifiant pour indiquer le type de message.
 
Alors voila comme je n'ai jamais programmé de sockets, je voudrais quelques conseils : quel type de sockets utiliser (STREAM, DGRAM ?), quels stratégies adopter pour le serveur (1 thread par client ?), et pour les echanges entre les protagonistes (1 seule socket pour parler dans les 2 sens, ou des sockets à sens uniques...).
Bref je voudrais tout savoir quoi ;)


---------------
Au royaume des sourds, les borgnes sont sourds.
mood
Publicité
Posté le 30-11-2002 à 20:53:56  profilanswer
 

n°257963
lorill
Posté le 30-11-2002 à 22:37:17  profilanswer
 

Utilises tcp plutot que udp (stream plutot que datagram). UDP ne te garanti pas qu'un message a été reçu, alors que TCP si.
 
Et les sockets, ca marche dans les deux sens, donc a priori une socket par client.

n°258001
R3g
fonctionnaire certifié ITIL
Posté le 30-11-2002 à 23:14:51  profilanswer
 

Ok. Bon alors moi je voyais les choses comme ça : une socket pour recevoir les demandes de connexion des clients, et quand une demande arrive, on crée une nouvelle socket pour écouter le client et lui envoyer les infos.
Alors la question maintenant c'est : une thread par client c'est bien, ou il vaut mieux essayer de gérer tous les clients dans la même thread avec des sockets non bloquantes ou asynchrones (question subsidiaire : c'est pareil ou il y a une différence ?)
 
P.S. : puree je pose des questions comme ça un samedi soir, doit vraiment y avoir quelque chose qui va pas chez moi :(


---------------
Au royaume des sourds, les borgnes sont sourds.
n°258005
lorill
Posté le 30-11-2002 à 23:17:10  profilanswer
 

R3g a écrit a écrit :

Ok. Bon alors moi je voyais les choses comme ça : une socket pour recevoir les demandes de connexion des clients, et quand une demande arrive, on crée une nouvelle socket pour écouter le client et lui envoyer les infos.




ben ca c'est le comportement normal, c'est ce que fait accept()
 

R3g a écrit a écrit :

P.S. : puree je pose des questions comme ça un samedi soir, doit vraiment y avoir quelque chose qui va pas chez moi :(




y'a pire, du style comment gérer des attributs privés, mais qu'on puisse rajouter dynamiquement des méthodes qui peuvent quand même acceder a ces attributs  :o

n°258012
R3g
fonctionnaire certifié ITIL
Posté le 30-11-2002 à 23:20:37  profilanswer
 

lorill a écrit a écrit :

 
ben ca c'est le comportement normal, c'est ce que fait accept()



Tu veux dire que accept() me crée automatiquement une nouvelle socket connectée au client ? A ce moment là c'est très bien mais j'avais pas compris
 

lorill a écrit a écrit :

 
y'a pire, du style comment gérer des attributs privés, mais qu'on puisse rajouter dynamiquement des méthodes qui peuvent quand même acceder a ces attributs  :o  




Effectivement ca à l'air bien pire, mais je comprends pas bien.


---------------
Au royaume des sourds, les borgnes sont sourds.
n°258016
lorill
Posté le 30-11-2002 à 23:22:11  profilanswer
 

R3g a écrit a écrit :

 
Tu veux dire que accept() me crée automatiquement une nouvelle socket connectée au client ? A ce moment là c'est très bien mais j'avais pas compris




 
oui. accept() accepte justement une connexion, et te renvoie la socket associée a cette connexion.

n°258024
R3g
fonctionnaire certifié ITIL
Posté le 30-11-2002 à 23:27:25  profilanswer
 

Bon ben c'est super ça alors. Encore nu ou deux tutorials, et je suis prêts à y aller. Merci.


---------------
Au royaume des sourds, les borgnes sont sourds.

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  C++

  Clients/serveur, conseils de conception

 

Sujets relatifs
Configuration de php sur un serveurDétection de marche/arrêt d'un serveur
Client/Serveur Simple!!!!!!!!!!!!!![PHP] Récuperer les infos d'un serveur irc
PB connection Refused serveur / client javaBesoin de conseils pr un script de news
Probleme mysql avec mon serveur apacheScript qui empêche de d/l directement sur le serveur
[hebergeur] conseils...Création d'un serveur SQL Server puis sélection ds groupe.
Plus de sujets relatifs à : Clients/serveur, conseils de conception


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR