Travaux Pratiques Réseaux Communication TCP/IP par Socket

Transcription

1 Travaux Pratiques Réseaux Communication TCP/IP par Socket Durée : 4 séances de 4 heures. 1 Objectif Ces travaux pratiques permettent de mettre en application les concepts de la communication Socket dans des environnements hétérogènes en utilisant la méthode standard Berkeley. On peux procéder développant l'application en deux étapes entre un PC Windows et un PC Windows entre un PC Windows et un système Linux L'application consiste à réaliser un chat entre deux machine 2 Ressources fournies Mise en œuvre de la communication Ethernet par Socket windows - Cours Pascal TREBOSC. Architecture ETHERNET TCP/IP - Cours Pascal TREBOSC. Dossier technique : BTS II 1999 Exécutable de démonstration de l'application WireShark : sniffer permettant la capture de trame. Les ressources disponibles sur le réseau dans le répertoire ressources. Les ressources disponibles sur Internet. P. TREBOSC 1/7

2 3 Spécifications L'application consiste à réaliser le test d'intégration d'une application réseau TCP/IP installée et fonctionnant sous Windows. Vous devez réaliser la transmission de messages entre deux postes PC équipée de cartes réseaux. Poste Windows Serveur Socket Poste Linux Client Socket ETHERNET TCP/IP Poste Windows Client Socket Contraintes Le mode de transmission est TCP. Les développements sont réalisés : sous Visual Studio En C avec l'environnement éclipse sous Linux. L'application peut ne pas être totalement sécurisée, mais il faut prévoir au maximum les messages en cas de problèmes de communication. Pour vérifier que la communication est établie, il existe au moins 2 moyens : Faire un ping sur la machine distante sous l'éditeur de commande : ping Si la réponse est OK la liaison est établie. Utiliser un snifer qui intercepte les trames. Dans ce cas, il faut commencer par développer l'application client qui émet une donnée que l'on peut snifer seulement si le snifeur est serveur, c'est à dire qu'il acquitte la communication pour recevoir les données. Attention, Ethereal ne fonctionne pas pour analyser les trames de deux applications Socket installées sur le même PC. Il faut installer le client et le serveur Socket sur deux PC différents. Pour connaître les Sockets ouvertes faire la commande netstat. P. TREBOSC 2/7

3 4 Travail à effectuer Réaliser les étapes suivantes : Analyse UML : use case, diagramme de classe, diagramme séquence Développer l'application (client et serveur) en code natif C++ Objet sous Windows en mode console (projet Win 32 > Application console Win 32) avec détectiond'erreur. Développer l'application graphique et événementiel du chat qui intègre les objets de métier de la communication socket. Réaliser l'application en multi-tâche pour palier au problème de blocage. Réaliser le chat vers un client Linux. Le code client de la communication socket sous Linux est pratiquement le même (application console). Sur le poste Windows : La partie métier serveur Socket est réalisée en objet. On respecte au maximum l'indépendance de la partie graphique et de la partie métier : objet métier réseau Socket en code natif. Idem pour le code client. On utilise les API Windows pour programmer les Sockets avec le standard Berkeley. Réaliser la modélisation UML des applications communications réseaux pour l'émission de messages avec les API Windows. Réaliser sous Visual Studio l'application modélisée. L'interface utilisateur du chatdoit correspondre au minimum à la maquette ci-dessous. TP LIAISON ETHERNET Protocole TCP Initialiser Emettre Chaîne émise Bouton Réceptionner Chaîne reçue Contrôle Text La communication est réalisée, en mode bloquant, vous pouvez toutefois observer ce qui ce passe lorsque l'on travaille sous Windows en mode non bloquant. Voir < soit on garde toutes tes sockets dans le thread principal en mode non-bloquant (ok uniquement si tu as déjà une boucle de rafraîchissement qui tourne régulièrement) soit on utilise un unique thread + un sélecteur pour toutes tes sockets soit tu utilises un thread par socket P. TREBOSC 3/7

4 Le projet complet graphique événementiel + objet de métier code natif réalisé sous Visual Studio aura la structure ci-dessous. Partie graphique Chat Partie événementiel Classe wrapper Partie objet de métier Socket Client Serveur Sur le poste LINUX : L'application client est la même que l'application réalisé sous Windows. Réaliser l'application sous Eclipse C++. P. TREBOSC 4/7

5 5 Méthode de travail Le travail est réalisé en monôme. Le développement peut être fait de manière progressive : 1. Développement de l'application Serveur sous windows en utilisant un sniffer, l'exécutable mis à votre disposition, hyper terminal pour valider la solution. 2. Développement du client sous Windows. 3. Passage du développement sous Vindows dans un environnement Linux. Il faut prendre en compte les différences de codage, notamment le fait qu'une Socket est de type SOCKET sous Windows et de type entier sous LINUX. 6 Travail à rendre 1. Les tests unitaires de chaque application client et serveur. 2. Les exécutables permettant une démonstration de l'application complète. 3. Un rapport qui contient au minimum : L'analyse UML. Le code commenté suivant le standard de codage. La justification des choix. L'application est placée dans un dossier TP Socket du répertoire de votre groupe. Une sauvegarde est faite sur le serveur dans le répertoire TP Socket\<Noms>_TPSocket. 7 Travail complémentaire Si vous avez fini votre travail, vous pouvez refaire la communication socket en utilisant les composants.net using System.Net.Sockets TcpClient et TcpListener 8 Barème de notation Analyse UML Diagramme de classe Diagramme de séquence Démonstration 1 Points 1 Points La démonstration peut se faire en recompilant le code source avec des questions s'y rapportant. Fonctionnement de l'application console Windows: 7 Points Fonctionnement de l'application graphique Windows: 6 Points Fiabilité de l'application : 1 points Commentaires Ils mettent en évidence la compréhension des principes mises en œuvre. Pertinence des commentaires entête de programme et de méthode : Si les commentaires ne sont pas mis en cours de développement 1 point Questionnement 1 points 3 points P. TREBOSC 5/7

6 9 Perspectives On s'aperçoit que l'application fonctionne en mode bloquant sous Windows. Si on intègre ce type d'application dans un projet global cela signifie que l'application sera bloquée lors par exemple d'un attente de connexion ou d'une attente de réception. Pour pallier à ce problème, l'application Socket peut être intégrée dans un Thread. Le Thread sera bloqué mais pas l'application qui pourra être utilisée. Si vous être en avance sur le planning de développement fixé vous pouvez transformer votre application en Thread. 1. Reprendre l'application Windows en utilisant les composants réseau Visual studio Reprendre l'application Windows en programmant l'application client en code managé pour l'interface graphique sur laquelle on associe les objets de métier de communication réseau développé en MFC. 3. L'application sous LINUX peut être transformée en objet. 10 Méthodologie de développement Socket Etape 1 : Créer le modèle objet : composition de la feuille graphique avec l'objet client ou serveur (qui hérite de la classe commune socket. Etape 2 : Créer un serveur, jusqu'à la fonction accept. Etape 3 : Créer le client jusqu'à la connexions. Etape 4 : Créer la communication. P. TREBOSC 6/7

7 Nom : Chaque étape doit être validée avant de commencer la suivante Analyse UML Diagramme de classe Auto correction % Correction /1 Diagramme de séquence /1 Démonstration fonctionnement Fonctionnement de l'application console Windows: /7 Fonctionnement de l'application graphique Windows: /6 Fiabilité de l'application : /1 Commentaires Pertinence des commentaires entête de programme et de méthode : /1 Si les commentaires ne sont pas mis en cours de développement 1 point Questionnement /3 P. TREBOSC 7/7