Passons donc rapidement en revue les API de programmation de sockets que nous avons utilisées dans notre code de programmation
de sockets jusqu'à présent.
Le premier est l'appel système de la socket L'appel système de la socket est utilisé pour créer un descripteur de fichier de la socket principale
TCP ou UDP.
Il est utilisé aussi bien du côté serveur que du côté client.
Le second est l'appel système de sélection.
Il est utilisé pour surveiller plusieurs descripteurs de fichiers.
Il peut être utilisé aussi bien du côté client que du côté serveur.
Il s'agit d'un appel système bloquant.
L'appel système sélectionné se bloque donc jusqu'à ce qu'une nouvelle demande de connexion arrive ou que de nouvelles données arrivent
du client existant.
L'écriture sur n'importe quel descripteur de fichier surveillé et présent dans l'ensemble des fichiers acceptés par le système est utilisée
uniquement du côté du serveur TCP.
Notez donc que l'appel système excepté est spécifique au serveur TCP.
Il n'est même pas utilisé pour les serveurs UDP, si ce n'est que l'appel système est utilisé pour accepter la demande de connexion du client et
compléter l'échange de données à trois voies avec le client.
Le quatrième est l'appel système bind.
L'appel système Bind est utilisé du côté du serveur TCP ou UDP.
Il est utilisé par le processus d'application du serveur pour informer le système d'exploitation.
Il s'agit du système d'exploitation sous-jacent, des critères des paquets qui nous intéressent.
Le cinquième est l'appel du système de leçons.
Il est utilisé du côté du serveur TCP ou UDP.
Il est utilisé par le processus d'application du serveur pour informer le système d'exploitation de la longueur de la file d'attente
des demandes de connexion ou de données entrantes des clients.
Puis recevoir l'appel du système.
Il est utilisé du côté du serveur et du client TCP ou UDP.
C'est-à-dire qu'il est utilisé des deux côtés.
Il est utilisé par le serveur ou le processus client pour lire les données qui arrivent sur les descripteurs de fichiers de communication.
Cet appel est également un appel système bloquant par défaut.
Bloc de processus.
Si les données ne sont pas arrivées sur un descripteur de fichier, le septième est assigné à l'appel système.
Il est utilisé pour envoyer des données au client ou au serveur qui est une autre machine.
Cet appel système est utilisé aussi bien du côté du serveur que du côté du client.
Enfin, nous avons l'appel système close qui est utilisé pour fermer la connexion.
Elle est utilisée par le client ou par le serveur, qui peut choisir de fermer la
socket qu'il utilise pour communiquer avec l'autre machine.
Passons maintenant aux observations.
En d'autres termes, quels sont les éléments que nous aimerions observer dans le cadre de notre étude de la programmation des sockets client-serveur
Dhcp.
Notre serveur TCP peut donc accepter et maintenir jusqu'à 31 demandes de connexion.
Cela représente jusqu'à 31 clients.
La demande de connexion peut être acceptée par notre serveur et peut être maintenue.
C'est vrai.
En outre, 31 clients demandent une connexion, l'un d'entre eux étant le descripteur de fichier du socket principal.
C'est vrai.
Le serveur ne peut donc servir qu'un seul client à la fois.
C'est vrai.
Que notre serveur soit un serveur multi plex ou un serveur normal, il ne peut servir qu'un seul client
à la fois.
Cependant, notre serveur peut maintenir 31 connexions.
C'est vrai.
Si la demande de données de plusieurs clients est groupée, c'est-à-dire jusqu'à n, tous les clients
seront servis, mais un par un, n étant la valeur spécifiée dans l'appel système.
Avec l'augmentation du nombre de clients, ceux-ci peuvent commencer à souffrir de latence lorsqu'ils sont
servis un par un par le serveur.
Ainsi, la conception de ce serveur est bien meilleure que la précédente.
Il s'agit de la conception du serveur qui ne peut gérer qu'un seul client à la fois.
Notre serveur TCP avec multiplexage peut gérer plusieurs clients en même temps.
C'est vrai.
Mais notre serveur TCP avec multiplexage présente toujours des limites d'extensibilité.
Les limites de l'évolutivité seront toujours présentes, quelle que soit la manière dont vous concevez le serveur pour gérer un plus grand nombre
de clients.
Nous devons déployer davantage de serveurs indépendants.
C'est la raison pour laquelle les grandes multinationales comme Facebook et Google possèdent des centres
de données dans lesquels se trouvent des milliers de serveurs.
Ils traitent collectivement des millions de demandes de clients.
Il ne faut donc pas s'attendre à ce qu'un seul serveur puisse gérer un nombre important de clients.
Un tel serveur n'est pas limité par la conception du logiciel, mais par les limites du matériel.
Ce que j'essaie de dire ici, c'est que si vous avez un grand nombre de clients, disons un million de clients, la façon
dont vous concevez votre serveur n'a pas d'importance, vous êtes limité par le matériel.
Vous avez besoin de plus de serveurs pour gérer un plus grand nombre de clients.
C'est la raison pour laquelle les grandes agences ont des centres de données dans lesquels il y a des milliers
de machines serveurs et la charge de millions de clients est plus ou moins uniformément répartie sur ces machines serveurs.
Ensuite, nous allons parler de la programmation UDP, donc nous allons conclure la programmation UDP.
Très rapide car la création d'une machine serveur UDP et d'une machine client UDP est très simple.
Puisque nous avons appris à mettre en œuvre le client et le serveur TCP, il est très facile de mettre en œuvre le
client et le serveur UDP.
Si vous avez appris à créer une machine serveur TCP, la programmation UDP est beaucoup plus simple que la programmation
TCP et c'est la raison pour laquelle il vous est donné comme devoir d'écrire votre propre serveur et client UDP.
Si vous avez compris les étapes de la mise en œuvre d'un serveur TCP et d'un client TCP, il est très facile
de mettre en œuvre un serveur UDP et un client UDP.
Il s'agit donc d'un devoir pour vous d'implémenter un programme client-serveur UDP.