AlexMog

Une page facebook a été ouverte pour le projet (qui est un Framework pour la création de MMO), si vous souhaitez suivre de plus près l'actualité du projet, n'hésitez pas à aimer la page! https://www.facebook.com/pages/PFA-Marseille-Highlands-Framework/805015802897040?fref=ts

effectivement, tu n'es pas dans la bonne section. Je déplace ton sujet!

La communication via packets entre C++ et C# est complètement fonctionnelle! YAY! Dernières màj: Java: Tests sur des packets... QUI MARCHENT PAS POUR L'INSTANT C++: Ajout de modifications pour préparer la compilation sur windows + adaptation de packet >> char*, qui utilise un int32_t au lieu de int64_t pour s'adapter au C#. C#: Packets fonctionnels avec le serveur C++!

Merci pour vos encouragements . Ca fais plaisir

J'ai mis à jour le sujet en rajoutant le dépôt Java. Pour l'instant, j'ai fait uniquement des tests, qui s'avèrent être fonctionnels (j'arrive à communiquer correctement avec le serveur C++ )

Bonjour à tous, Je développe en ce moment une librairie permettant de gérer des connexions réseau de la manière la plus simple possible (aussi bien niveau AS-I/O (Asynchrone Input Output) que S-I/O (Synchrone Input Output)). Le but étant de fournir un Framework réseau, pouvant être utilisé pour plusieurs choses (je vise principalement le gaming, puisque cette lib a été spécialement crée pour mon PFA (projet de fin d'année) à Epitech, qui est un MMO). Genèse Dans le but de permettre une manipulation simple du réseau, et permettre de la modulation au projet, nous avons décidé de créer un Framework MMO avec mon équipe (le but principal étant d'utiliser ce framework pour un de nos projets, voir même le rendre public avec un engine fournis (bref, on réfléchit)). Pour ce faire, j'ai du développer une lib réseau, qui c'est plutôt concentrée sur un côté Framework (donc la lib gère aussi le lancement exécutif) et nous avons décidé de la partager. (vous pouvez trouver des informations sur ce framework (en C++ avec support Unity3D) ici.) Plusieurs raisons pour ce partage: Nous aimons beaucoup le monde de l'OpenSource. Les utilisateurs potentiels sont des développeurs, et peuvent donc nous faire des retours, voir même nous conseiller. Le partage c'est le bien, nous avons beaucoup appris grâce aux partages, nous souhaitons nous aussi partager nos projet! Bref, un projet OpenSource est né . Généralités et avancement Mais des lib réseau, en C++, il y en a plein! me direz-vous. Et je suis entièrement d'accord avec vous. Cela ne m'empêche pas de continuer à développer la lib, pour ceux qui en auraient besoin à un moment où un autre. Pour parler de l'avancement, je vais vous parler de ce qui est prévu, et de ce qui est fait. Ce qui est prévu (par ordre de priorités): La gestion du protocole WebSocket Une version C# de la lib Une version Java de la lib Ajouter une protection par Mutex à la lib C++ (ça arrive, je trouve la meilleure façon de l'optimiser actuellement) Ce qui est fait: Publication et développement de la version C++ Voilà. Objectifs Les objectifs de la lib sont simples: Permettre à l'utilisateur de créer un serveur/client de manière simple et efficasse, en permettant le multi-plateforme/langage. Pour ce faire, je me suis basé sur la librairie réseau de Java, qui est très simple à utiliser, et j'y ai rajouté des objets préfaits. (Ainsi, nous pouvons trouver "TcpASIOServer" qui est l'objet qui permet de créer un serveur ASIO). Des exemples sont disponibles dans le dossier "test". Voici un exemple de serveur (sans listeners): #include <mognetwork/Packet.hh> #include <mognetwork/TcpASIOServer.hh> #include <mognetwork/TcpASIOWriter.hh> #include <stdio.h> #include <iostream> #include <exception> mognetwork::TcpASIOServer* server; // oui, cette global n'est pas cool, mais c'est pour des tests! void shandler(int) { std::cout << "Stopping server..." << std::endl; server.stop(); } int main(void) { mognetwork::TcpASIOServer server_instance(4242); // Cool, on prépare un serveur sur le port 4242! server = &server_instance; signal(SIGINT, shandler); // On free tout quand on coupe le serveur, nanmého! std::cout << "Starting server..." << std::endl; try { server.start(); // On allume le serveur, il se coupera avec un CTRL+C std::cout << "Server ended." << std::endl; } catch (const std::exception& e) { std::cerr << e.what() << std::endl; } std::cout << "Finish." <<std::endl; return (0); } Liens et sources Voilà, je vous ai tout dis au niveau du projet, j'espère que vous serez nombreux à l'utiliser, et que j'aurais beaucoup de retours. Sources: Version C++: https://github.com/AlexMog/LibNet Version C#: https://github.com/AlexMog/LibNetCSharp Version Java: https://github.com/AlexMog/LibNetJava/ Documentation: Version C++: http://alexmog.labs-epimars.eu/projets/mognetwork-doc/doc/html/ Version C#: A VENIR Javadoc: A VENIR N'hésitez pas à poster votre avis sur la lib, et vos retours . Cordialement, AlexMog.

parfait

En sachant que php5 a perfectionné le modèle objet du PhP, je pense que la version PhP7 sera dédié à cette étape. On verra bien ce que ça vaudra . Ce serait bien qu'ils se rapprochent un peu plus du modèle MVC de Java2E

Quand je demande réinitialisation de mon mot de passe => page blanche!

J'ai finit de débuguer la lib. Elle est *théoriquement* fonctionnelle. J'attends de voir si certains d'entres vous veulent bien tester

Gg

On a pratiquement finit la conception du projet, on c'est déjà lancé dans le code, le MMO utilisera ma lib réseau.

La date de ton ordi est mal configurée. (oui, ça fait sauter les certificats) Have fun.

MAJ du sujet!

Essaye d'installer linux pour être sur que ça ne proviens pas d'un problème hardware. Si ça ne marche pas, vérifie le booting de ton bios, enfin, lance linux en usb live, et vérifie ton Grub.

Perso, j'ai mon Xperia Z depuis 2 ans, il ne m'a jamais laché

Haha, c'est la pipe de Bilbo le hobbit .

Il y a un moyen de tester ça. Essaye de te connecter sur un réseau local avec 2 clients sur ton serveur. Si vous vous voyez, c'est que ça ne viens pas forcément du serveur.

Heureux de t'avoir aidé Je verrais si j'ai la foi

Bon aller, amoa!

Exact, le but étant de faire une grosse introduction au réseau pour pouvoir faire des cours plus variés dessus . Avec plaisir .

S4L n'utilise pas de système P2P il me semble, du coup, tout passe par le serveur, si il n'y a pas de joueurs, je pense pas que ça vienne de tes joueurs.

Bonjour à tous, C'est un sujet aussi intéressent que difficile que nous allons voir aujourd'hui: Le réseau. Nous allons découvrir le réseau de manière théorique et pratique, via ce cours. Nous allons voir tout ça via diverses parties. Tenez-vous bien, après la gestion mémoire, le réseau est la deuxième plus grosse difficulté au niveau de la programmation (ce qui le rends très intéressent!), ce sera un cours principalement théorique (oui, je sais, j'en fais très TRES rarement), et du coup, vous y verrez que très peu de code. Index: 1- Le réseau, en théorie, c'est quoi? 2- En pratique? 3- Différence entre TCP, UDP et UDT (oui oui, ça existe). 4- Quel type de données on peux envoyer en réseau? 5- Synchrone? Asynchrone? Kesako? 6- Un serveur de tchat synchrone (théorique). 7- Notre tchat en version Asynchrone (théorique). 8- Index des fonctions utiles en C (RTFM ). 1- Le réseau, en théorie, c'est quoi? Le réseau définit un moyen pour deux programmes de pouvoir communiquer. Il existe deux définitions du réseau existantes: LAN et INET. De manière générale, le réseau LAN représente le réseau local (nous ne parlerons pas des réseaux VPN qui sont des exceptions à ce niveau là, puisqu'elles créent un réseau LAN virtuel), et les réseaux dis INET représentent les réseaux passant par internet. WOUHOUUUU! La partie théorique a l'aire plutôt bien simple! MAIS, et c'est là que le réseau deviens très cool à connaitre, c'est ULTRA-COMPLEXE à comprendre et en même temps pas si compliqué à mettre en place. Je vais donc essayer de ne pas vous perdre durant ce cours. 2- En pratique? Eh oui, la description ci-dessus simplifie pas mal le fonctionnement du réseau au final. Si nous voulons mettre les mains dans le cambouis, il faut savoir pas mal de choses sur le réseau (bien que pas très importantes dans la programmation en elle même, ça vous permettra au moins de comprendre comment fonctionne le réseau de l’intérieur. Il faut savoir que la couche réseau est la 3ième couche du modèle OSI voyons un peu, pour avoir de la culture info, les 7 couches du modèle OSI: 1- Physique (Le matériel de liaison, carte wifi, blutooth, etc...) 2- Liaison (Gestion de la liaison et de la communication) 3- Réseau (Gestion des couches réseau, IPv4, IPv6, etc...) 4- Transport (Gère la communication en bout des processus, UDP, TCP, etc...) 5- Session (Gère la synchronisation des communications et la gestion des "transactions") 6- Présentation (Code les données applicatives) 7- Application (Définit les points d'accès au service, Nous sommes ICI!) (je vous conseille de jeter un petit coup d’œil sur Wiki, c'est toujours un plus de savoir ce genre de choses , pour vous donner une idée, nous les apprenons par cœur à Epitech (3ième année)) La couche applicative est celle ou nous sommes lorsque nous développons un programme. Toutes les autres couches sont gérées par notre OS, qui fait tout le travail à notre place! Enfin, il faut retenir une chose TRES importante, et qui va beaucoup vous aider: les SOCKETS (système qui permet la communication en réseau) sont des FDs (File descriptors), il sera donc géré comme un fichier, et il faudra toujours penser à FERMER LES SOCKETS! (laisser des FDs ouverts, c'moche! Pauvre kernel ) 3- Différence entre TCP, UDP et UDT (oui oui, ça existe). Ahhh, les protocoles de communication réseau (à ne pas confondre avec les protocoles applicatifs), beaucoup de choix, avec beaucoup de différences. Nous allons voir ça tout de suite: 1- Le TCP Le protocole TCP est actuellement le plus stable et certainement le plus utilisé dans le domaine applicatif (ATTENTION: pas dans le jeu-vidéo). Le TCP comporte 3 grand principes: - Les packets sont certains d'arriver. - Les packets arrivent dans l'ordre. - On a une réponse de la réception du packet par le client. Et tout ça, grâce à un header implémenté dans le packet (oui, le packet est un peu plus lourd). Pour résumer, voici ce qui se passe lorsque vous envoyez un packet TCP: serveur = Envois du packet => client client = J'ai bien reçu le packet! => serveur serveur = Ok merci, j'ai bien reçu la réponse! => client Nous voyons donc qu'il y a 3 envois réseau pour chaque packets, ce qui peux ralentir le réseau pour tout ce qui est temps-réel. ATTENTION NEANMOINS, au vue des connexions internet de nos jours, la différence ne se fait pratiquement pas ressentir. Néanmoins, dans la plupart des jeux, le TCP permet de faire les actions importantes (envois de sorts, pop de monstres, etc...) et l'UDP permet de gérer les actions moins importantes (Déplacements, etc...) pour éviter de surcharger la couche réseau. Même si certains jeux nous montrent bien que le Full TCP, ça peux marcher aussi (RPZ World Of Warcraft). 2- L'UDP L'UDP de manière générale est plus simple, c'est un simple envois de packet ANONYME à un serveur. Cela offre une vitesse 3 fois plus rapide que le TCP mais néanmoins, on ne sais absolument pas sur le packet est bien arrivé au destinataire. Il faut donc apprendre à manier le TCP aussi bien que l'UDP en fonction de ce qu'on veux faire. 2- L'UDT Le cas de l'UDT est totalement différent, car c'est un protocole plutôt jeune qui a été créé pour pouvoir transporter un grand nombre de données (on parle ici de Téraoctets) sur un réseau généralement LAN. Nous n'allons pas en parler ici, mais si vous souhaiter vous renseigner dessus, je vous conseille Wikipedia . 4- Quel type de données on peux envoyer en réseau? Là est la question. Pour faire simple, qu'est-ce qui passe par du réseau, en soite? Eh bien, des données en BINAIRE! Eh oui, c'est des 1 et des 0 qui passent dans nos câbles! On s'y attendais pas, hein? Pour résumer, tant que les données peuvent être stockées en mémoire (soite presque toutes), il est possible de les envoyer en réseau (eh oui, c'est pour ça que le réseau est considéré très proche de la gestion mémoire ). D'une manière générale, faut pas faire l'imbécile, n'envoyez pas des pointeurs en réseau, puisque l'autre machine, n'aura pas allouée ce pointeur . Il faut envoyer des données dites "flat", donc des données et non pas des adresses! Ce qui est très souvent fait, c'est d'envoyer des structures en réseau. ça permet pas mal de chose, mais c'est très peu modulable. Une autre technique, c'est de créer un packet. Voici un exemple du contenu d'un packet: | taille des données dans le packet (4 octets) | données du packet.... | du coup, lorsqu'on reçois ce packet, on lit d'abord les 4 premiers octets pour savoir quelle est la taille du packet complet, et on lit le packet . Bref, de la théorie tout ça! On verra dans un autre cours sur le réseau du code à proprement parlé! 5- Synchrone? Asynchrone? Kesako? Le principe de l'Asynchrone et du Synchrone se retrouve souvent dans les applications ayant plusieurs threads (sous processus). Le principe du Synchrone, c'est d'avoir un thread qui exécute tout de manière Linéaire. Le principe de l'Asynchrone, c'est d'avoir plusieurs threads, ayant chacun un rôle et communicant entre eux. Dans notre cas, le Synchrone en réseau est nommé bloquant alors que l'Asynchrone est nommé non bloquant. Pour faire simple, dans un réseau bloquant, nous attendrons que le client ait bien reçu les informations, alors que dans l'autre cas, nous envoyons les informations en NOWAIT (voir les mans des sockets) et du coup, nous n'attendons pas la réponse TCP. Ce qui nous renvois la taille des données envoyées, et dans le cas ou des données n'ont pas été envoyées, on les renvois. D'une manière générale, le côté bloquant est utilisé dans les clients, alors que le côté non bloquant est utilisé pour les serveurs (eh oui jamie! Si on est bloquant et qu'un client lag, on fait laguer tout le monde! Exemple concret: Starcraft II, mais là encore l'exemple est spécial, puisque SCII, c'est du P2P via servering). Pour l'UDP, il n'est pas question d'être bloquant, puisque nous ne savons pas quand le client reçoit l'information. 6- Un serveur de tchat synchrone (théorique). A VENIR. 7- Notre tchat en version Asynchrone (théorique). A VENIR. 8- Index des fonctions utiles en C (RTFM ). - man 2 socket - man 2 select (une de mes fonctions préférées en C <3) - man 2 accept - man 2 bind - man 2 connect - man 2 listen - man 2 read - man 2 write - man 2 recv - man 2 send - man 7 ip - man 7 socket - man 7 tcp - man 7 udp A bientôt pour un prochain cours! AlexMog.

Faut revoir ta conception! Y'a quelque chose qui vas pas!

D'une manière générale, c'est le SERVEUR et non pas le CLIENT qui doit ouvrir ses ports. Prenons l'exemple de Skype, ou encore Starcraft, qui utilisent tous deux un système de serveur puis p2p: Le client se connecte au serveur, le serveur transfert les données aux autres clients. Ainsi: CLIENT <===> SERVEUR <====> CLIENT Si un client doit communiquer directement avec un autre client, il doit passer par un routeur manuel (comme l'exemple du serveur ci-dessous), ou bien, ouvrir le port du client, et le faire se comporter comme un serveur/client. Pour cela, et vue que le client se comporte comme un serveur, il devra ouvrir ses ports. Pour ouvrir tes ports, tout dépends de ton FAI . J'espère que ca t'aidera! AlexMog.