Faster, more secure connections for containerized environments like Docker under Linux and Windows for Communication on the same host.
Introduction
The following blog post caught my eye as I was reading through the Java Enhancement Proposals. I was working my way through all the JEPs, that I have been missing, since my last employer didn't allow me to take the time nor had the environment for getting up to speed. Since there was no active community for this type of conversations, i was told not to communicate with others outside of my scrum team, and there was quite a bit of control from one of the founders, I got to be in the same scrum team with, about what scope I am allowed to work in.
If you are in the same situation or you want to get up to speed with at least some of the JEPs, I collected here some information and prepared it for easier digestion, explaining the background, the motivation behind the JEPs, what they achieve, for what use case they are meant to be used.
Java HTTP Client API, Simple Web Server and API, UNIX-domain socket channels.
I was reading a blog from oracle, Java’s new HTTP Client API, UNIX-domain sockets, and Simple Web Server - January 7.,2022
It's mostly about a new HTTP client ... a new API that has been introduced, the Java HTTP Client API, It was made standard in JDK 11 as JEP 321.
And also about a simple web server and API targeted for Java 18 as JEP 408 (Read more about it in the blog post released just 3 months after, April 8.,2022 Java 18’s Simple Web Server: A tool for the command line and beyond)
Furthermore, another two JEPs were mentioned JEP 353, which reimplements the legacy Socket API, and JEP 373, which reimplements the legacy DatagramSocket API in preparation for Project Loom Virtual Threads.
But what I would like to talk about this time is another...UNIX-domain socket channels, which appeared in JEP 380.
UNIX-domain socket channels
Here is an excerpt:
David Delabassée, a developer advocate in the Java Platform Group at Oracle, recently spoke with Oracle Java architects Daniel Fuchs and Michael McMahon
Delabassée: Moving beyond the HTTP Client API, UNIX-domain socket channels were added to Java 16. What can you tell us about that?
McMahon: UNIX-domain sockets are like TCP/IP sockets, except that these sockets are used only for local interprocess communication (IPC), and they are addressed through file system pathnames, rather than through an IP address and port number. UNIX-domain socket channels, which appeared in JEP 380, offer several benefits for applications that need to do only local IPC or IPC between containers. Performance is one benefit: By cutting out the TCP/IP stack, you can improve throughput and lower CPU utilization. These sockets can also improve security because if you need only local IPC, you don’t need to open ports to the network. With UNIX-domain sockets, you can also make use of file system access controls and user credentials for additional security. When testing them with Docker, we found that UNIX-domain sockets make it easier to set up communication between containers.
Let's say you want to use the new libraries introduced JEP 380. Where would you find these?
To make all this work, JEP 380 added the following API elements: A new socket address class, java.net.UnixDomainSocketAddress.
I guess you would use this class when constructing a socket, to pass an argument to its constructor to specify configurations such as the domain.
(For those who are not familiar with the terminology, it's important to differentiate between "formal parameters" or "parameters", "actual parameters" or "arguments" and "type parameters" like "formal type parameters", and "actual type parameters" or "type arguments".
Here are some example sentences that showcases the correct usage of terminology:
formal parameters, parameters, arguments
"The constructor's signature includes formal parameters that define the types and number of arguments it accepts."
"The constructor's parameters are the specific pieces of data that need to be provided when creating an instance of the class."
actual parameters, arguments
"When a method or constructor is called, the values provided are known as actual parameters or arguments."
type parameters
"Generic classes or methods, might also have type parameters, but these would define the types it works with, not the actual values passed during construction."
formal type parameters, actual types
"They are placeholders for the actual types that will be specified when creating instances of the generic class or invoking the generic method. For example, in a generic class definition like class MyClass<T>, T is a formal type parameter."
actual type parameters, type arguments
"If you create an instance of MyClass<Integer>, Integer is an actual type parameter (or type argument) that replaces the formal type parameter T."
formal type parameters, actual type parameters
"If the class is generic and defined with formal type parameters, you would specify the actual type parameters when you create an instance of that class."
)
Okay, sorry for going on a tangent. Let's continue with the with the response of McMahon, from which we can find out where we would have to search to use the new API components.
A UNIX constant value in the existing java.net.StandardProtocolFamily enum. New open factory methods on SocketChannel and ServerSocketChannel that specify the protocol family. Updates to the SocketChannel and ServerSocketChannel specifications to allow you to define how the channels to the UNIX-domain sockets behave.
It should also be mentioned that despite the name, UNIX-domain sockets are also available on Windows!
Delabassée: Typically, with a network connection, security is enforced at the network level, such as by using firewalls and reverse proxies. How can security be enforced with UNIX-domain sockets?
McMahon: ..the main way you get security is through the operating system, its user and groups, and its file permissions, where you can restrict access to file system nodes through user IDs and group IDs. An additional useful feature, which works on the UNIX platform but not on Windows, is via testing user credentials. If a client socket channel is connected to a server socket channel, either side can request the identity of the user at the opposite side.
Okay, let's just try to understand what we have read in the article, and what UNIX-domain sockets allows us to do. I will summarize it in a more structured manner.
Let's start by explaining what the Unix domain sockets are, and what is the order of system calls, how is the connection established, how data is sent and received, and what role the buffer plays in that, and how the connection gets terminated.
Use Cases, Contrasting with network sockets
UNIX domain sockets are often used in containerized environments (such as Docker) for secure and efficient communication between the host and containers or between containers themselves. In containerized environments like Docker, UNIX domain sockets can be isolated within namespaces. This means that sockets in different containers or in the host can be isolated from each other, enhancing security and avoiding conflicts in socket addresses.
UNIX domain sockets can be more secure than IP sockets since they don't expose services over the network. They are suitable for a range of applications, from simple data transfer to complex IPC mechanisms(we are not going to go into that in this article, but its an exciting topic, look up the keywords IPC or ITC, Multiprocessing for more on this).
Domain: AF_UNIX (also known as AF_LOCAL).
These sockets allow communication between processes, inter-process communication (IPC) on the same host system, which is more efficient than using network sockets (like AF_INET) for local IPC. They are efficient as they avoid the networking layer overhead.
Flow Control and Congestion Control, Contrasting with network sockets
No Congestion Control: Unlike network sockets (AF_INET), UNIX domain sockets do not implement congestion control.
Flow Control: They still implement flow control mechanisms similar to TCP. It helps synchronize the sender and receiver's pace, this ensures that the sender does not overwhelm the receiver with more data than it can handle. Flow control in UNIX domain sockets is typically managed by the kernel, which adjusts the buffer size dynamically based on the current load and buffer occupancy. See below the part about what role the buffer plays in this.
System Calls, Contrasting with network sockets
The Unix stream socket connection follows the same set of calls as that of a stream connection as used for a internet protocol (AF_INET) stream socket connection.
Process Step 1 - Establishing the connection:
Short description The server uses socket(),bind(), listen(), and accept() to set up a socket that waits for connections.
Short description The client uses socket(),connect() to establish a connection with the server.
Role Passive socket (server)
Recommended by LinkedIn
commands socket(),bind(), listen(), and accept()
command socket():
Creates a new socket. For a UNIX domain socket, the domain is AF_UNIX. Socket Type: You can choose between SOCK_STREAM for a TCP-like , connection-oriented("stream-oriented") socket and SOCK_DGRAM for a UDP-like, connectionless ("datagram-oriented") socket.
For SOCK_DGRAM UNIX domain sockets, the connection establishment process (bind, listen, accept) is not applicable as they are connectionless. You directly send and receive messages to and from specific addresses.
The termination process is simpler for SOCK_DGRAM sockets. There is no connection teardown like in SOCK_STREAM. You just close the socket when done.
Half-Open Connections: Just like TCP, UNIX domain sockets support the concept of half-open connections. One side of the connection can close its end, signaling the end of data transmission, while the other side can still send data. See below under Process Step 3 - Closing the Connection.
Transmission Reliability Transmission Reliability: Although UNIX domain sockets use a transmission mechanism similar to TCP (for SOCK_STREAM) in terms of reliability and ordered delivery, they are not subject to the same network issues (like packet loss or variable latency) since they are confined to the local machine.
Also SOCK_DGRAM in UNIX domain sockets still provides reliable, ordered delivery of messages (unlike UDP in the network context), but without establishing a connection. However, datagram sockets do not guarantee that all messages will be delivered.
command bind(): Assign a local protocol address (file pathname in UNIX domain) to the socket (like /tmp/socket). This pathname is a unique identifier and functions as the 'address' for the socket on the local machine.
Abstract Namespace: Besides filesystem pathnames, UNIX domain sockets can also use an abstract namespace (starting with a null byte '\0'). This type of address does not correspond to a file in the filesystem, thus eliminating file system dependencies and the need to manage socket files, file permissions issues and the need to clean up leftover socket files. The address (pathname) used in bind() must be unique.
Point of failure: If it already exists, bind() will fail, usually requiring deletion of the pathname if it lingers from a previous socket.
command listen(): Mark the socket as passive, i.e., as willing to accept incoming connection requests. This call also defines the maximum number of pending connections that can be queued.
Point of failure: If a connection request arrives when the queue is full, the client may receive an error or the connection request may be ignored.
command accept(): Block the caller until a connection request arrives. It returns a new socket file descriptor for the accepted connection. The original socket descriptor continues to be used to accept new connections, while the new one is used for communication with the connected client.
Role Active socket (client)
commands socket(),connect()
command socket(): The client also starts by creating a socket using the socket() system call.
command connect(): Initiate a connection to the server. It needs the address of the server. The address is expected to be the pathname to which the server socket is bound. UNIX domain sockets use standard file permissions for security.
Point of Failure: The socket file (path) needs proper permissions so that the intended users or processes can access it.
Process Step 2 - Sending and Receiving Data:
Short description Data is sent back and forth using read() and write() (or recv() and send()).
Role Server/Client
commands write(),send(),read(),recv()
command write()/send(): Writes data to a buffer, from where it can be read by the receiving process. Process A writes to Socket X's write buffer, and Process B writes to Socket Y's write buffer. It places the data into a buffer associated with the socket. The data stays in this buffer until the corresponding process on the other end reads it using read() or until...see Buffer Role below
These calls are used to send data. While write() is more basic, send() offers more options (e.g., flags). It provides more control, such as specifying flags for non-blocking I/O or sending ancillary data.
Non-blocking Mode: Sockets can be set to non-blocking mode. In this case, calls like accept(), read(), and write() do not block the process if the operation cannot be completed immediately. For instance, read() might return EAGAIN or EWOULDBLOCK error codes if there's no data available in the receive buffer.
Asynchronous I/O: Besides non-blocking mode, asynchronous I/O is another important feature that can be used with UNIX domain sockets. This allows a process to initiate an I/O operation and continue with other tasks, receiving a notification when the I/O operation completes. This can be achieved using mechanisms like aio_read() and aio_write() for asynchronous I/O operations.
command read()/recv(): Reads data from the receive buffer. Similarly, recv() can provide more options than read(). Reads data from the buffer where it was written by the sending process. Process A reads from Socket Y's read buffer, and Process B reads from Socket X's read buffer.
Point of Failure: Handling partial reads/writes is essential as these system calls may transfer fewer bytes than requested. If so they should be looped with the remaining number of bytes until all data is sent or received.
Buffer role: When data is written to the socket, it goes into the send buffer and stays there until read by the receiving process from its receive buffer. The operating system manages the send and receive buffers for sockets.
When data is written to a socket, it's stored in the send buffer of the sending socket. The data is then transferred to the receive buffer of the receiving socket, from where it can be read.
These buffers help manage differences in speed between sending and receiving processes. The kernel manages these buffers, ensuring that the data stays there until it's read by the receiving process from its corresponding receive buffer.
The buffer size for UNIX domain sockets is typically configured at the kernel level. The size of these buffers can significantly impact the performance of your IPC, as it determines how much data can be in transit before blocking occurs. The SO_SNDBUF and SO_RCVBUF socket options can be used to adjust these buffer sizes.
Process Step 3 - Closing the Connection:
Role Server/Client
commands close()
command close(): When the communication is complete, both the client and the server use close() to close their respective socket descriptors.
A noteworthy point is that closing a socket decrements the reference count on the socket. If the count reaches zero, then resources are freed. For UNIX domain sockets, the server typically unlinks the pathname it was bound to using unlink(), this removes the file from the filesystem.
This prevents issues when restarting the server and trying to bind to the same pathname again. For SOCK_STREAM type sockets, it's important to note that closing a connection (using close()) initiates a TCP-like shutdown sequence. This means that it's not just closing the local end of the connection but also signaling the remote end.
This involves an exchange of messages to gracefully close the connection, similar to TCP's FIN handshake.
Also see above under Half-Open Connections under Process Step - 1 Establishing the Connection command socket().
Point of failure: It's crucial to handle errors at each step, particularly for socket(), bind(), listen(), accept(), and connect(). System calls can fail for reasons such as permissions issues (e.g., a client trying to connect to a socket file it doesn't have permission to access), resource exhaustion, or unexpected disconnection of the other end. So checking return values and errno is necessary for robust implementations. System calls return -1 on failure, and errno is set to indicate the error. Functions like perror() or strerror(errno) can provide human-readable error messages. It's important to handle the TIME_WAIT state properly in network sockets to avoid port exhaustion. However, this is less of a concern with UNIX domain sockets since they don't use network ports.
Point of Failure: Also error handling should be implemented if in send() we passed options for entering Non-blocking Mode, like mention above.
Socket Options: Various socket options can be set using setsockopt() to control socket behavior, like timeouts, buffer sizes, etc. You can also use getsockopt() to retrieve socket options.
Point of failure: What if one end of the connection closes unexpectedly: If you write to a socket that has been closed by the other end, your process will receive a SIGPIPE signal. To prevent process termination its necessary handling the SIGPIPE signal or using the send() function with the MSG_NOSIGNAL flag.
Zero-Copy I/O: For high-performance needs, zero-copy I/O mechanisms can be used with UNIX domain sockets. This allows data to be sent and received directly between user-space buffers and the socket without additional copying by the kernel, reducing CPU usage and improving throughput.
Advanced Socket Options: Beyond buffer sizes and timeouts, other socket options can be important in specific use cases, to support passing file descriptors or credentials (like PID, UID, GID) between processes. For example, SO_PASSCRED enables the transmission of credentials over a socket. Also mentioned in the article by McMahon
Scalability Considerations: For server applications that handle many simultaneous connections, it's common to use I/O multiplexing using select(), poll(), or epoll() is common in server applications. This allows a single process to monitor multiple file descriptors, waiting for one or more of the sockets to become "ready" for some class of I/O operation.
Socket Pair: Another useful feature is the ability to create a pair of connected sockets using socketpair(), which is handy for setting up a communication channel between parent and child processes. It is somewhat related to the abstract namespace (mentioned below bind() under Establishing a Connection) in that it provides an IPC mechanism without the need for a named socket in the filesystem, but it is a distinct concept and serves a different purpose. The socket pair is inherently connected(by default, no need for server: socket(),bind(),listen(),accept(), client: socket(),connect() (What!? just like SOCK_DGRAM? more on that later...in another article) ) and is used for bidirectional communication between two endpoints, typically within the same process or between a parent and child process.
Pictures on the top are credited to
Take a look, these depictions nicely encompass some aspects of Unix domain sockets.
In the next article we are going to look at the concrete implementations, here is a taste of what's coming:
Fast and Secure Inter-process Communication on JDK 16 - Inside Java Newscast #11