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

Salut à tous :D

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

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. :calim2:
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.

Citation:

---

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. :weird:

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

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.

Citation:

---

Envoyé par ternel

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 :mouarf:
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

Citation:

---

Envoyé par ternel

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 ;)

Cool! Je le lirai avec plaisir.
Je ne maitrise vraiment pas le réseau…

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 :?