Requirements: On the same server, processes communicate with each other using anonymous pipelines, named pipelines, memory mapping files, HTTP, TCP, Standard Input/Output Streams, etc. Sometimes servers need to deploy multiple applications, and applications can actually communicate with each other using gRPC and Unix domain sockets.
review
Unix domain sockets
Unix Domain Sockets (UDS), Local Sockets, or Interprocess Communication (IPC) sockets are communication endpoints that exchange data between processes running in the same Unix or Unix-like operating system.
The name Unix domain socket refers to the domain parameter value passed to the function that created the socket system resource. The same communication domain is also selected. [ 1 ] AF_UNIXAF_LOCAL
The valid parameter values for typeUDS are:
- SOCK_STREAM (compared to TCP) – Used for stream-oriented sockets
- SOCK_DGRAM (compared to UDP) – a datagram-oriented socket for preserving message boundaries (as with most UNIX implementations, UNIX domain datagram sockets are always reliable and do not reorder datagrams)
- SOCK_SEQPACKET (compared to SCTP) – Sequential packet sockets for connections that preserve message boundaries and deliver messages in the order in which they are sent
The UDS tool is a standard component of the POSIX operating system.
Why use Unix domain sockets?
Unix domain sockets allow inter-process communication on a single machine. So why would you choose them over TCP/IP? For example, in TCP/IP, you can use a loopback address (localhost) for single-server communication. On Windows, why would you choose them over Windows Naming Pipelines?
In general, there are several reasons why you might choose to use UDS instead of TCP/IP for interprocess communication:
- Unix domain sockets typically have less overhead and faster transfer speeds than using TCP/IP
- TCP/IP sockets are a finite resource, while Unix domain sockets have no hard limits
- Unix domain sockets come in file form, so it's easy to "discover" known paths
- Integration with file systems also adds an extra layer of security (if you don't have access to the file path, you can't access the socket)
The first point is easy to understand - a quick Google will show that UDS and TCP/IP benchmarks are always better than UDS because it not only has significantly lower latency, but also significantly higher throughput. This is mainly due to the fact that UDS is optimized for communication with the same server,For IP communication, localhost must go through the IP stack on both the sender and receiver sides。
TCP/IP sockets are a finite resource; You can only use up to 65,535 sockets at any one time. If you add the problem, the maximum number of sockets that TIME_WAIT actually available may be much less than this value. The localhost connection also consumes sockets in this pool. Using UDS cleverly avoids this problem; It allows communication without exhausting TCP/IP sockets.
server
Create a new .NET 8 console project, change the SDK to Microsoft.NET.Sdk.Web, and configure it as follows:
Greet.proto is configured as follows:
The code is as follows:
After the compilation starts, as shown below:
client
Create a new .NET 8 console project and reference the following libraries:
The method of calling the gRPC interface is called 10 times, and each call is called for 200 milliseconds, and the code is as follows:
Start the project, and after the execution is completed, as shown in the figure below:
Reference:
The hyperlink login is visible.
The hyperlink login is visible. |
Posted on 2025-8-11 20:24:04
|
|
|
|
Landlord|
Posted on 2025-8-11 20:57:04
|
