I/ DEFINITION
Les Sockets constituent une des A.P.I. (Application Program Interface) des protocoles de communication. Elles représentent donc une interface entre les applications et les couches réseaux (ou les couches communications systèmes pour les sockets systèmes).
1/ Objectifs des sockets
Le premier objectif des sockets est de définir une extrémité de connexion, un point de contact bidirectionnel dans lequel un processus pourra émettre et recevoir des données selon un protocole choisi. Elles permettent donc à plusieurs processus, même distant de communiquer.
Le second est d’offrir une interface simple à l’application, qui devra spécifier que le stricte nécessaire. Pour cela, l’A.P.I. des sockets s’approche de l’A.P.I. fichier d’Unix pour utiliser les mêmes primitives: read, write, iocl, select...
2/ Caractéristiques systèmes
Une socket est définit par:
a/ son domaine (famille)
* Local, UNIX (AF_UNIX), permet à plusieurs processus de communiquer sur la même machine.
* Internet (AF_INET), pareil sur un réseau I.P.
Autres réseaux:
* XeroxNS (AF_NS)
* SNA - IBM (AF_SNA)
* AppleTalk (AF_APPLETALK)
b/ son type
Il détermine le type et les caractéristiques de la communication. Par exemple l’établissement ou non d’une connexion, la fiabilité des échanges, le séquencement...
=> Mode déconnecté (SOCK_DGRAM)
Les caractéristiques du mode déconnecté dépendent de la famille de la
socket.
Si la socket est une AF_UNIX, les échanges sont locaux. Il n’y a donc aucune contrainte physique.
* Les envois de donnée par datagrammes sont indépendant les uns des autres.
* L’envoie d’un datagramme peut être adressé à plusieurs processus.
* L’adresse de destination est contenu dans chaque datagramme.
* L’adresse source aussi afin que le processus récepteur puisse éventuellement répondre.
Avec une socket AF_INET, les échanges reposent sur un média physique et sortent de la machine. Ceci ajoute donc aux précédentes caractéristiques que :
* L'adresse source aussi afin que le processus récepteur puisse éventuellement répondre.
Avec une socket AF_INET, les échanges reposent sur un média physique et sortent de la machine. Ceci ajoute donc aux précédentes caractéristiques que :
* L'ordre d’envoie des paquets n’est pas forcément le même à la réception car chaque paquet est routé indépendamment.
=> Mode connecté (SOCK_STREAM)
Ce mode réalise un canal de communication permanent entre le client et le serveur. Celui-ci est associé à un flot de données non interprété.
* Le programme serveur attend une connexion sur sa socket.
=> Autres types moins répandus
Mode accès direct au couches basses (SOCK_RAM).
Mode format structuré autre qu’Internet (SOCK_SEQPACKET).
COMBINAISON DOMAINES/TYPES
On accède à une socket par un descripteur de socket, assimilable à un descripteur de fichier afin d’assurer la compatibilité des I/O d’UNIX. Celui-ci est donc dans la table des descripteurs. Ceci offre alors les avantages suivant :
- Possibilité de rediriger des entrées ou des sorties dans une
socket.
- Les fils du processus héritent de la table des descripteurs, donc des sockets. Cela permet entre autre de faire un serveur concurrent en mode connecté. Le père accepte les connexions, chaque fils gère un client.
L'A.P.I. socket utilise les primitives et les appels systèmes classiques, ce qui assure un polymorphisme des I/O et une abstraction des caractéristiques réseaux.
Exemple pratique: select()
On peut scruter plusieurs I/O sans s’occuper de la nature du canal de communication grâce aux descripteurs. La primitive scrute tous les descripteurs. Lorsque des données sont prêtes à être lues, il suffit de faire une lecture grâce à
read sur le descripteur, en sachant que celui-ci peut pointer l’entrée standard, un fichier ou une socket, cela n’a pas d’importance.
Une socket est associée à deux mémoires tampons gérées par le noyau Unix.
- une pour l’émission
- une pour la réception
La gestion des tampons dépend du protocole de la couche transport pour le domaine Internet (AF_INET), du système pour le domaine Unix. Le noyau Unix décharge le programmeur des caractéristiques du protocoles désirés. Les tampons sont lus et écrits de façon concurrente par la socket (l’application) et le noyau.
Déroulement de l’écriture
Le noyau recopie les données placées dans l’espace mémoire du processus vers le tampon d’émission. Si le tampon est plein, l’écriture est bloquante, le processus est endormi en attendant que le tampon d’émission se vide. On sort de l’écriture quand la copie des données dans le tampon est achevée.
Déroulement de la lecture
Le noyau recopie les données du tampon de réception dans l’espace mémoire alloué pour la variable du processus. Par défaut, la lecture est bloquante sur un tampon vide. Cela veut dire que l’on indique le nombre d’octets à lire dans la socket et que l’on sort de la fonction qu’une fois ce nombre d’octets lus atteint.
On peut néanmoins rendre la lecture non bloquante. Seulement, lire dans une socket vide renvoie –1. Il faut donc scruter le descripteur de la socket pour lire le tampon que lorsque les données sont présentes.
Rendre la lecture non bloquante
int optSock
fcntl(sd, F_GETFL, &optSock); /* Lit options sur la socket */
optSock |= O_NDELAY; /* Définit options */
fcntl(sd, F_SETFL, &optSock);
/* Applique options */
sd = Descripteur de la socket
3/ Particularité des network I.O
Malgré la compatibilité de l’A.P.I. socket avec l’A.P.I. fichier d’Unix, celle-ci présente quand même quelques particularités.
Le mode connecté ne présente pas une symétrie dans la relation client serveur. Le client provoque la connexion, le serveur la gère. C’est donc deux comportements différents.
Une connexion réseau est définie par plus de choses qu’un descripteur de fichier. En effet, avant d’utiliser une socket, il faut définir sa famille, son type et son adresse locale. Pour envoyer des données dans une socket, il faut spécifier l’adresse distante et le processus distant.
Cela se note par l’ensemble (protocole, adresse locale, processus local, adresse distante, processus distant)
Exemple: (tcp, 128.10.0.1, 2500, 128.10.0.8, 9000)
Ici, le protocole utilisé est T.C.P.
C’est un mode connecté entre le processus local attaché au port 2500 qui fonctionne sur la machine d’adresse I.P. 128.10.0.1 et un processus distant attaché au port 9000 de la machine qui a une adresse I.P. égale à 128.10.0.8
Un port par processus permet de multiplexer un unique support physique entre plusieurs processus communiquant sur une même machine.
En mode déconnecté, une opération (une émission) peut cibler plusieurs processus (multicast ou broadcast).