Prasības: Tajā pašā serverī procesi sazinās savā starpā, izmantojot anonīmus cauruļvadus, nosauktus cauruļvadus, atmiņas kartēšanas failus, HTTP, TCP, standarta ievades/izvades plūsmas utt. Dažreiz serveriem ir jāizvieto vairākas lietojumprogrammas, un lietojumprogrammas var sazināties savā starpā, izmantojot gRPC un Unix domēna ligzdas.
Pārskats
Unix domēna ligzdas
Unix domēna ligzdas (UDS), lokālās ligzdas vai starpprocesu sakaru (IPC) ligzdas ir sakaru galapunkti, kas apmainās ar datiem starp procesiem, kas darbojas vienā un tajā pašā Unix vai Unix līdzīgā operētājsistēmā.
Nosaukums Unix domēna ligzda attiecas uz domēna parametra vērtību, kas nodota funkcijai, kas izveidoja ligzdas sistēmas resursu. Tiek atlasīts arī tas pats saziņas domēns. [ 1 ] AF_UNIXAF_LOCAL
Derīgās parametru vērtības tipamUDS ir šādas:
- SOCK_STREAM (salīdzinot ar TCP) - Izmanto uz straumi orientētām ligzdām
- SOCK_DGRAM (salīdzinot ar UDP) – uz datagrammu orientēta ligzda ziņojumu robežu saglabāšanai (tāpat kā lielākajā daļā UNIX ieviešanu, UNIX domēna datagrammu ligzdas vienmēr ir uzticamas un nepārkārto datagrammas)
- SOCK_SEQPACKET (salīdzinājumā ar SCTP) — secīgas pakešu ligzdas savienojumiem, kas saglabā ziņojumu robežas un piegādā ziņojumus nosūtīšanas secībā
UDS rīks ir POSIX operētājsistēmas standarta sastāvdaļa.
Kāpēc izmantot Unix domēna ligzdas?
Unix domēna ligzdas ļauj sazināties starp procesiem vienā mašīnā. Tātad, kāpēc jūs tos izvēlētos, nevis TCP/IP? Piemēram, TCP/IP var izmantot cilpas adresi (localhost) viena servera saziņai. Kāpēc operētājsistēmā Windows izvēlēties tos, nevis Windows nosaukumu cauruļvadus?
Kopumā ir vairāki iemesli, kāpēc starpprocesu saziņai varat izvēlēties izmantot UDS, NEVIS TCP/IP:
- Unix domēna ligzdām parasti ir mazāk pieskaitāmo izdevumu un ātrāks pārsūtīšanas ātrums nekā TCP/IP
- TCP/IP ligzdas ir ierobežots resurss, savukārt Unix domēna ligzdām nav stingru ierobežojumu
- Unix domēna ligzdas ir faila formā, tāpēc ir viegli "atklāt" zināmos ceļus
- Integrācija ar failu sistēmām arī pievieno papildu drošības slāni (ja jums nav piekļuves faila ceļam, jūs nevarat piekļūt ligzdai)
Pirmais punkts ir viegli saprotams - ātrs Google parādīs, ka UDS un TCP/IP etaloni vienmēr ir labāki par UDS, jo tam ir ne tikai ievērojami mazāks latentums, bet arī ievērojami lielāka caurlaidspēja. Tas galvenokārt ir saistīts ar to, ka UDS ir optimizēts saziņai ar to pašu serveri,IP saziņai localhost ir jāiet cauri IP stekam gan sūtītāja, gan saņēmēja pusē。
TCP/IP ligzdas ir ierobežots resurss; Vienlaikus varat izmantot tikai līdz 65 535 kontaktligzdām. Ja pievienojat problēmu, maksimālais kontaktligzdu skaits, kas faktiski TIME_WAIT pieejams, var būt daudz mazāks par šo vērtību. Localhost savienojums patērē arī ligzdas šajā baseinā. Izmantojot UDS, gudri izvairās no šīs problēmas; Tas ļauj sazināties, neizsmeļot TCP/IP ligzdas.
serveris
Izveidojiet jaunu .NET 8 konsoles projektu, nomainiet SDK uz Microsoft.NET.Sdk.Web un konfigurējiet to šādi:
Greet.proto ir konfigurēts šādi:
Kods ir šāds:
Pēc kompilācijas sākuma, kā parādīts zemāk:
klients
Izveidojiet jaunu .NET 8 konsoles projektu un atsaucieties uz šādām bibliotēkām:
gRPC interfeisa izsaukšanas metode tiek izsaukta 10 reizes, un katrs zvans tiek izsaukts 200 milisekundes, un kods ir šāds:
Sāciet projektu un pēc izpildes pabeigšanas, kā parādīts zemāk redzamajā attēlā:
Atsauce:
Hipersaites pieteikšanās ir redzama.
Hipersaites pieteikšanās ir redzama. |