Krav: På samme server kommuniserer prosesser med hverandre ved hjelp av anonyme pipelines, navngitte pipelines, minnemappingfiler, HTTP, TCP, standard input/output streams osv. Noen ganger må servere distribuere flere applikasjoner, og applikasjoner kan faktisk kommunisere med hverandre ved hjelp av gRPC- og Unix-domenesockets.
anmeldelse
Unix-domenesokler
Unix Domain Sockets (UDS), Local Sockets eller Interprocess Communication (IPC)-sokler er kommunikasjonsendepunkter som utveksler data mellom prosesser som kjører i samme Unix- eller Unix-lignende operativsystem.
Navnet Unix-domenesocket refererer til domeneparameterverdien som sendes til funksjonen som opprettet socket-systemets ressurs. Det samme kommunikasjonsdomenet velges også. [ 1 ] AF_UNIXAF_LOCAL
De gyldige parameterverdiene for typeUDS er:
- SOCK_STREAM (sammenlignet med TCP) – Brukes for strømorienterte sockets
- SOCK_DGRAM (sammenlignet med UDP) – en datagramorientert socket for å bevare meldingsgrenser (som med de fleste UNIX-implementasjoner er UNIX-domenedatagramsockets alltid pålitelige og omorganiserer ikke datagrammer)
- SOCK_SEQPACKET (sammenlignet med SCTP) – Sekvensielle pakkesokler for tilkoblinger som bevarer meldingsgrenser og leverer meldinger i den rekkefølgen de sendes i
UDS-verktøyet er en standardkomponent i POSIX-operativsystemet.
Hvorfor bruke Unix-domenesockets?
Unix-domenesokler tillater kommunikasjon mellom prosesser på en enkelt maskin. Så hvorfor skulle du velge dem fremfor TCP/IP? For eksempel kan du i TCP/IP bruke en loopback-adresse (localhost) for kommunikasjon med én server. På Windows, hvorfor skulle du velge dem fremfor Windows Naming Pipelines?
Generelt finnes det flere grunner til at du kan velge å bruke UDS i stedet for TCP/IP for kommunikasjon mellom prosesser:
- Unix-domenesokler har vanligvis mindre overhead og raskere overføringshastigheter enn bruk av TCP/IP
- TCP/IP-sokler er en begrenset ressurs, mens Unix-domenesokler ikke har noen faste grenser
- Unix-domenesokler kommer i filform, så det er lett å "oppdage" kjente stier
- Integrasjon med filsystemer legger også til et ekstra sikkerhetslag (hvis du ikke har tilgang til filstien, kan du ikke få tilgang til socketen)
Det første punktet er lett å forstå – et raskt Google-forsøk vil vise at UDS- og TCP/IP-benchmarks alltid er bedre enn UDS fordi det ikke bare har betydelig lavere latenstid, men også betydelig høyere gjennomstrømning. Dette skyldes hovedsakelig at UDS er optimalisert for kommunikasjon med samme server,For IP-kommunikasjon må localhost gå gjennom IP-stakken både på avsender- og mottakersiden。
TCP/IP-sokler er en endelig ressurs; Du kan bare bruke opptil 65 535 sokler om gangen. Hvis du legger til problemet, kan det maksimale antallet kontakter som faktisk TIME_WAIT tilgjengelig være mye færre enn denne summen. Localhost-tilkoblingen bruker også sokler i denne poolen. Å bruke UDS unngår dette problemet på en smart måte; Den tillater kommunikasjon uten å tømme TCP/IP-sokler.
server
Lag et nytt .NET 8-konsollprosjekt, bytt SDK-en til Microsoft.NET.Sdk.Web, og konfigurer det som følger:
Greet.proto er konfigurert som følger:
Koden er som følger:
Etter at samlingen starter, som vist nedenfor:
klient
Opprett et nytt .NET 8-konsollprosjekt og referer til følgende biblioteker:
Metoden for å kalle gRPC-grensesnittet kalles 10 ganger, og hvert kall kalles i 200 millisekunder, og koden er som følger:
Start prosjektet, og etter at gjennomføringen er fullført, som vist i figuren under:
Referanse:
Innloggingen med hyperkoblingen er synlig.
Innloggingen med hyperkoblingen er synlig. |
Publisert 11.08.2025 kl. 20:24:04
|
|
|
|
Vert|
Publisert 11.08.2025 kl. 20:57:04
|
