Discussion :

[Bandanas]

Super, merci !

[Bousk]

Salut à tous,

Maintenant que notre moteur commence à être dans un état utilisable, voyons comment l'appliquer à un premier jeu très simple : le morpion.
L'article présente comment créer un jeu en réseau à partir d'un jeu solo. La création du code du jeu solo ne fait pas partie de l'article.
Plusieurs diagrammes détaillent cette transition, ainsi que le code bien sûr, pour créer un programme jouable en réseau, seul ou avec 2 joueurs sur un même exécutable grâce à l'introduction du service réseau qui est le coeur de l'article.

Bonne lecture !
https://bousk.developpez.com/cours/r.../01-tictactoe/

[LuffyShop]

excellent cours, il est très intéressant

[Gouyon]

Bonjour

J'ai une incompréhension au niveau de l'UDP. Je pensais que lorsque l'on envoyait de données sur un port elle pouvaient être lues par tous ceux qui écoutent ce port et il semble que ce n'est pas du tout le cas.
Je pose cette question car on m'a fournis un logiciel sensé simuler un instrument de mesure qui envoie ses données en UDP
Dans ce logiciel je rentre une adresse IP d'émission et un port d'émission mais pas de destinataire.
Quand j'utilise un logiciel d'analyse de réseau je me trouve que l'adresse de destination et le port de destination sont identiques à l'adresse de source et au port de source.
Du coup je n'arrive pas à lire les données à partir du programme que je développe et qui est censé récupérer les information de cet instrument.
Y a t'il moyen de configurer le socket de réception de telle manière qu'il puisse récupérer ce message?

[Bousk]

UDP envoit vers un couple ip/port.
Il existe des IPs spécifiques, localhost et broadcast par exemple, pour s'envoyer à soi-même ou à tout le monde (dans le réseau/routeur local).
L'IP que tu donnes à ton programme est probablement l'IP destination, il n'y a (quasi) aucun intérêt à fournir l'IP source.
Ou le programme émet peut-être en broadcast sur le port que tu choisis.
Mais ça c'est sensé se trouver dans la doc du programme.

[Gouyon]

Merci pour cette réponse rapide.
Je viens d'essayer avec l'IP Broadcast et ça fonctionne très bien
Il serait bien de mettre un petit chapitre à ce sujet dans ton excellent cours

Mais ça c'est sensé se trouver dans la doc du programme.

Comment dire "oui dans un monde parfait"

[Serre-tete]

Merci pour le partage, c'est énorme !

[Bousk]

Salut à tous,

de retour avec un nouvel article... annuel (time flies )
Cette fois nous étudions comment débuguer une application en réseau, en ajoutant des mécanismes de pause et reprise de la connexion - tant que faire se peut.
Au lieu de déclencher une déconnexion, le moteur réseau enverra un message de pause. Par exemple quand un des process rencontre un breakpoint.
L'application est ensuite libre d'y réagir, typiquement en mettant en pause la simulation jusqu'à la reprise de la connexion,
Si la reprise est impossible ou celle-ci tarde, vous pouvez kicker le client distant.

Bonne lecture !
https://bousk.developpez.com/cours/r...cation-reseau/

[panthere noire]

Merci pour l'information et ton partage, je suis intéresser donc je m'abonne

[philodu83]

Bonjour,
Dans ton cour sur le mini serveur en TCP, tu dis "Si le serveur devient plus gros et doit accueillir une population plus importante, l'architecture mise en place dans ce chapitre ne sera pas adaptée."
J'imagine que le cour sur l'UDP est une solution pour répondre à ce besoin ?
Ou même si j'arrive au bout du cour sur l'UDP, je serais toujours limité à un nombre de connexion ?

Merci en tout cas pour ce cour qui permet de démystifier un peut le sujet ^^

[Bousk]

Non UDP n'est pas une solution pour scaler le miniserveur.
Pour scaler il faut changer le traitement des connexions et échanges de données (avec kqueue, epoll, .. mentionnés vers le début du thread).
UDP devrait être utilisé pour du gameplay (temps réel) où le nombre de connexions devrait déjà être limité par les règles gameplay ou les performances nécessaires.

Pour les lecteurs, je suis désolé du manque de contenus : le temps me manque depuis 3 ans .

[bacelar]

Il y a bien d'autres axes d'évolution que le choix des implémentations de protocole de niveau Transport de l'OSI fournies dans les OS "main stream".
- configuration de ces implémentations pour les adapter aux besoins, et pas qu'au niveau 4 de l'OSI (Transport) mais à n'importe quel niveau.
- implémentation customisé d'un composant de la stack réseau, voire de la stack complète via des drivers, qu'ils soient dans un firmware matériel, un driver de périphérique, un driver layer du Kernel, ou des parties "User" de la pile réseau
- Design de protocoles spécifiques utilisant, ou n'utilisant pas des composants de la stack réseau de l'OS,
- Mise en place de hardwares dédiés comme des répartiteurs de charge
- etc...

[ArnaudNRoses]

Dans le tutoriel à cette page : https://bousk.developpez.com/cours/r...ecture-client/

il y a ce code mais je ne comprends pas cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
class Message
{
	public:
		template<class M>
		bool is() const { return mType == M::StaticType; }// ICI : COMMENT SE FAIT LA DEDUCTION du type M ??????? Je comprends pas vraiment
		template<class M>
		const M* as() const { return static_cast<const M*>(this); }
 
	protected:
		enum class Type {
			Connection,
			Disconnection,
			UserData,
		};
		Message(Type type)
			: mType(type)
		{}
	private:
		Type mType;
};

Quelqu'un peut-il m'aider ? Merci beaucoup d'avance !!!

[Bousk]

M est le paramètre template et ceci est un CRTP.