IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Threads & Processus C++ Discussion :

Pilotage d'un serveur local au travers d'un client


Sujet :

Threads & Processus C++

  1. #1
    Membre actif
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 74
    Par défaut Pilotage d'un serveur local au travers d'un client
    Bonjour,

    Dans le cadre du développement d'un jeu vidéo multijoueur, j'aimerais faire une communication entre processus.

    Le serveur n'a pas d'interface graphique. Chacun des joueurs possède un client et se connecte à un serveur créé par l'un des joueurs.

    J'aimerais qu'un des joueurs puisse démarrer le serveur de sa machine en cliquant sur un bouton "Créer le serveur" depuis le programme client, et que ce serveur soit configurable depuis le client qui l'exécute sur sa machine : nombre de joueurs max, départ de la partie...

    Il m'est possible d'utiliser une socket en boucle local pour piloter le serveur depuis le jeu (le client). D'autant plus que l'échange de messages est en quelque sorte le rôle de serveur / client. Mais je doute que ce soit la meilleur solution pour piloter un serveur qui s'exécute sur la même machine que le client. Pour moi, les sockets sont plutôt réservés aux communications entre machines. N'est ce pas ?

    J'aimerais donc me faire conseiller sur un solution portable pour échanger des messages simplement entre deux processus d'une même machine.

    Les applications serveur et client sont codées en C++.

    Merci.

  2. #2
    r0d
    r0d est déconnecté
    Membre expérimenté

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    4 292
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2004
    Messages : 4 292
    Billets dans le blog
    2
    Par défaut
    Bonjour,

    en général, l'architecture choisie pour ce genre de chose est la suivante:
    1. le serveur est un programme à part, et on y accède par SOAP (en c++ il y a gSOAP par exemple. derrière gSoap il y a un (des) socket(s), mais ce n'est pas un problème).
    2. le client est un programme à part, et il se connecte au seveur par SOAP.

    Et du coup, ton client "spécial", celui qui crée le serveur, sera exactement comme les autres clients, la seule différence étant qu'il aura la possibilité de créer le serveur*. Après tu peux facilement implémenter un système de droits de façon à ce que lui seul (et pas les autres clients) puissent accéder aux fonctions de configuration du serveur.

    Il n'y a aucun inconvénient à ce que deux programmes sur la même machine discutent par socket. C'est certainement pas le plus efficace en termes de rapidité, mais c'est booste bien quand-même, ne t'en fais pas.

    Le problème qui se pose ici, c'est que comme SOAP fonctionne par socket, il faut que les clients connaissent l'adresse du serveur. Il existe tout un tas de solutions pour régler ce problème. J'en connais quelques unes:
    - un serveur avec une ip fixe, cette ip étant connue par le client, dans un fichier de config par exemple.
    - un serveur tiers (souvent sous forme de web service) qui connais la direction de ton serveur et que les client devront intérroger pour connaître cette dernière avant de se connecter.
    - un hub (logiciel) démon, qui, via UDP, est capable de retrouver ton serveur.

    Il doit exister bien d'autres solutions j'imagine.

    * et encore, suis partisan d'une même implémentation pour tous les types de clients, les différences entre chacun d'entre eux étant gérées par un fichier de configuration. Et si, à terme, il faut plus de sécurité, alors intégrer partie ou totalité de ce fichier de configuration dans le binaire (compilé donc).

  3. #3
    Membre actif
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    74
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 74
    Par défaut
    Je viens de regarder ton tuto sur GSOAP. Ça me parait plus compliquer à implémenter que la messagerie que j'ai mis en place pour le jeu. Si ce qu'il se cache derrière n'est rien d'autre de des sockets, alors je préfère réutiliser ma classe.

    En tout cas je te remercie pour tes conseils.

Discussions similaires

  1. serveur local apache, problème d'affichage
    Par ptit_seb dans le forum Apache
    Réponses: 2
    Dernier message: 08/01/2006, 23h40
  2. Insertion de données serveur local -> serveur distant
    Par Sunny dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 12/12/2005, 14h19
  3. apostrophe et serveur local
    Par Paulhac dans le forum SQL Procédural
    Réponses: 6
    Dernier message: 06/11/2005, 19h23
  4. [Debutant]Impossible de se connecter au serveur local
    Par Kenji dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 24/04/2005, 19h55
  5. serveur local Easyphp
    Par Covax dans le forum Débuter
    Réponses: 3
    Dernier message: 05/04/2004, 12h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo