Exigences : Sur le même serveur, les processus communiquent entre eux via des pipelines anonymes, des pipelines nommés, des fichiers de mappage mémoire, HTTP, TCP, flux standard d’entrée/sortie, etc. Parfois, les serveurs doivent déployer plusieurs applications, et les applications peuvent effectivement communiquer entre elles via gRPC et sockets de domaine Unix.
révision
Sockets de domaine Unix
Les sockets de domaine Unix (UDS), les sockets locaux ou les sockets de communication interprocessus (IPC) sont des points de terminaison de communication qui échangent des données entre des processus fonctionnant dans le même système d’exploitation Unix ou de type Unix.
Le nom socket de domaine Unix fait référence à la valeur du paramètre de domaine transmise à la fonction qui a créé la ressource système socket. Le même domaine de communication est également sélectionné. [ 1 ] AF_UNIXAF_LOCAL
Les valeurs valides des paramètres pour typeUDS sont :
- SOCK_STREAM (comparé au TCP) – Utilisé pour les sockets orientés flux
- SOCK_DGRAM (comparé à UDP) – un socket orienté datagrammes pour préserver les frontières des messages (comme pour la plupart des implémentations UNIX, les sockets de datagrammes du domaine UNIX sont toujours fiables et ne réorganisent pas les datagrammes)
- SOCK_SEQPACKET (comparé à SCTP) – Sockets de paquets séquentiels pour les connexions qui préservent les frontières des messages et livrent les messages dans l’ordre dans lequel ils sont envoyés
L’outil UDS est un composant standard du système d’exploitation POSIX.
Pourquoi utiliser des sockets de domaine Unix ?
Les sockets de domaine Unix permettent la communication entre processus sur une seule machine. Alors pourquoi les choisir plutôt que TCP/IP ? Par exemple, dans TCP/IP, vous pouvez utiliser une adresse de boucle (localhost) pour la communication entre un seul serveur. Sous Windows, pourquoi les choisiriez-vous plutôt que les pipelines de nommage Windows ?
En général, il existe plusieurs raisons pour lesquelles vous pourriez choisir d’utiliser UDS plutôt que TCP/IP pour la communication interprocessus :
- Les sockets de domaine Unix ont généralement moins de surcharge et des vitesses de transfert plus rapides que l’utilisation de TCP/IP
- Les sockets TCP/IP sont une ressource finie, tandis que les sockets de domaine Unix n’ont pas de limites strictes
- Les sockets de domaine Unix existent sous forme de fichiers, ce qui facilite la découverte des chemins connus
- L’intégration avec les systèmes de fichiers ajoute aussi une couche supplémentaire de sécurité (si vous n’avez pas accès au chemin du fichier, vous ne pouvez pas accéder au socket).
Le premier point est facile à comprendre : un rapide Google montrera que les benchmarks UDS et TCP/IP sont toujours meilleurs que UDS car non seulement la latence est nettement plus basse, mais aussi un débit nettement plus élevé. Cela s’explique principalement par le fait que UDS est optimisé pour la communication avec le même serveur,Pour la communication IP, localhost doit passer par la pile IP à la fois du côté émetteur et du récepteur。
Les sockets TCP/IP sont une ressource finie ; Vous ne pouvez utiliser que jusqu’à 65 535 sockets à la fois. Si vous ajoutez le problème, le nombre maximal de sockets réellement disponibles TIME_WAIT peut être bien inférieur à cette valeur. La connexion localhost consomme également des sockets dans ce pool. L’utilisation de UDS évite habilement ce problème ; Il permet la communication sans épuiser les sockets TCP/IP.
serveur
Créer un nouveau projet console .NET 8, changer le SDK en Microsoft.NET.Sdk.Web, et configurer comme suit :
Greet.proto est configuré comme suit :
Le code est le suivant :
Après le début de la compilation, comme indiqué ci-dessous :
client
Créez un nouveau projet console .NET 8 et faites référence aux bibliothèques suivantes :
La méthode d’appel de l’interface gRPC est appelée 10 fois, et chaque appel est appelé pendant 200 millisecondes, et le code est le suivant :
Commencez le projet, et une fois l’exécution terminée, comme montré dans la figure ci-dessous :
Référence:
La connexion hyperlientérée est visible.
La connexion hyperlientérée est visible. |
Publié le 11-08-2025 à 20:24:04
|
|
|
|
Propriétaire|
Publié le 11-08-2025 à 20:57:04
|
