Td corrigé l'architecture des reseaux tcp/ip - Free pdf

l'architecture des reseaux tcp/ip - Free

Pour corriger les erreurs de transmissions, plusieurs techniques de protection sont utilisées. .... de manipulation de données : par exemple syntaxique ou sémantique. ...... L'idée des réseaux à relais de trame (frame relay) est d'intégrer des ...




part of the document



x de conception des couches  RENVOIPAGE _Toc11843885 \h 23
1.2.2 Fonctions de transport et de traitement  RENVOIPAGE _Toc11843886 \h 24
1.2.3 Couche physique  RENVOIPAGE _Toc11843887 \h 24
1.2.4 Couche liaison  RENVOIPAGE _Toc11843888 \h 24
1.2.5 Couche réseau  RENVOIPAGE _Toc11843889 \h 25
1.2.6 Couche transport  RENVOIPAGE _Toc11843890 \h 26
1.2.7 Couches hautes  RENVOIPAGE _Toc11843891 \h 28
1.2.8 Encapsulation des données  RENVOIPAGE _Toc11843892 \h 30
1.3 Modèle serveur-client  RENVOIPAGE _Toc11843893 \h 30
1.3.1 Le problème des accès concurrents  RENVOIPAGE _Toc11843894 \h 31
1.3.2 Le modèle des lecteurs et des rédacteurs  RENVOIPAGE _Toc11843895 \h 32
1.3.3 Méthodes de verrouillage d'accès  RENVOIPAGE _Toc11843896 \h 33
2. Réseaux locaux  RENVOIPAGE _Toc11843897 \h 34
2.1 Généralités sur les réseaux locaux  RENVOIPAGE _Toc11843898 \h 34
2.1.1 Généralités  RENVOIPAGE _Toc11843899 \h 34
2.1.2 Services rendus par les réseaux locaux  RENVOIPAGE _Toc11843900 \h 35
2.1.3 Classification des réseaux locaux  RENVOIPAGE _Toc11843901 \h 36
Topologie des réseaux locaux  RENVOIPAGE _Toc11843902 \h 37
2.1.4 Réseaux en étoile  RENVOIPAGE _Toc11843903 \h 37
2.1.5 Réseaux en boucle : le réseau Token Ring  RENVOIPAGE _Toc11843904 \h 37
2.1.6 Réseaux en bus : le réseau Ethernet à 10 Mbits/s  RENVOIPAGE _Toc11843905 \h 40
2.2 Premiers réseaux de PC  RENVOIPAGE _Toc11843906 \h 43
2.3 Contraintes d'exploitation des réseaux locaux  RENVOIPAGE _Toc11843907 \h 43
2.4 Normalisation des réseaux locaux  RENVOIPAGE _Toc11843908 \h 44
2.5 Installation d'un réseau local  RENVOIPAGE _Toc11843909 \h 45
2.6 Interconnexions de réseaux locaux aux niveaux 1 et 2  RENVOIPAGE _Toc11843910 \h 45
2.6.1 Nom, adresse, route  RENVOIPAGE _Toc11843911 \h 45
2.6.2 Répéteurs  RENVOIPAGE _Toc11843912 \h 46
2.6.3 Ponts  RENVOIPAGE _Toc11843913 \h 47
2.7 Interconnexion de réseaux distants  RENVOIPAGE _Toc11843914 \h 50
2.7.1 Généralités sur les Wan  RENVOIPAGE _Toc11843915 \h 50
2.7.2 Techniques de commutation  RENVOIPAGE _Toc11843916 \h 50
2.7.3 X25 et le réseau Transpac  RENVOIPAGE _Toc11843917 \h 52
2.7.4 Le RNIS  RENVOIPAGE _Toc11843918 \h 52
2.7.5 ATM  RENVOIPAGE _Toc11843919 \h 54
2.7.6 Le relais de trames  RENVOIPAGE _Toc11843920 \h 55
2.8 Conclusions sur les réseaux locaux  RENVOIPAGE _Toc11843921 \h 56
2.9 Bibliographie du présent chapitre  RENVOIPAGE _Toc11843922 \h 56
3. SERVICES RESEAUX traditionnels dans le monde TCP/IP  RENVOIPAGE _Toc11843923 \h 57
3.1 Historique  RENVOIPAGE _Toc11843924 \h 57
3.2 Présentation des services traditionnels  RENVOIPAGE _Toc11843925 \h 57
3.2.1 Services de la DARPA  RENVOIPAGE _Toc11843926 \h 57
3.2.2 Services BSD (Berkeley)  RENVOIPAGE _Toc11843927 \h 60
3.2.3 Services répartis et distribués  RENVOIPAGE _Toc11843928 \h 60
3.2.4 Services traditionnels basés sur des protocoles de communication asynchrones  RENVOIPAGE _Toc11843929 \h 62
3.2.5 Autres services Berkeley  RENVOIPAGE _Toc11843930 \h 62
3.2.6 Service de noms  RENVOIPAGE _Toc11843931 \h 63
3.2.7 Autres services réseau  RENVOIPAGE _Toc11843932 \h 63
3.2.8 Contraintes de sécurité  RENVOIPAGE _Toc11843933 \h 64
3.3 Le réseau Internet  RENVOIPAGE _Toc11843934 \h 65
3.3.1 Historique et architecture  RENVOIPAGE _Toc11843935 \h 65
3.3.2 Philosophie de l'Internet  RENVOIPAGE _Toc11843936 \h 65
3.3.3 Les services disponibles  RENVOIPAGE _Toc11843937 \h 65
3.3.4 World Wide Web  RENVOIPAGE _Toc11843938 \h 66
3.3.5 Le service des news  RENVOIPAGE _Toc11843939 \h 67
3.4 Commandes usuelles  RENVOIPAGE _Toc11843940 \h 68
3.4.1 Notions sur la Base de données réseau  RENVOIPAGE _Toc11843941 \h 68
3.4.2 Services DARPA (ftp-telnet/ssh)  RENVOIPAGE _Toc11843942 \h 69
3.4.3 Services BSD (r-commandes)  RENVOIPAGE _Toc11843943 \h 71
3.4.4 Impression distante  RENVOIPAGE _Toc11843944 \h 72
3.5 Communication entre utilisateurs  RENVOIPAGE _Toc11843945 \h 73
3.5.1 Validation de la réception de messages  RENVOIPAGE _Toc11843946 \h 73
3.5.2 Dialogue interractif  RENVOIPAGE _Toc11843947 \h 73
3.6 Messagerie  RENVOIPAGE _Toc11843948 \h 74
3.6.1 Graphe de fonctionnement de la messagerie  RENVOIPAGE _Toc11843949 \h 75
3.6.2 Convention d'adressage et types de stations  RENVOIPAGE _Toc11843950 \h 75
3.6.3 Agents utilisateurs  RENVOIPAGE _Toc11843951 \h 76
3.6.4 Fichiers de configuration de la messagerie électronique  RENVOIPAGE _Toc11843952 \h 78
3.7 Services répartis et distribués  RENVOIPAGE _Toc11843953 \h 80
3.7.1 NFS  RENVOIPAGE _Toc11843954 \h 80
3.7.2 NIS  RENVOIPAGE _Toc11843955 \h 81
3.7.3 Informations générales sur l'état du réseau  RENVOIPAGE _Toc11843956 \h 82
3.8 L'interface graphique XWindow  RENVOIPAGE _Toc11843957 \h 83
3.8.1 Généralités sur XWindow  RENVOIPAGE _Toc11843958 \h 83
3.8.2 Historique  RENVOIPAGE _Toc11843959 \h 83
3.8.3 Architecture de XWindow  RENVOIPAGE _Toc11843960 \h 84
3.8.4 L'interface homme-machine (IHM)  RENVOIPAGE _Toc11843961 \h 84
3.8.5 Les boites à outils  RENVOIPAGE _Toc11843962 \h 85
3.8.6 La bibliothèque Xlib  RENVOIPAGE _Toc11843963 \h 85
3.8.7 Les applications X  RENVOIPAGE _Toc11843964 \h 85
3.8.8 Les gestionnaires de fenêtres  RENVOIPAGE _Toc11843965 \h 87
3.8.9 Lancement de X11  RENVOIPAGE _Toc11843966 \h 88
3.9 Réseaux bureautiques  RENVOIPAGE _Toc11843967 \h 88
3.9.1 Connexion PCTCP/IP  RENVOIPAGE _Toc11843968 \h 88
3.9.2 Le monde McIntosh  RENVOIPAGE _Toc11843969 \h 89
3.9.3 L'architecture Novell  RENVOIPAGE _Toc11843970 \h 89
3.10 L'architecture client-serveur et les bases de données  RENVOIPAGE _Toc11843971 \h 90
3.10.1 Historique  RENVOIPAGE _Toc11843972 \h 90
3.10.2 Serveur  RENVOIPAGE _Toc11843973 \h 91
3.10.3 Normes  RENVOIPAGE _Toc11843974 \h 91
3.10.4 Le moteur  RENVOIPAGE _Toc11843975 \h 91
3.10.5 Les SGBDOO  RENVOIPAGE _Toc11843976 \h 92
3.10.6 Les clients  RENVOIPAGE _Toc11843977 \h 92
3.10.7 DCE  RENVOIPAGE _Toc11843978 \h 93
3.10.8 Tuxedo  RENVOIPAGE _Toc11843979 \h 93
3.10.9 Encina  RENVOIPAGE _Toc11843980 \h 94
3.10.10 Conclusions  RENVOIPAGE _Toc11843981 \h 95
3.11 Graphe récapitulatif des services réseaux  RENVOIPAGE _Toc11843982 \h 96
3.12 Etudes de cas  RENVOIPAGE _Toc11843983 \h 96
3.12.1 Réseaux  RENVOIPAGE _Toc11843984 \h 96
3.12.2 Services  RENVOIPAGE _Toc11843985 \h 97
3.13 Exercices  RENVOIPAGE _Toc11843986 \h 97
3.13.1 Services DARPA-BSD  RENVOIPAGE _Toc11843987 \h 97
3.13.2 Outils de communication divers  RENVOIPAGE _Toc11843988 \h 98
3.13.3 Exercices sur l'utilisation de XWindow  RENVOIPAGE _Toc11843989 \h 99
3.14 Bibliographie du présent chapitre  RENVOIPAGE _Toc11843990 \h 99
4. L'architecture du système de communication TCP/IP dans le monde Unix  RENVOIPAGE _Toc11843991 \h 101
4.1 Le système de communications BSD  RENVOIPAGE _Toc11843992 \h 101
4.2 évolutions système V  RENVOIPAGE _Toc11843993 \h 101
4.3 Architecture du système de communications BSD  RENVOIPAGE _Toc11843994 \h 102
4.4 La Couche socket et ses API  RENVOIPAGE _Toc11843995 \h 103
4.4.1 Définition d'un socket  RENVOIPAGE _Toc11843996 \h 103
4.4.2 Type, domaines de communication et famille de protocoles  RENVOIPAGE _Toc11843997 \h 103
4.4.3 Création  RENVOIPAGE _Toc11843998 \h 105
4.4.4 Dialogue en mode connecté  RENVOIPAGE _Toc11843999 \h 105
4.4.5 Dialogue en mode non connecté  RENVOIPAGE _Toc11844000 \h 106
4.4.6 Graphe d'état d'un socket  RENVOIPAGE _Toc11844001 \h 107
4.5 Implémentation SYSTEM V  RENVOIPAGE _Toc11844002 \h 107
4.5.1 Généralités sur les streams  RENVOIPAGE _Toc11844003 \h 107
4.5.2 Streams et flots  RENVOIPAGE _Toc11844004 \h 108
4.5.3 Modules  RENVOIPAGE _Toc11844005 \h 109
4.5.4 Message  RENVOIPAGE _Toc11844006 \h 110
4.5.5 Services d'un module  RENVOIPAGE _Toc11844007 \h 111
4.5.6 Appels système  RENVOIPAGE _Toc11844008 \h 111
4.5.7 Ordonnancement  RENVOIPAGE _Toc11844009 \h 112
4.5.8 Multiplexage de modules  RENVOIPAGE _Toc11844010 \h 113
4.5.9 Fichiers de configuration  RENVOIPAGE _Toc11844011 \h 114
4.5.10 Flots et API  RENVOIPAGE _Toc11844012 \h 114
4.6 Implémentation BSD  RENVOIPAGE _Toc11844013 \h 115
4.6.1 Structures mbuf  RENVOIPAGE _Toc11844014 \h 115
4.6.2 Cluster  RENVOIPAGE _Toc11844015 \h 115
4.6.3 Tampons d'émission et de réception  RENVOIPAGE _Toc11844016 \h 116
4.6.4 Interface socket protocoles  RENVOIPAGE _Toc11844017 \h 116
4.6.5 Structure ifnet  RENVOIPAGE _Toc11844018 \h 116
4.6.6 Traitement d'une trame Ethernet  RENVOIPAGE _Toc11844019 \h 117
4.7 Bibliographie du présent chapitre  RENVOIPAGE _Toc11844020 \h 118
5. La famille des pROTOCOLES tcp/ip  RENVOIPAGE _Toc11844021 \h 119
5.1 Introduction  RENVOIPAGE _Toc11844022 \h 119
5.2 Protocoles de niveau réseau IP et ICMP  RENVOIPAGE _Toc11844023 \h 119
5.2.1 Le protocole IP  RENVOIPAGE _Toc11844024 \h 119
5.2.2 L'adresse IP  RENVOIPAGE _Toc11844025 \h 122
5.2.3 Le protocole ICMP  RENVOIPAGE _Toc11844026 \h 124
5.3 Principes de base du routage IP  RENVOIPAGE _Toc11844027 \h 125
5.3.1 Routage Ethernet  RENVOIPAGE _Toc11844028 \h 125
5.3.2 Routage Internet  RENVOIPAGE _Toc11844029 \h 125
5.3.3 Protocoles de résolution d'adresse  RENVOIPAGE _Toc11844030 \h 126
5.3.4 Routeurs  RENVOIPAGE _Toc11844031 \h 127
5.3.5 Routage statique et routage dynamique  RENVOIPAGE _Toc11844032 \h 127
5.3.6 Routage direct ou indirect  RENVOIPAGE _Toc11844033 \h 127
5.3.7 Sous réseau  RENVOIPAGE _Toc11844034 \h 129
5.4 Protocoles de routage  RENVOIPAGE _Toc11844035 \h 130
5.4.1 Généralités  RENVOIPAGE _Toc11844036 \h 130
5.4.2 Système autonome  RENVOIPAGE _Toc11844037 \h 130
5.4.3 Les protocoles IGP et EGP  RENVOIPAGE _Toc11844038 \h 131
5.5 Protocoles de routage IGP de type vecteur de distance  RENVOIPAGE _Toc11844039 \h 131
5.5.1 Définition  RENVOIPAGE _Toc11844040 \h 131
5.5.2 Le protocole RIP  RENVOIPAGE _Toc11844041 \h 132
5.5.3 Le protocole IGRP  RENVOIPAGE _Toc11844042 \h 134
5.6 Protocoles de routage IGP de type SPF  RENVOIPAGE _Toc11844043 \h 134
5.6.1 Le protocole OSPF  RENVOIPAGE _Toc11844044 \h 134
5.6.2 Le protocole HELLO  RENVOIPAGE _Toc11844045 \h 135
5.6.3 Implémentation des différents protocoles  RENVOIPAGE _Toc11844046 \h 135
5.6.4 Passerelles IP et X25  RENVOIPAGE _Toc11844047 \h 135
5.7 Evolutions de l'adresse IP  RENVOIPAGE _Toc11844048 \h 136
5.8 Le protocole DHCP  RENVOIPAGE _Toc11844049 \h 137
5.9 Protocoles de Transport  RENVOIPAGE _Toc11844050 \h 138
5.9.1 Le protocole UDP  RENVOIPAGE _Toc11844051 \h 138
5.9.2 Le protocole TCP  RENVOIPAGE _Toc11844052 \h 139
5.10 protocole SNMP d'administration de réseau  RENVOIPAGE _Toc11844053 \h 144
5.10.1 Généralités sur l'administration de réseau  RENVOIPAGE _Toc11844054 \h 144
5.10.2 Origines  RENVOIPAGE _Toc11844055 \h 145
5.10.3 Serveurs et clients SNMP  RENVOIPAGE _Toc11844056 \h 146
5.10.4 Structure des objets de la MIB  RENVOIPAGE _Toc11844057 \h 147
5.10.5 Accès et statut  RENVOIPAGE _Toc11844058 \h 148
5.10.6 Protocole de transport utilisé par SNMP  RENVOIPAGE _Toc11844059 \h 148
5.10.7 Primitives du protocole SNMP  RENVOIPAGE _Toc11844060 \h 149
5.10.8 Communauté et authentification  RENVOIPAGE _Toc11844061 \h 150
5.10.9 Autorisation  RENVOIPAGE _Toc11844062 \h 150
5.11 Protocoles de niveau de niveau session et présentation  RENVOIPAGE _Toc11844063 \h 151
5.11.1 Le protocole de niveau session RPC  RENVOIPAGE _Toc11844064 \h 151
5.11.2 Le protocole de niveau présentation XDR  RENVOIPAGE _Toc11844065 \h 153
5.12 Le protocole Samba  RENVOIPAGE _Toc11844066 \h 156
5.12.1 Rappels sur le protocole netbios et les api netbeui  RENVOIPAGE _Toc11844067 \h 156
5.12.2 Les blocs de messages de serveur (SMB)  RENVOIPAGE _Toc11844068 \h 156
5.12.3 Limites de l'architecture netbiosnetbeuismb  RENVOIPAGE _Toc11844069 \h 157
5.12.4 Présentation de Samba  RENVOIPAGE _Toc11844070 \h 157
5.12.5 Installation  RENVOIPAGE _Toc11844071 \h 157
5.13 Bibliographie du présent chapitre  RENVOIPAGE _Toc11844072 \h 158
5.14 Exercices  RENVOIPAGE _Toc11844073 \h 158
5.14.1 Adressage IP et protocoles associés  RENVOIPAGE _Toc11844074 \h 158
5.14.2 Routage  RENVOIPAGE _Toc11844075 \h 159
5.14.3 Protocoles de transport  RENVOIPAGE _Toc11844076 \h 160
5.14.4 Protocoles de haut niveau  RENVOIPAGE _Toc11844077 \h 160
5.14.5 Protocoles d'administration de réseau  RENVOIPAGE _Toc11844078 \h 161
6. MISE EN OEUVRE des SERVICES  RENVOIPAGE _Toc11844079 \h 162
6.1 La base de données réseau  RENVOIPAGE _Toc11844080 \h 162
6.1.1 Généralités  RENVOIPAGE _Toc11844081 \h 162
6.1.2 Le fichier hosts  RENVOIPAGE _Toc11844082 \h 162
6.1.3 Le fichier networks  RENVOIPAGE _Toc11844083 \h 163
6.1.4 Le fichier hosts.equiv  RENVOIPAGE _Toc11844084 \h 163
6.1.5 Le fichier ethers  RENVOIPAGE _Toc11844085 \h 164
6.1.6 Le fichier protocols  RENVOIPAGE _Toc11844086 \h 164
6.1.7 Le processus démon serveur inetd  RENVOIPAGE _Toc11844087 \h 164
6.1.8 Le fichier des services clients services  RENVOIPAGE _Toc11844088 \h 165
6.1.9 Le fichier netcroup  RENVOIPAGE _Toc11844089 \h 166
6.1.10 Procédures associées à la base de données réseau.  RENVOIPAGE _Toc11844090 \h 166
6.2 Services DARPA et Berkeley  RENVOIPAGE _Toc11844091 \h 167
6.3 NFS  RENVOIPAGE _Toc11844092 \h 168
6.3.1 Protocoles RPC et XDR  RENVOIPAGE _Toc11844093 \h 168
6.3.2 Mise en place des services NFS  RENVOIPAGE _Toc11844094 \h 168
6.3.3 La commande mount  RENVOIPAGE _Toc11844095 \h 169
6.3.4 Mise à jour du fichier exports  RENVOIPAGE _Toc11844096 \h 171
6.3.5 Un problème lié à NFS  RENVOIPAGE _Toc11844097 \h 171
6.4 NIS  RENVOIPAGE _Toc11844098 \h 171
6.4.1 Domaine  RENVOIPAGE _Toc11844099 \h 171
6.4.2 Serveur maître et serveur esclave  RENVOIPAGE _Toc11844100 \h 172
6.4.3 Mise à jour d'une liste  RENVOIPAGE _Toc11844101 \h 172
6.4.4 Fichiers de constitution des listes  RENVOIPAGE _Toc11844102 \h 173
6.4.5 Commandes d'administration associées  RENVOIPAGE _Toc11844103 \h 174
6.4.6 Problèmes de sécurité  RENVOIPAGE _Toc11844104 \h 174
6.4.7 Groupes de stations  RENVOIPAGE _Toc11844105 \h 175
6.5 Service d'impression distante SYSTEM V  RENVOIPAGE _Toc11844106 \h 176
6.5.1 Lancement de l'exécution d'une impression distante  RENVOIPAGE _Toc11844107 \h 176
6.5.2 Généralités sur le service RLP  RENVOIPAGE _Toc11844108 \h 176
6.5.3 Fonctionnement du service RLP  RENVOIPAGE _Toc11844109 \h 177
6.5.4 Service d'impression distante sous BSD  RENVOIPAGE _Toc11844110 \h 178
6.6 Messagerie  RENVOIPAGE _Toc11844111 \h 178
6.6.1 Architecture générale du système de messagerie  RENVOIPAGE _Toc11844112 \h 179
6.6.2 Agents de transport  RENVOIPAGE _Toc11844113 \h 179
6.6.3 Le processus démon sendmail  RENVOIPAGE _Toc11844114 \h 180
6.6.4 Boites aux lettres publiques  RENVOIPAGE _Toc11844115 \h 182
6.6.5 Autres fichiers de la messagerie  RENVOIPAGE _Toc11844116 \h 182
6.6.6 Fichiers de configuration d'un utilisateur de la messagerie électronique  RENVOIPAGE _Toc11844117 \h 182
6.7 Service de noms  RENVOIPAGE _Toc11844118 \h 183
6.7.1 Le protocole DNS  RENVOIPAGE _Toc11844119 \h 183
6.7.2 Agents utilisateurs associés au service DNS  RENVOIPAGE _Toc11844120 \h 184
6.7.3 Serveurs de noms  RENVOIPAGE _Toc11844121 \h 184
6.7.4 Résolveur et résolveur inverse  RENVOIPAGE _Toc11844122 \h 186
6.7.5 Commandes associées et fichiers de configuration  RENVOIPAGE _Toc11844123 \h 187
6.7.6 Format interne des fichiers du DNS  RENVOIPAGE _Toc11844124 \h 188
6.7.7 Syntaxe associée aux fichiers  RENVOIPAGE _Toc11844125 \h 189
6.7.8 Formats selon le type d'enregistrement  RENVOIPAGE _Toc11844126 \h 189
6.7.9 Configuration des serveurs  RENVOIPAGE _Toc11844127 \h 191
6.7.10 Configuration des clients  RENVOIPAGE _Toc11844128 \h 194
6.7.11 Administration du processus démon named  RENVOIPAGE _Toc11844129 \h 194
6.8 Mise en place des routeurs  RENVOIPAGE _Toc11844130 \h 195
6.8.1 Routage statique  RENVOIPAGE _Toc11844131 \h 195
6.8.2 Routage dynamique : le protocole RIP et le démon routed  RENVOIPAGE _Toc11844132 \h 196
6.8.3 Routage dynamique : le protocole HELLO et le démon gated  RENVOIPAGE _Toc11844133 \h 197
6.9 Configuration de ftp anonyme  RENVOIPAGE _Toc11844134 \h 198
6.10 Accès concurrents et NFS  RENVOIPAGE _Toc11844135 \h 199
6.10.1 Rappels sur les méthodes de verrouillage sous UNIX  RENVOIPAGE _Toc11844136 \h 199
6.10.2 Verrous SYSTEM V  RENVOIPAGE _Toc11844137 \h 200
6.10.3 Verrous BSD  RENVOIPAGE _Toc11844138 \h 200
6.10.4 NFS et les verrous  RENVOIPAGE _Toc11844139 \h 200
6.11 Le protocole bootp  RENVOIPAGE _Toc11844140 \h 201
6.12 Exercices sur la mise en place des services  RENVOIPAGE _Toc11844141 \h 203
6.12.1 Base de données réseau  RENVOIPAGE _Toc11844142 \h 203
6.12.2 NFS et NIS  RENVOIPAGE _Toc11844143 \h 204
6.12.3 Messagerie  RENVOIPAGE _Toc11844144 \h 205
7. Installation D'UNE STATION  RENVOIPAGE _Toc11844145 \h 206
7.1 Connexion d'une station à un réseau  RENVOIPAGE _Toc11844146 \h 206
7.1.1 Configuration des contrôleurs  RENVOIPAGE _Toc11844147 \h 206
7.1.2 Démarrage des processus démons  RENVOIPAGE _Toc11844148 \h 208
7.1.3 Configuration d'un serveur de fichiers  RENVOIPAGE _Toc11844149 \h 208
7.1.4 Configuration d'un client  RENVOIPAGE _Toc11844150 \h 209
7.1.5 Protocoles de gestion des stations sans disque et des terminaux X  RENVOIPAGE _Toc11844151 \h 209
7.1.6 Station sans disque  RENVOIPAGE _Toc11844152 \h 210
7.2 Optimisation du noyau  RENVOIPAGE _Toc11844153 \h 212
7.2.1 Noyau SYSTEM V  RENVOIPAGE _Toc11844154 \h 212
7.2.2 Noyau BSD  RENVOIPAGE _Toc11844155 \h 213
7.3 Installation des terminaux X  RENVOIPAGE _Toc11844156 \h 216
7.3.1 Le fichier xdm-config  RENVOIPAGE _Toc11844157 \h 216
7.3.2 Autres fichiers de configuration de xdm  RENVOIPAGE _Toc11844158 \h 217
7.3.3 Terminal X ou station sans disque  RENVOIPAGE _Toc11844159 \h 218
7.4 RFC  RENVOIPAGE _Toc11844160 \h 218
7.5 Exercices  RENVOIPAGE _Toc11844161 \h 219
8. Commandes traditionnelles d'administration dans le monde TCP/IP  RENVOIPAGE _Toc11844162 \h 220
8.1 Introduction  RENVOIPAGE _Toc11844163 \h 220
8.2 Commandes d'administration du réseau  RENVOIPAGE _Toc11844164 \h 220
8.2.1 Commandes standards TCP/IP  RENVOIPAGE _Toc11844165 \h 220
8.2.2 La commande netstat  RENVOIPAGE _Toc11844166 \h 223
8.2.3 Commandes spécifiques SUN  RENVOIPAGE _Toc11844167 \h 227
8.3 Fichiers associés au protocole snmp  RENVOIPAGE _Toc11844168 \h 229
8.3.1 Démarrage d'un agent SNMP  RENVOIPAGE _Toc11844169 \h 229
8.3.2 Le fichier /etc/snmpd.conf  RENVOIPAGE _Toc11844170 \h 229
8.3.3 Le fichier /etc/snmpd.comm  RENVOIPAGE _Toc11844171 \h 229
8.3.4 Le fichier /etc/snmpd.trap  RENVOIPAGE _Toc11844172 \h 230
8.4 Commandes associées au protocole snmp  RENVOIPAGE _Toc11844173 \h 230
8.4.1 getid  RENVOIPAGE _Toc11844174 \h 231
8.4.2 getone  RENVOIPAGE _Toc11844175 \h 231
8.4.3 getnext  RENVOIPAGE _Toc11844176 \h 231
8.4.4 getmany  RENVOIPAGE _Toc11844177 \h 232
8.4.5 getroute  RENVOIPAGE _Toc11844178 \h 232
8.4.6 setany  RENVOIPAGE _Toc11844179 \h 232
8.4.7 snmpstat  RENVOIPAGE _Toc11844180 \h 233
8.4.8 trap_rece  RENVOIPAGE _Toc11844181 \h 233
8.4.9 trap_send  RENVOIPAGE _Toc11844182 \h 234
8.5 Suivi d'exécution du protocole snmp  RENVOIPAGE _Toc11844183 \h 234
8.6 Bibliographie du présent chapitre  RENVOIPAGE _Toc11844184 \h 234
9. Les protocoles sur ports séries et le service uucp  RENVOIPAGE _Toc11844185 \h 235
9.1 Les protocoles SLIP et ppp  RENVOIPAGE _Toc11844186 \h 235
9.1.1 Le protocole SLIP  RENVOIPAGE _Toc11844187 \h 235
9.1.2 Le protocole PPP  RENVOIPAGE _Toc11844188 \h 235
9.2 Généralités sur le service uucp  RENVOIPAGE _Toc11844189 \h 237
9.2.1 Implémentation  RENVOIPAGE _Toc11844190 \h 237
9.2.2 Définition du réseau uucp  RENVOIPAGE _Toc11844191 \h 237
9.3 Agents utilisateurs  RENVOIPAGE _Toc11844192 \h 238
9.3.1 uucp  RENVOIPAGE _Toc11844193 \h 238
9.3.2 cu  RENVOIPAGE _Toc11844194 \h 239
9.4 Fichiers associés au service uucp  RENVOIPAGE _Toc11844195 \h 240
9.4.1 Répertoires  RENVOIPAGE _Toc11844196 \h 240
9.4.2 Commandes d'administration  RENVOIPAGE _Toc11844197 \h 241
9.4.3 Processus démons  RENVOIPAGE _Toc11844198 \h 241
9.4.4 Relations entre les fichiers uucp  RENVOIPAGE _Toc11844199 \h 242
9.4.5 Le fichier Systems  RENVOIPAGE _Toc11844200 \h 242
9.4.6 Le fichier Devices  RENVOIPAGE _Toc11844201 \h 242
9.4.7 Le fichier Permissions  RENVOIPAGE _Toc11844202 \h 244
9.4.8 Le fichier Dialers  RENVOIPAGE _Toc11844203 \h 244
9.5 Graphe d'état d'une connexion uucp  RENVOIPAGE _Toc11844204 \h 245
10. Principes élémentaires de Sécurité dans les réseaux TCP/IP  RENVOIPAGE _Toc11844205 \h 246
10.1 Contraintes sur les protocoles de bas niveau  RENVOIPAGE _Toc11844206 \h 246
10.1.1 Rappels sur les protocoles TCP/IP  RENVOIPAGE _Toc11844207 \h 246
10.1.2 Techniques d'attaque  RENVOIPAGE _Toc11844208 \h 247
10.1.3 Attaques par recherches d'informations  RENVOIPAGE _Toc11844209 \h 247
10.1.4 Techniques de protections contre les attaques  RENVOIPAGE _Toc11844210 \h 249
10.2 Sécurité et Internet  RENVOIPAGE _Toc11844211 \h 250
10.3 Contraintes sur les protocoles de haut niveau et les applicatifs  RENVOIPAGE _Toc11844212 \h 252
10.3.1 Mot de passe unique ou mots de passes multiples  RENVOIPAGE _Toc11844213 \h 252
10.3.2 Sécurisation et NFS  RENVOIPAGE _Toc11844214 \h 253
10.3.3 Systèmes equivalents  RENVOIPAGE _Toc11844215 \h 254
10.3.4 Services TCP  RENVOIPAGE _Toc11844216 \h 254
10.3.5 Montage distant de systèmes de fichiers  RENVOIPAGE _Toc11844217 \h 254
10.3.6 Station sans disque  RENVOIPAGE _Toc11844218 \h 255
10.3.7 Ordre de démarrage des stations  RENVOIPAGE _Toc11844219 \h 255
10.3.8 Messagerie  RENVOIPAGE _Toc11844220 \h 256
10.3.9 Charge du réseau  RENVOIPAGE _Toc11844221 \h 256
10.3.10 Démarrage  RENVOIPAGE _Toc11844222 \h 256
10.3.11 Fichiers systèmes  RENVOIPAGE _Toc11844223 \h 256
10.3.12 Serveur horaire  RENVOIPAGE _Toc11844224 \h 256
10.3.13 Contrôle des accès extérieurs  RENVOIPAGE _Toc11844225 \h 256
11. Présentation d'un système sécurisé de haut niveau d'administration de reseau  RENVOIPAGE _Toc11844226 \h 257
11.1 Introduction à Kerberos  RENVOIPAGE _Toc11844227 \h 257
11.1.1 Contrôle centralisée des services distribués  RENVOIPAGE _Toc11844228 \h 257
11.1.2 Privilèges et contrôle d'accès aux services  RENVOIPAGE _Toc11844229 \h 258
11.1.3 Service d'enregistrement  RENVOIPAGE _Toc11844230 \h 258
11.1.4 Authentification mutuelle  RENVOIPAGE _Toc11844231 \h 258
11.1.5 Intégrité et pérennité des informations transportées  RENVOIPAGE _Toc11844232 \h 258
11.1.6 Confidentialité, chiffrement et clés  RENVOIPAGE _Toc11844233 \h 258
11.1.7 Principes et architecture de Kerberos  RENVOIPAGE _Toc11844234 \h 260
11.2 L'Authentification  RENVOIPAGE _Toc11844235 \h 261
11.2.1 Les trois étapes de l'authentification  RENVOIPAGE _Toc11844236 \h 261
11.2.2 Le ticket initial  RENVOIPAGE _Toc11844237 \h 262
11.2.3 La clé de session  RENVOIPAGE _Toc11844238 \h 262
11.2.4 L'authentificateur  RENVOIPAGE _Toc11844239 \h 263
11.2.5 Demande et obtention du ticket de service  RENVOIPAGE _Toc11844240 \h 263
11.3 La base de donnée de Kerberos  RENVOIPAGE _Toc11844241 \h 264
11.3.1 Principauté  RENVOIPAGE _Toc11844242 \h 265
11.3.2 Principal  RENVOIPAGE _Toc11844243 \h 265
11.3.3 Contenu de la base de données Kerberos  RENVOIPAGE _Toc11844244 \h 265
11.3.4 Serveur maître  RENVOIPAGE _Toc11844245 \h 266
11.3.5 Serveur esclave  RENVOIPAGE _Toc11844246 \h 266
11.3.6 Espace de nommage de Kerberos  RENVOIPAGE _Toc11844247 \h 266
11.3.7 Déclaration d'un principal  RENVOIPAGE _Toc11844248 \h 267
11.4 Conséquences de l'utilisation de Kerberos  RENVOIPAGE _Toc11844249 \h 267
11.4.1 Interface programmeur  RENVOIPAGE _Toc11844250 \h 267
11.4.2 Administration  RENVOIPAGE _Toc11844251 \h 267
11.5 Le service d'enregistrement  RENVOIPAGE _Toc11844252 \h 268
12. Bibliographie  RENVOIPAGE _Toc11844253 \h 269
Index  RENVOIPAGE _Toc11844254 \h 270
 Architecture et normalisation des systèmes distribués
Définitions et concepts de base
La téléinformatique résulte de la synergie vers 1960 entre deux industries : celle de l'informatique (1948) et des télécommunications (1850). Les techniques informatiques commencent à être utilisées dans le monde des télécommunications et les techniques des télécommunications permettent d'accéder aux ressources informatique distantes. A partir de 1980, apparaît l'informatique distribuée : l'utilisateur accède de façon transparente à des ressources informatiques qui peuvent se trouver sur d'autres systèmes (homogène ou hétérogène).
L'objectif est la transmission de l'information. Les contraintes d'exploitation sont la rapidité et la fiabilité de la transmission.
Activités
Activités classiques de la téléinformatique
Temps partagé, traitement par lot à distance (Remote Batch), transferts de fichiers quelque soit son type (texte, binaire, exécutable).
Transactionnel (carte de paiement type CP8).
Bureautique.
Concentration de terminaux.
Réseau Numérique à Intégration de Services (R.N.I.S.).
Connexion depuis un système sur des systèmes distants (Remote Login).
Gestion des bases de données réparties. Le problème fondamental est la mise au point d'algorithme de gestion correcte des transactions (gestion des accès concurrents, gestion des ruptures de communication, gestion d'événements imprévus, etc.).
Informatique distribuée
Les possibilités nouvelles sont la possibilité de réunir les ressources de différentes stations soit :
pour créer une station virtuelle unique,
pour utiliser des ressources distantes quand elles ne sont pas disponibles localement (pagination sur le réseau par exemple).
On peut, depuis un poste de travail multi-fenêtres ouvrir des terminaux virtuels sur des systèmes extérieur. Par exemple, la station S3 permet de visualiser les accès aux stations S1 et S2.
INCORPORER Designer \s \* fusionformat
Les différents types de réseaux
On distingue les types de réseaux suivants :
un réseau publicex "réseau public" est un service public de transport des informations digitales (réseau TRANSPAC en France),
un réseau homogèneex "réseau homogène" est un réseau constitué d'une gamme d'ordinateurs d'un même constructeur,
un réseau hétérogèneex "réseau hétérogène" est un réseau constitué d'une gamme hétérogène d'ordinateurs de différents constructeurs,
un réseau localex "réseau local" (Local Area Networkex "Local Area Network" ou LANex "LAN") est un réseau d'ordinateurs situés à une petite distance (de l'ordre du km) les uns des autres (Exemples : Token Ring, Ethernet).
un réseau métropolitainEX "réseau métropolitain" (Metropolitan Area NetworkEX "Metropolitan Area Network" ou MANEX "MAN") est constitué de plusieurs réseaux locaux interconnectés sur un même site.
un réseau local longue distance EX "réseau local longue distance "(Wide Area NetworkEX "Wide Area Network" ou WAN) est constitué de plusieurs MAN interconnectés sur de grandes distances.
Réseau multimédia
Toutes les données étant représentables sous une forme digitale, les réseaux permettent de transmettre simultanément tous les types de données sur un même support à savoir :
données binaires classiques (instructions, données numériques et alphanumérique),
archivage
télécopie,
son, image, texte.
Ce type de réseau a l'architecture suivante :
INCORPORER Designer \s \* fusionformat
Schéma de base
L'ETTDex "ETTD" est l'équipement terminal de traitement de donnéesex "équipement terminal de traitement de données". C'est le terminal ou l'ordinateur muni de son contrôleur de communicationsex "contrôleur de communications" dont la fonction est l'émission et la réception des informations ainsi que le contrôle des erreurs de transmission. Ce sont les couples (émetteur, contrôleur) et (contrôleur, récepteur).
Le circuit de donnéesex "circuit de données" est le réseau de télécommunications utilisé pour transporter l'information. L'ETCD est son équipement terminal. Il assure l'interface entre le circuit de données et l'équipement informatique permettant l'accès de l'ETTD au circuit de données par l'adaptation du signal électrique émis. C'est le modem.
Les éléments informatiques sont l'émetteur et le récepteur des données. Les contrôleurs de communications sont les élément de télécommunications qui leur sont associés.
INCORPORER Designer \s \* fusionformat
Compléments de Théorie du signal
Le signalex "signal" assure le transport d'un message codé par une modulation. Il utilise un support de transmissionex "support de transmission" caractérisé par sa bande passanteex "bande passante" qui est la bande (l'intervalle) de fréquences où les signaux émis sont correctement reçus.
Exemple : la bande passante du téléphone est l'intervalle [300, 3400 Hz]
Soient :
PE la puissance du signal à l'émission,
PS la puissance du signal à la réception.
L'idéal serait que PS et PE soient identiques. Mais dans le réalité, il y a toujours des pertes. On a donc toujours :
INCORPORER Equation INCORPORER Equation 
à cause du bruitEX "bruit" de la ligne (résistance interne, longueur de la ligne, etc.).
Le rapport se mesure en décibelex "décibel"s par la formule :
10 INCORPORER Equation CARSPECIAUX 163 \f "Symbol" -n dB
Exemple : pour n = -3 dB, on obtient :
INCORPORER Equation CARSPECIAUX 163 \f "Symbol" -0.3 CARSPECIAUX 187 \f "Symbol" -log10 (2)
D'où :
INCORPORER Equation 
Si n = -30 dB, on obtient :
INCORPORER Equation CARSPECIAUX 163 \f "Symbol" -3 CARSPECIAUX 187 \f "Symbol" -log10 (210)
D'où :
INCORPORER Equation 
Un support physique supportant de telles contraintes est beaucoup plus coûteux que dans le cas précédent.
Modulation
La modulation transforme le signal digital initial pour émission sous une forme analogique. Elle est réalisée par un modemEX "modem" qui est un convertisseur digital/analogique, analogique/digital.
INCORPORER Designer \s \* fusionformat
L'opérateur de modulation est défini par la relation :
s(t) = M e(t)
Comme il est nécessaire de moduler le signal pour l'émettre puis de le démoduler à la réception pour l'interpréter, on a le schéma :
INCORPORER Designer \s \* fusionformat
Le modemex "modem" est le modulateur/démodulateur. Sur l'ETTD, le signal est digital. A la sortie de l'ETCD, il est soit digital, soit analogique.
Les types de modulation
Il existe plusieurs types de modulation, chacun avec ses caractéristiques physiques propres.
Modulation bande de baseex "modulation bande de base"
C'est la technique la plus simple car le signal de sortie est pratiquement identique au signal d'entrée. Les systèmes de codage les plus fréquents sont les codages ManchesterEX "codage Manchester", et Manchester différentielEX "codage Manchester différentiel".
Modulation téléphoniqueex "modulation téléphonique"
Le signal de sortie est analogique. Le transport de l'information est assuré par une onde porteuseex "onde porteuse" de la forme :
y(t) = A sin(CARSPECIAUX 119 \f "Symbol"t + CARSPECIAUX 102 \f "Symbol")
Il existe trois modulations possibles avec ce type de signaux : la modulation d'amplitude, la modulation de fréquence, la modulation de phase.
Modulation par impulsion codéeex "modulation par impulsion codée"
La modulation par impulsion codée (MIC) ou PCM (Pulse Code Modulationex "Pulse Code Modulation") utilise un signal échantillonné qui est une discrétisation (approximation à partir d'un nombre important de signaux discrets) du signal continu. Le théorème d'échantillonnage de Shannon permet de définir une borne inférieure de la fréquence d'échantillonnage F d'approximation du signal continu par des impulsions. Elle est telle que :
F =INCORPORER Equation 
avec B la largeur de bandeEX "largeur de bande" du signal. Le respect de cette borne inférieure garantit une bonne approximation du signal continu.
Le débitex "débit" d'une ligne s'exprime en bits par seconde. La rapidité de modulation est l'inverse de la période de modulation. Elle s'exprime en baudex "baud".
Relation entre bit et baud
Soit T la période du signal à la sortie de l'ETTD et CARSPECIAUX 100 \f "Symbol" celle du signal à la sortie de l'ETCD. On suppose qu'il y a un bit émis par période par l'ETTD et p bits par période par l'ETCD.
INCORPORER Designer \s \* fusionformat
La valenceex "valence" q du signal s(t) est son nombre d'états. Soit p le nombre de bit émis à chaque modulation. Alors
q = 2P CARSPECIAUX 219 \f "Symbol" p = log2 q
Exemple : p=3 CARSPECIAUX 219 \f "Symbol" q = 8
L'avis V27 du CCITT décrit les modems à modulation de phase octovalente avec les relations suivantes.
angle tribits correspondant
0 001
45 000
90 010
135 011
180 111
etc.
On obtient, en appliquant la loi de conservation du débit, la relation :
INCORPORER Equation 
Application : AVIS V27 du CCITT avec R = 1600 bauds, q = 8 et p = 3.
D = 3*1600 bauds = 4800 bits/s
Il y a identité entre bit et baud si le signal est bivalent (cas de la modulation bande de base).
Formule de Shannon
La formule de Shannon indique une borne supérieure du débit théorique maximal d'une ligne par la relation :
INCORPORER Equation 
avec S la puissance du signal, B le bruit de la ligne, W sa bande passante.
Exemple : réseau téléphonique (commuté).
W = 3000 Hz
INCORPORER Equation 
D'où
INCORPORER Equation  3000log2 ( 1 + 1000) CARSPECIAUX 187 \f "Symbol" 3000 log2 (210) CARSPECIAUX 187 \f "Symbol" 30.000 bits/s
Le débit réel maximum est de 19200 bits/s.
Remarque
Si le bruit tend vers l'infini, le débit tend vers zéro car :
INCORPORER Equation 
Transmission
La transmission peut être unidirectionnelle (simplexex "simplex"), bidirectionnelle à l'alternat (half duplexex "half duplex"), bidirectionnelle simultanée (full duplexex "full duplex").
INCORPORER Designer \s \* fusionformat
Il y a plusieurs types de transmission :
Transmission sérieex "Transmission série"
Le support de transmission est unique. Les bits y sont transmis en série. Les bits start stop sont des signaux de synchronisation pour le récepteur.
INCORPORER Designer \s \* fusionformat
Transmission parallèleex "Transmission parallèle"
Chacun des bits du caractère à émettre est émis simultanément sur n lignes.
Exemple : interface parallèle d'une imprimante, échange d'informations entre le processeur et la mémoire centrale.
La synchronisation de l'émetteur et du récepteur est nécessaire car il existe un délai entre l'émission et la réception du signal du au temps de propagation.
Le protocole assure la gestion du dialogue entre l'émetteur et le récepteur. Il en existe deux types : les protocoles synchrones et les protocoles asynchrones.
Transmission asynchrone
L'émetteur et le récepteur se synchronisent au début de la communication de la façon suivante : l'émetteur émet un signal de début d'émission ce qui permet au récepteur de se synchroniser. En toute rigueur, une émission asynchrone est synchrone à partir du moment ou l'émetteur et le récepteur se sont synchronisés.
Exemple : transmission de caractère avec les protocoles XON/XOFF, DTR, KERMIT utilisé pour les terminaux asynchrones et les imprimantes séries.
INCORPORER Designer \s \* fusionformat
La synchronisation est assurée par les bits START/STOP (signal de début et de fin d'émission).
Transmission synchrone
L'émetteur et le récepteur sont synchronisés en permanence suivant une base de temps commune.
Exemple : protocoles TCP/IP, HDLC (OSI), BSC (IBM).
Supports physique
Il existe plusieurs types de supports de transmission : les câbles, les faisceaux hertziens.
Les câbles
Le fil téléphonique est appelé paire métalliqueex "paire métallique". Le problème est l'affaiblissement du signal sur la ligne ce qui nécessite une régénération du signal tous les 1830 m.
Les débits usuels sont les suivants :
D CARSPECIAUX 163 \f "Symbol" 9600 bits/s (liaison 4 fils qualité supérieure)
D CARSPECIAUX 163 \f "Symbol" 72 kbits/s (d CARSPECIAUX 163 \f "Symbol" 10km)
D CARSPECIAUX 163 \f "Symbol" 500 Mbits/s.
La paire torsadée blindée est un fil téléphonique blindé qui peut supporter un débit de 100 Mbits/s.
Le câble coaxialex "câble coaxial" est en cuivre blindé. Il est utilisé pour l'élimination de bruits parasites. C'est un des supports utilisé pour la réalisation du réseau local Ethernet.
INCORPORER Designer \s \* fusionformat
Les débits usuels sont les suivants :
D CARSPECIAUX 163 \f "Symbol" 25 Mbits/s si d CARSPECIAUX 163 \f "Symbol" 10 km
D CARSPECIAUX 163 \f "Symbol" 10 Mbits/s si d CARSPECIAUX 163 \f "Symbol" 1 km.
La fibre optiqueex "fibre optique" est la technologie de l'avenir. L'atténuation est faible (amplification tous les 40/80 km) et le débit est tel que :
D CARSPECIAUX 163 \f "Symbol" 140 Mbits/s
Les réseaux en fibre optique sont en voie de normalisation (FDDIex "FDDI" - Fiber Distributed Data Interfaceex "Fiber Distributed Data Interface").
Onde Hertzienne
Il n'y a pas de support matériel. L'utilisation dépend de la fréquence d'émission.
Types de liaison
Une liaison assure la connexion de différents équipements informatiques.
Une liaison point à pointex "liaison point à point" assure la connexion directe de deux équipements.
INCORPORER Designer \s \* fusionformat
Une liaison multipoints permet à de multiples équipements de dialoguer entre eux.
INCORPORER Designer \s \* fusionformat
Une liaison bouclée réalise un anneau logique.
INCORPORER Designer \s \* fusionformat
Topologie des réseaux
Différentes architectures sont possibles : boucle, anneau, bus. Les types de réseaux associés sont définis par leur protocole, leur câble, et leur méthodes d'accès.
Réseau en étoile
INCKRPORER Designer \s \* fusionformat
Exemple : le réseau Starlan utilise le protocole CSMA/CD. Son support physique est la paire torsadée blindée.
Réseau en anneau
INCORPORER Designer \s \* fusionformat
Exemple
Le réseau Token ring (IBM) fonctionnant avec le protocole de l'anneau à jeton, dont le support physique est le câble ICSex "ICS" (IBM Cabling Systemex "IBM Cabling System").
Réseau en bus
INCORPORER Designer \s \* fusionformat
Exemple
Le réseau local Ethernet, utilise avec le protocole CSMA/CD. Son support physique est le câble coaxial (thick Ethernet (10base5) ou thin Ethernet (10base2)), la paire torsadée blindée (10baseT, 100baseTex "10baseT").
Réseaux arborescents
INCORPORER Designer \s \* fusionformat
Réseau maillé
INCORPORER Designer \s \* fusionformat
Exemple
réseau Transpac, réseau Internet.
Gestion des erreurs de transmission
Pour corriger les erreurs de transmissions, plusieurs techniques de protection sont utilisées.
Bits de parité
Parité simple
Un bit de contrôle est ajouté au caractère transmis. Il est déterminé tel que la somme des bits soit paire (parité paire) ou impaire (parité impaire). Il permet la détection d'une erreur simple.
Parité croisée
On considère deux bits de contrôle : le bit de contrôle longitudinalex "bit de contrôle longitudinal" LRC (Longitudinal Redunduncy Check) et le bit de contrôle verticalex "bit de contrôle vertical" VRC (Vertical Redunduncy Check).
INCORPORER Designer \s \* fusionformat
Une erreur détectée est corrigée. Deux erreurs détectées ne sont pas corrigées.
Protection par Polynôme cyclique (Cyclic Redunduncy Check- CRC)
Principe simplifié : la chaîne de bits à émettre est assimilée à un polynôme de degré n P(x). Un polynôme de référence admettant peu de multiples D(x) est choisi à priori.
Avant émission, le modem réalise la division :
INCORPORER Equation 
Le modem émet ensuite les polynômes P(x) et R(x). A la réception, on obtient une suite P'(x) R'(x). Les polynômes multiples de D(x) sont connus. On connaît donc G(x) D(x). La somme G(x) D(x) + R'(x) est calculée et comparée avec P'(x).
Le taux d'erreurs est le rapport du nombre de bit erronés transmis sur le nombre total de bits transmis.
Exemple
Le polynôme D(x) de degré 16 est normalisé par l'ISO. Il est utilisé dans la plupart des modems.
D(x) = x16 +x12 + x5 + 1
Le niveau de protectionex "niveau de protection" d'un CRC à 16 bits est de l'ordre de 10-8. Celui d'un CRC à 80 bits est de l'ordre de 10-27.
Le taux d'utilisation de la ligne se calcule comme suit : supposons que l'on ait 800 bits à transmettre.

t = 10-8 CARSPECIAUX 219 \f "Symbol" n = 16 CARSPECIAUX 219 \f "Symbol" F = INCORPORER Equation = 98%

t = 10-27 CARSPECIAUX 219 \f "Symbol" n = 80 CARSPECIAUX 219 \f "Symbol" F = INCORPORER Equation = 90%
Principes de base des systèmes de communications et normalisation
Les objectifs des systèmes de communications sont :
la constitution de réseaux téléinformatique permettant une intégration de la plus grande variété de systèmes informatiques,
l'indépendance des applications des contraintes apportées par le réseau de transmission,
la définition de règles de communication universelles, indépendantes des moyens de transfert,
l'indépendance de l'application vis-à-vis des terminaux,
l'adaptation du réseau à tous les types de réseaux existants.
Il existe deux types d'activités :
les activités d'allocation de ressources,
les activités consommatrices de ressources.
Comme dans les systèmes d'exploitation, il est nécessaire de résoudre les problèmes classiques d'allocation de ressources :
gestion de l'asynchronisme des demandes d'où la création et la gestion de files d'attente avec stratégie de demande,
gestion de l'interblocage et des congestions.
Définitions
Les protocoles sont les conventions de gestion des relations entre les activités distantes.
Une couche regroupe les activités de même nature et offre des services aux couches adjacentes.
Un service définit les fonctionnalités de la couche.
Une requête issue de l'émetteur utilise les services de la couche application qui utilise elle-même les services de la couche de niveau inférieur. La définition est récursive. Les couches de même niveau, dites couches homologues, dialoguent en utilisant les protocoles de ce niveau.
INCORPORER Designer \s \* fusionformat
Activités en cascade
INCORPORER Designer \s \* fusionformat
En général, Pi-1,i = Pi,i+1 pour tout i mais cela n'est pas obligatoire.
Principes généraux de conception des couches
Les couches sont conçues suivant les principes suivants :
le nombre de couches est peu important pour simplifier la description et l'intégration de l'ensemble,
les couches sont distinctes pour prendre en charge des fonctions qui diffèrent manifestement par le traitement effectué ou par la technologie mise en jeu,
les fonctions similaires sont regroupées dans une même couche,
une frontière de couche est crée à un endroit où la description des services est concise et le nombre d'interactions à travers cette frontière réduit au minimum,
chaque couche n'a de frontières qu'avec les couches adjacentes,
les fonctions d'une couche sont définies de telle sorte que sa conception puisse être entièrement revue et ses protocoles modifiés sans avoir à modifier les services fournis ou attendus des couches adjacentes,
une couche est présente quand il est nécessaire de distinguer un niveau d'abstraction de manipulation de données : par exemple syntaxique ou sémantique.
Il existe plusieurs modèles en couches : celui d'IBM (architecture SNA devenue architecture AUA), celui des organismes de normalisation (modèle OSI), celui qui est utilisé dans le monde TCP/IP.
Fonctions de transport et de traitement
Le modèle présenté ici est le modèle OSI. Il nous permet de mettre en évidence les fonctions universelles des systèmes de communications. Les couches sont nettement délimitées ce qui permet d'en dégager les concepts fondamentaux.
Il y a séparation des fonctions de transport (couches bassesex "couches basses") et des fonctions de traitement des données (couches hautesex "couches hautes") car le transport est une fonction élémentaire spécialisée alors que le traitement est un ensemble infini de fonctions.
Les développements ces deux fonctionnalités sont effectués indépendamment. Les reprises d'erreurs de transmission sont simples en transport, impossibles en traitement.
Services assurés par la fonction transport
Mémorisation de blocs de longueur finie.
Acheminement des blocs d'informations en temps réel si possible avec un taux d'erreurs négligeable. On distingue à ce niveau deux fonctionnalités :
le contrôle des réseaux : c'est la couche réseau,
le contrôle du transport : c'est la couche transport.
Couche physique
Elle assure l'interface entre les systèmes informatiques et les supports physiques ainsi que le relais des éléments binaires transmis et l'interconnexion des circuits de données.
Exemple : câble Ethernet (norme ISO 8802.3).
Couche liaison
Son rôle est le suivant :
établissement de la liaison pour fournir les procédures et les moyens fonctionnels nécessaires pour l'établissement, le maintien et la libération des connexions de liaison de données,
identification des connexions qui utilisent les connexions physiques,
réglementation de la ressource commune pour éviter les verrous mortels,
synchronisation de l'envoi des informations (invitation à émettre ou à recevoir),
reprise sur erreurs de liaison ou interruption de la liaison,
contrôle de l'acheminement sans erreurs des blocs d'informations sur le support physique,
définition d'un bloc ou d'une trame pour le découpage de l'information,
gestion des caractères de synchronisation,
contrôle d'erreurs (méthodes VRC, LRC, CRC).
Exemple : contrôleur de tramme Ethernet (norme ISO 8802.2).
Couche réseau
Elle assure le relais, le routage, le multiplexage logique des paquets. Elle dispose de mécanisme de contrôle d'erreurs et de contrôle de flux. Elle doit permettre l'adaptation dynamique du réseau et la récupération des pannes de ligne.
INCORPORER Designer \s \* fusionformat
Un routeur (on dit aussi abusivement passerelle) assure l'interface entre deux réseaux.
Les types de réseaux sont :
les réseaux à commutation de circuits,
les réseaux à commutation de paquets, avec les services de circuit virtuel ou de datagrammes.
Routage et adressage
L'adresseex "adresse" est l'identificateur relatif à la couche d'utilisation. Par exemple l'adresse Internet (adresse réseau) est différente de l'adresse Ethernet (numéro du contrôleur). La portée d'une adresse peut être globale (universelle) ou locale (portée limitée à un réseau local).
La fonction d'adressageex "fonction d'adressage" détermine le chemin suivant lequel les informations transiteront. Il en existe deux types :
l'adressage global distribuéex "adressage global distribué" : c'est long à gérer.
les adressages en cascadeex "adressage en cascade" : chaque routeur détermine le chemin ultérieur ce qui définit des conventions locales d'adressage.
Contrôle de flux
Sa nécessité est due à l'effondrement possible du réseau en fonction de la charge du trafic. Il est possible soit au niveau réseau soit au niveau transport. Les méthodes de contrôle de flux sont :
Les politique à seuil : le nombre de paquets qui transitent sur le réseau est limité à priori dans sa totalité.
Inconvénient : sous utilisation possible des équipements,
Avantage : simple à mettre en oeuvre.
Les politiques de pré allocation : les ressources nécessaires au transport des paquets sont réservées préalablement au transport. Les inconvénients sont la durée du traitement et son coût en ressources ce qui conduit à une sous-utilisation du réseau.
L'auto-contrôle de congestion
le système garde des mémoires en réserve (réseau ARPANET),
les paquets ont des durées de vie limitées et s'autodétruisent en cas de dépassement (protocole IP).
Mécanismes associés au contrôle de flux
Contrôle du trafic : c'est un protocole de dialogue entre le processus émetteur et le processus récepteur tel que le récepteur puisse inviter l'émetteur à cesser temporairement d'émettre en cas de nécessité, puis à réémettre quand c'est possible.
Contrôle en cascade : la quantité totale d'information en transit est inconnue.
Contrôles de bout en bout : il y a un contrôle permanent entre l'émetteur et la récepteur. Les délais de transmission imposent une durée très longue.
Mécanismes de fragmentation et de réassemblage
Fragmentation
Les paquets à transporter sont fragmentés pour s'adapter au réseau de transport. Ils sont numérotés pour regroupement ultérieur. Ils n'ont pas toujours la même taille, selon les caractéristiques des équipements intermédiaires.
Séquencement des paquets
Ce problème est traité par les procédures de liaison.
Transparence des informations transportées
Toute configuration binaire doit pouvoir utiliser le réseau.
Acheminement
Le routage dynamique de chemins nécessite leur adaptation et un adressage indépendant des conventions des autres couches.
Exemple : couche IPex "IP" (Internet Protocolex "Internet Protocol").
Couche transport
Cette couche assure le transport des informations de bout en bout. Elle assure :
le contrôle et la reprise sur erreurs de transmission,
le contrôle et l'optimisation de bout en bout du transport des données,
la sélection d'une qualité de servicesex "qualité de service".
Erreurs possibles
Erreur sur le contenu : il y a retransmission du paquet/datagramme erroné.
Perte d'un paquet/datagramme détectée par la numérotation des paquets. Il y a retransmission du paquet perdu.
Duplication d'un paquet/datagramme : il faut l'ignorer.
Erreur du destinataire : à éviter.
Les contrôles sont réalisés par une cascade de contrôles intermédiaires. Le protocole de transport est dit de bout en bout. L'objectif est la communication de deux utilisateurs situés dans différents systèmes indépendamment des caractéristiques du réseau.
Qualité de services
La qualité de service EX "qualité de service "est définie par :
le délai d'établissement de la connexion,
la probabilité d'échec de cet établissement,
le délai entre l'émission et la réception,
le taux d'erreur résiduel non détecté,
la probabilité d'une panne (arrêt de déconnexion),
le délai de déconnexion,
la protection des connexions (sécurité et confidentialité de l'acheminement).
Classes de protocoles
La prise en compte ou non des différents mécanismes possibles amène à définir cinq classes de protocoles (au niveau OSI). La classe minimale (classe 0) ne prend en compte que les fonctions dites "de base" à savoir : ouverture de la connexion, transfert de données, segmentation, déconnexion.
Sans entrer dans le détail, on peut considérer que les différentes classes comportent les mécanismes suivants :
Classes de protocole
Mécanismes 0 1 2 3 4
Concaténation non oui oui oui oui
Contrôle de flux non non oui oui oui
Numérotation des paquets non oui oui oui oui
Multiplexage non non oui oui oui
Données exprès non oui oui oui oui
Reprise sur erreur ou resynchronisation non oui non oui oui
Détection d'erreur non non non non oui
Eclatement non non non non oui
Segmentation oui oui oui oui oui
Les classes de protocoles sont définies par les propriétés suivantes :
Classe O : classe simple
pas de correction ni reprise sur erreurs,
compatibilité avec l'avis S70 du CCITT (telex).
Classe 1 : classe de base avec correction d'erreurs (Flew control)
pas de multiplexage,
récupération des erreurs signalées par le réseau.
Classe 2 : classe avec multiplexage
avec ou sans multiplexage sur une même connexion de réseau,
contrôle de flux optionnel,
pas de reprise sur erreur.
Classe 3 : classe avec correction d'erreurs
multiplexage avec ou sans contrôle de flux,
reprise sur erreur signalées par le réseau.
Classe 4 : classe avec détection et correction d'erreurs
multiplexage avec ou sans contrôle de flux,
reprise sur erreurs signalées par le réseau,
reprise sur erreurs non signalées par le réseau.
Types de réseaux
A ces classes de protocoles correspondent des types de réseaux : plus la qualité du transport est bonne, moins il est nécessaire que la qualité du réseau le soit et réciproquement.
Réseau de type A : bon réseau pour les applications courantes
Il y a un taux acceptable d'incidents signalées par le service réseau et d'erreurs résiduelles non signalées par le service réseau.
Réseau de type B : réseau de qualité moyenne
Il y a un taux acceptable d'erreurs résiduelles non signalées et un taux inacceptable d'erreurs signalées. Les mécanismes de détection et de correction sont nécessaires. D'où une qualité de transport de classe 1 ou 3.
Réseau de type C : réseau de mauvaise qualité
Il y a un taux inacceptable d'erreurs signalées et non signalées. D'où la nécessité de compenser par un service de transport de classe 4.
Exemple : la transmission de données par satellite nécessite un protocole de transport de classe 4.
Couches hautes
La couche session
Cette couche est la première du modèle qui ne concerne pas la transmission des données. C'est l'interface entre le système d'exploitation et les réseaux de transmission. Elle fournit aux entités de présentation coopérantes les moyens nécessaires pour organiser et synchroniser leurs dialogue et pour gérer leur échange de données. Elle a les propriétés suivantes :
offre des outils communs aux différents utilisateurs,
utilise le service de transport sans chercher à l'améliorer,
les fonctions de session ne concernent que le traitement,
aujourd'hui, communications point à point en mode connexion.
Cette couche assure les fonctions suivantes :
support du dialogue entre le processus émetteur et le processus récepteur,
initialisation, synchronisation, terminaison du dialogue.
Exemple : couche RPCex "RPC" (Remote Procedure Callex "Remote Procedure Call") de Sun.
Couche Présentation
Elle assure la prise en charge des problèmes associés à la représentation des données et informations que les applications doivent échanger.
Exemple : couche XDRex "XDR" (eXternal Data Representationex "eXternal Data Representation") de Sun.
Couche Application
C'est une fenêtre d'accès aux services réseau pour le processus d'application. Elle assure les services suivants :
identification et authentification des partenaires susceptibles d'entrer en communication,
détermination de leur disponibilité,
délivrance de l'autorisation de communiquer,
agrément des mécanismes de préservation du secret.
Exemple
La commande mount s'appuie sur le protocole NFSex "NFS" (Networked File Systemex "Networked File System").
INCORPORER Designer \s \* fusionformat
La couche application a deux modes de fonctionnement :
le mode connectéex "mode connecté" : le traitement est synchrone,
le mode non connectéex "mode non connecté" : le traitement est différé.
Exemple d'applications en mode connecté et non connecté
En mode non connecté la messagerie, en mode connecté la gestion des transactions, l'interrogation de bases de données, le traitement en temps partagé, la soumission de travaux sur une station distante, le transfert de fichiers.
Encapsulation des données
Chaque protocole gère des unités de données de protocoleex "unité de données de protocole" (Protocol Data Unitex "Protocol Data Unit") qui sont encapsulées puis transmises à la couche de niveau inférieure.
Exemple
Couche liaison : trame Ethernet ,
Couche réseau : datagramme IP,
Couche transport : segment TCP ou UDP.
Le segment (TCP ou UDP) est complété par un entête. L'ensemble est transmis à la couche IP sous forme d'un datagramme, lui même complété par un entête, transmis au contrôleur Ethernet qui émet la trame sur le support physique.
Modèle serveur-client
Le modèle serveur-clientex "modèle serveur-client" est le modèle théorique utilisé pour réaliser des communications entre processus distants.
Un processus client s'exécutant sur une station A fait des requêtes de services à un processus serveur s'exécutant sur une station B. Le processus serveur détient la ressource demandée et le processus client émet des requêtes sur cette ressource.
On distingue donc deux types de stations fonctionnant en réseau : le serveurex "serveur" et le clientex "client". Le serveur met à la disposition du client des services réseauex "service réseau", définis à partir de nombreux fichiers de configuration.
INCORPORER Designer \s \* fusionformat
La relation serveur-client est asymétrique : le processus client est actif, le processus serveur est passif. Le dialogue serveur-client se déroule de la façon suivante :
Processus serveur
Le processus serveur est endormi, en attente des requêtes de service de la part des processus clients. Il doit idenpifier le processus client pour l'authentifier. Il exécute alors le traitement de la requête par la création du processus approprié. Il assure ensuite l'émission des données.
Processus client
Localise le processus serveur (adresse, numéro de port, liaison).
Etablit la liaison vers le processus serveur (nom du serveur).
Etablit la transaction (sur la couche socket).
Reçoit les résultats du traitement.
Exemple
Sous UNIX, un processus démon est verrouillé en mémoire, prêt à répondre immédiatement à d'éventuelles requêtes. Par exemple, avec UNIX BSD, le processus serveur d'impression lpd s'exécute à la suite de la requête de service lpr. Soit lp l'étiquette logique d'une imprimante. L'exécution de la commande
lpr -Plp fichier
provoque la création du fichier /usr/spool/lp/fichier, imprimé par la suite par le processus lpd dont l'algorithme de fonctionnement, basé sur le modèle du producteur et du consommateur, permet l'impression effective d'un fichier une et une seule fois.
Le modèle client-serveurex "modèle client-serveur" se généralise à des processus s'exécutant sur des stations distantes permettant la réalisation des réseaux locaux.
Exemple :  station A (Client) station B (serveur)
ftp ftpd (démon)
rlogin rlogind (démon)
telnet telnetd (démon)
Le problème des accès concurrents
Soit une base de données accessible depuis plusieurs postes de travail. Une transaction est une opération complète d'entrées/sortie sur un élément (enregistrement logique, ou champ) de cette base, par exemple la consultation ou le retrait d'argent d'un compte bancaire. Plusieurs transactions simultanées sur le même objet définissent des accès concurrents. Comme nous allons le voir, des précautions d'utilisation sont nécessaires.
Une ressource critiqueex "ressource critique" est une ressource dont le partage entre plusieurs processus entraîne une incohérence.
Exemples
Soit une imprimante unique et P,Q deux processus produisant simultanément des données à éditer. Quand P est en impression, il faut que Q soit en attente, faute de quoi les résultats de P et Q seraient mélangés. Dans ce cas, l'imprimante est une ressource critique à un seul point d'accès.
Soit l'application distribuée définie par la suite d'instructions suivantes :
LIRE X
ADD 1 /* additionner 1 à X */
ECR X /* écrire X sur un fichier */
On suppose que deux processus différents P1 et P2 l'exécutent simultanément. C'est le cas classique de deux transactions bancaires simultanées sur le même compte. Supposons qu'aucune hypothèse ne soit faite sur l'ordre dans lequel doivent être exécutées les instructions suivantes :
Processus P1 Processus P2
a) LIRE X d) LIRE X
b) ADD 1 e) ADD 1
c) ECR X f) ECR X
L'utilisation d'un algorithme de gestion des processus en temps partagé peut conduire à une séquence aléatoire d'instructions, par exemple :
S1 = (a,b,c,d,e,f)
ou bien la séquence
S2 = (a,b,d,c,e,f).
Le résultat de l'exécution est différent suivant la séquence exécutée :
Séquence S1 : la valeur ((X+1)+1) est écrite sur le fichier,
Séquence S2 : la valeur X+1 est écrite sur le fichier.
Dans le cas S2, une des transactions a été perdue alors que les deux transactions ont été comptabilisées dans le cas S1. L'ensemble de la transaction doit donc être protégé puisque l'exécution d'une transaction rend impossible l'exécution simultanée d'une autre transaction. Chaque transaction doit s'effectuer en exclusion mutuelle d'une autre transaction.
Le modèle des lecteurs et des rédacteurs
Le problème des accès concurrentsex "problème des accès concurrents" est modélisé de la façon suivante : plusieurs processus font simultanément des requêtes d'accès en lecture (processus lecteurs) ou en écriture (processus rédacteurs) à une ressource partageable (fichier, enregistrement logique, zone mémoire...). L'algorithme est le suivant :
LECTEURS
Début
demande de lecture
si les conditions d'accès sont satisfaites
alors
lecture
fin de lecture
sinon
mise en attente
is
Fin
REDACTEURS
Début
demande d'écriture
si les conditions d'accès sont satisfaites
alors
écriture exclusive
fin d'écriture
sinon
mise en attente
is
Fin
Les conditions d'accès concurrents sont :
Processus lecteur
A un instant donné, n processus lecteurs ( n CARSPECIAUX 179 \f "Symbol"1) peuvent accéder à l'information à condition qu'aucun processus rédacteur ne la modifie (accès partagé).
Processus rédacteur
A un instant donné, l'accès exclusif de l'information à un processus rédacteur est garanti.
La gestion des accès en écriture ou en lecture est une opération complexe dans un environnement distribué. Le modèle des lecteurs et des rédacteurs permet de modéliser les différents cas et de mettre en évidence les sections critiques en écriture.
Exercice
1°) Ecrire les conditions d'accès concurrents avec des sémaphores binaires.
2°) On considère quatre stratégies de gestion des priorités des processus lecteurs et rédacteurs. Quels en sont les inconvénients et les avantages ?
a) Un processus rédacteur n'est jamais mis en attente sauf si un processus lecteur est actif.
b) La requête d'un processus rédacteur est satisfaite dès que les processus lecteurs actifs au moment de la requête sont terminés. Tous les nouveaux processus lecteurs sont alors mis en attente.
c) Aucune catégorie de processus n'est prioritaire. Quand un processus lecteur est actif, toute requête d'un nouveau processus lecteur est satisfaite jusqu'à l'émission d'une requête d'un processus rédacteur. A partir de ce moment, tous les processus arrivants attendent sans distinction de catégorie. Quand le processus rédacteur est terminé, il réveille le premier processus (inconnu) en attente.
d) Les processus lecteurs sont prioritaires sur les processus rédacteurs si et seulement un processus lecteur est actif. Dans le cas contraire, les processus lecteurs et rédacteurs ont la même priorité.
3°) On cherche un algorithme au cas 2a. Soient les sémaphores mutex et wrt et la variable entière readcount définis de la façon suivante :
readcount est le compteur associé au nombre de processus lecteurs simultanés de l'objet partagé,
mutex est un sémaphore d'exclusion mutuelle associé à la variable d'état readcount,
wrt est le sémaphore d'exclusion mutuelle associé soit à la phase d'écriture des processus rédacteurs soit à la phase de lecture des processus lecteurs.
a) Quelles sont les valeurs initiales de readcount, mutex, et wrt.
b) A partir des variables que l'on vient de définir, proposer un algorithme suivi par un processus lecteur.
Indication : wrt est utilisé par le premier et le dernier des processus lecteurs dans la phase d'écriture.
c) Même question pour un processus rédacteur.
Méthodes de verrouillage d'accès
Une solution au problème des accès concurrents est la pose d'un verrou d'accèsex "verrou d'accès" lors d'une transaction suivant l'algorithme :
structure verrou lock
lock = faux
/* requête de transaction */
si lock == faux alors
lock = vrai
exécution de la transaction
lock =faux
réveil du processus en attente du verrou
sinon
mise en attente de la requête
is
Il est possible de définir un verrou sur un fichier, un enregistrement logique ou un champ d'un enregistrement. C'est la granularitéex "granularité" du verrou.
Verrou consultatif
Un verrou est consultatif (advisory locking) s'il n'a pas d'influence sur les primitives d'entrée/sortie. Un verrou consultatif n'empêche pas un processus ayant les droits d'accès convenables d'écrire sur un fichier verrouillé par un autre processus.
Verrou impératifex "verrou impératif"
Un verrou est impératif (mandatory lockingex "mandatory locking") s'il peut modifier le fonctionnement habituel d'une primitive d'entrée/sortie. Par exemple, en contrôlant la phase d'écriture en la rendant bloquante ou en l'empêchant. Ce type de verrou garantit le meilleur niveau de sécurité.
Verrou partagéex "verrou partagé" et verrou exclusifex "verrou exclusif"
Un verrou partagé en lecture garantit à plusieurs processus lecteurs l'accès à un fichier en empêchant la pose d'un verrou exclusif en écriture.
Réseaux locaux
Généralités sur les réseaux locaux
Généralités
Introduction
Les réseaux locaux sont apparus avec la naissance de l'informatique distribuée, au début des années 1970. Réservés tout d'abord à la l'interconnexion de quelques ordinateurs, l'évolution de la technologie a permis d'en accroître les performances et d'en réduire les coûts, ce qui explique la très forte expansion actuelle de ce marché.
Si l'on peut dire que le premier réseau local fut le réseau DCS (Distributed Computer System) de l'université d'IRVINE en Californie, il faut surtout retenir les dates de 1973 pour le dépôt du brevet du protocole CSMA/CD et de 1980 pour la commercialisation du réseau Ethernet, le premier à utiliser ce principe.
Un réseau local est un moyen de transport de l'information (données, texte, image, voix) sur un même site (une pièce, un étage, un immeuble, un groupe de bâtiments) avec un débit pouvant varier de 1 à 150 Mbits/s, permettant de raccorder des systèmes informatiques homogènes ou hétérogènes. La distance d'utilisation peut varier de quelques mètres à quelques kilomètres.
Fonctionnalités
Les principales caractéristiques que doit offrir un réseau local sont :
fiabilité (24h/24h),
simplicité d'utilisation,
support de types de données hétérogènes (texte, voix, image),
ouverture sur les réseaux extérieurs,
débits de 1 à 150 Mbits/s,
adaptable en permanence donc souple d'utilisation,
permettant de nombreux raccordements (1 à 6000),
supportant différents types de matériels,
coût ne devant pas dépasser 10 % du coût du poste raccordé.
Norme et standard
Un matériel est conforme à une norme internationale si ses spécifications techniques respectent les fonctionnalités décrites dans les normes des organismes correspondants (ISO, CCITT).
Un standard du marché est un produit d'un constructeur, qui s'est imposé par ses qualités intrinsèques et que les autres constructeurs se doivent d'offrir; les produits peuvent alors être différents sur les diverses implémentations.
Compte tenu de la diversité des matériels et des logiciels, le raccordement doit être conforme à un standardex "standard" ou à une normeex "norme".
Services rendus par les réseaux locaux
Partage de ressources
L'idée est de mettre en commun des ressources situées géographiquement sur un autre système informatique : ce sont des disques, des fichiers, des imprimantes, des passerelles de connexions vers des ordinateurs centraux, et vers d'autres réseaux locaux.
Transparence des ressources distantes
L'accès aux ressources distantes doit être transparent pour l'utilisateur ce qui pose un grand nombre de problèmes techniques :
transparence du système d'exploitation : par exemple accéder depuis un PC, fonctionnant sous MS/DOS à une imprimante piloté par un serveur UNIX sachant que la syntaxe des commandes d'accès est différente sur chacun des systèmes,
transparence des jeux de caractères : sur un PC sous DOS et un serveur sous UNIX, les jeux de caractères peuvent être différents. Comment utiliser depuis le PC l'imprimante du serveur UNIX,
transparence de la représentation des informations : on peut utiliser un serveur de fichiers sous UNIX pour y stocker des fichiers DOS. Or, les systèmes de fichiers sont implémentés différemment sous UNIX et MS/DOS.
Outils divers
transfert de fichiers entre système homogènes ou hétérogènes,
connexion depuis un poste vers d'autre postes de travail (remote loginex "remote login"),
intégration des services dans l'environnement de travail standard : par exemple l'accès depuis une fenêtre sous Windows3 à une station sous UNIX ce qui implique la possibilité depuis Windows3 d'ouvrir des fenêtres sur des postes de travail distants,
fonction de messagerie pour émettre et recevoir du courrier et éventuellement l'archiver. Par exemple, la messagerie du réseau FNET, sous UNIX permet à plusieurs millions d'utilisateurs d'échanger des informations.
Classification des réseaux locaux
La classification des réseaux locaux est faite suivant le type de modulationex "modulation" utilisé (bande de baseex "bande de base" ou bande largeex "bande large"), de la topologieex "topologie" (bus, boucle ou étoile), du protocole de transmissionex "protocole de transmission".
INCORPORER Designer \s \* fusionformat
Réseau bande de base
L'opération de modulation sur un réseau bande de base est élémentaire. La liaison est de courte distance avec des débits faibles. Le coût du raccordement au réseau de télécommunication est peu élevé.
Les digits 0 et 1 sont respectivement représentés par une tension de 0 et 5V.
Le codage Manchesterex "codage Manchester" à deux états est utilisé.
Principe : il y a toujours une transition du signal par période d'émission de l'élément binaire. Avant la transition, le signal est le complément du bit, après c'est la valeur non complimentée.
INCORPORER Designer \s \* fusionformat
Dans le codage Manchester différentielex "codage Manchester différentiel", la valeur du bit précédent est utilisée pour déterminer celle du bit suivant. Le bit 0 est caractérisé par un changement de polarité en début de bit, le bit 1 par l'absence de ce changement.
INCORPORER Designer \s \* fusionformat
Réseaux à bande large
Le coût de la transmission est plus élevé car il y a une modulation (modulation de fréquence ou de phase). Le bit 0 est représenté par la fréquence f0+f1, le bit 1 par la fréquence f0f1 avec :
f0 la fréquence porteuse,
f1 la fréquence de modulation associée.
Avantages
Le multiplexage permet de transmettre plusieurs canaux simultanés sur le même câble d'où plusieurs ondes porteuses.
La couverture géographique est importante.
Le modem est coûteux car la bande passante est plus large (de l'ordre de 400 MHhz).
INCORPORER Designer \s \* fusionformat
Topologie des réseaux locaux
Réseaux en étoile
Ces réseaux utilisent la classique et obsolète architecture du nœud central de communication (informatique centralisée).
Les inconvénients de ce système sont bien connus : en cas de panne commutateur central, tout le réseau est arrêté. Le rendement est faible car le système est dimensionné pour des performances moyennes. Cependant, il est nécessaire de présenter cette architecture car elle a permis aux fabricants de réseaux téléphoniques de s'introduire dans le marché des réseaux informatiques. Les autocommutateurs numériquesex "autocommutateur numérique" (PABXex "PABX") offrent simultanément des communications informatiques et vocales. Ces autocommutateurs étant des ordinateurs à part entière, certains constructeurs proposent des logiciels de traitement de pexte, de courrier électronique et d'archivage offrant ainsi des systèmes bureautique complets.
Réseaux en boucle : le réseau Token Ring
Les stations y sont reliées par une liaison point à point monodirectionnelleex "liaison point à point monodirectionnelle".
Le support de transmission peut être la paire torsadéeex "paire torsadée", le câble coaxial ex "câble coaxial "ou la fibre optiqueex "fibre optique".
Les protocoles utilisés sont le protocole du jetonex "protocole du jeton" et le celui de la tranche videex "protocole de la tranche vide".
Protocole du jeton
Le jeton est un droit d'émettre logiciel qu'une unique station du réseau doit détenir à un instant donné. Chaque station qui veut émettre doit donc attendre de recevoir le jeton qu'elle transmet après émission à la station suivante sur la boucle.
Le protocole doit prendre en compte les probhèmes suivants :
le partage équitable du jeton entre les stations : deux stations ne doivent pas le monopoliser,
la perte du jeton : en cas de panne d'une station, il faut en régénérer un et un seul pour éviter sa duplication éventuelle.
Une seule station pouvant émettre à un instant donné, les autres stations doivent attendre le jeton avant de pouvoir émettre ce qui diminue d'autant plus le débit effectif que la nombre de stations est élevé.
Voici un problème amusant, de E. Dijkstra (1974) qui met en évidence ces différents aspects. C'est le problème des Sioux et des signaux de fumée.
Imaginons que nous soyons au Far West. Une caravane composée de visages pâles, rangée circulairement est attaquée par des indiens Sioux. Comme chacun le sait, les combats cessent pendant la nuit. Toutefois, les sioux veulent être surs de retrouver leur proie le lendemain matin. Leur culte leur imposant d'invoquer périodiquement le Grand Manitou durant la nuit, il leur faut empêcher les visages pâles de s'enfuir pendant la prière.
Comme ce sont d'excellents logiciens, ils décident pendant leur guet d'invoquer le Grand Manitou selon le rituel suivant :
ils constituent un anneau virtuel circulaire, leurs yeux perçants leur permettant de communiquer entre eux. Soit l'ensemble S = {S1, S2,..., Sn} de n guetteurs en attente, ordonné de telle sorte que chaque guetteur Sk voit uniquement son voisin de gauche ou prédécesseur Sk1. Cette chaîne est bouclée car S1 a pour voisin de gauche Sn.
à un instant donné, un sioux au plus doit prier, et sa prière dure un temps fini quelconque, éventuellement nul.
Pour mettre en oeuvre ce rituel, ils adoptent le protocole suivant :
Chaque sioux Sk de l'ensemble {S2,...,Sn} peut commencer à invoquer le grand Manitou si son voisin Sk1 a son feu allumé alors que luimême a son feu éteint ou l'inverse. Il allume ou éteint son feu (selon que le feu est déjà éteint ou allumé) dès qu'il cesse sa prière.
Le sioux S1 peut recommencer à prier si le feu de Sn et le sien sont simultanément soit allumés soit éteints. Pour cesser de prier, il allume ou éteint son feu selon qu'il est éteint ou allumé.
Au départ, tous les feux sont éteints.
S1 initialise le processus à sa convenance. Il peut prier dès qu'il le souhaite et allume un feu dès qu'il terminé ses évocations. Le sioux S2 peut alors constater qu'il détient le droit de prier, invoquer le Grand Manitou à sa convenance, allumer un feu dès qu'il a terminé, cédant ainsi le droit de prier au guetteur suivant. Le procédé est itératif jusqu'à ce que les n feux soient allumés. Le processus reprend par une suite d'extinctions de feux jusqu'à ce qu'ils soient tous éteints et ainsi de suite. Imaginez la terreur des visages pâles voyant ce spectacle insolite...
1°) Le rituel précédemment décrit est-il respecté par ce protocole ? Justifier la réponse.
2°) Un sioux est-il obligé d'observer en permanence son voisin pour pouvoir prier ? (justifier la réponse). Quels sont les conséquences de cette observation ?
3°) Déterminer les instants les plus adaptés durant lesquels les visages pâles peuvent s'enfuir ?
4°) Que se passe-t-il si un des sioux tarde à prier ? Peuton améliorer l'algorithme ? Le temps de prière doitilêtre borné ?
5°) Que se passe-t-il si un des guetteurs est tué ? Proposer une modification de l'algorithme pour y remédier selon les deux stratégies :
le chef décide d'une solution à partir du moment où il réalise que le droit de prier ne circule plus,
les guetteurs mettent automatiquement en place une solution (à définir) à partir du moment où l'un d'entre eux réalise que le droit de prier ne circule plus (comment peutil le réaliser ?).
6°) Que se passe-t-il si le chef est tué ? Proposer et discuter des avantages et des inconvénients d'au moins deux stratégies de remplacement du chef, l'une basée sur le remplacement automatique du chef par un guetteur (le premier ?, un au hasard), l'autre basée sur l'élection d'un nouveau chef.
7°) Démontrer que le temps d'attente du droit de prier est borné. Conclusion ?
8°) Que pensez-vous de l'efficacité de cet algorithme ? Justifier la réponse.
9°) Que se passe si un sioux est mécréant et refuse de prier ?
10°) Le chef peutil être aidé dans sa tâche par un souschef ? Préciser son rôle et ses droits, en particulier si le chef est tué.
11°) Que se passe-t-il si deux guetteurs sont tués simultanément ? Indiquer deux remèdes différents.
12°) Peuton imaginer une modification de l'algorithme qui permette à deux sioux de prier simultanément ?
12°) Existe-t-il des applications de ce type d'algorithme ? Si oui, lesquelles ?
13°) Pour s'enfuir, les visages pâles sont prêt à tout, y compris à essayer de se faire passer pour un sioux.
a) Le présent algorithme garantitil l'authentification mutuelle du couple de sioux (Sk,Sk+1). Justifier la réponse.
b) Proposer un algorithme qui garantisse cette mutuelle authentification. On distinguera le cas particulier du chef.
Réseau Token Ring
Le protocole du jeton a été retenu par IBM avec le réseau Token Ring.
Caractéristiques techniques
Méthode d'accès : anneau à jeton,
Débit : 4 ou 16 Mbits/s,
Codage Manchester en bande de base,
Diamètre maximum de l'anneau : 700 m,
Interconnexion des boucles,
Support : paire torsadée blindée à 4 Mbits/s,
Câble ICS (IBM CABLING SYSTEM),
Mécanisme de priorité pour accès synchrone,
Station pilote du réseau,
Unité de raccordement MAU (Multiple access unit) 8228,
96 stations par anneau an maximum,
Distance du PC à l'unité 8228 (lobeex "lobe") : 100 m maximum.
Conclusions
Les topologies en boucle ont les inconvénients des liaisons séries :
fiabilité et facilité de mise en oeuvre moyennes,
temps de réponse dépendant du nombre de stations raccordées ce qui limite les possibilités d'extension du réseau.
Les protocoles utilisés (jeton) étant déterministes, ces réseaux peuvent être utilisés pour tous les types d'applications : contrôle industriel ou bureautique.
Réseaux en bus : le réseau Ethernet à 10 Mbits/s
Les réseaux en boucles sont constitués d'ordinateurs branchés en série. Les réseaux à busex "réseau à bus", sont constitués d'ordinateurs branchés en parallèle, et permettent d'en corriger les principaux inconvénients.
Principe
Les échanges d'informations sont réalisé par diffusion sur le support de transmission.
Avantages
la fiabilité est améliorée car les messages sont lus directement sur le bus,
il n'y a pas de problème matériel ou logiciel de fonctionnement en cas de panne d'une station,
le temps de réponse ne dépend plus du nombre de stations, puisque le message sur le bus est reçu par toutes les stations en même temps, au temps de propagation près.
La topologie du réseau étant différente, les protocoles CSMA/CA (Carrier Sense Multiple Access/Collision Avoidanceex "Carrier Sense Multiple Access/Collision Avoidance") et CSMA/CD (Carrier Sense Multiple Access/Collision Detectionex "Carrier Sense Multiple Access/Collision Detection"), ayant un rendement meilleur que les précédents, ont été développés.
Exemples : les réseaux ex "DANUBE"ethernetex "ETHERNET"ex "ZNET"ex "NET ONE".
Il existe deux types d'architecture :
les réseaux à bus monodirectionnel, constitués d'un support séparé pour l'émission et la réception.
les réseaux à bus bidirectionnel constitués d'un support unique de transmission sur lequel s'effectuent l'émission et la réception.
Protocole CSMA/CD
Ce protocole a été conçu pour obtenir un meilleur rendement des réseaux à bus par une minimisation du temps d'attente d'une station faisant une requête d'émission. Le premier principe du protocole CSMA/CD est que chaque station peut émettre sans autorisation, après une écoute préalable pour détecter l'émission éventuelle simultanée d'une autre station et une attente que le câble soit libre avant d'émettre à son tour dans ce cas. C'est la partie CSMA.
Plusieurs stations risquant d'émettre simultanément dès que le câble est libre, il y a risque de collisions. Plutôt que de laisser les stations émettre après une collision (messages entachés d'erreurs), les stations détectent les collisions quand elles se produisent (au début de l'émission) et arrêtent d'émettre ce qui libère le câble et permet à d'autres stations d'émettre. La détection des collisions permet de maximiser la période de transfert d'informations sans erreurs donc d'accroître le rendement.
Cependant, il reste le problème des stations qui ont provoqué une première collision. Pour minimiser la probabilité de collisions répétées, chaque station génère une attente aléatoire de retransmission dont la probabilité qu'elles soient toutes différentes est très élevée, ce qui va les empêcher de réémettre simultanément, donc de provoquer de nouvelles collisions.
Par sa conception, le protocole CSMA/CD permet d'obtenir un très bon rendement. Cependant, quand trop de stations émettent simultanément, les collisions, malgré les intervalles de retransmissions aléatoires peuvent saturer le réseau et en dégrader fortement le rendement.
Un autre inconvénient de l'utilisation de nombres aléatoires est que le protocole CSMA/CD est probabiliste et non déterministe. On ne peut modéliser son fonctionnement que 95% du temps. En cas de surcharge, son comportement n'est pas déterminé contrairement au protocole du jeton. Son utilisation peut donc être envisagée sans problèmes dans la bureautique et les réseaux locaux traditionnels, mais avec précaution dans les processus de contrôle industriel.
Réseau Ethernet à 10 Mbits/s
C'est le premier réseau local à utiliser le protocole CSMA/CD et à être normalisé internationalement (IEEE 802.3 aux USA et ECMA 80, 81, 82 en Europe) à quelques variations près.
INCORPORER Designer \s \* fusionformat
Rôle du répéteur
répéter les données pour resynchroniser et ajuster le préambule de la trame,
détecter les collisions sur un autre segment et émission d'un signal jam dans ce cas,
répéter le signal jam,
segmenter les messages si la collision est permanente (contrôle de flux par interdiction de communication).
Rôle du transceiver
Il assure :
le transfert bidirectionnel des données,
la détection des collisions,
la transmission du signal jam au serveur.
Il dispose de la fonction jabberex "fonction jabber" permettant à une station de tester son propre signal de collision.
Le câble transceiver a une longueur maximum de 30 m.
La position du transceiver sur le bus est déterminé. La pose doit être réalisée par un spécialiste.
Tous les transceivers ne sont pas compatibles entre eux.
Il est possible d'ajouter de nouvelles stations sans interrompre le fonctionnement du réseau.
Caractéristiques d'un réseau Ethernet à 10 Mbits/s
protocole CSMA/CD,
câble de 50 CARSPECIAUX 87 \f "Symbol",
segment de câble de 500 mètres maximum,
100 stations maximum par segment,
interconnexion des segments par des répéteurs,
distance maximum entre deux stations limitée à 1,5 km,
1024 stations maximum sur l'ensemble du réseau,
vitesse de transmission de 10 Méga bits/s,
débit effectif de 3Mbits/s,
codage Manchester,
quand il y a plus de 1024 stations, plusieurs réseaux Ethernet interconnectés sont nécessaires,
les extensions possibles maximum du réseau suivent la règle : 2500 m par 5 segments et 4 répéteurs.
Le principal inconvénient de ce protocole est son faible rendement, défini par le rapport entre le débit effectif du transfert d'informations entre deux stations (3 Méga bits/s) et la vitesse de transmission sur la liaison entre les deux stations (10 Méga bits/s), soit environ 30%.
Normalisation
La norme IEEE 802.3 est supportée par l'ensemble des constructeurs informatiques.
Conclusions
Les réseaux à bus présentent une meilleure fiabilité, des conditions d'utilisation plus simples (introduction ou retrait d'une station sans arrêter le fonctionnement du réseau), et une grande capacité à supporter un nombre important de stations.
Le protocole CSMA/CD permet d'avoir de très bonnes performances de débit, mais avec des restrictions en cas de surcharge (charge supérieure à 70% de sa capacité; par exemple à partir de débit instantané supérieur à 7 Méga bits/s sur Ethernet).
Premiers réseaux de PC
Le réseau PC-NET des années 80
Le réseau PC-NET d'IBM a été conçu avec le même objectif que le réseau starlan : réduction du coût de raccordement par rapport à l'architecture ethernet. Le protocole CSMA/CD est utilisé avec un débit de 2 Méga bits/s. C'est une modulation large bande dont le coût du contrôleur est voisin de celui d'un contrôleur Ethernet.
Le réseau PC-NET permettait de connecter jusqu'à 72 PC dans un rayon de 300 mètres. Il n'a pas été commercialisé.
Le protocole netbiosEX "netbios", développé par IBM à cette occasion, repris aujourd'hui par microsoft, est devenu un des standards actuels dans le monde des réseaux locaux. Il est supporté sur des architectures ethernet, token ring. Il est intégré aux environnements microsoft MS/DOS, Windows 9.x, Windows NT, OS/2, UNIX, Netware.
Autres protocoles de réseaux locaux dans les PC des années 85-95
Le protocole IPX/Netbios ainsi que les protocoles IPX/SPX, développé par Novell,
le protocole XNS, développé par Xerox.
Les réseaux actuels
Ce sont surtout des réseaux basés sur l'utilisation des protocoles TCP/IP devenus le standard du marché.
Contraintes d'exploitation des réseaux locaux
Administration
L'administrateur d'un réseau définit son architecture, ses fonctionnalités, les services qu'il doit rendre, vérifie la compatibilité techniques de ses différents constituants.
Il installe les différentes ressources (matérielles, logicielles) soit en local, soit en réseau, suivant les besoins.
Logiciels installés en local
Deux cas :
ils ne fonctionnent pas dans un environnement réseau,
ils sont dédiés à un unique poste de travail.
Logiciels installés en réseau
Un logiciel installé en réseau est accessible depuis n'importe quel poste de travail, pourvu que l'usager ait les privilèges nécessaires. Cela permet un gain important de place sur un disque (gain de n1 installations pour un logiciel pouvant avoir n utilisateurs simultanés)
Gestion distribuée des ressources
L'administrateur du réseau doit garantir l'accès aux différentes ressources avec un niveau de sécurité et de convivialité convenable.
Contraintes culturelles
Un utilisateur d'un réseau doit recevoir une formation adéquate lui permettant de connaître les services disponibles ainsi que les contraintes d'exploitations locales : règle d'utilisation des mots de passe, mode d'utilisation et d'installation des logiciels, etc.
Il doit se conformer à certaines règles de vie communes dans la mesure où il n'est pas seul à utiliser les services disponibles.
Normalisation des réseaux locaux
La normalisation des réseaux locaux se situe essentiellement au niveau des couches 1 et 2 du modèle ISO. La couche physique spécifie le support de transmission (paire torsadée, câble coaxial, fibre optique) et son interface d'accès. La couche liaison spécifie le protocole (jeton, CSMA/CD, etc.) ainsi que le format des messages échangés.
Les fonctionnalités à normaliser sont :
l'interface avec le support physique,
le protocole de liaison,
la politique d'accès au support,
l'interface avec l'utilisateur.
La couche liaison est divisée en deux sous couches : la couche LLC et la couche MAC
INCORPORER Designer \s \* fusionformat
Les principales normes de réseaux locaux sont les suivantes :
ISO 8802.1 Mac
ISO 8802.2 LLC
ISO 8802.3 Ethernet
ISO 8802.4 Map (bus à jeton)
ISO 8802.5 Token Ring (anneau à jeton)
ISO 8802.6 Map (Non adopté)
ISO 8802.7 Map Broadband (support physiqqe uniquement)
ISO 8802.8 Standard fibra optiqua
ISO 8802.9 ISDN (RNIS)
CCITT I430 Interface S
ANSI XT39 FDDI
CCITT X25 RESEAU X25
Installation d'un réseau local
Le support de transmission
Le premier travail consiste à poser le support de transmission. C'est une étape où il faut prendre beaucoup de précautions pour éviter les pannes par coupure ou les taux d'erreurs importants dus à des radiations électromagnétiques mal éliminées. Puis vient l'installation des interfaces proprement dits. On distingue deux types d'équipements :
les raccordements en mode natif,
les raccordements par "boîte noire".
Raccordements directs
Ce sont les raccordements pour lesquels il existe un contrôleur de communications spécialement adapté à la station à raccorder au réseau. Ils sont disponibles chez presque tous les constructeurs pour le réseau Ethernet. L'intérêt d'un raccordement en mode natif est de pouvoir utiliser au maximum toutes les possibilités offertes par le réseau.
Raccordement "boîte noire"
Pour combler les manques chez certains constructeurs, des sociétés se sont spécialisées dans le développement de boîtes de raccordements aux réseaux locaux, appelées "boîtes noires". Elles permettent d'adapter les différents équipements entre eux en offrant des interfaces standards (RS 232-C, X 25, BSC, IEEE 488 ..) vers les ordinateurs ou les terminaux et gèrent complètement les protocoles de transmission et d'accès au réseau local ce qui permet de composer facilement des réseaux constitués de matériels hétérogènes.
Cependant, elles ne peuvent offrir à chaque station raccordée le service maximum. Un autre intérêt des "boîtes noires" est d'offrir des outils d'interconnexion de réseaux locaux : interconnexion par réseau X 25 (TRANSPAC en France) ou interconnexion par réseau large bande (surtout utilisée aux U.S.A.).
Interconnexions de réseaux locaux aux niveaux 1 et 2
Pour interconnecter des réseaux, il est nécessaire de définir les notions de nom, d'adresse du réseau, et de route.
Nom, adresse, route
Le nom du réseau permet d'y accéder. Il dépend du site ou son définies des règles de nommage.
Son adresse indique sa position géographique. Elle doit être valide quel que soit l'endroit où se trouve la station de travail.
La route décrit le chemin d'accès à une station.
Ces notions sont relatives à chacune des couches du modèle. Ainsi, une adresse de niveau liaison (par exemple Ethernet) est différente d'une adresse de niveau réseau (par exemple IP).
On distingue trois types d'unités matérielles d'interconnexion de réseau :
les répéteursex "répéteur" au niveau de la couche physique,
les pontsex "pont" au niveau de la couche liaison,
les routeursex "routeur" au niveau de la couche réseau.
Répéteurs
La fonction essentielle du répéteur est d'assurer la régénération du préambule et la resynchronisation du signal entre deux segments de même nature (par exemple Ethernet) d'un réseau permettant son extension géographique.
Sa nature dépend à la fois de l'architecture du réseau ainsi que du type de support physique utilisé. Un répéteur n'étant pas reconnu des stations du réseau est transparent.
Il existe des répéteurs pour les réseaux Ethernet, Token Ring ou Arcnet.
Un répéteur multimédiaex "répéteur multimédia" permet l'interconnexion de segments de réseau de même type sur des supports physiques différents (paire torsadée, fibre optique...).
Un répéteur permet d'isoler un segment altéré par des collisions ou des erreurs.
Répéteur Ethernet 10 Mbits/s
Ce sont des répéteurs multimédia qui permettent une extension du réseau sur plusieurs segments en suivant la règle 5 - 4 - 3 à savoir :
5 segments maximum entre deux stations (dont deux libres),
4 répéteurs maximum entre deux stations,
3 segments habités entre deux stations.
Ces règles ne s'appliquent pas si un des segments est en fibre optique car le temps de propagation est alors trop rapide et le retour de l'écho est immédiat.
Ils transmettent 96 bits au minimum ce qui permet une détection aisée des fragments de collision.
Ils permettent également d'isoler un segment dont le trafic serait altéré par trop de collisions successives.
Il existe des répéteurs multiports pour paire torsadée en 10baseT.
Répéteur Fast Ethernet classe 1
un seul répéteur par segment (domaine de collision).
la distance totale de bout en bout est limitée à 200m
Répéteur Fast Ethernet classe 2
2 répéteurs autorisés par domaine de collision, hub ou répéteur.
la distance de bout en bout est de 205 m (100m par segment, 5m entre deux hubs).
Répéteur TokenRing
Il permet d'augmenter la distance MAU/station. Les contraintes de distances doivent être rigoureusement respectées.
INCORPORER Designer \s \* fusionformat
Ponts
Un pontex "pont" permet d'étendre la portée géographique des réseaux en créant un unique réseau virtuel à partir de plusieurs (sous) réseaux physiques de même nature ou de nature différente, permettant ainsi une extension des possibilités initiales des réseaux locaux.
Caractéristiques
Ils ne sont pas connus par les stations du réseau. Ils sont donc passifs.
Chacun des réseaux connectés doit respecter ses limites techniques spécifiques.
Ils permettent de garantir la tolérance de panne grâce à la redondance possible des chemins.
Ils permettent de filtrer les adresses ou les unités de protocolesEX "ponts filtrants".
Ils peuvent assurer la collecte de données pour un contrôle de performances ou pour l'élaboration de statistiques.
Un pont localex "pont local" interconnecte directement deux réseaux locaux.
INCORPORER Designer \s \* fusionformat
Un demipontex "demipont" interconnecte deux réseaux à distance, par exemple en utilisant une liaison spécialisée. FranceTélécom offre ainsi les possibilités du réseau TRANSFIX.
INCORPORER Designer \s \* fusionformat
On distingue cinq types de ponts :
les ponts à routage statiqueex "pont à routage statique" ou Simple Bridgeex "simple bridge",
les ponts à autoapprentissageex "pont à autoapprentissage" ou Learning Bridgeex "learning bridge",
les ponts Source Routingex "source routing".
les ponts Spanning Tree,
les ponts translationnels,
Les fonctionnalités qu'ils peuvent intégrer sont les suivantes :
multiprotocoles,
locaux ou distants,
filtrants,
administrables
Ponts à routage statique
Les tables d'adressage sont statiques. Les avantages de l'utilisation de ces ponts sont la simplicité et la rapidité d'installation. L'inconvénient majeur est la limitation due à l'inflexibilité de la technique. Cette technique interdit le maillage des réseaux restreignant la topologie du réseau à une arborescence stricte.
Ponts filtrants
Ils assurent le filtrage des adresses de destination selon les critères suivants :
type de protocole autorisé,
filtrages de collision,
filtrage de trames en mode broadcast ou multicast.
Un pont filtrantex "pont filtrant" permet le filtrage des trames au niveau des adresses Ethernet ou au niveau des protocoles (IP, Novell...).
Ponts à autoapprentissage et filtrage
Ce type de pont est utilisé sur les réseaux Ethernet. Ils sont performants pour éliminer les goulets d'étranglement (12000 à 15000 paquets par seconde).
Chaque pont observe le traffic et apprend à reconnaître le chemin d'accès de chaque station du réseau qu'il intègre à sa base de données de filtrage.
Ponts Spanning Tree
L'algorithme de routage/pontage utilisé est normalisé par l'ISO sous le nom d'algorithme Spanning Treeex "Spanning Tree".
Cet algorithme induit un trafic sur le réseau tout en évitant le bouclage des informations qui conduirait à un verrou mortel.
Il modifie le réseau maillé en un réseau logique suivant une topologie arborescente et permet donc de définir une arborescence des ponts.
Il évite les possibilités de duplication de trame dans les réseaux maillés par suppression des liaisons redondantes.
Le routage est réalisé selon l'algorithme suivant :
Le pont qui a la plus haute priorité devient la racine de l'arborescence.
Le coût d'acheminement le plus faible est validé. Tous les autres chemins sont bloqués.
Le Spanning Tree reste effectif jusqu'à ce qu'il y ait un changement dans la topologie.
L'adresse est déterminée de la façon suivante :
Cas 1 : adresse de destination connue donc émission directe.
Cas 2 : adresse de destination inconnue donc émission sur tous les réseaux attachés de trames STE (Spanning Tree Explorer Frame) et attente de réponse par la station destinataire pour mise à jour des tables de routage.
Cas 3 : adresse de destination identique à l'adresse du réseau d'origine. La trame est supprimée pour éviter l'écho.
INCORPORER Designer \s \* fusionformat
L'apprentissage des adresses est réalisé selon l'algorithme suivant :
Cas 1 : adresse de la source connue d'où mise à jour de la direction et des horloges de synchronisation.
Cas 2 : adresse de la source inconnue d'où ajout à la base de données.
Certains ponts assurent également une répartition de la charge en utilisant des algorithmes de load balancingex "load balancing".
Pont Source Routing
Cette technique a été définie par IBM pour la constitution de ponts entre des réseaux TokenRing (norme ISO 8802.5). Le principe de base de cet algorithme est l'acquisition puis le traitement du champ "Routing Information" de la trame ce qui élimine la nécessité pour le pont de mémoriser des tables de routage.
Son principe est la mémorisation progressive des adresses des stations des réseaux qui y sont attachés : la station émettrice déclenche un processus de recherche du meilleur chemin vers la station destinataire. Une première trame de test permet d'étendre la recherche de la station destinataire sur l'ensemble des réseaux interconnectés.
Le rôle du pont est réduit à partir du moment où le meilleur chemin a été déterminé.
L'algorithme de recherche du meilleur chemin est le suivant :
émission d'un jeton sur tous les chemins possibles,
la station destinataire choisi le "meilleur" et renvoie l'information vers la station émettrice,
elle peut aussi tout renvoyer vers la station émettrice qui choisit alors le meilleur chemin.
L'inconvénient de cette approche est que le choix du meilleur chemin est fait exclusivement en fonction du nombre de sauts. Le débit réel de la ligne n'est pas pris en compte.
Supposons n anneaux Token Ring, chacun interconnecté avec son successeur par trois ponts.
INCORPORER Designer \s \* fusionformat
Le nombre de chemins potentiels est de 3n-1. C'est le reproche fondamental fait à cet algorithme exponentiel qu'il est impossible de modifier car ses données sont contenues dans la trame. Le nombre de ponts en série est donc limité à 7.
Ponts multiprotocoles Ethernet-Token Ring
Ces ponts permettent d'interconnecter des réseaux de nature différente à la condition expresse que les normes d'adressage soient strictement respectées de part et d'autre. Le problème est la gestion des pseudoadresses car une station Ethernet (resp Token Ring) ne peut dialoguer qu'avec une autre station Ethernet (resp Token Ring). La station émettrice Ethernet (resp Token Ring) croit donc que la station destinataire a une pseudo adresse Ethernet (resp Token Ring). Le pont doit donc effectuer les conversions d'adresse de part et d'autre par modification des champs adresses des trames émises. Sa présence doit être transparente pour les stations, y compris au niveau des performances.
Interconnexion de réseaux distants
Généralités sur les Wan
L'interconnexion de réseaux locaux à travers des liaisons longues distances impose quelques précautions :
évaluation des besoins (bande passante, durée de fonctionnement, protocoles d'interconnexion).
gestion des performances et des goulots d'étranglement.
facturation à la durée ou au volume.
connexions ponctuelles (utilisation du réseau commuté) ou permanentes avec des liaisons spécialisées.
gestion de la sécurité.
gestion des services en fonction des différentes offres.
Le choix des protocoles à interconnecter peut être fonction des applicatifs.
Techniques de commutation
Un système téléinformatique est un graphe dont les équipements informatiques sont les noeuds de commutationex "noeud de commutation" ou systèmes intermédiairesEX "système intermédiaire" et les liaisons de donnéesEX "liaison de données" sont les arcs.
Fonctions des systèmes intermédiaires
Ils doivent disposer de capacités de mise en mémoire, de traitements des attentes, de reprise sur erreurs et de procédures de surveillance. Les différentes liaisons de données peuvent fonctionner en parallèle permettant le recouvrement des transmissions ce qui permet une meilleure utilisation du réseau.
Un blocex "bloc" est le découpage physique de l'information à transmettre. Le messageex "message" est le découpage logique de l'information lié à l'application. Pour l'émission, le message est découpé en paquets, ensembles de n bits tel que :
500 CARSPECIAUX 163 \f "Symbol" n CARSPECIAUX 163 \f "Symbol" 2000.
Le paquet émis transite par un noeud de commutation qui le conserve temporairement, puis détermine la liaison suivante. C'est la fonction de routageex "routage". L'acheminement peut être dynamiqueex "dynamique" donc adaptatif.
Les ressourceex "ressource"s nécessaires à la transmission ne sont allouées que pour la transmission d'un paquet. Elles sont donc utilisables par plusieurs conversations simultanées.
Les techniques de commutations sont les suivantes :
Commutation de messageex "commutation de message"
Le message est transmis de bout en bout de commutateur en commutateur.
Commutation de circuit (Time Division Multiplexing)
Un lien à 2 Mbits/s est découpés en 32 intervalles de temps (IT), chacun fournissant un débit effectif de 64 Kbits/s.
La technique est transparente au protocole, efficace en temps de commutations.
Inconvénient : les IT inutilisées sont perdues.ex "commutation de circuit"
Commutation de paquet en mode connectéex "commutation de paquet"
Le message est découpé en paquets avant la transmission. Deux techiques sont utilisée : le circuit virtuel et le datagramme.
ex "circuit virtuel"La communication est établie suivant un chemin fixe, appelé circuit virtuel, que suivent tous les paquets.
L'échange est bidirectionnel simultané.
L'ordre d'émission des paquets est conservé.
Le mécanisme de contrôle de flux est simple.
Un utilisateur peut utiliser l'intégralité des ressources disponibles
Exemple : réseau X25
La complexité du protocole et les contrôles effectués aux niveaux deux et trois ne permettent pas à X25 de gérer des hauts débits.
Commutation de paquet en mode non connecté
ex "datagramme" Chaque paquet est découpé en datagramme dont chacun peut suivre un chemin spécifique, indépendant de celui des autres. Il n'y pas de séquentialité pendant le transfert et il n'est pas nécessaire d'établir unne communication préalable.
Exemple : TCP/IP.
X25 et le réseau Transpac
La norme X.25 de CCITT décrit une réalisation possible des couches 2 et 3 de l'architecture OSI. A la différence du RNIS, les réseaux X25 sont basés sur la notion de circuit virtuel.
Dans un circuit virtuel, l'émetteur envoie un flux d'octets à une cadence variable, comprise à chaque instant entre 0 et un maximum fixé. Le récepteur reçoit ces octets avec un retard variable.
Le circuit virtuel est adapté aux applications informatiques telles que le transfert de fichiers, où les données sont envoyées de manière irrégulière, et où un retard imprévisible de quelques secondes ne constitue pas un problème sérieux. Les réseaux conformes à la norme X25 assurent la retransmission des données erronées ce que le RNIS ne peut pas faire.
Le protocole X25 est utilisé pour des connexions fréquentes, géographiquement réparties, de longue durée.
Le réseau Transpac
Actuellement, chaque pays industrialisé possède au moins un réseau national conforme à la norme X25, interconnectés avec les autres réseaux nationaux X25.
Rappelons que le réseau français s'appelle Transpac et qu'il est utilisé par les services Minitel.
L'offre Transpac est la suivante :
facturation basée sur les volumes d'informations, le débit, et la durée de la connexion.
gamme de vitesse de 9600 bps à 1920 Kbps.
accès possibles par le réseau téléphonique commuté ou les liaisons spécialisées.
Le RNIS
Le téléphone et le RNIS
Les transmissions numériques offrent plusieurs avantages par rapport aux transmissions analogiques. Elles permettent en particulier l'utilisation de fibres optiques et peuvent être réalisées de façon à ne causer aucune dégradation au signal transmis. En conséquence le réseau téléphonique des pays industrialisés est devenu en grand partie numérique. En France, seul le combiné téléphonique et la ligne le reliant au central transmettent encore le son de façon analogique. Les centraux et les lignes qui les relient entre eux sont numériques. Le signal analogique issu du téléphone est converti en numérique dès qu'il entre dans le central, puis est reconverti en analogique juste avant son envoi vers le téléphone du correspondant.
Ce système transmet très bien la parole, mais n'est pas adapté aux communications de données à cause de l'existence d'éléments analogiques. On a donc introduit un système de téléphonie entièrement numérique, le RNIS (réseau numérique à intégration de services) dont le nom commercial en France du RNIS est Numéris (l'équivalent anglais est ISDN : Integrated Services Digital Network). Le sigle RNIS ne fait pas référence au mot téléphone : c'est pour souligner qu'il n'est pas limité à cet outil. C'est une évolution du réseau téléphonique avec la téléphonie comme application principale.
Le RNIS et la normalisation
Divers systèmes de téléphonie numérique incompatibles ont été développés dans le monde. Par exemple en Europe, on échantillonne le son à une cadence de 8000 échantillons par seconde, et les valeurs obtenues sont codées sous forme de nombres de 8 bits ce qui impose un débit de 64 Kbits/s sur une liaison téléphonique numérique. En Amérique, le débit est de 56 Kbits/s. Selon les pays, on ne code pas de la même manière les différents événements qui se produisent au cours d'une communication (sonnerie, décrochage du téléphone, numérotation). Ces disparités constituent un obstacle sérieux au développement du téléphone numérique, car un tel équipement ne peut être conçu que pour un usage international.
Le RNIS repose sur un ensemble de normes internationales, édités par le CCITT, décrivant en détail une manière unique de mettre en œuvre la téléphonie numérique. Le respect de ces normes permet à un équipement de fonctionner dans n'importe quel pays du monde de façon identique.
Aspects pratiques
L'abonné reçoit une ligne électrique pouvant transporter deux canaux de données et un canal de signalisation. Les trois canaux sont bidirectionnels en mode full duplex. Chacun des canaux de données fonctionne à 64 Kbits/s et le canal de signalisation fonctionne à 16 Kbits/s. Il échange avec le central téléphonique local des informations de contrôle (numéros appelés, appel en cours, etc.).
Chez l'abonné, une boîte spéciale connecte la ligne électrique au bus S, une liaison multipoints conforme aux normes de CCITT. Sur ce bus, on peut connecter des appareils divers, notamment des ordinateurs et des téléphones numériques. Grâce à l'existence de deux voies de données, une installation d'abonné peut comporter deux conversations (téléphoniques ou données) à la fois. Les abonnements RNIS sont donc vendus par paire.
Une configuration sur une ligne d'un débit de 64 Kbits/s peut comporter jusqu'à 30 canaux de données.
Particularités du RNIS
Le RNIS est un réseau téléphonique modernisé et omniprésent. Les lignes téléphoniques analogiques ont été utilisées dans les connexions numériques RNIS ce qui est une réussite technique et économique importante.
Le RNIS permet d'établir exclusivement des circuits temps réel, où l'émetteur émet et reçoit, avec un certain retard, des bits à une cadence fixe (64 Kbits/s). Il n'y a donc pas ici de notion de paquet, remplacée par celle d'un flux continu de bits.
L'expression temps réel provient du fait que chaque bit est transmis en un temps fixé à l'avance, sans que des délais inhabituels puissent apparaître. Ce type de connexion est parfaitement adapté à la téléphonie, où l'on souhaite entendre immédiatement, sans retard variable, les paroles du correspondant. Le circuit temps réel n'est pas, en revanche, parfaitement adapté à l'informatique, quand les besoins de transmission sont irréguliers.
En cas d'erreur, un circuit temps réel ne permet pas la retransmission des données manquantes les données retransmises arriverant forcément en retard, à un instant où le récepteur attend déjà les bits suivants. Lorsqu'une communication RNIS est utilisée en informatique, elle correspond donc forcément à la couche 1 du modèle OSI, la retransmission des données erronées étant prise en charge par une couche de niveau supérieur.
Caractéristiques du réseau Numéris
le coût est fonction de la durée et l'abonnement peut couteux.
les débits autorisés vont de 64 Kb/s à 2 Mb/s par palier de 64 Kb/s.
le débit est garanti avec une allocation à la demande.
Le réseau Numéris est utilisé pour :
des besoins ponctuels de bande passante,
interconnecter un grand nombre de correspondants,
une répartition géographique très diversifiées.
ATM
ATM (Asynchronous Transfer Mode, transmission en mode asynchrone) est un type de réseau, concurrent du RNIS, d'X25 et d'Internet, destiné à réaliser des interconnexions à très haut débits et supportant des applications multimédia qui exigent une qualité de service.
Ses objectifs sont très ambitieux :
débits de 25 Mb/s à 1 Gbit/s.
réseau polyvalent, supportant simultanément des circuits virtuels à débit variable (similaires à ceux de X.25 ou d'Internet) et des circuits temps réel (similaires à ceux du RNIS).
Les débits élevés et la polyvalence d'ATM devraient permettre à ce réseau de prendre en charge toutes les catégories de trafic de l'information, y compris la télévision haute définition.
ATM a été conçu pour remplacer à terme tous les autres réseaux de transmission d'information, tels que les réseaux informatiques existants, le téléphone ou la télévision par câble.
ATM fonctionne selon le principe de transmission asynchrone. Ce principe est issu de celui du circuit virtuel, mais comporte les améliorations nécessaires pour réaliser des circuits temps réel et pour obtenir des débits très élevés. Dans les paragraphes qui suivent, nous présentons brièvement deux aspects de la transmission asynchrone : la réservation des ressources et la simplicité des protocoles utilisés.
Réservation de ressources
Les réseaux X.25 ne peuvent réaliser des connexions temps réel compte tenu du retard imprévisible que peut prendre la transmission d'un paquet lorsque les ressources du réseau sont utilisées d'une manière trop intense. Par exemple, lorsque l'on essaye de transmettre un flux de paquets de 70 Kbits/s en moyenne par une ligne à 64 Kbits/s, il se crée une file d'attente de paquets à transmettre, qui s'allonge progressivement ce qui provoque le retard cumulé de tous les paquets de la file. Pour les éviter, un réseau ATM doit disposer en permanence de suffisamment de ressources pour satisfaire tous ses circuits. Plus précisément, un nouveau circuit ne peut être ouvert que si le gestionnaire du réseau détermine qu'il y a assez de ressources pour satisfaire à la fois le nouveau circuit et tous les circuits préexistants.
La règle ci-dessus est applicable aux circuits temps réel, dont le débit est déterministe. Elle est n'est pas applicable aux circuits virtuels, dont le débit est aléatoire. Pour ces derniers, l'utilisateur déclare le débit qui lui paraît le plus probable. Il peut ensuite le dépasser à tout moment, mais le réseau s'autorise alors à détruire éventuellement les paquets surnuméraires. Une telle destruction aura lieu à chaque fois que le traitement normal de ces paquets risquerait de consommer trop de ressources et de compromettre ainsi la transmission rapide d'autres paquets. Conformément aux principes qui gouvernent les circuits virtuels, la destruction est acceptable car les paquets détruits pourront être retransmis ultérieurement.
Simplicité des protocoles
Les protocoles utilisés par ATM sont simples : tous les paquets sont de longueur fixe (48 octets de données utilisateur, 5 octets de service). Cette simplicité est essentielle car la réalisation de débits élevés nécessite une manipulation efficace des paquets.
La détection des erreurs de transmission n'est pas prévue. On considère en effet que dans ce domaine, les besoins de chaque utilisateur sont différents. Chacun doit donc choisir sa propre méthode de détection d'erreurs. Par exemple, dans un circuit téléphonique on peut choisir d'ignorer les erreurs, celles-ci se traduisant simplement par des "cracs" audibles. Dans une application de transfert de fichiers, il faut au contraire détecter toutes les erreurs, et provoquer la retransmission des données mal reçues. Sous ATM, cette tâche incombe à un logiciel spécifique ne faisant ne fait pas partie du protocole.
Le relais de trames
L'objectif est de connecter toujours plus rapidement des réseaux locaux à longues distances en offrant des débits toujours plus importants, avec une excellente qualité de service.
L'idée des réseaux à relais de trame (frame relay) est d'intégrer des éléments raccordés "intelligents" pour qu'ils puissent en particulier gérer les erreurs en effectuant la commutation au niveau 2 ce qui permet d'alléger considérablement le niveau 3.
Le protocole du frame relay intègre les fonctions suivantes :
reprises sur erreur,
application supportant des délais variables sur des liaisons de bonne qualité.
Techniques de base
Elles sont dérivées à la fois des protocoles HDLC (niveau 2) et de X25 (niveau 3).
La commutation de type relais de trame intègre à la fois le concept de commutation de circuits et celui de commutation de paquets de la façon suivante :
temps de commutation réduits par appauvrissement fonctions de contrôle des niveaux 2 et 3.
circuit virtuel maintenu pour utiliser en totaliter la bande passante disponible si nécessaire.
Algorithme du relais de trame
Phase 1
vérification de l'intégrité de la trame.
si problème,abandon immédiat de la trame.
Phase 2
comparaison de l'identificateur de connexion logique avec les éléments d'une table interne.
si problème,abandon immédiat de la trame.
Phase 3
relayage de la trame vers la porte indiquée.
Conséquences
Pas de mécanisme de garantie d'un débit minimum.
Existence d'éventuel problème de congestion sur le réseau.
Conclusions sur les réseaux locaux
Les solutions techniques sont déterminées en fonction de la quantité et du type de données à transmettre.
Si les besoins d'une entreprise sont "voix et données faible débit", la solution PABX semble la plus appropriée.
S'il y a un impératif de données à haut débit, il faut alors envisager un réseau en bande de base (jeton ou CSMA/CD en fonction du type d'utilisation).
Enfin, s'il y a un impératif de plusieurs canaux simultanés, seuls les réseaux à large bande peuvent y répondre.
On trouve également des solutions hétérogènes :
un PABX et un réseau bande de base,
un réseau large bande et des réseaux bande de base.
Dans ces solutions mixtes, on distingue trois niveaux de communication :
niveau micro : 64 K-bits/s à 100 Méga bits/s,
niveau mini : 2 à 10 Méga bits/s,
niveau mainframe : 10 à 100 Méga bits/s.
Une solution normalisée est le standard FDDIex "FDDI".
Les réseaux locaux ont terminé leur période de démarrage. Après une quinzaine d'années où tous les types de solutions ont été proposés, la normalisation et l'expression des besoins exacts des utilisateurs a permis l'émergence d'un ensemble de produits fiables, supportés par la plupart des constructeurs.
L'accroissement très rapide du nombre de sites installés montre que l'ère de l'utilisation massive des réseaux locaux est commencée.
Le souci aujourd'hui est de garantir la transparence ainsi que la pérennité des solutions proposées. En particulier, la notion de système ouvert devient impérative : on veut pouvoir, sur un même poste de travail, accéder à des fichiers sur des sites différents, faire du coupercoller entre les fenêtres, quelque soit le système d'exploitation utilisé (Dos, UNIX, OS/2, Mac Intosh, etc.).
Bibliographie du présent chapitre
Interconnections : bridges and routers
Radia Perlman, éditeur : Addison-Wesley
Téléinformatique
C.MACCHI, JF GUILBERT, éditeur : Dunod
Réseaux : architecture, protocoles, applications
Andrew Tanenbaum, éditeur : InterEditions
Communications for Cooperating Systems OSI, SNA, and TCP/IP
R.J. Cypser, éditeur : Addison-Wesley
Modern Operating Systems
Andrew Tanenbaum, éditeur : Prentice Hall
SERVICES RESEAUX traditionnels dans le monde TCP/IP
Historique
Historiquement, les services réseau du monde TCP/IP ont été définis et développés sous UNIX. Les services réseaux ont été définis progressivement et ils évoluent encore aujourd'hui.
Dans l’ordre historique, on distingue les services suivants :
les services DARPA (Defence Advanced Research Projects Agency),
les services développés à l'Université de Berkeley,
les services complémentaires aux précédents,
les services basés sur l'utilisation simultanée du réseau téléphonique commuté et de modem,
les services répartis et distribués, développés par la société SUN MICRO-SYSTEM comme NFS et NIS,
les services graphiques distribués dans des environnements hétérogènes basés sur le protocole XWindow,
les services d'administration de réseaux hétérogènes basés sur les protocoles SNMP, SNMP2,
les services permettant d'utiliser le réseau Internet (navigateur, moteurs de recherche, service d'annuaire, gestion du format hypertext (HTML).
les services définis par OSF/DCE.
Présentation des services traditionnels
Le modèle serveur-client
C'est le modèle théorique utilisé pour l'implémentation de tous les services et protocoles réseau du monde TCP/IP.
Services de la DARPA
L'ensemble des protocoles Internet, dont les plus connus sont TCP et IP, a été développé pour permettre à des ordinateurs de communiquer entre eux et de pouvoir partager des ressources dans un réseau.
Les recherches financées par la DARPA ont permis de définir les protocoles TCPex "TCP", UDPex "UDP", IPex "IP" utilisés pour la mise en place du réseau, des services de transfert de fichier et de terminal virtuel dans des environnements homogènes ou hétérogènes.
Le réseau ARPANETex "ARPANET" (1979) est le plus connu des réseaux fonctionnant avec les protocoles TCP/IP. Le réseau INTERNET regroupe le réseau ARPANET, le réseau NSFNET, ainsi qu'un grand nombre de réseaux locaux d'établissements universitaires ou de centres de recherches.
Les protocoles
On distingue :
les protocoles de bas niveau (TCP, IP),
les protocoles de haut niveau (ftpex "ftp", SMTPex "SMTP"), utilisés pour le transfert de fichiers ou la messagerie.
Les protocoles de bas niveau
Les protocoles de bas niveau, mis au point dans les années 1975, utilisent des mécanismes classiques d'adressage, de nommage, de contrôle de flux simples, fiables, et efficaces permettant une implémentation aisée sur différents systèmes.
Très rapidement, de nombreux ordinateurs des universités américaines s'y sont connectés permettant aux chercheurs d'échanger des informations. Cette ouverture a été fondamentale dans le succès d'UNIX.
Le protocole de contrôle de la transmission TCPex "TCP" (Transmission Control Protocolex "Transmission Control Protocol") découpe les messages d'informations sous la forme de segmentsex "segment"s, entités indépendantes émises sur le réseau, les réassemble et les réordonne à l'autre extrémité. Il contrôle leur arrivée et émet des requête de réémission des datagrammes manquants. C'est un protocole de niveau transport, en mode datagramme, d'une qualité de service de classe 4. Ses versions les plus récentes intègrent les fonctions de niveau transport définies dans le modèle OSIex "modèle OSI" (Interface TLIex "Interface TLI" : Transport Layer Interfaceex "Transport Layer Interface").
UDPex "UDP" (User Data Protocolex "User Data Protocol") est un protocole de niveau transport, intégrant un minimum de fonctionnalités, utilisé dans des réseaux locaux où la qualité du service de transport offerte par le protocole TCP n'est pas nécessaire.
IPex "IP" (Internet Protocolex "Internet Protocol") est un protocole de niveau réseau, à la base du réseau INTERNET, utilisé par les protocoles TCP ou UDP. Il assure la fragmentation et le routage des datagrammes, qui peut, sur de grands réseaux être une opération très complexe.
L'interface entre les protocoles TCP et IP est très simple : c'est un datagramme muni de son adresse de destination. Le protocole TCP ignore la façon dont le protocole IP assure le transport du paquet à sa destination.
Une application basée sur les protocoles TCP/IP utilise au moins 4 couches de logiciels :
la couche application, par exemple ftp,
la couche transport telle TCP qui met à la disposition de l'application les services de niveau transport,
la couche réseau qui assure le routage des datagrammes à leur destination,
la couche liaison telle ETHERNET.
INCORPORER Designer \s \* fusionformat
Les protocoles TCP/IP sont basés sur les principes suivants :
des réseaux indépendants sont connectés par des routeurs. L'utilisateur doit pouvoir accéder aux ordinateurs ou aux ressources informatiques de n'importe lequel d'entre eux.
INCORPORER Designer \s \* fusionformat
Le routage utilisé est transparent à l'utilisateur.
Une connexionex "connexion" est une conversation entre deux systèmes distants, en mode connecté ou non connecté.
Les atouts des protocoles TCP/IP
Les spécifications de ces protocoles ouverts, développés indépendamment du matériel et du système d'exploitation utilisé, sont disponibles gratuitement.
Ils fonctionnent sur différents types de réseau : ethernet, anneau à jeton, réseau téléphonique commuté, X25, etc.
La plupart des informations les concernant sont publiées sous la forme de RFCEX "RFC" (Requests For CommentsEX "Requests For Comments").
Les protocoles TCP/IP sont devenus en 1995 le standard de communication dans les réseaux hétérogènes.
Les couches TCP/IP sont économes de ressources mémoire.
Avec quelques millions de noeuds, le réseau Internet est le premier réseau TCP/IP du monde.
Services traditionnels de la DARPA
Les services traditionnels sont basés essentiellement sur les protocoles TCP/IP.
ftpex "ftp" (file transfert protocolex "file transfert protocol") est un utilitaire de transfert de fichiers, utilisable sur des systèmes hétérogènes (UNIX, MS/DOS, etc.), interactivement ou en batch. Très puissant, il utilise des directives pour transférer des fichiers sur différents systèmes. Il contrôle les droits d'accès, les mots de passe et effectue les éventuelles conversions de format entre systèmes hétérogènes.
telnetex "telnet" est un utilitaire d'émulation de terminaux assurant le service de terminal virtuelex "service de terminal virtuel" dans un environnement hétérogène.
tftpex "tftp" est un utilitaire de transfert de fichiers simplifié utilisé pour le démarrage de station sans disque ou de terminaux X.
Services BSD (Berkeley)
La couche socket
Les services réseaux développés par l'Université des Berkeley ont offerts aux utilisateurs du monde UNIX l'ouverture sur le monde extérieur. Ils offrent une interface de programmation (Application Programming Interfaceex "Application Programming Interface" ou APIex "API") : la couche socket, permettant d'accéder directement aux services offerts par les protocoles TCP/IP depuis un processus applicatif. Le terme socket peut être traduit par prises de communicationex "prise de communication".
Services traditionnels (remote commande ou commandes déportées)
Les services réseaux rloginex "rlogin", rcpex "rcp", rshex "rsh" permettent les communications entre des stations distantes dans un environnement homogène. Les commandes précédentes sont paramétrables à partir des fichiers systèmes de gestion de réseau permettant d'assurer une transparence totale, ou très surveillée des accès aux différents services.
rloginex "rlogin" (remote loginex "remote login") assure le service de terminal virtuel dans un environnement (UNIX/PC) hétérogène. De nombreuses fonctions de contrôle sont disponibles (mot de passe, droits d'accès à la station, etc.).
rcpex "rcp" (remote copyex "remote copy") est l'extension de la commande UNIX cp à un environnement de réseau homogène.
rshex "rsh" (remote shellex "remote shell") permet de lancer l'exécution d'un travail sur un système UNIX distant.
INCORPORER Designer \s \* fusionformat
Services répartis et distribués
La compagnie SUN Microsystem a eu une contribution décisive dans le monde des réseaux grâce aux services définis par les protocoles NFSex "NFS" et NISex "NIS" dont les objectifs sont la transparence de l'accès d'un utilisateur aux stations d'un réseau local (protocole (distribué) NIS) ainsi que la transparence de la localisation des fichiers au niveau applicatif (protocole (réparti) NFS). C'est l'informatique répartie et distribuée.
Les protocoles de niveau application NFS et NIS utilisent les protocoles RPC (niveau session), et XDR (niveau présentation). Ces derniers utilisent les services fournis par la couche transport et les protocoles TCP et UDP.
Les protocoles
INCORPORER Designer \s \* fusionformat
Le protocole RPCex "RPC" (Remote Procedure Callex "Remote Procedure Call"), de niveau session, assure l'exécution (transparente localement) de procédures sur une station distante.
Le protocole XDRex "XDR" (eXternal Data Representationex "eXternal Data Representation"), de niveau présentation assure la conversion transparente des données entre différentes architectures de stations (par exemple les microprocesseurs Motorola ou Sparc des stations de travail SUN et les microprocesseurs Intel des PC utilisent des représentations internes de données différentes, appelées big endianex " big endian" et little endianex "little endian").
Les services
Le protocole de niveau application NFSex "NFS" (Networked File Systemex "Networked File System"), assure de façon transparente et fiable le partage de certaines ressources entre différentes stations d'un réseau local (fichiers, disques, imprimantes, etc.). Il généralise la notion de montage local d'un système de fichiers au réseau dans un environnement homogène ou hétérogène. Tous les constructeurs ont aujourd'hui la licence NFS, standard du marché.
Le protocole NISex "NIS" (Network Information Serviceex "Network Information Service"), anciennement Yellow Pageex "Yellow Page", gère de bases de données distribuées (la base de données réseau) qui assurent les services distribués d'administration de réseau suivants :
gestion des utilisateurs et des groupes réseau,
gestions des services réseau,
gestions des nom symboliques IP,
gestion des sous réseaux.
Les Interfaces Applicatives (API EX "API" )
Comme pour la couche socket, il est possible d'utiliser des primitives permettant d'accéder aux services RPC et XDR.
Services traditionnels basés sur des protocoles de communication asynchrones
Les services suivants peuvent fonctionner en mode asynchrone sur des liaisons séries. Ils ne nécessitent pas de modification du système d'exploitation alors que les services précédents sont intégrés dans le noyau UNIX. Ils sont encore (très peu) utilisés quand aucune autre solution n'est possible.
cuex "cu" (Connection to UNIXex "Connection to UNIX")
Service similaire à celui offert par la commande rlogin par connexion directe du terminal vers la station distante à 9600 bits/s (UNIX SYSTEM V) et à 2400 bits/s (UNIX 4.2 BSD) sans nécessité d'un logiciel particulier.
uucpex "uucp" (UNIX to UNIX copyex "UNIX to UNIX copy")
réseau virtuel fonctionnant quelque soit le type de communication,
un noeud actif permet d'effectuer les liaisons avec toutes les stations prévues du réseau,
convient aussi bien au réseau local qu'au réseau distant,
exécution de tâches distantes, pouvant mettre en jeu des ressources de plusieurs stations,
très haut niveau de sécurité entre les différentes stations,
fonction de mailing possible,
automatisation complète de tâches de liaison (dialup, protocoles, files d'attente),
transfert de données par messages avec contrôle de validité à la réception et retransmission en cas d'erreur,
aucune contrainte sur le contenu des fichiers (ASCII, binaire..),
syntaxe d'emploi agréable et usuelle, non totalement transparente.
kermitex "kermit"
utilitaire de transfert de fichiers entre systèmes homogènes ou hétérogènes,
facilité de portage et programme du domaine public,
liaison point à point sur ports asynchrones,
convient pour des transferts occasionnels,
possibilité réduite de remote login,
simplicité de mise en oeuvre.
Autres services Berkeley
Téléphone
Les commandes writeex "write" ou talkex "talk" permettent le dialogue interactif entre utilisateurs d'un même réseau TCP/IP.
Liste des utilisateurs connectés
Les commandes rwhoex "rwho" et rusersex "rusers" permettent de connaître les statistiques d'utilisation du réseau (autres utilisateurs, charge, etc.).
Serveur horaire
Le protocole timedex "timed" est un serveur horaire permettant de garantir l'unicité de l'heure sur les différentes stations d'un réseau.
Messagerie électronique
Elle est basée sur le protocole SMTPex "SMTP" : Send Mail Transfert Protocol,
Impression distante
Le protocole d'impression distante lpd est implémenté dans le processus démon lpdex "lpd".
INCORPORER Designer \s \* fusionformat
Service de noms
Avec la croissance du nombre de stations, il devient impossible qu'un fichier contienne la liste de tous les noms des autres stations du monde Internet.
Le service de nomsex "service de noms" a été défini par le protocole DNS (Domain Name Serviceex "Berkeley Internet Naming Daemon") pour accéder à des stations distantes, externes au domaine local.
Il retourne des adresses IP, des noms symboliques IP, des noms de stations relais d'un réseau donné.
Il permet de maintenir une base de données distribuées des tables de routage par utilisation de serveurs de noms.
Il est utilisé sur le réseau INTERNET.
Grâce au service de noms, un organisme peut gérer de façon interne la topologie de ses systèmes et en autoriser une visibilité partielle ou totale.
Autres services réseau
Multifenêtrage distribué
Les système multi-fenêtres tels XWindowex "XWindow".
Administration centralisée
Le protocole SNMP permet d'assurer l'administration de réseau dans un environnement hétérogène.
Services serveur/clients dans un environnement hétérogène
L'accès à des services fournis par un serveur UNIX à des requêtes clientes issues de systèmes fonctionnant dans le monde PC par exemple SQLnet dans les SGBD, l'émulation d'un terminal X sous Windows 3.x, 9x, NT, 2000.
Utilisation du réseau téléphonique commuté
Deux protocoles permettent d'accéder au réseau Internet en utilisant une liaison téléphonique. Ce sont les protocoles SLIPEX "SLIP" (Serial Line IPEX "Serial Line IP") ou PPPEX "PPP" (Point to Point ProtocolEX "Point to Point Protocol").
Le premier utilise le protocole UDP et convient aux stations connectées par modem.
Le protocole PPP garantit une transmission fiable en assurant des services de niveau liaison.
Accès à l'Internet
La croissance de l'utilisation du réseau Internet à conduit à la définition d'interface homme machine conviviales permettant d'en banaliser l'accès.
L'architecture DCE
L'architecture DCEex "DCE" (Distributed Computing Environnementex "Distributed Computing Environnement"), définie par l'OSF, intègre les services suivants :
service de nommage homogène ou hétérogène et accès à la messagerie X400 et X500,
implémentation des services précédents et utilisation du concept d'activité multipleex "activité multiple" d'un processus (multithreadex "multithread") pour l'implémentation,
modification du protocole RPC pour intégrer la sécurisation des transactions,
authentification des requêtes par utilisation du protocole Kerberosex "Kerberos",
gestion des systèmes de fichiers distribués conforme au modèle lecteur/rédacteur par une modification importante de NFS.
Contraintes de sécurité
Il est fondamental de pouvoir garantir le bon fonctionnement d'un réseau. La sécurité en est un élément important. On en distingue plusieurs domaines d'utilisation :
surveillance de la charge du réseau,
états des logiciels distribués,
comptabilité et audit,
administration centralisée,
souplesse,
service d'intégrité,
surveillance des systèmes,
privilèges et contrôle d'accès aux services,
service d'enregistrement,
authentification,
intégrité des données,
confidentialité des informations transportées.
Le réseau Internet
Historique et architecture
Plusieurs millions de machines sont connectées au réseau mondial Internet. L'ensemble des services disponibles et la gestion des ressources associées est architecturé selon le modèle client serveur.
Les RFC
Internet est un réseau créé à l'initiative du ministère de la défense américain (DoD, Department of Defense). Il est décrit dans une série de documents qui, bien qu'ils constituent des normes, portent le nom de Requests For Comments (RFCs, demandes d'avis). Internet correspond approximativement aux couches 3-4 de l'architecture OSI; d'autres protocoles et logiciels décrits dans les RFCs correspondent aux couches 5-7.
Les couche réseau et transport
L'architecture du routage et du transport de l'Internet est organisée en deux couches. La couche basse correspond au protocole Internet Protocol (IP), la couche haute correspond au Transport Control Protocol (TCP).
Internet n'est pas basé sur la notion de circuit, mais sur celle de mode non connecté. Dans ce mode, n'importe quelle station peut émettre un paquet sans établissement préalable d'une connexion. Les concepts de circuit temps réel et de circuit virtuel ne sont pas utilisés.
Philosophie de l'Internet
Chacun des membres de l'Internet met gratuitement à la disposition des autres utilisateurs un certain nombre de services.
Bien sûr, cela implique une éthique de fonctionnement car l'objectif n'est pas de saturer le réseau ou de détruire des données, ou encore de faire circuler des virus. En outre, les aspects commerciaux, en croissance permanente, représentent une part croissante du trafic grand public (plus de 50%).
Les services disponibles
On distingue les services suivants :
Les services traditionnels de la Darpa (téléchargement (dowload) ou transfert de fichiers entre systèmes hétérogènes, connexion sur des sites distants, messagerie électronique et utilisation implicite ou explicite du service de nom (DNS).
Les navigateurs sont des outils d'exploration de la toile. Deux produits s'affrontent : Netscape (netscape) et Internet Exploreur (microsoft).
EX "mosaïc"Les serveurs Web (World Wide Web ou Toile d'Araignée Mondiale) permettent aux internautes d'accéder aux informations qu'ils contiennent, représenté sous le format HTML ou dans un format dérivé (XML).
Les moteurs de recherche permettent de localiser des sites Web en fonction de critères définis par l'utilisateur.
Le service de nouvelles (news).
La gestion de bases de données.
L'émission de fax et de communications téléphoniques.
Les divers modes de connexion avec les protocoles SLIP, PPP, RNIS, RTC, UUCP.
Dans ce qui suit, nous présentons rapidement ces différents services.
World Wide Web
Le service World Wide WebEX "World Wide Web" (littéralement traduit par toile d'araignée mondiale) est le plus récent des services de l'Internet. Appelé également le service WWW (ou encore W3), il a pour objectif l'organisation des informations de l'Internet et leur diffusion.
Les informations sont accessibles avec une interface graphique disponible sur un navigateur.
Chaque page d'écran contient des liens vers d'autres pages d'écran.
Il utilise le concept d'hypertexte dont le principe simplifié est le suivant : à partir d'un menu, certains mots apparaissent soulignés, d'une autre couleur, en surbrillance...Il suffit de sélectionner l'un d'eux pour voir apparaître un nouvel écran d'aide contextuelle qui lui correspond. On peut itérer le procédé à l'infini. Il est également possible de rappeler des écrans précédents comme dans les bases de données navigationnelles.
Interface homme machine
Les pages d'écran sont accessibles par l'intermédiaire de browserEX "browser" (afficheurEX "afficheur") dont les plus connus, EX "mosaïc"Netscape et Internet ExploreurEX "netscape", sont orientés multimédia et peuvent accéder à des fichiers de toute nature (image, son, données, etc.) ce qui permet de créer des documents sonores et même des animations. On peut également utiliser le système multimédia de l'ordinateur comme téléphone, voire comme poste de télévision interractive.
Des modules additionnels (plug in) peuvent être téléchargé pour intégrer des fonctionnalités nouvelles.
Adresse d'un document
Chaque document est accessible par un URL EX "URL"(Uniform Ressource LocatorEX "Uniform Ressource Locator") indiquant son site et son type selon la syntaxe :
 LIENHYPERTEXTE file://[nom_utilisateur@]nom_serveur/chemin_d'accès file://[nom_utilisateur@]nom_serveur/chemin_d'accès
Exemple
 LIENHYPERTEXTE ftp://enpc.fr/pub ftp://enpc.fr/pub
 LIENHYPERTEXTE http://www.larc.nasa.gov/cgi-bin/NTRS http://www.larc.nasa.gov/
 LIENHYPERTEXTE ftp://ftp@foo.bar.edu ftp://ftp@foo.bar.edu
Page d'accueil
Un utilisateur peut créer son propre site Web et y créer ses propres pages d'accueil, par utilisation du protocole de représentation htmlEX "html".
Un portail permet d'accéder à d'autres sites Web grâce aux liens hypertextes qu'il contient.
Le service des news
Le service des news est l'équivalent sur l'Internet de groupes de discussion, de tableau d'affichage (BBS), de forum télématiques.
Principes du système
Les nouvelles (news) sont organisées par thème d'intérêt appelés newsgroups, organisés de façon hiérarchique.
Il existe actuellement près de 5000 serveurs de News.
De nombreuses applications clientes lecteur de news sont disponibles.
Les articles accessibles sur le site local sont stockés dans le répertoire /usr/spool/newsEX "/usr/spool/news".
Le service des news le plus important est constitué par le réseau Usenet, organisé en 7 grandes catégories :
comp informatique, architecture matérielle et logicielle,
news problèmes réseau et logiciels,
rec loisirs, arts,
sci activités de recherche et développement,
soc problèmes sociaux,
talk forum de débats,
misc tout ce qui ne rentre pas dans les catégories précédentes.
INCORPORER Designer \s \* fusionformat
Fonctionnalités d'un lecteur de news
Les principales fonctionnalités sont les suivantes :
navigation dans les groupes de news,
sauvegarde et contrôle des articles lus,
abonnement et désabonnement à un groupe de news,
sélection automatique et suppression d'un groupe,
mise en forme, émission, réponse à des articles.
Commandes usuelles
Nous présentons dans le présent paragraphe la syntaxe des commandes (DARPA et Berkeley) les plus usuelles ainsi que quelques commandes de statistiques d'état du réseau.
Rappelons que l'internaute utilise implicitement ou explicitement toutes ces notions.
Notions sur la Base de données réseau
De nombreux fichiers, constituant la base de données réseauex "base de données réseau", sont nécessaires pour l'utilisation des services réseau. Nous présentons ici ceux que l'utilisateur doit connaître.
/etc/hostsex "/etc/hosts"
Toute station d'un réseau local sous ethernet est définie par 
son adresse physique (adresse ethernet ou modem),
son nom symbolique,
son adresse réseau (adresse IP).
Le fichier /etc/hosts assure la correspondance entre le nom symbolique et son adresse IP.
Adresse IP
Elle est représentée sur 4 octets, en notation décimale pointée : 192.5.6.18. Elle contient deux informations : l'adresse IP du réseau et le numéro du poste de travail dans le réseau.
adresse IP nom symbolique IP
non arbitraire arbitraire
alloué par le NIC choisi par l’administrateur du site

Rappelons que NIC signifie Network Informations Center. Elle est retrouvée par un serveur de noms (DNS) si nécessaire.
Le 1er octet permet de distinguer :
les "gros réseaux (classe A)" 0 <
Texte du message
...
EOF
Il est également possible d'envoyer un message dont le texte est dans un fichier en utilisant le principe de la redirection.
mail -s "Objet du message"< fichier nom_utilisateur
Exemple 2
mail  LIENHYPERTEXTE mailto:philipp@soc philipp@soc  LIENHYPERTEXTE mailto:guy@chef guy@chef
Subject : essai
Il fait beau.
..
EOF
Dans cet exemple, le message envoyé par dupond va transiter sur le réseau et ira renseigner les boites aux lettres de philipp et guy qui se trouvent respectivement sur les stations soc et chef.
Lors de la connexion d'un utilisateur, le système lui notifie l'instance d'un courrier par le message :
You have mail
Exemple 3 : réception
Pour lire un courrier électronique en instance, il suffit d'exécuter la commande mail(x) sans argument. L'agent utilisateur affiche alors :
Mail version SMI 3.0 Tue Nov 10 10 :10 PST 1987 Type ? for help
From  LIENHYPERTEXTE mailto:dupond@soc dupond@soc Mon may 27 14 :59 15/280 Essai
&
Pour lire le contenu du message, il suffit alors de taper RETURN
Message1 :
from  LIENHYPERTEXTE mailto:dupond@soc dupond@soc. Mon May 27 14 :59 :59 1990
Return-Path : 
Received : from soc.fl.com by soc.fl.com (4.0/SMI-4.0)
id AA08265; Mon 27 May 90 15 :00 :00 +0200
Received : by soc.fl.com (3.2/SMl-3.2)
id AA22480; Mon 27 May 90 15/xxxxx
Date : Mon, 27 May 90 15 :01 :02 +0200
From :  LIENHYPERTEXTE mailto:dupond@soc dupond@soc (Donald)
Message-Id : 
To :  LIENHYPERTEXTE mailto:philipp@soc philipp@soc,  LIENHYPERTEXTE mailto:guy@chef guy@chef
Subject :
Il fait beau.
&
Services répartis et distribués
Nous présentons cidessous les services offerts par les protocoles NFS et NIS.
NFS
NFS est un protocole de niveau application qui permet à des serveurs d'exporter des systèmes de fichiers à travers le réseau. Il est indépendant du système d'exploitation en fournissant un accès transparent aux fichiers dans un environnement hétérogène. Les accès distants utilisant la même syntaxe que les accès locaux, ils sont généralement transparents pour les utilisateurs et les processus d'application. Toutefois, la sémantique étant différente, cela peut quelquefois poser des problèmes.
Les performances sont raisonnables car le temps d'accès à un fichier via NFS est de l'ordre de 80 % de celui du temps d'accès à un fichier local. Le protocole NFS est un des standards du marché.
Les systèmes de fichiers exportables par un serveur de fichiers NFS à des stations clientes sont définis dans le fichier /etc/exportsex "/etc/exports". La commande de montage d'un système de fichiers mount est étendue aux systèmes de fichiers distants via NFS. Un client monte (mount) ou démonte (umount) un système de fichiers exportable d'un serveur. Un point de montage sur une station serveur peut se trouver n'importe où dans l'arborescence du client. Les systèmes de fichiers distants sont montés sur des répertoires locaux et un répertoire distant est alors accessible comme s'il s'agissait d'un répertoire local.
Exemple : soit la configuration suivante avant le montage :
INCORPORER Designer \s \* fusionformat
Soit les commandes de montage suivantes :
station A
mount -t NFS B:/usr/users/src /usr2/proj1/src
station B
mount -t NFS A:/usr2/divers /usr/divers
station C
mount -t NFS A:/usr2 /usr2
mount -t NFS A:/usr/bin /usr/bin
mount -t NFS B:/usr/users /usr/users
On obtient la configuration logique :
INCORPORER Designer \s \* fusionformat
Architecture de NFS
Les systèmes de fichiers sont gérés comme des protocoles réseaux en utilisant une architecture en couche.
L'idée est de faire toutes les opérations d'entrée/sortie sur un système de fichiers virtuelEX "système de fichiers virtuel", interfacé avec le système de fichiers réel, masqué à l'application.
La couche correspondante est la structure VNODE.
INCORPORER Designer \s \* fusionformat
NIS
Les services distribués sont accessibles par une clé d'accès appelée listeex "liste" ou quelquefois carteex "carte" (traduction du mot mapex "map"). Un domaineex "domaine" définit la portée d'un ensemble de listes et chaque station du réseau appartient à un domaine unique.
Exemples
Les droits d'accès d'un utilisateur sur une station sont définis dans le fichier /etc/passwd local par son identificateur (User ID UID ) et son numéro de groupe (Group ID GID ) qui peuvent être étendues au réseau grâce aux listes passwd et group.
Un utilisateur a alors une identité unique sur toute station du réseau sauf s'il y est redéfini dans son fichier /etc/passwd local.
La liste passwd contient la liste des noms des utilisateurs du réseau. Pour des raisons de sécurité l'utilisateur root d'une station devient l'utilisateur nobody sur une station distant.
La liste hosts contient les noms symboliques des stations et leur adresse IP. Elles constituent un domaine définit dans le fichier /etc/hosts du serveur NIS maître.
Quand les listes ne sont pas installées, toute recherche d'une adresse IP nécessite la lecture du fichier local /etc/hosts.
L'ajout d'une nouvelle station sur le réseau nécessite la modification d'un de ces fichiers sur chaque station du réseau.
Quand les listes sont installées, un programme qui veut lire le fichier /etc/hosts ou le fichier /etc/networks consulte les listes correspondantes pour obtenir l'information.
La mise à jour d'une liste est le plus souvent faite par l'administrateur.
Pour des raisons historiques, les nom de l'ensemble des commandes NIS commence par yp.
Informations générales sur l'état du réseau
dfex "df" 
liste des systèmes de fichiers montés en local et en réseau, affichage de l'espace disque disponible.
Exemple
Filesystem kbytes used avail capacity Mounted on
pss:/export/root/sparc2 121599 112413 6754 94% /
pss:/export/exec 121599 112413 6754 94% /usr
swap 6740 4 6736 0% /tmp
...
pss:/usr/spool/mail 72335 59090 6011 91% /var/spool/mail
pss:/usr2/prof 175791 141659 16552 90% /usr2/prof
pss:/usr2/etudiants 157231 137245 16841 89% /usr2/etudiants
hostname, uname -a
ex "hostname"nom symbolique de la station en cours d'utilisation.
ps
ex "ps"état des processus actifs sur le poste de travail.
Exemple
ps -ealf
USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND
philipp 1965 3.9 1.5 28 108 p0 S 15:07 0:00 /bin/sh
philipp 1951 0.0 4.8 128 344 co S 15:04 0:00 xload
...
rupex "rup" et ruptimeex "ruptime"
Affichage de la charge des stations du réseau. La commande rup utilise le protocole RPC et la commande ruptime le processus démon rwhod.
rwhoex "rwho" et rusers
Affichage, à partir du démon rwhodex "rwhod" de l'état approximatif des utilisateurs du réseau (à trois minutes près). Ce démon consomme beaucoup de CPU. Il est donc conseillé de ne pas l'utiliser et d'utiliser rusersex "rusers".
ypcatex "ypcat" nom_liste : affichage du contenu d'une liste.
yppasswdex "yppasswd"
Permet à un utilisateur d'un domaine de changer son mot de passe dans tout le domaine depuis n'importe quelle station la commande passwd n'étant pas adaptée car elle modifie le fichier local /etc/passwd. La version 4.1.1 de SUNOS remplace la commande yppasswd par une commande passwd généralisée au réseau.
Les contraintes classiques de sécurité augmentent sur un réseau car il est plus difficile d'en contrôler les accès.
L'interface graphique XWindow
Généralités sur XWindow
Une des applications les plus spectaculaires des services TCP/IP est la gestion de l'environnement multi-fenêtres.
Le succès d'UNIX provient incontestablement des possibilités graphiques des stations de travailex "station de travail". Equipées d'un processeur puissant, d'un écran bitmapex "écran bitmap", elles permettent de disposer d'outils graphiques très performants : écran de 14 à 21 pouces, avec des définitions graphiques de l'ordre de 1600*1200 pixels.
Le plus connu des environnements multi-fenêtres sous UNIX est XWindow. Il a un tel succès que des terminaux adaptés à son utilisation ont été commercialisés : les Terminaux Xex "terminal X". Ils sont moins coûteux qu'une station de travail, mais ne permettent de travailler qu'avec un environnement s'appuyant sur les bibliothèque X11 (par exemple MOTIF de l'OSF ou OPENWINDOW de SUN).
Historique
L'informatique a intégré la notion d'ergonomie pour ex "ergonomie"simplifier l'accès aux services système. Cette approche s'est concrétisée par la définition de la notion d'interface hommemachineex "interface hommemachine" : une souris, un écran graphique, une interface conviviale.
Le premier système de fenêtrage est du à XEROX. Apple l'a intégré dans le système LISA, puis a commercialisé le McIntosh, avec le succès que l'on connaît. Cette notion a été reprise dans le monde PC avec Windows (3.xx, 9x, NT, 2000, XP), dans le monde UNIX avec XWindowex "XWindow".
Le système XWindow est issu du projet ATHENA, développé au MIT. L'objectif était de développer des protocoles et une interface permettant le partage de ressources graphiques dans un environnement hétérogène.
On distingue les versions suivantes :
1982 Etude du système W par P.Asente,
1984 Premier système X,
1988 X11 R3, première version stabilisée,
1991 X11 R5, encore très utilisée,
1994 X11 R6, base des versions actuelles.
XWindow est un produit du domaine public, portable, écrit en C, indépendant de toute architecture matérielle. Il s'interface également avec les programmes LISP ou ADA.
Le consortium Xex "consortium X", crée en 1988 permet de contrôler le développement et l'évolution des produits dérivés. Il incite les constructeurs et les éditeurs de logiciels à développer des systèmes d'interface standards dans un environnement X.
L'environnement commun en 2002 est basée sur CDE (HP, SUN, IBM, CALDERA) ou KDE (Linux).
Architecture de XWindow
Le système de multi-fenêtrage XWindow offre des services de haut niveau (applications fonctionnant dans un environnement multi-fenêtres) et des services de bas niveau (possibilité de développer ses propres applications en langage C à partir de la bibliothèque Xlibex "Xlib" ou des boites à outils (XToolkitex "XToolkit"). Le protocole de dialogue entre des applications distantes s'appuie sur les couches réseaux des protocoles TCP/IP ce qui permet à des systèmes hétérogènes de fonctionner dans un environnement multi-fenêtres réparti. Certaines applications peuvent fonctionner simultanément sur plusieurs stations, suivant le modèle serveur-clientex "modèle serveur-client".
L'architecture de X11 est constituée des couches suivantes :
couche application (application X),
couche présentation (interface hommemachine par exemple MOTIF),
couche boite à outils (Tool Kit),
couche XtIntrinsics, description des objets de base,
couche Xlib,
couche protocole X,
couches de transport (TCP/IP et/ou DECNET).
INCORPORER Designer \s \* fusionformat
L'interface homme-machine (IHM)
Cette couche permet l'intégration et l'utilisation des services et applications X11. L'interface normalisée utilise des techniques d'origine DEC, HP et IBM.
Il existe d'autres interfaces similaires. L'intérêt de cette approche est l'utilisation du langage Postscriptex "Postscript" pour la gestion de l'affichage, très performante.
Le système Linux offre les interface graphiques Win9x, gnome, kde, motif, X11, etc.
Les boites à outils
Les boites à outils (toolkits) sont des bibliothèques de haut niveau s'appuyant sur la bibliothèque Xlib. Elles implémentent un ensemble d'interfaces utilisateur de gestion des fenêtres appelés widgetsex "widget", acronyme de window gadget.
Les boites à outils rapprochent la programmation d'applications sous X11 de la programmation orientée objet et tendent à en normaliser l'interface utilisateur.
Une boite à outils est constituée par :
des fonctions intrinsèques de construction de widgets,
des interfaces utilisateurs tels la gestion des boutons, des menus déroulants, des boites de dialogue, la création de ses propres widgets.
La couche Xt Intrinsic intègre la description des objets de base utilisés par les boites à outils.
Plusieurs boites à outils ont développées par OSF, HP, DEC, SUN, ATT. Elles offrent des fonctionnalités similaires, quelquefois incompatibles.
La bibliothèque Xlib
Les répertoires standards utilisé par XWindow sont accessibles à partir du répertoire /usr/local/X11.
La Xlibex "Xlib" est une bibliothèque de primitives de bas niveau écrites en C du système XWindow. Elle est constituée de fonctions pour :
créer des fenêtres,
faire des dessins,
prendre en compte des événements,
réaliser des connexions à un serveur donné.
Les appels à la Xlib sont identiques sur toutes les stations et représentent le premier niveau de compatibilité totale.
Ils sont convertis dans le protocole X qui utilise les services fournis par les protocoles TCP/IP ce qui assure la complète transparence des protocoles réseau de niveau inférieur. Il est ainsi possible d'exécuter une application sur une station et de l'afficher sur une autre, même d'architecture différente.
INCORPORER Designer \s \* fusionformat
Les applications X
Les applications X constituent une couche de logiciels qui s'appuient directement sur la couche Xlib, la couche Tool Kit, ou les deux.
Elles peuvent être développées dans un quelconque langage de programmation. Un grand nombre d'applications clientes sont fournies avec la distribution X11 : xclock, xload, xbiff, xman, etc.
L'environnement X est indépendant d'un constructeur et les applications X sont portables.
Elles s'appuient sur un réseau TCP/IP ou DECNET de façon transparente et peuvent communiquer avec tous les serveurs X d'un réseau. Une application X s'exécutant sur un processeur peut accéder à toute station ou terminal X.
Le système d'affichage gère des applications locales ou s'exécutant sur d'autres processeurs ce qui permet un affichage sur le même ou sur un autre processeur, sur plusieurs stations de travail ou terminaux X.
Exemples
bitmapex "bitmap" édition d'un fichier bitmap,
xbiffex "xbiff" affichage de l'arrivée d'un courrier,
xcalcex "xcalc" calculatrice,
xclockex "xclock" affichage d'une horloge,
xdbxex "xdbx" débogueur symbolique sous X11,
xdprex "xdpr" recopie immédiate d'une fenêtre sur l'imprimante,
xdpyinfoex "xdpyinfo" information relative à un serveur X donné,
xeditex "xedit" éditeur de texte graphique multifenêtres,
xeyesex "xeyes" affichage d'une paire d'yeux suivant la souris dans son mouvement,
xfdex "xfd" visualisation d'une police de caractères,
xfedex "xfed" éditeur graphique de police de caractères,
xfontselex "xfontsel" sélection d'une police de caractères,
xhostex "xhost" autorisation d'affichage d'applications clientes s'exécutant sur d'autres stations,
xkillex "xkill" destruction d'une application cliente,
xloadex "xload" affichage de la charge de la station,
xlogoex "xlogo" affichage du logo X11,
xlsfontsex "xlsfonts" affichage de la liste des polices de caractères (fonte) disponibles,
xmanex "xman" utilisation de la documentation en ligne sous X11,
xmodmapex "xmodmap" modification des tables de transcodage associées au clavier,
xmoreex "xmore" similaire à la commande UNIX more,
xprex "xpr" mise en forme d'un fichier produit par xwd pour impression,
xpropex "xprop" affichage des propriétés des fenêtres et des polices d'un serveur X,
xrefreshex "xrefresh" rafraîchissement de l'écran,
xsetex "xset" préférence de l'utilisateur pour le display associé au serveur X,
xsetrootex "xsetroot" modification de l'apparence de la fenêtre racine,
xtermex "xterm" ouverture d'une fenêtre d'émulation vt100,
xwdex "xwd" recopie d'une fenêtre X dans un fichier bitmap,
xwinfoex "xwinfo" information sur les différentes fenêtres X11 actives,
xwudex "xwud" visualisation dans une fenêtre d'un fichier crée par l'application xwd.
Les gestionnaires de fenêtres
Généralités
Les gestionnaires de fenêtresex "gestionnaire de fenêtres" (Window Managerex "Window Manager") sont des applications clientes exécutées en mode différé (background), une seule à la fois.
Ils permettent à l'utilisateur d'organiser et de gérer les fenêtres par l'utilisation de menus déroulants. Les opérations sur les fenêtres sont le déplacement, la modification de la taille, la suppression, l'iconification, le recouvrement. Les utilisateurs peuvent modifier les menus par modification de shell scripts avec un éditeur.
Display et screen
Displayex "Display" : c'est le triplet {écran virtuel, clavier, souris}, représentant l'adresse logique de l'affichage de l'application.
Screenex "Screen" : c'est le moniteur (écran réel).
Un display peut être composé de plusieurs screens.
Un screen peut contenir plusieurs displays :
une fenêtre en noir et blanc est le display 0,
une fenêtre en couleur est le display 1.
Serveur X
Un serveur Xex "serveur X" s'exécute sur des systèmes supportant des displays (stations ou terminaux X). Il assure les fonctionnalités suivantes :
établissement des liens entre le logiciel et le matériel,
gestion des événements issus de différentes applications clientes,
traduction de ces événements en requêtes pour les pilotes de périphériques,
répartition des événements et réponses aux applications clientes,
exécution des requêtes issues d'un ou plusieurs displays d'applications clientes s'exécutant sur des stations différentes.
Le serveur et le client sont donc découplés. La syntaxe d'affichage est :
hostname:serveur.screen
Evénement
La transmission d'informations entre le client et le serveur est réalisée suite à un événementex "événement" : par exemple "cliquer" sur la souris dans une fenêtre. L'application cliente transmet ces informations au serveur X pour leur prise en compte.
Déroulement d'une application X
connexion avec le serveur X,
création de fenêtre(s),
boucle de traitement des événements en provenance du serveur X et emission de requêtes,
fermeture de la connexion avec le serveur ce qui provoque la libération de l'ensemble des ressources allouées pour l'application.
Terminal X
Un terminal X est un constitué d'un clavier, d'un écran et d'un souris. Il comporte un processeur et des ressources mémoire permettant de charger et d'exécuter le programme serveur X. Il dialogue avec un serveur CPU par l'utilisation des protocoles bootp EX "bootp"ou tftp EX "tftp"et du protocole X.
INCORPORER Designer \s \* fusionformat
Lancement de X11
Deux possibilités se présentent lors du démarrage d'une session X :
le serveur X est inopérant. Il faut donc le lancer préalablement à toute exécution d'une application X,
un gestionnaire de session est actif ainsi qu'un serveur X. Dans ce cas, une fenêtre X d'identification est active et l'utilisateur accède directement à l'environnement X11.
Serveur opérant
C'est le cas par exemple des terminaux Xex "terminal X" : le programme xdmex "xdm" substitue au programme login une fenêtre proposant des fonctionnalités similaires à celles d'un terminal fonctionnant en mode caractère : gestion du login et du mot de passe dans l'environnement X11.
Serveur inopérant
Le programme xinitex "xinit" initialise le serveur X ainsi que la première application cliente, indispensable si l'utilisateur veut reprendre la main à la terminaison de sa session X11. Il est ensuite nécessaire de lancer un gestionnaire de fenêtres.
Réseaux bureautiques
Connexion PCTCP/IP
Port série
Des micro-ordinateurs peuvent être interconnecté avec les protocoles TCP/IP à partir d'un port série et d'un logiciel de communication tel kermitEX "kermit", EX "xtalk"EX "pc-interface"EX "locus" pc-nfsEX "pc-nfs", (débit historiquement limité à 9600 bits/s) ou d'un modem ce qui leur permet d'accéder au réseau Internet.
Réseau local
Le protocole NFS est un standard du marché et permet à des PC ou à des McIntosh d'accéder aux services NFS avec un logiciel de communication sur un réseau ethernet.
Ce type de logiciel rend les services suivants :
accès transparent depuis un PC sur des ordinateurs partageant des ressources avec le protocole NFS,
accès partagé aux données des serveurs NFS et utilisation de ces derniers comme disque dur virtuel du PC (de e: à z:) avec possibilité de stocker du binaire au format interne PC (fat 16, fat 32, NTFS) sur des systèmes de fichiers virtuels,
utilitaires de conversion des fichiers ASCII issus du monde PC vers le monde UNIX et réciproquement,
accès aux imprimantes du réseau,
configuration d'imprimantes distantes,
service d'impression sur des imprimantes distantes (protocole lpd),
transfert de fichiers avec le service ftp,
accès aux listes NIS,
statistiques d'utilisation du réseau,
service client telnet.
Protocoles de démarrage des PC
Les protocoles DHCP EX "DHCP"(Dynamic Host Configuration ProtocolEX "Dynamic Host Configuration Protocol") et bootpEX "bootp" permettent de résoudre les contraintes de l'installation ou de la mise à jour d'une station sur un réseau. Ils permettent en particulier à un PC de démarrer et de se connecter automatiquement au réseau par téléchargement des paramètres nécessaires.
Le monde McIntosh
Il est possible d'intégrer des McIntosh sur un réseau ethernet. Il suffit d'utiliser la couche MacTCP. Sur le serveur UNIX, un logiciel tel ethershare permet à la station McIntosh de voir la station UNIX comme une autre station McIntosh et de partager des ressources avec le serveur UNIX.
L'architecture Novell
Historique
Le système d'exploitation multitâches Netware, développé pour intégrer des PC dans des réseaux hétérogènes fut développé par Novell en 1986. Ses différentes versions sont les suivantes :
Netware LITE permet de gérer de 2 à 25 postes (entrée de gamme),
Netware 2.x permet de gérer jusqu'à 100 postes de travail,
Netware 3.x permet de gérer jusqu'à 250 postes de travail,
Netware 4.x est utilisé sur les sites multiserveurs,
Netware for UNIX.
Services
Il offre les services suivants:
interconnexion de tout les types de réseaux sur n'importe quel type de support,
courrier électronique,
administration,
gestion de la sécurité.
Parts de marché
Novell a une part de marché de l'ordre de 40% des réseaux locaux d'entreprise.
Le système Netware est doté des fonctionnalités suivantes : serveur de fichiers, d'applications, et d'imprimantes pour les applications clientes.
Netware 3.11
Netware est un système d'exploitation multitâches orienté télécommunications. Il gère des clients hétérogènes DOS, OS/2, UNIX, Windows 3.x, Windows 9x. Les postes clients voient les fichiers du serveur mais la réciproque n'est pas vraie.
Le serveur Netware est une station dédiée qui peut coopérer avec un serveur UNIX.
La couche ODI permet de s'interfacer de façon transparente avec les couches hautes du modèle OSI.
Les protocoles de niveau réseau sont IPX et SPX, propres à Novell. Ils s'interfacent avec les mondes TCP/IP, SNA, AppleTalk, OSI.
Les communications avec le monde UNIX sont aujourd'hui réalisée soit par TCP/IP, soit par IPX/SPX.
Netware 4.0
Gère la messagerie X400, le service d'annuaire X500, les interfaces graphiques OSF/MOTIF et Open Look, jusqu'à 1000 utilisateurs.
Netware For UNIX
Netware 3.11 a été portée sur UNIX par IBM (RS/6000 et DPX/20) ce qui permet à une station UNIX de devenir serveur Netware sur architecture RISC.
Unixware
Unixware est un système d'exploitation UNIX qui permet à une station UNIX d'être serveur ou client Netware.
L'architecture client-serveur et les bases de données
Historique
Dans les années 70, les systèmes d'informations étaient centralisés (architecture en étoile). UNIX est arrivé, avec le C, la portabilité, les réseaux, les stations de travail, les principes d'interopérabilité, les interfaces graphiques multifenêtres, les microordinateurs ce qui a rendu les systèmes centralisés obsolètes.
La philosophie de l'architecture clientserveur
Le serveur gère la base de données (la plus générale possible),
Le client gère l'interface utilisateur. Il est doté de plus en plus de ressources lui permettant d'exécuter des traitements locaux de plus en plus complexes.
Le principe est que le serveur et le client doivent coopérer en utilisant un réseau ce qui pose des problèmes de synchronisation, de répartition de charges (load balancing), de gestion de la fiabilité des transactions entre les serveurs et les clients. L'objectif est de déplacer les processus clients s'exécutant sur le poste serveur vers le poste client de telle sorte que la station cliente soit capable localement d'exécuter la "plus grande partie du traitement possible".
Serveur
Le système d'exploitation du serveur est le système UNIX dans 95% des cas.
Le SGBD relationnel est constitué d'une interface hommemachine (L4G), d'un langage de requêtes (SQL), d'un moteur.
Normes
Il existe trois groupes de normes
SQLEX "SQL"
Trois normes : SQL1 (1989) constituée des niveaux 1 et 2, SQL2 (1992) constituée des niveaux entry, intermediate, full, SQL3, pour les bases de données orientées objet.
Tous les éditeurs de base de données sont regroupés au sein du SQL Access GroupEX "SQL Access Group" (SAG), fondé en 1989.
RDAEX "RDA"
Le RDA (Remote Data AccessEX "Remote Data Access"), crée par le SAGEX "SAG", permet l'échange de données entre bases hétérogènes. Il introduit la notion d'acquittement à deux phasesEX "acquittement à deux phases" ou encore commit à deux phasesEX "commit à deux phases" pour résoudre le problème de la cohérence de la distribution des données, alors que la norme SQL ne permet que d'en formaliser l'accès.
CLI
Un pré compilateur, dépendant du SGBD, est nécessaire pour interpréter des instructions SQL dans un programme. La norme CLIEX "CLI" (Call Level InterfaceEX "Call Level Interface") permet de disposer d'instructions SQL, indépendantes du SGBD. C'est un ensemble d'API normalisé permettant d'appeler directement des instructions SQL, implémentées sous forme de pilotes vers le SGBD, depuis un programme C ou C++. Le fournisseur du SGBD se contente de fournir le pilote adéquat (Pro*C avec Oracle, ODBC avec Microsoft...).
Il existe aujourd'hui essentiellement deux types de SGBG :
les SGBD relationnels (SGBDR),
les SGBD orientés objets (SGBDOO).
Le moteur
Le moteur constitue l'élément essentiel du SGBDR dans sa partie serveur.
Moteur multithreads
Certains constructeurs ont implémenté des serveurs multithreadsEX "multithreads" permettant de gérer simultanément plusieurs flots de données dans une même unité d'exécution. Leur implémentation dépend de celle du système d'exploitation car elle peut être basé soit sur un noyau multithreads (mono ou multiprocesseurs), soit sur un moteur multithreads (par exemple ORACLE); dans ce cas, la gestion de l'activité multiple, que le noyau du système d'exploitation ne "voit" pas, est reléguée au niveau applicatif, doté de son propre ordonnanceur.
Moteur multivoies
Plusieurs copies du moteur sont chargées en mémoire, chacune pouvant gérer une flot de données. Un répartiteur de charge en assure l'optimisation.
Moteurs transactionnels
Dans un architecture clientserveur, la validation d'une transaction distribuée est plus complexe. Il a donc fallu définir la notion de commit à deux phasesEX "commit à deux phases" et de rollback (retour arrière)EX "rollback".
Les SGBDOO
Les déclarations et les structures des données de base sont fournies sous forme objet. On y trouve les notions de :
objet, objet complexe,
classe, type, méthode,
encapsulation, instanciation,
héritage,
polymorphisme
résolution tardive (late binding).
L'intégration entre le langage de programmation et la base de données est très forte car son but est d'uniformiser les trois composantes d'une application clientserveur à savoir :
l'Interface Homme Machine,
le langage de programmation,
le système de base des données en le rendant objet.
L'architecture est alors intégralement orientée objet ce qui permet au développeur de disposer d'une représentation unique des objets.
Aux états Unis, deux groupes de normalisation : l'OMGEX "OMG" (Objet Management GroupEX "Objet Management Group") et l'ANSI.
Dans le monde objet, le langage SQL devient le langage OQL.
Les clients
Interface Hommemachine
Windows et/ou XWindow : Windows est un des standards du marché sur les PC, XWindow est la norme du monde UNIX qui fonctionne sans problème dans les environnements Windows.
Les générateurs d'interface graphique et de requêtes SQL
Deux types de produits : les interprétés et les compilés.
les interprétés génèrent des ordres SQL encapsulés. Ils permettent la programmation événementielle. Ils ne sont pas tous orientés objets.
les compilés génèrent une interface graphique avec le langage C ou C++ ce qui permet au programmeur d'ajouter ses propres traitements.
La norme ODBC (Microsoft)
ODBC EX "ODBC "(Open Data Base ConnectivityEX "Open Data Base Connectivity") est une interface d'accès aux systèmes de gestion de bases de données relationnelles ou non dans des environnement hétérogènes, disponible depuis 1992 permettant à un même client d'accéder simultanément à plusieurs serveurs de bases de données. C'est un standard du marché, supporté par de nombreux éditeurs de logiciels.
DCE
L'environnement DCEEX "DCE" (Distributed Computing EnvironnementEX "Distributed Computing Environnement") fait apparaître un réseau de machines de différents constructeurs comme un unique ensemble de ressources partageables sur une même machine virtuelle. Les technologies de base utilisées par DCE sont :
le service RPC,
le service de noms,
le système de sécurité dérivé de Kerberos
la gestion de l'activité multiple au niveau applicatif (Pthreads),
la gestion distribuée de l'heure,
un système de fichiers distribués.
DCE est utile dans les applications où il est nécessaire :
de gérer des ressources distribuées,
d'une optimisation des ressources,
d'applications portables.
DCE est complexe d'utilisation. Il est puissant pour aider à résoudre des problèmes de répartition des données utilisant des algorithmes complexes sur ces données.
Tuxedo
Les SGBD permettent de faire des requêtes SQL à travers le réseau sur plusieurs bases de données simultanément. Il est possible également de distribuer des transactions dans un réseau.
Tuxedo est un moniteur transactionnel ouvert, portable, et indépendant du SGBD, développé par USL. Ses propriétés sont les suivantes (ACID) :
atomicité : une transaction doit être insécable,
consistante : les mises à jour doivent toujours rester cohérentes sur les différentes stations,
isolation : le résultat d'une transaction ne doit pas dépendre d'autres traitements en cours,
durabilité : une transaction doit être fiable, même en cas d'incident.
Architecture
L'application cliente fait la saisie sur la station cliente.
Sur la station serveur, il y a :
le SGBD,
le moniteur transactionnelEX "moniteur transactionnel" (TMEX "TM" ou Transaction ManagerEX "Transaction Manager"),
l'application serveur.
L'application cliente et l'application serveur peuvent être des stations quelconques du réseau.
Les relations entre l'application cliente et le moniteur transactionnel sont réalisées selon le protocole ATMI.
Les dialogues entre l'application serveur et le SGBD utilisent le langage SQL.
Le moniteur transactionnel utilise l'interface XA pour gérer le commit à deux phases et le roolback.
Il peut y avoir plusieurs moniteurs transactionnels. Toutefois, le poste client n'en verra qu'un seul, même si des transactions sont réparties sur plusieurs sites.
Les services de Tuxedo sont répertoriés dans le Bulletin Board, qui est le moniteur de l'ensemble des transactions et qui contient en outre l'état des services ainsi que des statistiques. Il assure également le service de nommage.
Avantages de Tuxedo
gestion d'un grand nombre d'utilisateurs,
optimisation de la gestion des ressources,
gestion de l'intégrité des données par l'interface XA,
haute disponibilité car les transactions pouvant être présentes sur des serveurs différents.
Connectivité avec les gros systèmes traditionnels (mainframes)
Tuxedo permet d'accéder aux bases de données sur gros systèmes (CICS, DB2...).
Encina
Ce produit s'appuie entièrement sur l'architecture DCE. Sur la station serveur, les couches suivantes sont nécessaires :
UNIX et DCE,
Encina Base,
Encina Serveur (ou Encina Toolkit),
Encina Moniteur.
Sur le client, on n'utilise que les couches :
UNIX et DCE,
Encina Base.
La couche Encina serveur
Elle assure les fonctions suivantes : loging, journalisation, verrouillage de ressources, interface XA.
Trois modules de services assurent en outres les fonctions suivantes
SPF permet de gérer des fichiers de type C-ISAM, X-ISAM, VSAM
PPC gère la distribution des données dans le réseau local avec TCP/IP,
PPC est une passerelle avec le monde SNA.
Le module Encina Moniteur
Ce module gère les fonctions transactionnelles proprement dites. Il utilise le module RPC pour la gestion des requêtes distantes et le module Directory Service pour la localisation des ressources. La sécurité est assurée par le module Kerberos.
Conclusions
Tuxedo
Tuxedo permet de choisir un SGBD et d'en interroger plusieurs. Il assure une meilleure gestion des ressources grâce à un équilibrage automatique des charges (load balancing).
Il garantit l'indépendance des applications clientes et serveurs qui peuvent s'exécuter sur n'importe quelles stations du réseau. Le dialogue entre serveurs est assuré par le moniteur transactionnel, qui identifie les transactions en cours ainsi que les serveurs sur lesquelles elles s'exécutent. Une transaction peut également être dupliquée sur plusieurs serveurs.
Encina
Encina est basé sur les normes et les standards utilisés dans le monde des systèmes ouverts. Les développements sont réalisés en langage C.
Les organisme ISO et X-OPEN travaillent à la normalisation du monde du transactionnel sur le modèle DTPEX "DTP" (Distributed Transaction ProcessingEX "Distributed Transaction Processing").
Moniteur transactionnel ou SGBD
Le choix est fonction de l'importance de la base et du nombre d'utilisateurs.
Dans le cas d'une simple base avec peu d'utilisateur, le SGBD est suffisant.
Si le nombre d'utilisateurs augmente, le moniteur transactionnel assure de bien meilleures performances sauf si le SGBD est multithreads.
Si on utilise plusieurs bases réparties sur plusieurs serveurs, le moniteur transactionnel est beaucoup mieux adapté.
Règles de conception des SGBD en architecture client-serveur
Le serveur fonctionne sous UNIX.
Le moteur du SGBD doit être multithreads
Le SGBD doit fournir aux postes clients des pilotes ODBC.
Le générateur d'interfaces est un interprète acceptant la norme ODBC.
Le poste client fonctionne sous Windows, Windows/Motif, ou OS/2.
Le protocole réseau de base est TCP/IP.
Le SGBD doit être conforme à la norme RDA ce qui permet de garantir l'intégrité des données.
Il faut respecter les standards pour gagner la liberté de changer de moteur ou de client sans remettre en cause l'ensemble des investissements.
Graphe récapitulatif des services réseaux
 INCORPORER Designer.Drawing.6 
Etudes de cas
Nous présentons ici deux architectures de réseau différentes.
Réseaux UNIX/PC
Les services que l'on peut ainsi assurer sont les suivants : assurer sur les même postes de travail à la fois des utilisations orientées bureautique PC (Windows 9x, NT...) et des utilisations utilisant l'environnement UNIX (utilisation, administration, ou développement) dans l'environnement XWindow.
INCORPORER Designer \s \* fusionformat
Réseaux
Le réseau de l'Enseignement de l'Ecole Nationale des Ponts et Chaussées, se compose des stations suivantes :
4 serveurs UNIX Sun,
80 postes de travail sous Linux/NT.
Les stations sont réparties à Paris et à Noisy-le-Grand dans deux salles de travaux pratiques.
La philosophie du réseau est la suivante :
Les serveurs SPARC
Ils assurent les services suivants : serveurs de disques, d'imprimantes, du réseau de télécommunications, de façon transparente pour les utilisateurs. Ainsi, l'intégralité des fichiers utilisateurs se trouve sur les serveurs.
Services
Les services offerts sont les suivants :
Partage de ressources
NFS permet le partage des ressources quelque soit la station utilisée.
Accès indifférencié à toutes les stations
Un utilisateur est identifié, de façon unique, sur n'importe quelle station du réseau. Cette gestion est assurée par le service NIS.
Interconnexion entre toutes les stations du réseau
On peut se connecter depuis Paris sur les stations de Noisy et réciproquement. On peut ouvrir, sur une station, des "fenêtres" sur les autres stations du réseau et faire des transferts de fichier entre les différentes stations fonctionnant sous UNIX.
Autres services
L'ensemble des services réseau sous UNIX est disponible. Chaque station du réseau a son identité (hostname).
Exercices
Services DARPA-BSD
1°) A partir de la commande hostname ou de la commande uname, identifiez le nom symbolique de votre station. Cet identificateur estil arbitraire ?
2°) A partir du fichier /etc/hosts, identifiez l'adresse IP de votre station. Estelle arbitraire ?
3°) Dans certains sites, le fichier /etc/hosts ne contient pas cette information. Essayer la commande
ypcat hosts
4°) A partir des fichiers /etc/hosts et éventuellement /etc/networks, dressez une cartographie des stations du réseau.
5°) A partir de la commande telnet (ou encore ssh EX "ssh" ), connectez vous sur une station
a) à partir de son adresse IP,
b) à partir de son nom symbolique.
Vous noterez (selon la station sur laquelle vous travaillez) que la commande telnet (ssh) peut être exécutée depuis un poste client sous UNIX, Windows.
c) Sur certains sites, la commande telnet est remplacée par la commande sécurisée ssh que l'on testera comme dans les cas a) et b).
6°) A partir de la commande ftp, faire un transfert de fichiers entre deux stations. Essayer d'utiliser la commande ftp dans deux situations différentes :
a) Vous n'avez pas de mot de passe sur le serveur ftp,
b) Vous avez un mot de passe sur le serveur ftp.
7°) Essayer d'écrire un shell script de transfert de fichiers entre deux stations en utilisant la commande ftp.
8°) A partir de la commande crontab, essayer de lancer ce shell script périodiquement.
9°) Même question que la question n°5 avec la commande rlogin.
10°) A partir de la commande rcp, faire un transfert de fichiers entre deux stations du réseau. Décrire son comportement en fonction du contenu du fichiers hosts.equiv.
11°) Même question en utilisant le fichier .rhosts
12°) A partir des commandes tar, rsh et dd, imaginez une séquence qui permettent de faire une sauvegarde sur une station distante contenant un support magnétique.
13°) Etablir une statistique de la charge du réseau à partir des commandes rup ou ruptime (quand elles fonctionnent).
14°) Quels sont les systèmes de fichiers montés par NFS. Comment pouvez vous y accéder ? A partir des commandes mount, df, et du contenu du fichier /etc/exports, déterminer les droits des stations clientes en lecture et en écriture.
15°) ftp anonyme
Intérêt
Principes de fonctionnement.
16°) Tester la commande nmap EX "nmap"  si elle est disponible.
Outils de communication divers
1°) Etablir un dialogue avec votre voisin en utilisant les commandes talk, write et mesg.
2°) Se protéger d'intrusions intempestives à partir de la commande mesg.
3°) Essayer d'utiliser la commande wall pour envoyer un même message à tous les utilisateurs présents.
4°) Envoyer un courrier électronique à un ou plusieurs voisins. Essayer de lire les messages que vous avez reçus. Les archiver ou les détruire. Vous pouvez également vous constituer un carnet d'adresses, un fichier d'alias et essayer de réacheminer votre courrier.

Exercices sur l'utilisation de XWindow
1°) A partir de la commande shell echo, établir l'adresse d'affichage de l'écran virtuel associé à votre poste de travail.
2°) Lancer des applications X simples (xload, xterm, xclock, xlogo, xcalc, etc.)
3°) Si impossible directement, essayer, à partir de la commande find d'identifier leur répertoire public d'utilisation. Après modification de la variable PATH, exécutez à nouveau la question 2.
4°) Essayez d'afficher le résultat d'exécution d'une application X chez un voisin. Pour cela, il doit vous donner son accord en exécutant la commande xhost +.
5°) Parmi tous les processus actifs, identifier les processus clients X et le processus serveur X.
6°) Recherchez l'application X qui vous permette de changer le fond de votre écran.
7°) Vous voulez utiliser une imprimante laser pour éditer une fenêtre. Indiquer les applications X vous permettant de le faire. Quelle séquence allez vous utiliser ?
8°) Si vous travaillez dans un environnement Windows, changer de gestionnaire de fenêtres. Conclusion.
Bibliographie du présent chapitre
Internetworking with TCP/IP
D.COMER
Editeur : Prentice Hall
Les réseaux sous UNIX
Jacques PHILIPP
Editeur : Presses des Ponts et Chaussées
Le monde Internet - guide et ressources
Ed Krol, Editeur : O'Reilly International Thompson
Bibliographie sur XWindows
X Protocol Reference Manual : volume 0
Xlib Programming Manuel : volume 1
Xlib Reference Manuel : volume 2
X Window System User's Guide : volume 3
X Toolkit Intrinsics Programming Manuel : volume 4
X Toolkit Intrinsics Reference Manuel : volume 5
XView Programming Manual : volume 7
Tous ces ouvrages sont écrits par Valérie Quercia et Tim O'Reilly et sont publiés chez O'Reilly & Associates, Inc.
En français :
PratiX : utiliser et programmer X
Renaud Dumeur, Jean-Alain Le Borgne, Marc Bassini
Edition C2V : 82 Bd Haussmann 75008 PARIS

L'architecture du système de communication TCP/IP dans le monde Unix
Le système de communications BSD
Evolution des communications inter processus avant BSD 4.3
Les seuls mécanismes de communication inter processus existants (le tube ou le fichier), fonctionnent sur une même station. Il sont rudimentaires et lents d'utilisation.
Il y a alors création d'outils de type processus tels cu et uucp. Ces extensions sont dépendantes du système d'exploitation, du système de gestion de fichiers, de l'espace de nommage, de l'implémentation. Ils fonctionnent en mode asynchrone avec des performances très faible. Il devient nécessaire de concevoir des mécanismes de communications inter-processus plus performants. Des mécanismes complémentaires, intégrés dans le noyau, apparaissent progressivement :
UNIX BSD 4.2 les sockets (1979),
UNIX SYSTEM III la gestion des accès concurrents (1982),
Objectifs du système communications inter processus de la version 4.2 BSD
extension des mécanismes de communications inter-processus pour permettre le développement de systèmes répartis, tout en restant dans la philosophie UNIX,
définition d'un cadre d'implémentation de protocoles de communication très général (normes américaines ou normes ISO),
masquage de la gestion des mécanismes spécifiquement système pour décharger au maximum les développeurs de protocoles,
définition d'une structuration solide, indépendante si possible du système d'exploitation,
grande facilité d'utilisation,
mise à disposition d'un espace de nommage étendu aux divers réseaux existants,
masquage des couches de bas niveau,
transparence de l'accès au réseau,
possibilité de communiquer dans des environnements hétérogènes multi-protocoles.
évolutions système V
Les apports des versions UNIX SYSTEM V permettent de compléter puis de réimplémenter les mécanismes précédents :
UNIX SYSTEM V R2 les IPC (mémoire partagée, messages, sémaphores),
UNIX SYSTEM V R3 les streams.
Nous présentons dans le présent chapitre les sockets et les streams. Pour les autres mécanismes, une présentation plus complète est réalisée dans l'ouvrage "UNIX : mécanismes internes" du même auteur.
Architecture du système de communications BSD
Les outils de type processus étant lents et peu performants, la couche socket ainsi que les couches TCP/IP ont été intégrées dans le noyau.
On décompose le système de communications en trois couches de logiciels :
l'interface utilisateur, appelée la couche socket,
l'interface socket-protocole,
l'interface protocole matériel.
INCORPORER Designer \s \* fusionformat
La Couche socket et ses API
Définition d'un socket
L'entité abstraite utilisée pour la transmission de messages entre processus locaux ou distants est la priseex "prise", ou, plus usuellement, le socketex "socket" qui représente un canal logique de communication entre deux processus distants.
L'interface socket, est accessible par des appels système constituant les APIEX "API" (Application Programming InterfaceEX "Application Programming Interface") du système de communications.
Un processus peut donc émettre ou recevoir des informations par l'intermédiaire d'un socket qui sera identifié par un descripteur de même nature que celui des fichiers. Cette propriété est fondamentale car elle permet d'utiliser la redirection des fichiers d'entrées/sorties sur le socket et réciproquement assurant ainsi la communication entre processus distants. Tout processus fils hérite des descripteurs du socket du processus père.
Propriétés sémantiques d'un socket sont les suivantes :
la transmission est fiable car aucune donnée transmise n'est perdue,
les données sont ordonnées car elles arrivent dans l'ordre où elles ont été émises,
les données sont non dupliquées car une occurrence unique d'une donnée arrive à destination,
la communication est orientée connexion car une connexion préalable est établie,
les limites de messages émis sont préservées car retrouvées à la destination,
les données expresses ex "données expresses" (out of band dataex "out of band data") sont supportées.
Définitions
Une paire (peer) du socket est le couple {socket serveur, socket client}.
Des données expresses sont émises et délivrées au processus destinataire indépendamment du flot normal de données.
Une connexion est un mécanisme utilisé pour éviter de devoir transmettre l'identité de l'émetteur avec chaque paquet de données. L'idée est de transmettre l'adresse de chaque point de communication avant l'émission effective et de la conserver de part et d'autre pendant toute la durée de la communication.
Il existe deux modes de dialogue : le mode connectéex "mode connecté" et le mode non connectéex "mode non connecté".
Le dialogue en mode connectéex "dialogue en mode connecté" est dissymétrique. Le processus client a l'initiative du dialogue et émet des requêtes de services au processus serveur. La connexion est de type stream.
Le dialogue en mode non connectéex "dialogue en mode non connecté" est symétrique. L'initiative du dialogue provient indifféremment du processus client ou du processus serveur et la connexion est de type datagramme.
Type, domaines de communication et famille de protocoles
Un socket se caractérise par son mode d'utilisation, son domaine de communication et le protocole utilisé.
Mode d'utilisation
Un socket utilisé en mode datagramme représente un flot bidirectionnel de données non ordonné, non dupliquées pour des communications en mode non connecté. Les limites de messages sont transmises. Le processus peut assurer lui même la gestion des séquencements et de la duplication.
Un socket utilisé en mode streamex "stream" représente une communication fiable en mode connecté qui supporte l'émission de données expresses. C'est un flot bidirectionnel ordonné d'octets non dupliquées et sans limite d'enregistrement comme un tube.
Un socket utilisé en mode raw permet l'accès direct, depuis l'application, aux protocoles de niveau inférieur. Ce type de sockets n'est pas conçu pour l'usage commun mais seulement comme une aide au développeur de nouveaux protocoles ce qui permet à des systèmes hétérogènes de dialoguer entre eux.
Un socket utilisé en mode paquet séquentiel est utilisé pour la commutation par paquets.
Domaine de communication
Le domaine de communicationex "domaine de communication" représente le monde informatique dans lequel le socket est utilisée, par exemple le monde UNIX local, le réseau Internet, ou le réseau Xerox. C'est l'abstraction introduite pour lier les propriétés communes aux processus communiquant à travers les sockets. C'est un des domaines :
AF_UNIX communications locales (nouvelle implémentation des tubes par Exemple),
AF_INET Internet : TCP, IP, UDP, etc.,
...
AF_APPLETALK Réseau Appletalk.
Famille de protocoles
A chaque domaine de communication est associée une famille de protocoles (protocol familyex "protocol family") :
PF_UNIX communications locales
PF_INET TCP, IP, UDP, etc.,
...
PF_APPLETALK Réseau Appletalk
Chaque famille de protocoles est constituée d'un ou de plusieurs protocoles. Par Exemple, les protocoles du domaine de communications Internet sont l'un des suivants :
IPPROTO_ICMP le protocole ICMP,
IPPROTO_GGP gestion des routeurs (désuet),
IPPROTO_TCP le protocole TCP,
IPPROTO_PUP le protocole PUP,
IPPROTO_UDP le protocole UDP,
IPPROTO_RAW gestion des paquets en mode raw,
IPPROTO_MAX limite du nombre de protocoles.
Création
Appel système socket
L'appel système socket crée mais ne permet pas d'utiliser le socket. Même créé, aucun processus ne peut le référencer tel quel et aucun message ne peut lui parvenir.
L'appel système bindex "bind" associe une adresse à un socket. La création d'une connexion entre deux sockets distants nécessite la connaissance par les processus serveur et client de l'adresse du socket du processus destinataire.
Dialogue en mode connecté
Un processus associé à un socket nommé par l'appel système bind peut donner un rendez-vous à un processus distant. Cette opération, généralement asymétrique se déroule selon le modèle client/serveur :
le processus serveur crée un socket, le nomme puis attend une requête de connexion du client (appel système acceptex "accept"),
le processus client crée un socket, le nomme puis émet au serveur une requête d'initialisation de la connexion (appel système connectex "connect").
INCORPORER Designer \s \* fusionformat
Etablissement du dialogue : l'appel système connectex "connect"
Si le socket du processus client n'est pas nommé lors de l'appel système connect, le noyau du système client réalise l'association (descripteur, adresse distante).
Attente de connexion : l'appel système listenex "listen"
Acceptation de connexion : l'appel système acceptex "accept"
L'appel système accept retourne le descripteur associé au nouveau socket avec lequel s'effectuera le dialogue. L'ancien socket sert exclusivement pour le traitement immédiat de l'ensemble des requêtes de connexion.
Rejet d'une connexion
L'appel système rejectex "reject" effectue le rejet d'une requête de connexion.
Echange d'informations
Les entrées/sorties sur des sockets sont bloquantes (état par défaut). Cela implique qu'un appel système d'entrées/sorties est bloqué jusqu'à sa terminaison ou sur erreur.
Les appels systèmes classiques de lecture/écriture (read, write) sont utilisables. Les appels systèmes sendex "send" et recvex "recv" ont une fonction similaire. Ils sont plus précis.
Dialogue en mode non connecté
La création et le nommage des sockets s'effectuent comme en mode connecté.
Emission : l'appel système sendtoex "sendto"
Réception : l'appel système recvfrom
Fermeture d'une connexion
L'appel système close assure la fermeture d'une connexion.
Un socket de type stream continue d'émettre pendant un certain temps, mêma après la rupture d'une connexion. L'appel système close devant opérer une remise fiable des messages, les données à émettre sont conservées dans le tampon d'émission pendant une durée limitée jusqu'à leur destruction en cas d'insuccès de la requête.
L'appel système shutdownex "shutdown" provoque la destruction des données sur l'ensemble des files d'attente concernées. Il est utilisé s'il n'est plus nécessaire de traiter des données en attente. L'utilisateur peut l'exécuter avant l'appel système close.
Graphe d'état d'un socket
INCORPORER Designer \s \* fusionformat
Implémentation SYSTEM V
La version UNIX SYSTEM V Release 3.2 utilise le mécanisme des streams, que nous présentons très sommairement cidessousex "Stream" pour implémenter les sockets. Une présentation plus complète est réalisée dans l'ouvrage "UNIX : mécanismes internes".
Généralités sur les streams
Les gestionnaires des périphériques utilisent souvent les mêmes fonctions, quelquefois de façon différentes.
Les flotsex "flots" d'entrée/sortie ou Streamsex "Stream", ont été introduits par Dennis Ritchie dans la version d'UNIX V8 des Bell Labs.
Cette approche révolutionnaire permet de réimplémenter l'ensemble des mécanismes de communications interprocessus (tubes, tubes nommés, IPC SV R2, sockets) de façon modulaire ce qui permet par Exemple de considérer le système de communications BSD comme un empilement de protocoles.
Les streams sont disponibles depuis UNIX SYSTEM V release 3. Ils sont aujourd'hui présents dans pratiquement toutes les implémentations du système.
Objectifs : évolution et ouverture du système d'entrée/sortie
structuration modulaire et en couches dans le noyau,
masquage des couches de niveau inférieur,
souplesse d'utilisation grâce à l'évolution dynamique des différents modules,
transparence des média,
partage possible du code d'un protocole par plusieurs contrôleurs de communication,
portage aisé des applications.
Dans le présent paragraphe sont définis les termes spécifiques associés aux streams.
Streams et flots
Le terme stream est employé également dans la couche socket. Pour éviter toute ambiguïté, dans tout ce qui suit, les streams de Dennis Ritchie seront nommés streamsex "stream" ou flots d'entrées/sortieex "flots d'entrées/sortie" ou plus simplement flotsex "flots".
Flot
Un flot est un gestionnaire de périphériques constitué d'une chaîne de procédures de traitement (Stream Moduleex "Stream Module") opérant sur deux flux de données bidirectionnels entre un processus et un pilote dans le noyau dans un mode full duplex (stream messageex "stream message").
Extrémités
Les deux extrémités d'un flot sont nécessaires. Elles sont définies :
du côté processus en mode utilisateur,
du coté pilote en mode noyau.
Flux de données
On distingue le flux des données descendantesex "flux des données descendantes", du processus utilisateur vers le pilote et le flux des données montantesex "flux des données montantes", du pilote vers le processus utilisateur. Les variables d'état de chacun des flux ainsi que les files de messages associées sont gérées par une fileex "file" (Stream Queueex "Stream Queue"). La file des messages montantsex "file des messages montants" (upstream queueex "upstream queue") est aussi appelée file en lectureex "file en lecture" (read queueex "read queue") ou encore messages entrantsex "message entrant". La file des messages descendantsex "file des messages descendants" (downstream queueex "downstream queue") est aussi appelée file d'écritureex "file d'écriture" ou encore messages sortantsex "message sortant".
INCORPORER Designer \s \* fusionformat
Modules
Stream Module
Un module stream ou moduleex "module" assure un traitement, éventuellement optionnel sur les flux de données.
Il est constitué d'un allocateur de mémoire privé, des deux flux de données, de procédures internes, appelées services streamex "service stream" ou servicesex "service", lui permettant d'exécuter des opérations sur ces files.
Les services sont implémentés sous forme de primitives de bas niveau du noyau. Ils constituent un filtre bidirectionnel.
Les deux flux de données étant fullduplex, les opérations de traitement peuvent être simultanées.
Chaque module s'exécute dans son propre contexte d'exécution, son espace d'adressage étant intégré dans celui du noyau.
Module de Tête
Ce module, appelé également Tête du Flotex "Tête du Flot" (Stream Headex "Stream Head") est l'interface de dialogue entre le processus utilisateur et les autres modules dans le noyau ce qui permet au processus utilisateur d'y transmettre des paramètres.
Module Terminal
Ce module, également appelé Pied du Flotex "Pied du Flot" (Stream Endex "Stream End") est un pilotestreamex "pilotestream" (Stream driverex "Stream driver") ou un pseudopilote (stream).
Un pilotestream est un pilote adapté pour devenir un module stream. Même s'il ne fait rien, sa présence est nécessaire pour supporter la chaîne des modules.
Tables systèmes
Tout pilote est accessible par l'une des tables bdevsw ou cdevsw.
Tout module est identifiable par la table système fmodswex "fmodsw" accessible à partir de l'appel système ioctlex "ioctl". Elle est compatible avec les tables cdevsw et bdevsw. Les concepts classiques (inode, utilisation des appels système d'entrée/sortie) restent vrais. Un pilote stream a un point d'entrée dans le répertoire /dev puisque c'est un pilote. Un module stream n'en a pas.
Chaîne de modules
Une chaîne de modulesex "chaîne de modules" ou chaîneex "chaîne" est l'ensemble des modules permettant de constituer un flot.
Elle se compose d'un module de tête et d'un module terminal au moins. Dans ce cas, la chaîne de modules internes est vide et aucune opération de filtrage n'est réalisée sur les flux de données.
Tous les modules ont une interface standard permettant leur interconnexion.
La chaîne des modules permet de constituer deux chemins de donnéesex "chemin de données" où circulent des messages.
Exemple
Les caractères saisis à partir d'un clavier sont transmis au processus destinataire (par Exemple /etc/getty) à partir de files de caractères, traitées par un pilote de type caractère.
Evolution dynamique d'une chaîne
Une chaîne de modules peut évoluer dynamiquement par empilement ou dépilement de module dans le noyau (commande shell lddrex "lddr", appel système ioctlex "ioctl") grâce à l'édition de lien dynamique.
Les modules compilés doivent donc être relogeables.
Les pilotes deviennent donc chargeables dynamiquement à partir du moment où ils sont développés en utilisant les notions associées aux flots (par Exemple dans AIX/V3).
La prise en compte d'une modification du code d'un module nécessite la recompilation du noyau.
Le code de chaque module peutêtre réentrant.
Message
Un stream messageex "stream message" ou messageex "message" est l'unité de communication typée entre deux modules, allouée dans l'espace mémoire propre du module.
Blocs de messages
Un message est constitué d'une liste chaînée de blocs de données, chacun étant un descripteur des données auxquelles il permet d'accéder.
Tout message est typé (donnée ou contrôle) et contient des informations de contrôle.
Evolution dynamique
L'extension dynamique de la taille des messages entre différents modules est possible, par des algorithmes de gestion de listes chaînées des blocs de message.
Ordonnancement des messages
Toute requête d'allocation de message est soumise à un ordonnanceur local au module.
Le message doit traverser la chaîne des modules pour le traitement complet.
File de message
Une file de messagesex "file de messages" est une liste chaînée de messages.
Services d'un module
Les opérations réalisées par un module sur un flot sont des servicesex "service".
Ils sont optionnels et ne sont pas d'exécution immédiate car ils sont régulés par le contrôle de flux interne du module avec une gestion interne des priorités.
Autonomie du soussystème d'entrées/sorties
Le soussystème d'entrée/sortie devient autonome dans le noyau car il est muni de ses appels système propres, de son allocateur mémoire, de ses gestionnaires de travaux propres (ordonnanceur, multiplexeur).
Exemples
module permettant à un pilote de clavier de 102 touches de gérer un clavier à 80 touches,
module additionnel de chiffrement de données d'un disque,
chiffrement de données et stockage sur deux disques différents.
Appels système
La plupart des appels systèmes utilisés sont classiques (open, close, read, write, ioctl). D'autres sont spécifiques (getmsg, putmsg, poll).
Appels système classiques
La sémantique et la syntaxe des appels systèmes classiques sont conservées. C'est indispensable pour pouvoir réutiliser les programmes standards sans les modifier ce qui permet à un processus d'utiliser les flots de façon transparente.
openex "open" ouverture d'un flot,
closeex "close" fermeture d'un flot,
readex "read" lecture en mode flot de données dans un module stream de type M_DATA,
writeex "write" écriture en mode flot vers un module stream.
ioctl
L'appel système ioctlex "ioctl" permet d'effectuer des opérations sur les modules à savoir :
insertion ou suppression dynamique d'un module dans une chaîne de modules à partir du pilote stream seulement,
multiplexage de messages entrants ou sortants,
opérations de contrôle.
getmsg et putmsg
Les appels système putmsgex "putmsg" et getmsgex "getmsg" permettent des échanges de messages entre modules.
poll
L'appel système pollex "poll" permet de faire de l'attente sur plusieurs flots (attente multiple) pour prendre en compte la réception des données, la gestion des codes d'erreur, ou le contrôle de flux.
C'est l'équivalent de l'appel système selectex "select" des versions BSD qui permet de réaliser des opérations de synchronisation entre modules.
Il scrute l'événement attendu sur chaque descripteur de fichier. Le processus est bloqué si l'événement ne s'est pas produit pendant une certaine durée ou jusqu'à ce qu'il apparaisse. Il émet alors un signal de notification d'événementex "notification d'événement" se produisant dans un module au processus concerné. Son mode de fonctionnement est synchrone.
Ordonnancement
L'ordonnancement des messages dans un module est indépendant de celui du système d'exploitation. Ainsi, il n'est pas possible d'y exécuter les primitives de bas niveau sleepex "sleep" ou wakeprocex "wakeproc" car les contextes d'exécution sont à la fois celui d'un module, dans le noyau, et celui du processus utilisateur appelant.
L'ordonnanceur local traite chacune des files d'attente de requêtes de messages en mode FIFO, active la procédure de service associée à la queue, qui traite les messages en attente. La durée de l'attente est donc aléatoire. Tous les traitements différés sont traités simultanément.
L'ordonnanceur du module effectue un vol de cycle sur le temps d'exécution résiduel des appels système des autres processus. Il est plus prioritaire que celui des processus utilisateurs et est seulement interruptible par des traitement sur interruption de haut niveau. Les transferts de messages entre modules s'exécutent très rapidement. Ainsi, le routage interne est très rapide s'il est intégré à un module.
Une procédure de service n'est pas obligatoire. Elle complète la procédure d'écriture par écriture du message dans la file associée à l'ordonnanceur du module.
Synopsis : int putq();
Description
transmission du message entrant dans la file d'attente de traitement,
sortie immédiate du niveau d'interruption courant,
traitement ultérieur par l'ordonnanceur local du module.
Contrôle de flux
Deux niveaux de contrôle de flux :
global, au niveau de l'allocation du message pour la chaîne des modules,
local, dans les module dotées d'une procédure de type "service".
Le contrôle du flux des messages est réalisé par l'utilisation des constantes HIGHWATERMARK et LOWWATERMARK selon l'algorithme :
si le nombre d'informations en attente est supérieur à HIGHWATERMARK alors attendre is
si le nombre d'informations en attente est inférieur à LOWWATERMARK alors redémarrer is
La primitive de bas niveau canputex "canput" permet, au niveau de chaque module, la prise en compte des variables de gestion du contrôle de flux.
INCORPORER Designer \s \* fusionformat
Exemple
if canput() putq;
else (remise en attente);
Si cette primitive n'est pas utilisée, ou si la valeur maximum est trop importante, cela risque de conduire à un blocage dans le processus. La solution est de diminuer la valeur HIGHWATERMARK et non pas de l'augmenter pour une bonne régulation de module à module.
Multiplexage de modules
Le multiplexage amont ou aval de files issues de différents modules est possible. L'implémentation est réalisé sous forme de pseudopilote.
La connexion à un module multiplexeur est réalisée avec l'appel système ioctl.
INCORPORER Designer \s \* fusionformat
Fichiers de configuration
Fichier strconfex "strconf" : fichier descripteur des différents modules streams.
INCORPORER Designer \s \* fusionformat
Flots et API
Le système de communications BSD a été réimplémenté sous SYSTEM V en utilisant les mécanismes des streams.
La couche socket s'appuie donc sur des modules streams, même si l'interface utilisateur n'a pas changée.
La couche TLI offre une interface applicative similaire à celle de la couche socket pour développer des applications dialoguant avec le monde ISO.
Implémentation BSD
Implémentation BSD
Le système de communications est doté de son propre allocateur de mémoire. Dans l'implémentation BSD, l'entité est la structure mbufex "mbuf".
Implémentation SV
Dans l'implémentation SYSTEM V, l'entité est le flot.
Structures mbuf
Une structure mbuf est un tampon de mémoire de 128 octets.
Des structures mbuf chaînés peuvent définir une chaîne, qui représente un objet unique et peut contenir une quantité arbitraire de données. Une liste de structures mbuf est un ensemble d'objets.
INCORPORER Designer \s \* fusionformat
L'espace disponible d'une structure mbuf peut être utilisé de façon arbitraire. Cette flexibilité pour ajouter ou supprimer des espaces est particulièrement utile pour l'implémentation de protocoles de communications ceux-ci devant souvent ajouter ou supprimer des entêtes de trames. Les structures mbuf sont particulièrement adaptées à ce type d'approche car elles ne nécessitent pas de nouvelles allocations mémoire.
La taille des structures mbuf est fixe pour éviter les problèmes de fragmentation. Le champ m_dat, de 112 octets, est réservés pour le stockage des données, accessibles par les pointeurs m_len et m_off. Pour des messages d'une taille importante, il est possible associer une page d'un Koctets à une structure mbuf. La possibilité d'adresser des pages dans une structure mbuf évite les inutiles transferts de mémoire à mémoire.
Cluster
Une structure mbuf ne pouvant contenir que 112 octets de données au plus, c'est insuffisant quand les messages à transmettre en comportent davantage. A l'initialisation du système, 4 Koctets de mémoire sont allouées pour les structures mbuf. Quatre pages sont en outre réservées pour l'adressage des structures mbuf en mémoire. Un cluster est un couple { 1 structure mbuf, 1page de 1Koctets }.
INCORPORER Designer \s \* fusionformat
Les structures mbuf et les cluster sont respectivement gérées dans deux files : files des structures mbuf disponibles (resp cluster disponibles) et files des structures mbufs allouées (resp cluster alloués).
Tampons d'émission et de réception
Les communications utilisent deux tampons : un en émission et en réception. Les sockets en attentes de requêtes de connexions entrantes utilisent deux files d'attentes de tampons.
Interface socket protocoles
Nous décrivons dans le présent paragraphe les mécanismes internes d'interface entre la couche socket et les protocoles.
Chaque protocole est accessible par la structure protoswex "protosw" (protocol switchex "protocol switch") qui permet de l'identifier, et de l'interfacer avec les protocoles des différents niveaux. Elle s'interface avec la couche socket au niveau supérieur et la couche interfacematériel au niveau inférieur. Elle est constituée d'un ensemble de protocoles regroupés en famille qui dialoguent entre eux et qui sont regroupés sommairement en trois niveaux :
Protocole de niveau supérieur interface socket-protocole
Protocole de même niveau interface protocole-protocole
Protocole de niveau inférieur interface avec la couche matérielle.
L'interface socket-protocole assure le dialogue entre l'application appelante et les protocoles.
L'interface protocole-protocole permet le dialogue entre différents protocoles de même niveau.
L'interface avec la couche matérielle assure la gestion physique des échanges et offre aux protocoles une interface logique indépendante du matériel. Cette couche regroupe l'ensemble des pilotes d'accès aux réseaux et présente à la couche protocole une interface basée sur une structure de données générique : la structure ifnetex "ifnet".
Structure ifnet
A chaque interface matérielle d'accès au réseau est associé un descripteur ifnet qui fournit à la couche protocole appelante :
les éléments d'adressage de cet interface,
les points d'entrée de ses pilotes,
des informations sur son état.
Ces descripteurs constituent une liste chaînée ce qui permet à tous les protocoles d'accéder à l'ensemble des interfaces réseaux.
INCORPORER Designer \s \* fusionformat
Emission d'un paquet
Lorsqu'un protocole fait une requête d'émission d'un paquet, il sélectionne l'interface ifnet concernée qui appelle le pilote correspondant pour assurer la gestion de l'initialisation de l'émission ou son stockage si le support physique est occupé et redonne le contrôle au protocole appelant.
Réception d'un paquet
A la réception d'un paquet, le pilote détermine le protocole de bas niveau destinataire et l'appelle. La plupart du temps, le protocole met ce paquet dans une file d'attente interne. Son niveau d'exécution est modifié de telle sorte que la réactivation de sa fonction de réception soit provoquée par le système de communications, ce qui permet de retourner immédiatement au pilote appelant qui peut alors libérer le niveau d'interruption sur lequel il s'exécute.
La structure ifnet est la représentation de l'univers des accès réseaux disponibles au niveau protocole. Les couches sockets et interface matérielle n'ont pas de couches homologues dans le modèle ISO.
INCORPORER Designer \s \* fusionformat
La sélection d'une interface réseau est assurée par le protocole de routage (IP par Exemple).
L'interface réseau assure l'émission, la réception des paquets, l'encapsulation et la décapsulation des en-têtes de niveau inférieur.
Un contrôleur est, en principe, associé à une interface réseau. Toutefois, chaque système est muni d'une interface en boucle fermée loopback utilisée pour la mise au point et les évaluations de performance.
Chaque interface réseau gère sa propre file d'émission : la file if_snd décrite par la structure ifqueue.
Les champs de la structure ifnet (if_ipackets, if_ierrors, if_opackets, if_oerrors, if_collision) sont accessibles à partir des commandes shell netstatex "netstat" ou snmpstat.
La commande shell ifconfigex "ifconfig" permet la consultation de l'adresse et des drapeaux associés à une structure ifnet.
Traitement d'une trame Ethernet
On suppose qu'il s'agit du trame gérée à partir du protocole IP.
Niveau Pilote Ethernet
L'arrivée d'une trame provoque une interruption. Il faut alors en vérifier la validité puis la déposer dans la file de traitement associée au protocole.
L'en-tête du protocole Ethernet de la trame est supprimé.
La définition du protocole de niveau supérieur étant immédiatement contenu dans l'en-tête de la trame, le pilote peut appeler les procédures associées au protocole IP (ipintr).
Niveau IP
Le protocole IP vérifie l'en-tête de la trame et effectue soit un réassemblage soit une redirectionex "ip_forward".
La définition du protocole de niveau supérieur étant immédiatement contenu dans l'en-tête du paquet, les procédures associées au protocole de niveau supérieur sont accessibles et le paquet est transmis au niveau supérieur.
Niveau TCP
La procédure vérifie l'en-tête du paquet et effectue la mise à jour de la fenêtre.
Le socket associée est recherchée à partir du quintuplet :
< lport, laddr, fport, faddr, in_pcblookup >
Le traitement exécuté est fonction de l'état du socket :
réassemblage,
si le paquet est complet, les données sont recopiées dans le tampon de réception associé au socket.
Bibliographie du présent chapitre
Unix Network Programming
W.RICHARD STEVENS - Editeur : Prentice Hall


La famille des pROTOCOLES tcp/ip
Introduction
Nous présentons dans ce chapitre les protocoles de base du monde TCP/IP : les protocoles de niveau réseau et transport (TCP et UDP) ainsi les protocoles de haut niveau RPC et XDR.
Protocoles de niveau réseau IP et ICMP
Les deux protocoles les plus utilisés au niveau des couches réseau sont les protocoles IP et ICMP.
Le protocole IP
Le protocole IP (Internet Protocolex "Internet Protocol") assure l'interconnexion des réseaux et de leurs stations.
Les communications sont réalisés par émission et réception de datagrammeEX "datagramme"s qui représentent l'unité de données de protocole. La source et la destination sont des stations (hosts) identifiés par des adresses de longueur fixe. La taille des datagrammes pouvant varier d'un réseau à un autre, le protocole doit savoir assurer la fragmentation et le réassemblage de paquets sur des réseaux de type "plus petits paquets".
Le protocole IP est de type point à point, présent sur chaque station et chaque passerelle, qui traite les différents datagrammes comme des entités indépendantes. Il n'existe pas de notion de connexion au niveau IP ou de circuit virtuel (type X25). Ce n'est pas un protocole de bout en bout. Il ne gère pas le contrôle de flux, le reséquencement ou tout autre type de services des protocole de transport de classe 4 du modèle ISO. Il est appelé par un protocole de niveau supérieur (TCP, UDP,...) et appelle un pilote qui interface le réseau réel pour acheminer les trames IP vers un routeur ou vers la station destinataire. Il s'appuie sur différentes interfaces : 802.x, asynchrones, X25...
INCORPORER Designer \s \* fusionformat
Un environnement inter-réseaux est un ensemble de stations et de réseaux connectés par des routeursex "routeur". Les communications entre systèmes distants sont représentées sous la forme :
INCORPORER Designer \s \* fusionformat
L'en tête du datagrammeex "en tête du datagramme" contient les informations nécessaires au fonctionnement du protocole.
Le protocole IP a deux fonctions essentielles : l'adressage et la fragmentation.
La fonction de routage utilise les adresses internet contenues dans l'en-tête d'un datagramme IP. De même, les fonctions de fragmentation et de réassemblage utilisent les différents champs de l'en-tête pour assurer la transmission sur les réseaux "petits paquets". Le protocole Internet est basé sur quatre notions clefs :
Le type de service
C'est la qualité du service désiré, utilisé par le routeur pour sélectionner les paramètres de la transmission.
La durée de vieex "durée de vie"
C'est la durée de vie du datagramme, définie par l'émetteur. Elle est décrémentée à chaque franchissement d'un routeur (métriqueex "métrique"). Le datagramme est détruit dès qu'elle devient nulle, même avant son arrivée à sa destination.
Les options
C'est la possibilité de mettre en oeuvre des fonctions de contrôle comme l'estampillation, la sécurité ou un routage particulier (non utilisés en temps normal).
La somme de contrôle (checksum) de l'en-tête
Elle assure la vérification de l'information transmise de chaque trame, détruite quand une erreur est détectée puis réémise.
Le protocole IP ne fournit pas de services tels les acquittements, le contrôle d'erreurs sur des données (à part le checksum), le contrôle de flux, la retransmission des trames. Les anomalies détectées sont gérées par le protocole ICMPex "ICMP" (Internet Control Message Protocolex "Internet Control Message Protocol").
Quand un paquet doit traverser un réseau dont la taille maximale du paquet est plus petite que celle du réseau précédent, les procédures de fragmentation et de réassemblage le découpent en un nombre arbitraire de fragments sauf s'il est marqué "don't fragment". Il est alors détruit. Le module IP récepteur utilise les champs d'identification pour :
ne pas mélanger deux datagrammes (identification unique sur les réseaux),
replacer le fragment dans le datagramme arrivé (champs offset et length).
Un datagramme de taille importante peut être divisé en deux (au niveau donnée) pour donner naissance à deux datagrammes autonomes, plus petits, munis du même en-tête, leur réassemblage n'étant possible que si leurs champs identification, source, destination, protocole sont identiques. Le premier doit avoir un champ offset nul et le deuxième le drapeau more fragments à zéro.
Les segments issus des couches supérieures sont encapsulées dans les datagrammes IP.
INCORPORER Designer \s \* fusionformat
Analyse des différents champs
Version sur 4 bits : numéro de l'implémentation du protocole IP
IHL (Internet Header Length) sur 4 bits : nombre de mots de 32 bits de l'en-tête
Type of service sur 8 bits : qualité des services mis en oeuvre (précédence, priorité, contrôle par le protocole ICMP...)
Total Length sur 16 bits : longueur totale du datagramme (avec son entête), bornée à 65343 octets. La plupart des réseaux utilisent une longueur de 576 octets.
Identification sur 16 bits : identification fournie par l'émetteur pour l'assemblage des fragments d'un même datagramme.
Drapeaux sur 3 bits
bit 0 : drapeau de contrôle (réservé)
bit 1 : drapeau de fragmentation (don't fragment/may fragment)
bit 2 : gestion des fragments (lost fragment/more fragment).
Fragment offset sur 13 bits : position du fragment courant dans les données du datagramme original
Time to live sur 8 bits : temps maximum autorisé pour la traversée des réseaux (décrémenté par chaque module IP traversé).
Protocol sur 8 bits : identification du protocole de niveau supérieur (TCP ou UDP) devant recevoir le datagramme.
Header checksum sur 16 bits : somme de contrôle de l'en-tête.
Source Adress sur 32 bits : adresse internet de l'émetteur
Destination adresse sur 32 bits : adresse IP du premier routeur permettant d'accéder au destinataire.
Analyse des options
variable pas toujours implémenté
sécurité Confidentiel
Restricted
Secret
Top secret
Route stricte et route enregistrée
information de routage pour le franchissement des routeurs
Stream identificateur
Estampillation
Padding
bits de bourrage de telle sorte que la fin de l'en-tête soit sur une frontière de mots de 32 bits (derniers bits à zéro).
L'adresse IP
Un noeud du réseau Internet est accessible par son adresse Internet d'une longueur fixe de 4 octets. Elle se compose d'un numéro de réseau suivi d'une adresse locale dans le réseau (host number). Pour fournir une grande souplesse dans le choix des numéros de réseau (aussi bien nombre faible de réseaux constitués de beaucoup de stations que nombre important de réseaux constitués de peu de stations), il existe cinq classes de réseau et cinq formats d'adresses Internet :
Bits de poids fort Netid Hostid Classe de réseau 1er octet
0 7 24 A 0 < ...8kf O N N N O (4MO mini)
S >25kf N O O O N
RFC
Protocole EGP RFC 911, 904
Protocole BGP RFC 1163, 1164
Protocole RIP RFC 1058
Protocole HELLO RFC 891
Exercices
1°) Rappeler la commande de configuration d'un contrôleur ?
2°) Quelles sont ses principales options ? Rappeler leur utilité.
3°) Quand son utilisation estelle nécessaire ?

Commandes traditionnelles d'administration dans le monde TCP/IP
Introduction
Nous présentons dans le présent chapitre :
les commandes standard d'administration de réseau des systèmes fonctionnant avec les protocoles TCP/IP,
les commandes associées au protocole SNMP,
les notions élémentaires de sécurité permettant d'assurer une bonne sécurité de fonctionnement sont présentées au chapitre correspondant.
Commandes d'administration du réseau
Il existe plusieurs catégories de commandes : les commandes standards TCP/IP et les outils constructeurs, par exemple les outils spécifiques SUN.
Commandes standards TCP/IP
arpex "arp"
Permet de connaître le nom d'une machine, son numéro Internet et son numéro Ethernet.
Exemple
L'exécution de la commande arp -a indique :
paris (192.54.211.15) at 8 :0 :20 :0 :3f :74 permanent
paris1 (192.54.211.16) at 8 :0 :20 :0 :1e :cb permanent
...
fingerex "finger"
Affichage des informations disponibles relatives à un utilisateur donné par consultation des fichiers /etc/utmpex "/etc/utmp" et /etc/passwdex "/etc/passwd".
nfsstatex "nfsstat" : statistiques d'utilisation des protocoles nfs
Client rpc :
calls badcalls retrans badxid timeout wait newcred timers
77513 3 86 11 85 0 0 1148
Client nfs :
calls badcalls nclget nclsleep
77502 0 76910 0
null getattr setattr root lookup readlink read
0 0% 40517 52% 1538 1% 0 0% 13271 17% 3936 5% 9559 12%
wrcache write create remove rename link symlink
0 0% 4697 6% 711 0% 653 0% 248 0% 104 0% 0 0%
mkdir rmdir readdir fsstat
11 0% 3 0% 2213 2% 41 0%
pingex "ping"
Emission de trames de contrôle (protocole ICMP) pour déterminer si une machine est accessible ou chargement du réseau pour tester son comportement.
Exemple : ping paris
PING paris : 56 data bytes
64 bytes from paris (192.70.63.19) : icmp_seq=0. time=10. ms
64 bytes from paris (192.70.63.19) : icmp_seq=1. time=0. ms
64 bytes from paris (192.70.63.19) : icmp_seq=2. time=0. ms
pstatex "pstat" : état des tables système.
Exemples 
pstat -T (BSD)
157/582 files
0/ 0 inodes (station diskless seulement)
42/138 processes
6408/16380 swap
rpcinfoex "rpcinfo"
Interroge le processus démon portmap et indique les numéros de port RPC actif ainsi que les protocoles utilisés.
Exemple : rpcinfo -p (extrait)
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100004 2 udp 658 ypserv
100004 2 tcp 659 ypserv
100007 2 tcp 1024 ypbind
100029 1 udp 660 keyserv
100028 1 tcp 665 ypupdated
100010 1 udp 699 etherstatd
100003 2 udp 2049 nfs
100005 1 udp 714 mountd
100026 1 udp 719 bootparam
100024 1 tcp 723 status
100020 1 udp 1036 llockmgr
100021 2 tcp 736 nlockmgr
100011 1 udp 1038 rquotad
100001 2 udp 1039 rstatd
100002 1 udp 1040 rusersd
100012 1 udp 1041 sprayd
100008 1 udp 1042 walld
sprayex "spray"
Sur certaines implémentations, il est possible de tester la bande passante par utilisation de requêtes RPC. Le démon rpc.sprayd assure les réponses aux requêtes de la commande /usr/etc/sprayex "/usr/etc/spray".
Synopsis
spray host [-c nombre] [-d délai] [-i] [-l longueur]
avec les arguments
nombre total des requêtes à émettre, par défaut 10000,
délai délai en milliseconde entre les requêtes, par défaut 0,
i utilisation du protocole ICMP au lieu du protocole RPC,
longueur taille de la trame Ethernet, fixée par défaut 86 octets.
rupex "rup"
Statististiques d'état du réseau par utilisation du protocole RPC.
ruptimeex "ruptime"
Statistiques d'état du réseau par utilisation du démon rwhod, beaucoup plus lent que le précédent.
ypcatex "ypcat"
état des listes NIS.
showmountex "showmount"
Permet à la station serveur de connaître les stations clientes montées sur ses systèmes de fichiers exportables.
Exemple
ps1 :/export/root/ps1
ps1 :/export/swap/ps1
ps1 :/usr
ps1 :/usr/kvm
ps1 :/usr/share
ps1 :/home/ps
ps2 :/export/root/ps2
ps2 :/export/swap/ps2
rdateex "rdate"
Permet de régler la date et l'heure d'une station sur celles d'une autre station.
timedex "timed"
Processus démon de mise à la même heure de toute les stations du réseau. Il existe sur le serveur et les clients. Il faut le valider préalablement dans le fichier /etc/servicesex "/etc/services". Sur le serveur, il est lancé par la commande
timed -M
Les fichiers /usr/adm/timed.log et /usr/adm/timed.masterlog sont utilisés respectivement pour l'audit des clients et des autres serveurs horaires.
Sur un client, il suffit de lancer le processus démon sans option.
timedcex "timedc"
Ce programme contrôle le fonctionnement du démon timedex "timed".
La commande netstat
netstatex "netstat"
Permet de connaître le nom, le numéro Internet, le numéro de réseau d'une station. Elle permet de savoir si une passerelleex "passerelle" est active. Les principales options sont les suivantes :
netstat -a
Etat des connexions actives, du nombre de bytes en attente dans les files d'attentes en réception et en émission, ainsi que leur numéro de port local et distant.
Exemple
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
...
udp 0 0 *.1042 *.*
...
udp 0 0 *.ttytst *.*
udp 0 0 *.daytime *.*
udp 0 0 *.discard *.*
...
tcp 0 0 sparc2.6000 sparc2.1057 ESTABLISHED
tcp 0 0 sparc2.1057 sparc2.6000 ESTABLISHED
tcp 0 0 sparc2.6000 sparc3.1035 ESTABLISHED
...
tcp 0 0 *.6000 *.* LISTEN
tcp 0 0 sparc2.1021 sparc1.cmd CLOSE_WAIT
...
tcp 0 0 *.source *.* LISTEN
...
Active UNIX domain sockets (voir plus bas)
netstat -A
Numéros Internet, protocoles utilisés, numéros de port locaux et distants, état des connexions.
Exemple
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 192.70.63.22.6000 192.70.63.22.1063 ESTABLISHED
tcp 0 0 192.70.63.22.1063 192.70.63.22.6000 ESTABLISHED
....
tcp 93 0 192.70.63.22.1018 192.70.63.21.1020 CLOSE_WAIT
...
tcp 0 0 192.70.63.22.1021 192.70.63.21.514 CLOSE_WAIT
Active UNIX domain sockets
Address Type Recv-Q Send-Q Vnode Conn Refs Nextref Addr
ff64968c dgram 0 0 ff02b284 0 0 0 /dev/log
ff65010c stream 0 0 ff06b018 0 0 0 /tmp/.X11-unix/X0
...
ff64aa0c stream 0 0 ff025594 0 0 0 /dev/printer
netstat -i
Adresse logique du contrôleur, unité maximale de transmission, nom Internet du réseau destinataire, nom du poste de travail émetteur, paquets et erreurs en réception et en émission.
Exemple
Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
le0 1500 par-ether sparc2 26672 0 19439 0 17 0
lo0 1536 loopback localhost 53648 0 53648 0 0 0
netstat -m
Taux d'utilisation des structures mbuf.
Exemple
294/384 mbufs in use :
3 mbufs allocated to data
25 mbufs allocated to packet headers
103 mbufs allocated to socket structures
151 mbufs allocated to protocol control blocks
6 mbufs allocated to routing table entries
4 mbufs allocated to socket names and addresses
2 mbufs allocated to interface addresses
0/24 cluster buffers in use
72 Kbytes allocated to network (51% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines
streams allocation :
cumulative allocation
current maximum total failures
streams 9 10 71 0
queues 30 34 271 0
mblks 13 60 48606 0
dblks 13 60 48606 0
streams buffers :
external 0 0 0 0
within-dblk 0 6 30976 0
size 
 :