1. #1
    Membre à l'essai
    Homme Profil pro
    Cimentage
    Inscrit en
    septembre 2014
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Cimentage
    Secteur : Associations - ONG

    Informations forums :
    Inscription : septembre 2014
    Messages : 23
    Points : 22
    Points
    22

    Par défaut [Réseau Serveur/Multi-Clients] Plantage de synchronisation avec SFML

    Salut à tous

    Je viens vous voir car j'aurais besoin que vous m'éclairiez sur la façon dont je pourrais m'y prendre afin de gérer simultanément plusieurs clients sur un serveur monothreadé, que vous m'expliquiez un peu en théorie comment optimiser et gérer la connexion et la déconnexion des clients en temps réel etc..

    J'utilise la librairie Network.hpp fournie avec la SFML, j'ai déjà réussi à concevoir un serveur qui peut gérer plusieurs clients sur un chat, tout fonctionne correctement, mais lorsque je veux manipuler des objets ( création / destruction d'objets dans un vecteur "player" ) avec des formes visibles ( autrement-dit des Rectangleshape ) qui peuvent être déplacés en temps réel sur chaque fenêtre de chaque joueur, je suis perdu et j'ai souvent des plantages suite à des dépassements de vecteur ( je suis conscient que c'est ça ) mais je n'ai pas idée de la façon dont je peux gérer dynamiquement ces tableaux à la PERFECTION.

    Je poste ici car la section "api graphique & sfml" est morte, les réponses sont quasiment inexistantes.. Merci à vous tous pour vos conseils, je suis avide de théories constructives et je serais très attentif à vos réponses ! :-)

  2. #2
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    4 184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 4 184
    Points : 15 686
    Points
    15 686

    Par défaut

    Salut,

    si ton problème est de l'ordre de "mon client plante par accès hors borne de tableau", ton problème est tout sauf un problème de réseau.
    Le réseau te permettra d'échanger des données entre les clients. Si les clients font n'importe quoi au point de crasher, ce n'est pas la faute au réseau mais à ton client.

    vous m'expliquiez un peu en théorie comment optimiser et gérer la connexion et la déconnexion des clients en temps réel etc..
    Ben... ton serveur il appelle accept et reçoit un socket qu'il doit stocker, et si un appel futur à send ou recv retourne une erreur qui stipule qu'il est déconnecté tu peux supprimer le socket de ta liste. Je vois pas trop ce que tu veux de plus.

    Et gérer un tableau dynamique, ça s'appelle utiliser std::vector. Eventuellement avec du mutex.

  3. #3
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2007
    Messages
    4 597
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 4 597
    Points : 14 459
    Points
    14 459

    Par défaut

    monothreadé?
    Comment peux-tu te débrouiller?
    Les connexions réseaux ont cette propriété qu'on ne maitrise pas le moment de réception des données.

    L'arrivée de données sur le réseau est sur une autre ligne de temps que ton main().
    Tu dois donc forcément avoir au moins un thread dédié à la récupération du contenu de la socket.

    Il y a deux possibilités: soit la SFML a ce thread en interne, et te propose un moyen de lire les informations reçues, soit tu dois le faire toi même.
    A priori, pour ce que je sais de la SFML, tu dois être dans le premier cas.
    Auquel cas, il suffit de lire ces informations quand tu en as le temps, sans y passer trop de temps, mais sans oublier de le faire.
    Pour moi, ca nécessite d'être fait dans le thread de logique du jeu/de l'application.

    Ta boucle d'écoute réseau correspond à de la logique de fonctionnement de l'application. Il n'y a aucune raison de la synchroniser avec la boucle graphique (et donc de mettre l'écoute dans l'affichage).
    Si jamais tu avais l'idée de le faire, malgré tout, au moment où tu récupères les événements, ajoute la récupération des événements réseau.

    Je note tout de même quelque chose d'étrange: pourquoi passer par la SFML pour faire le serveur (qui n'est pas graphique, puisque c'est un serveur?)

    EDIT:
    Ou alors, je suis à côté de la plaque, et j'ai rien compris à ton problème de réseau.
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  4. #4
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 074
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 074
    Points : 11 466
    Points
    11 466

    Par défaut

    Citation Envoyé par ternel Voir le message
    EDIT:
    Ou alors, je suis à côté de la plaque, et j'ai rien compris à ton problème de réseau.
    tu n'est pas tout(e) seul(e) on est 2
    effectivement utiliser la SFML pour un programme serveur n'a pas d'intérêt puisque il n'y pas de rendu temps réel..à la rigueur on peut afficher les paquets qui passent et sont redispatchés mais en Winform, VCL sous Delphi ou autre ça se fait aussi bien...
    Bousk a très bien décrit la méthode toute simple pour faire des connections réseaux
    * Descartes: "je pense donc je suis"
    * Bob l'éponge : "je pense donc j'essuie"
    * l'infirmière : "je panse donc je suis"

  5. #5
    Rédacteur/Modérateur

    Homme Profil pro
    Network game programmer
    Inscrit en
    juin 2010
    Messages
    4 184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 29
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Network game programmer

    Informations forums :
    Inscription : juin 2010
    Messages : 4 184
    Points : 15 686
    Points
    15 686

    Par défaut

    Citation Envoyé par ternel Voir le message
    monothreadé?
    Comment peux-tu te débrouiller?
    Les connexions réseaux ont cette propriété qu'on ne maitrise pas le moment de réception des données.
    Avec des sockets non-bloquants
    C'est assez efficace pour un serveur de petite taille, j'ai un article à venir qui montre ça

  6. #6
    Expert éminent sénior

    Femme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    juin 2007
    Messages
    4 597
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : juin 2007
    Messages : 4 597
    Points : 14 459
    Points
    14 459

    Par défaut

    Cool! Je le lirai avec plaisir.
    Je ne maitrise vraiment pas le réseau…
    Mes principes de bases du codeur qui veut pouvoir dormir:
    • Une variable de moins est une source d'erreur en moins.
    • Un pointeur de moins est une montagne d'erreurs en moins.
    • Un copier-coller, ça doit se justifier... Deux, c'est un de trop.
    • jamais signifie "sauf si j'ai passé trois jours à prouver que je peux".
    • La plus sotte des questions est celle qu'on ne pose pas.
    Pour faire des graphes, essayez yEd.
    le ter nel est le titre porté par un de mes personnages de jeu de rôle

  7. #7
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2008
    Messages
    21 688
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2008
    Messages : 21 688
    Points : 145 360
    Points
    145 360
    Billets dans le blog
    5

    Par défaut

    Notez que le problème a été discuté ici : https://www.developpez.net/forums/d1...ombre-clients/ et que si le forum était "mort" c'est grandement parce que vous n'avez pas donné de suite
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

Discussions similaires

  1. [sockets][UDP][C/C++] serveur multi-clients
    Par l@rry dans le forum Développement
    Réponses: 4
    Dernier message: 08/06/2006, 14h11
  2. serveur multi clients
    Par aaronw dans le forum C++Builder
    Réponses: 4
    Dernier message: 06/03/2006, 09h01
  3. Fork, pthread et serveur multi-clients
    Par Pico10 dans le forum POSIX
    Réponses: 13
    Dernier message: 05/01/2006, 11h48
  4. Serveur Multi-clients
    Par darsky dans le forum C++Builder
    Réponses: 5
    Dernier message: 16/04/2004, 09h53
  5. Création d'un Serveur Multi Client
    Par N*E*R*D dans le forum Autres outils C & C++
    Réponses: 5
    Dernier message: 16/03/2004, 17h13

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