Aller au contenu

Leaderboard

Popular Content

Showing content with the highest reputation on 18/02/2017 in all areas

  1. 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.
    1 point
×
×
  • Créer...