Quelques raccourcis :

Université de Sherbrooke – SCS

Ce qui suit concerne le cours INF756, Systèmes client/ serveur (SCS) et est offert en priorité au DGL, diplôme offert par l'Université de Sherbrooke. Vous pouvez venir y piger ce dont vous avez envie, tout en sachant que le cours évolue, que les outils évoluent, et qu'il faut lire et manipuler toute chose ci-dessous avec prudence.

Plan de cours

Consignes pour le projet de session

Survol du contenu des séances en classe

Date

Séance

Détail

24 août

S00

Au menu :

Dans les notes de cours, ce que nous avons fait touche aux pages suivantes :

  • SCS – Volume 00, du début à la fin
  • SCS – Volume 01, pp. 29-38

31 août.

S01

Au menu, cours à saveur technique, mais on ne parle pas de technique banale ici, ne vous en faites pas. Vous devriez trouver de quoi nourrir votre cerveau dans le cours de cette séance :

La multiprogrammation est une thématique qui transcende celles des systèmes répartis, mais il est difficile – voire impossible – de bien réaliser un serveur dynamique pour plusieurs clients sans rendre ce serveur capable de faire plusieurs choses à la fois, du moins si on se limite à une approche synchrone au sens faible (ou, plus typiquement, bloquante) pour le volet communication.

Dans les notes de cours, ce que nous avons fait touche aux pages suivantes :

  • SCS – Volume 01, pp. 31-40 (exemple non-portable de programme multiprogrammé)
  • SCS – Volume 01, pp. 46-74 (bases sur les outils de synchronisation)
  • SCS – Volume 01, appendice 08 (portabilité et approche RAII)
  • SCS – Volume 01, pp. 17-28

7 sept.

S02

Au menu :

  • Q00
  • Bases appliquées sur les sockets, code et tests à l'appui
  • Survol du marshalling et de ses contraintes (ce qui peut circuler sur un lien réseau)
  • Bref regard sur le transfert de structures de grande taille (p. ex. : un fichier texte, un fichier binaire)
  • Exemples concrets avec sockets bloquants
  • Discussion du fonctionnement des sockets non-bloquants et de leur utilité (ou non)
  • Suites sur les bases de multiprogrammation avec des applications efficaces de la synchronisation : illustration par une zone de transit
  • Quelques considérations protocolaires
  • Objets qualifiés volatile (sujet controversé!)
  • Discussion du fonctionnement des sockets non-bloquants et de leur utilité (ou non)

Dans les notes de cours, ce que nous avons fait touche aux pages suivantes :

  • SCS – Volume 02, pp. 6-39

14 sep.

S03

Pas de cours cette semaine; je serai hors du pays pour donner des cours et une conférence à CppCon. Pour suivre mes péripéties : ../../Sujets/Orthogonal/cppcon2022.html

21 sept.

S04

Au menu :

  • Q01
  • Début d'un survol de l'approche par composants
  • Premiers pas avec l'approche par composants

Avec cette première approche, nous entreprenons la couverture, avec code natif (en C++) à la fois du côté client et du côté serveur, la mise en place d'un SCS complet réalisant une tâche banale. Nous utilisons pour cette fin un serveur à contexte interne.

Les sources des exemples sont disponibles ici

28 sept.

S05

Au menu :

  • Q02
  • Refactorisation de la version reposant sur un serveur à contexte interne
  • Approche reposant sur un serveur à contexte externe. Les sources des exemples sont disponibles ici
  • Trucs périphériques (quoique...), dont nous discuterons si le temps le permet :
    • Petit détour pour expliquer le faux partage et l'impact des variables globales sur la vitesse des programmes (exprimé autrement : l'impact de la Cache)
    • Mention brève de considérations de taille et d'alignement
    • Coup d'oeil rapide sur les objets autonomes (et retour sur std::thread)

5  oct.

S06

Au menu :

12 oct.

S07

Au menu :

19 oct.

S08

Au menu :

  • Q05
  • Excursions dans d'autres langages :
    • Quelques exemples avec le langage Go
    • Quelques exemples avec le langage Erlang
  • On bavarde sécurité, à partir d'un fait vécu
    • J'ai fait des diapos pour vous. En espérant que ce soit utile : Survol_OAuth.pdf

26 oct.

S09

Au menu :

  • Q06
  • Q07
  • Récapitulatif des principes de base des systèmes client / serveur sur le plan de la communication (perspective historique) :
    • Pourquoi des systèmes répartis?
    • Sens des mots « client » et « serveur »
      • Général et historique
      • Contemporain, en particulier dans une optique REST
      • Gains et pertes de cette évolution
    • De protocoles, de fonctions et de services
      • Époque des sockets bruts
      • Avènement du modèle RPC
      • Passage aux composants et rôle des intergiciels
      • De protocoles binaires aux protocoles Web basés XML : pourquoi?
      • De XML à JSON : pourquoi?
      • De RPC et REST : pourquoi?
    • Ce qui peut circuler entre les homologues
    • Découvrabilité : localiser l'homologue (typiquement, le serveur)
      • Services de repérage et de découverte
      • Bottins UDDI
      • ... Google!
    • Identifier et décrire les services offerts
    • Gestion de la durée de vie
      • Gestion collaborative
      • Gestion par péremption (et mécènes)
      • Singletons
    • Gestion des pannes
      • Éviter de planter
      • Accepter de planter
      • Être remplaçable et être sans états (Stateless)
    • Échelonnabilité
      • Que faire quand la charge augmente?
  • Modèles architecturaux et interopérabilité (détails à venir), en particulier le style architectural REST (suite)
  • L'approche SOA, qui n'est pas équivalente (du tout!) à SOAP
    • Distinguer la publicité de la réalité
    • Choix des types et définition des services
    • Relation (ou pas) avec REST
  • Bref sur le théorème CAP que l'on doit à Eric Allen Brewer

L'idée du théorème CAP (qui n'est pas vraiment un théorème, pas plus que la loi de Moore n'est une loi) est que dans un système réparti, vous ne pouvez pas avoir à la fois les trois propriétés suivante... mais vous pourrez en avoir deux des trois :

  • La cohérence (C, Consistency), au sens où tous les composants voient les mêmes données en même temps
    • Plus précisément, dans le contexte de CAP, la cohérence signifie que lorsqu'une entité lit l'état d'un objet, il y a deux possibilités : (a) elle voit la valeur de la plus récente écriture, ou (b) elle constate une erreur
  • La disponibilité (A, Availability), au sens où toutes les requêtes auront une réponse, qu'elles aient réussi ou échoué
    • Plus précisément, dans le contexte de CAP, la disponibilité signifie que chaque requête pour l'état d'un objet recevra une réponse qui ne sera pas une erreur dû à une indisponibilité de la donnée, mais il se peut que la valeur obtenue ne soit pas celle de la plus récente écriture sur cet objet
  • La tolérance envers la perte de sections du système (P, Partition Tolerance), au sens où le système continuera de fonctionner même si un de ses sous-systèmes tombe en panne
    • Plus précisément, dans le contexte de CAP, cette tolérance signifie que le système poursuivra son exécution même si un nombre arbitrairement grand de messages sont perdus (ou arrivent en retard) sur le réseau entre les noeuds du système

Ce « théorème » parle en fait de ce qui se passe dans un système quand les erreurs surviennent sur le réseau. En pratique, deux options se présentent pour compenser ces erreurs :

  • Annuler l'opération en cours, ce qui réduit A mais accroît C, ou encore
  • Poursuivre l'opération en cours, ce qui réduit C mais accroît A

Cela signifie que CAP ne présente pas vraiment toujours un « choisissez deux options parmi ces trois options » en pratique, car pour plusieurs systèmes la partie P de l'équation est stable et les erreurs sur le réseau sont rares. Par contre, si le réseau se fragilise et si le système doit compenser (partie P de l'équation), alors il faut typiquement choisir de sacrifier soit C, soit A

Pour plus d'informations, voir ../../Liens/Client-Serveur--Liens.html#theoreme_cap

  • Bref sur NoSQL
    • L'approche NoSQL est en quelque sort une actualisation du théorème CAP, qui vise souvent (au mieux) la cohérence éventuelle
    • Ainsi, dans la plupart des cas, une base de données NoSQL fera le choix de privilégier A par rapport à C quand le maintien de P le demande
  • Systèmes stratifés et concept de tiers

Puisque ce fut une session un peu inhabituelle sur le plan du rythme (on va vite quand on est un petit groupe!), je me permettrai peut-être un petit quelque chose d'inhabituel ce soir. J'espère que vous apprécierez!

2 nov.

S10

Au menu, parce qu'on est un peu en avance sur le temps habituel (petit groupe de gens brillants, c'est votre faute! 🙂) :

  • Survol de ce que sont les Blockchains
    • La position de Nakamoto est autant idéologique que technique
    • Sur le plan technique, il y a des raisons pour avoir recours à des algorithmes à base d'orchestration, tout comme il y a des raisons d'avoir recours à des algorithmes à base de chorégraphie
  • La mémoire transactionnelle (versions matérielle et logicielle)
  • Réaliser des acteurs (comme le fait Erlang)
  • Brin de programmation fonctionnelle réactive (Functional Reactive Programming)
  • Objets autonomes (et bêtise historique)

9 nov.

S11

Au menu :

  • Présentation d'un chic conférencier, Jean-Philippe Paquette. La rencontre se fera par Teams, et un lien en ce sens sera placé sur le site Moodle du cours. Le synopsis de sa présentation va comme suit :

L'univers du mobile et les médias

« Depuis plus de dix ans maintenant, la mobilité a fait partie intégrante de la stratégie des médias pour diffuser et monétiser leur contenu. Lors de cette présentation, nous discuterons donc des outils et des systèmes utilisés, passés et futurs, par certains médias du Québec afin d'atteindre leurs buts dans un écosystème ultra compétitif. »

 

16 nov.

S12

Au menu :

  • Nous aurons le plaisir d'accueillir Jean-François Pezet, qui oeuvre aux caisses Desjardins, en particulier dans la gestion du cycle de vie des services. La rencontre se fera par (Zoom? Teams?), et un lien en ce sens sera placé sur le site Moodle du cours.

Gestion des services dans une organisation en évolution

« Les technologies évoluent rapidement, tout comme les organisations. Comment gérer l'intégration de nouveaux systèmes avec le moins d'impact possible sur les systèmes existants et sur les opérations de tous les jours? Comment faire face aux besoins d'aujourd'hui et tenter d'anticiper ceux de demain en maximisant les investissements technologiques? Comment gérer l'utilisation des systèmes en place pendant ces changements?

La présentation se veut une réflexion sur l'évolution des systèmes informatiques pendant une période de croissance ou de changement d'une entreprise. »

 

23 nov.

S13

Au menu :

  • Votre présentation du fruit de vos labeurs tout au long de la session
    • Comptera à la fois comme Q08 et comme une démonstration de L02 (il ne vous restera qu'à remettre la documentation)

30 nov.

S14

Chic examen plein d'amour.

Sources des programmes dans les notes de cours

Plusieurs sources et exemples sont disponibles dans la section du site prévue à cet effet. Portez particulièrement attention aux éléments suivants.

Sources pour les projets par sockets

Vous trouverez ici les sources du projet ClientTresSimple

Vous trouverez ici les sources du projet ServeurTresSimple

Vous trouverez ici les sources du projet ClientTresSimpleOO

Vous trouverez ici les sources du projet ServeurTresSimpleOO

Vous trouverez ici les sources du projet SocketFluxLib

Vous trouverez ici les sources du projet SocketFluxClient

Vous trouverez ici les sources du projet SocketFluxServeur

Sources pour les projets par composants

Exemple simple de SCS par composants avec C++ dans le modèle COM (projet construit pour Visual Studio 2017 avec C++ 17) :

  • Client console
  • Interface IDL
  • Serveur à contexte interne

Refactorisation de l'exemple simple de SCS par composants avec C++ dans le modèle COM (projet construit pour Visual Studio 2017 avec C++ 17) :

  • Client console
  • Interface IDL
  • Assemblage par implémentations partielles
  • Pointeurs intelligents
  • Serveur à contexte interne

Exemple simple de SCS par composants avec C++ dans le modèle COM (projet construit pour Visual Studio 2015 avec C++ 14) :

  • Client console
  • Interface IDL
  • Bibliothèque de marshalling
  • Serveur à contexte externe

Exemple simple de SCS par composants avec client .NET en C# et serveur C++ ISO mêlant les modèles COM et .NET (projet construit pour Visual Studio 2008) :

  • Client console
  • Interface IDL
  • Bibliothèque de types
  • Coclasse
  • Bibliothèque de marshalling
  • Serveur à contexte externe

Pour que le client .NET puisse accéder aux services COM simplement, il est d'usage de générer une bibliothèque de types (une .TLB) à partir de la description IDL des interfaces, puis d'intégrer cette .TLB à .NET à l'aide du programme tlbimp.exe, typiquement invoqué à la ligne de commande et sur lequel vous trouverez de la documentation en ligne.

Exemple simple de SCS par composants avec client C++ ISO et serveur .NET en C# (projets construits pour Visual Studio 2008) :

  • client console
  • bibliothèque de types générée à partir du code .NET
  • importation (directive non portable #import) de la bibliothèque de types
  • serveur à contexte interne (mais chargé par le CLR de .NET, donc en pratique le contexte est externe).

Pour que le client COM puisse accéder aux services du serveur .NET simplement, il est d'usage de procéder ainsi :

  • Dans le code C#, déclarer une interface publique exposant la signature des services à offrir, puis en dériver une classe qui jouera le rôle du serveur et qui implémentera ces services
  • Ajouter une clause using pour System.Runtime.InteropServices
  • Apposer une annotation (ce que les gens de .NET nomment des attributes) à l'interface pour qu'elle se conforme à IUnknown
  • Apposer une annotation au serveur pour qu'il soit identifié par un GUID (ce qui constituera la coclasse du point de vue du code client)
  • Dans le fichier AssemblyInfo.cs, indiquer true pour l'annotation ComVisible;
  • Signer l'assemblage (soit en utilisant sn.exe à la ligne de commande, soit en passant par les propriétés du projet)
  • À la ligne de commande (utilisez la console de Visual Studio si vous voulez éviter de définir plusieurs variables d'environnement), extraire une .TLB de l'assemblage .NET en utilisant le programme tlbexp.exe, puis publier l'assemblage .NET avec gacutil.exe et publier la correspondance entre l'assemblage .NET et la .TLB avec regasm.exe (voir la documentation en ligne pour plus de détails)

Pour le code C++, le code source devrait suffire. Retenez peut-être qu'importer une .TLB avec #import provoque la génération de deux fichiers de code C++ (un .TLH et un .TLI), fichiers décrivant l'interface en termes du code client. Si vous avez des bogues, examinez le contenu de ces fichiers!

Nous avons aussi vu un exemple de client C++ pour serveur .NET en intégrant le chargement du CLR de .NET lors du lancement du programme C++, et en ajoutant au projet C++ des références sur les assemblages .NET souhaités. Cette approche repose sur le template gcroot de <vcclr.h>.

Exemple de mise en application de l'approche Map/ Reduce, avec programmation par promesses (mieux connu sous le nom de futures), délégués et Thread Pooling (en C++ ISO, projet Visual Studio 2008).

Articles sur des sujets connexes

Cliquez sur cette cible pour aller au document portant sur les classes imbriquées

Cliquez sur cette cible pour aller au document portant sur les templates

Cliquez sur cette cible pour aller au document portant sur les singletons

Cliquez sur cette cible pour aller au document portant sur les mutex portables

Cliquez sur cette cible pour aller au document portant sur les autoverrous

Cliquez sur cette cible pour aller au document portant sur les objets autonomes

Cliquez sur cette cible pour aller au document portant sur les méthodes volatiles

Vous trouverez ici un petit document expliquant comment déboguer un contexte externe COM (un exécutable dans lequel résident des composants COM).

Inspirations du passé lointain (pour vous inspirer...)

Dans le passé, le cours INF756 portait le sigle IFT756, et les programmes tels que le DTI (avant même l'existence du DGL) fonctionnaient sous le principe des cohortes, des groupes de gens qui tendaient à se suivre essentiellement du début à la fin de leur formation, comme une famille. Certains de vos prédécesseurs vous ont légué des cadeaux (merci à eux!). Je vous ai aussi laissé ici, à titre d'exemple de format d'examen seulement (car le contenu du cours – et des examens – change chaque session, donc ces exemples sont désuets sur le plan du contenu), quelques exemples de vieux examens. Peut-être sauront-ils vous inspirer?

Vous trouverez ici l'examen final des cohortes 01 et 02 pour IFT756

Vous trouverez ici l'examen final de la cohorte 03 pour IFT756



Valid XHTML 1.0 Transitional

CSS Valide !