logo telecom ipp

Communication Client Serveur

Jean-Claude Dufourd, Thomas Robert

Objectifs pédagogiques du module

  • Savoir communiquer entre deux programmes tournant sur 1 ou 2 machines en utilisant le réseau
  • Définir le bon niveau de communication et les éléments du dialogue en fonction du contexte
  • Option: Savoir gérer une base de données simple
  • Option: Savoir gérer un serveur virtuel

Vocabulaire

Client et serveur sont deux entités sur un réseau.

Le client se connecte au serveur.

Le serveur écoute. Il doit être démarré avant le(s) client(s).

Avant la technique…

Quel est votre besoin en communication:

  • un client (ex: mobile) et un serveur (ex: PC)
  • ou des clients et un serveur avec communication “rare”
  • ou des clients et un serveur avec communication rapide et critique
  • ou des clients qui doivent communiquer entre eux, mais pas de serveur

Ces 4 situations donnent des structures de projet très différentes.

Quel est votre besoin en traitement:

  • les calculs sont faits en python sur un PC
  • les calculs sont en java mais trop lourds pour un mobile
  • il y a besoin de synchroniser plusieurs clients

Pour ces raisons, vous avez besoin d’un serveur. Autrement, pas forcément besoin d’un serveur…

CAS1: Un client, un serveur

Le client se connecte et reste connecté en permanence.

La complexité est dans la nature, le volume et la vitesse des échanges.

Le serveur se justifie car il y a des traitements ou du stockage.

Il arrive que le client et le serveur soient sur la même machine: un programme Java client qui dialogue avec un programme Python serveur.

CAS2: Des clients, un serveur, communication rare

Les clients se connectent un par un, font leur demande, reçoivent la réponse et se déconnectent. C’est à peine plus compliqué que le cas précédent.

La complexité est dans la nature, le volume et la vitesse des échanges.

Le serveur se justifie car il y a des traitements ou du stockage.

CAS3: Des clients, un serveur, communication lourde

Les clients se connectent tous, le serveur doit gérer des “threads”.

La complexité est dans la nature, le volume et la vitesse des échanges, mais aussi les délais de réponse, le parallelisme des threads, etc.

Le serveur se justifie car il y a des traitements ou du stockage.

CAS4: Des clients entre eux

Il n’y a pas besoin d’un serveur, sauf pour stocker les données échangées. Si les clients sont des mobiles, le projet est un client idéal pour une base de donnée dans le cloud nommée Firebase.

Un serveur n’est pas justifié car il n’y a pas de traitements lourds.

Situation du Serveur

Au début, le serveur est sur votre machine, dans la phase d’apprentissage.

Dès que vous avez besoin de vous connecter avec plusieurs clients, ou de stocker de l’info, vous devez dédier une machine comme serveur:

  • ça peut être la machine (portable ou tour) de l’un d’entre vous
  • ça peut être une VM fournie par INFRES
Quoi Pour Contre
Votre machine facile à gérer, accessible physiquement, OS de votre choix pas d’accès externe, change de numéro IP, doit être allumée et accessible aux autres
Une VM accessible depuis l’extérieur, accessible en permanence accès uniquement à distance en terminal, Linux, pas d’accès physique à la machine

Architecture du module

Cas A: Pas de serveur nécessaire

Dans ce cas, la meilleure solution est une base de donnée dans le cloud, FireBase, surtout si les clients sont des mobiles Android.

Le module devient alors un module mixte client-serveur + base de donnée.

Firebase fournit:

  • authentification
  • communication de beaucoup de types de données sur un lien internet
  • stockage dans le cloud
  • base de données orientée documents
  • échanges de message

Actions:

  • apprendre à se servir de FireBase
  • apprendre l’API FireBase d’Android
  • définir ce qui sera stocké dans la base de donnée partagée et son organisation
    • quel client a droit d’écrire quoi à quel moment

Cas A: attention !!

Firebase est utilisable facilement avec Android et tous les tutos sont faits pour Android. L’utilisation de Firebase suppose d’apprendre les bases du développement Android, ce qui est un gros coût:

  • installation et utilisation de Android Studio et des outils annexes comme gradle
  • compréhension des cycles de vie d’applications Android
  • utilisation du réseau et des permissions

J’insiste: ça peut être LOURD, parce que la différence entre ce que vous avez vu en INF103 et ce qui est dans Android est grande. En passant à Firebase, votre module devient un gros module, à cause de l’apprentissage correspondant. En même temps, vous allez acquérir une compétence réutilisable.

Par contre, il n’est pas utile d’apprendre le développement des interfaces graphiques ou l’utilisation des principaux composants d’un téléphone (caméra, accéléromêtre…)

Cas B: un serveur et une base de donnée

Si la base de donnée doit être d’un type incompatible avec Firebase, ramenez-vous au cas C avec une base de donnée à part.

S’il y a un serveur, par exemple pour faire des calculs trop lourds pour un mobile, alors vous pouvez considérer le serveur comme un “client” du cas A.

Que le serveur soit en python ou en Java, une API est disponible. Cette API étant prévue pour l’administration des bases Firebase, elle est plus complexe.

Le choix entre cas B et cas C peut être difficile. L’usage de Bluetooth oblige à passer au cas C.

Cas C: un vrai client-serveur

Sur chaque lien client-serveur, il faut un “protocole”.

  • Wifi (TCP-IP sur 802.11x): simple, à préférer
  • Bluetooth: plus complexe, parfois imposé par l’utilisation d’Arduino

Sur de tels liens, vous pouvez échanger des chaines ou des tableaux d’octets.

Sur cette base, vous pouvez construire votre protocole applicatif = liste de échanges au niveau de votre application.

Les questions à se poser:

  • échanges en texte ou en JSON ? JSON est une syntaxe pour décrire des objets dans une chaine de caractères
  • le serveur a-t-il une mémoire des messages précédents ou pas ? est-il un automate à états ?

Il faut prévoir du temps pour installer le programme serveur sur la machine virtuelle Linux fournie par INFRES pour faire tourner le serveur.

«packaging» des messages applicatifs vs définition du protocole

  • En général TCP sera le protocole de transport
    • (description très caricaturale) TCP permet le transfert de données de machine à machine d’une boite aux lettres à une autre
    • L’adresse IP identifie la machine,
    • le port la «boite aux lettres»
    • Opération classique: send (non bloquant), receive (mise en attente jusqu’à réception).
  • Ce qui peut changer et donner lieu à biblio: le protocole de transport (Bluetooth, protocole dédiés système embarqués …)
  • Protocoles applicatifs : Définir des messages spécialisés par rapport à leur fonction avec un format par exemple: (cmd, data) ou (dest, objref, method)
  • Utilité: vérifier la cohérence de l’échange entre application (si une commande est attendue et que d’autre arrivent => erreur).

En pratique, les options sont

  • Communication entre deux programmes Java tournant sur la même machine
    • Les options ci-dessus entre deux PC différents,
    • ou entre un appareil Androïd et un PC,
    • ou entre deux appareils Androïd
  • Les options ci-dessus avec des programmes écrits dans des langages différents
    • Java et C/C++
    • Java et Python
  • Les options ci-dessus avec plus de 2 entités communicantes
  • Les options ci-dessus avec une problématique «réseau» physique ou protocole de transport (ex: Internet/Wifi ou bluetooth)
    • Une communication simple commande/réponse en texte
    • Une communication plus complexe incluant aussi des transferts de ressources
    • Une communication à débit plus élevé nécessitant l’utilisation d’un format binaire
    • Une communication utilisant un protocol standard comme HTTP

Livrables

  1. Document: étude complète des échanges
    1. Nature (type des données)
    2. Fréquence
    3. Taille
    4. Contraintes (débit, utilisation d’un navigateur, …)
    5. Synchrone – asynchrone ?
    6. Liste exhaustive des commandes et réponses
  2. Code “simple”: Java réalisant une communication de messages entre deux nœuds (initialisation de l’interface, formatage et décodage de messages simples)
  3. Document: étude des bibliothèques à utiliser et des interfaces du client et du serveur pour les autres modules, description de la BDD (option), description du serveur (option)
  4. Option: Code client Android / Python / C++
  5. Code: final (référence Git)

Livrable 1

  • Document: étude complète des échanges
    1. Nature (type des données)
    2. Fréquence
    3. Taille
    4. Contraintes (débit, utilisation d’un navigateur, …)
    5. Synchrone – asynchrone ?
    6. Liste exhaustive des commandes et réponses
  • Plus vous avez d’informations, plus j’aurai l’impression que vous avez compris :D
  • Livrable = le document word ou pdf envoyé par email avec le titre PACT-XY-clientServeur-livrable1

Livrable 2

  • Cas 1: Code d’une appli minimale qui communique par Firebase
  • Cas 2: Faire le tutoriel Client Serveur
  • Livrable = le code et un log d’execution de l’option la plus pertinente pour votre projet, dans un zip, envoyé par email avec le titre PACT-XY-clientServeur-livrable2

Livrable 3

  • Interface de la partie serveur
  • Interface de la partie client
  • Question:
    • Connection permanente ?
    • Modification du code en conséquence
  • Extension pour clients multiples (option)
    • Une connection réutilisée ?
    • Autant de ports et de Thread que de clients ?
  • Bibliothèque à utiliser (option)
    • Protocole HTTP
  • Base de données (option)
    • Type et structure de la base
  • Serveur VM (option)
    • Description du serveur
  • Livrable = le document word ou pdf envoyé par email avec le titre PACT-XY-clientServeur-livrable3

Livrable 4

  • Pour android, demandez au binome android de vous faire une classe pour intégrer votre travail
  • Testez
  • Livrable = le code et un log d’execution, dans un zip, envoyé par email avec le titre PACT-XY-clientServeur-livrable4

Livrable 5

  • Code final
  • Dans le depot git du groupe

Evaluation

  • PACT Modules: fin janvier: livrables L1 à L3
  • PACT Valorisation: fin mai: livrables L4 et L5

Les problèmes classiques

  • Un parefeu sur votre machine interdit la connection depuis une autre machine
  • Le parefeu de l’école interdit d’entrer dans l’école depuis un mobile connecté en 4G (sauf VPN)
  • Le Wifi de l’école interdit les connections avec d’autres appareils en Wifi: seuls sont visibles les appareils à connexion filaire depuis un client connecté en WiFi.
  • Le numéro IP de votre serveur a changé
  • Votre programme refuse de démarrer parce qu’un autre programme utilise le même numéro de port (c’est sans doute un zombie de votre programme)

Questions

Une ressource nouvelle: connectez vous sur

https://moodle.r2.enst.fr/moodle/my/

et choisissez le module ExpPACT-TR