Usmux: Unix-Domain Socket Multiplexing

Usmux: Unix-domain socket multiplexing Steven Simpson December 3, 2018 Abstract opens a Unix-domain socket, and multiplexes connections on the socket to the Java process via the pipes. A protocol is defined to permit the multiplexing. Although Java programs are executed on a virtual machine, they can run as fast as programs compiled to Specifications of the protocol and the Java API are in- the native architecture when just-in-time (JIT) compi- dependent of this particular use of sockets and pipes, so lation is applied, along with other optimizations involv- they could be re-applied on other platforms with alter- ing profiling and in-lining. These are most effective in native concepts, while allowing the Java code that uses long-running executions, where the cost of initialization them to remain portable between platforms. and analysis can be amortized. Consequently, Java programs can run efficiently over long periods as server Introduction processes and desktop applications, but perform signif- icantly less well as short lived programs such as CGI At first, Java appears inherently slow by its design. Java scripts. source code is first compiled into bytecode, an assembly A long-running Java application could be adapted language for a virtual processor called the Java Virtual for use by short-lived commands by making them con- Machine (JVM). The JVM then processes each (virtual- nect to (say) a socket which the application is listening )machine code instruction to produce the behaviour rep- on. The short-lived commands are then simple clients, resented by the source code, and it is this processing whose job is merely to relay I/O between the user and which is slower that an equivalent program compiled to the application. The only built-in and portable mech- a native machine code. The benefit is a write-once, run- anism to connect with such a Java process is to use anywhere (WORA) environment making Java programs network sockets, possibly restricted to the loopback ad- maximally portable. The additional layer of abstraction dress for security purposes. (the JVM must ultimately be written in native machine There are also third-party Java libraries which pro- code) also provides greater integrity, increasing secu- vide access to Unix-domain sockets, giving additional rity, making dynamic loading of foreign code possible, security (especially on multi-user machines), but these and detecting programmer error. do not fit well with Java’s native socket abstrac- The creators of Java have also sought speed improve- tion, which allows its Internet-specific nature to leak ments along several avenues. Start-up times have been through. They also usually require JNI, and therefore reduced by increasing the modularity of the standard li- introduce additional complexity in terms of installation. brary, and by permitting some lazy class initialization. This report details an approach to supporting Unix- Bytecode can be compiled to native code as it is loaded domain socket access to persistent Java processes, with- with a just-in-time (JIT) compiler installed in the JVM. out using any JNI, and just a small amount of C in a sep- The JVM may also monitor its process, looking for sec- arate wrapper or launcher program. This brings an addi- tions of code most frequently executed, in order to pri- tional benefit of launching the Java process in the back- oritize its optimization. It may also in-line sections of ground, with a synchronization point just after start-up code to reduce the overhead of method invocation. Note to allow the process to abort execution if failure is de- that these optimizations apply at run time in the JVM, tected early. Under the approach, the launcher creates whereas the compiler mostly avoids them, as the effec- a pair of named pipes in the filesystem, starts the Java tiveness of these optimizations depend greatly on run- process (informing it of the names of the two pipes), time characteristics not available during compilation. 1 Altogether, these optimizations can allow a Java pro- junixsocket3 cess to run at least as fast as a natively compiled pro- This is a JNI library that uses the the Java Sockets gram, while still retaining the benefits of portability. API, and supports RMI. Fitting in with the Sockets However, each one also comes with an overhead, which API is a feat, as much of it is based on Internet- must be amortized by its results being applicable over domain sockets, and doesn’t seem to fit well when a sufficiently long period. For example, a Java pro- a broader abstraction is required. gram used as a short-lived command cannot easily benefit from JIT because JIT-ed code may only be executed J-BUDS a small number of times before exiting (and the next in- This is an orphaned project. [Investigate.] vocation will have to be re-JIT-ed), nor from HotSpot gnu.net.local because the process terminates before enough analysis This is another oprhaned project. [Investigate.] has been performed. Consequently, Java performs best when used for long-running programs, such as desktop Providing native support for Unix-domain sockets in applications and server processes. Java seems to create more problems than it solves. It Some environments are designed to work with short- is necessarily platform-specific, so the Java code that lived processes. A command shell such as Bash re- uses the support must be wrapped behind a platform- peatedly executes external commands, and the Com- independent abstraction if the program is to remain mon Gateway Interface (CGI) used by web servers to platform-independent itself. The fact that the Internet- delegate requests to user programs mandates one pro- domain nature of the Java Sockets API leaks through its cess per request. These are therefore poor environments own abstraction means that that API does not help to in which to use Java. hide platform-specificity. Persistence for CGI programs Usmux Java isn’t the only language to suffer great overheads Usmux is an approach to allow one-invocation-per- due to repeated start-ups. Any per-process delay on a request environments like CGI to be used with persis- CGI program, in whatever language, makes CGI the tent Java processes. At the time of writing, the im- bottleneck for any high-demand service. FastCGI1 was plementation is POSIX-specific, but the architecture is devised to address this issue by using a regular TCP platform-independent. Implementations on other plat- connection between the web server and the CGI pro- forms may be possible. gram, which runs persistently and serves multiple re- On a POSIX system, the usmux command takes a quests, instead of running once per request. This is a Java command as its trailing arguments. It also opens a good approach, but the Usmux project aims for a more Unix-domain socket, creates two named pipes, and in- general mechanism than one built to support CGI; it jects the names of these pipes as a configuration string should be possible to implement a FastCGI-like mech- into the Java command, which is then executed in the anism over Usmux. background. It then accepts connections on the socket, [upcgi] and presents them as sessions to the Java process by creating another pair of named pipes per session, using its original pipes to notify the Java process of them, and Java support for Unix-domain sockets relaying data between the pipes and the socket. As a result, the Java process can run persistently, but be in- Another approach to allow a Java process to run per- voked by multiple clients over a Unix-domain socket. sistently is to provide a library supporting Unix-domain On other platforms, a similar command could use sockets. Several implementations are summarized here: other platform-specific features to interact with a server running the same Java software. Only the injected con- JUDS2 figuration string needs to change, and the Usmux Java [Investigate.] library will dynamically load in the matching server- side implementation. 1http://www.fastcgi.com/drupal/ 2https://github.com/mcfunley/juds 3http://code.google.com/p/junixsocket/ 2 Even under POSIX, other mechanisms are possible user id, group id) can be detected by the daemon, and too. For example, usmux could create a pair of named be relayed to the server. When the client connects di- pipes, and multiplex several sessions over them. (How- rectly to the server via TCP, its host and port can be ever, experience has shown that this is error-prone to made available to the server. These are exposed to the code, and hampers over-all through-put.) server in a generic form as client meta-data, described The use of a Unix-domain socket to communicate in x2.1. When the daemon is involved in implementing with clients has several advantages. First, as its ren- sessions, the protocols involved in talking to the server dezvous point is part of the filesystem, the host’s native allow the daemon to relay this information as opaque access control can be applied to it. For more sophisti- binary data. cated control, it is possible to inform the server of which Figure 2 depicts one daemon-server scheme which user or group is actually connecting. Finally, invocation can appear platform-independent to the server, in which of the client could exploit external authentication proto- all connections accepted by the daemon are multiplexed cols such as SSH. over two simplex named pipes. This protocol is described in x3.2, and is capable of relaying arbitrary client meta-data to the server. Architecture Alternatively, the daemon may establish a pair of pipes per session, and inform the server of each one, Usmux aims to allow a client to initiate a session with plus client meta-data, over a pipe pair dedicated for sig- a server.

Load more