Rserve is a TCP/IP server which allows other programs to use facilities of R (see www.r-project.org) from various languages without the need to initialize R or link against R library. Every connection has a separate workspace and working directory. Client-side implementations are available for popular languages such as C/C++, PHP and Java. Rserve supports remote connection, authentication and file transfer. Typical use is to integrate R backend for computation of statstical models, plots etc. in other applications.

The following Java code illustrates the easy integration of Rserve:

RConnection c = new RConnection();
double d[] = c.eval("rnorm(10)").asDoubles();

d now contains 10 random samples from the N(0,1) distribution if there is a runing Rserve on the local machine. The RConnection doesn't have to be created more than once for subsequent commands (however, each thread must have its own connection object unless synchronized explicitly).

As a side note - if you are looking just for a way to access R from Java in one application without the need for the client/server concept, you may want to have a look at JRI. It uses JNI to link R directly into Java.

The original Rserve paper is available in the DSC-2003 proceedings. Please cite that paper when using Rserve.

NOTE: Rserve is perfect as a back-end for web services and is often used that way. See also FastRWeb.

Important note about the Java clients: please make sure you're using the REngine-based client! (org.rosuda.REngine.Rserve.RConnection class). For some strange reason some users are still using the old, unsupported JRclient which has been replaced three years ago! On a somewhat related note, if you get the following error: "Rserve exception: Handshake failed: The server uses more recent protocol than this client." then you are using a very old build of the old client! Always take the client supplied with the Rserve version you're using - it's located in src/clients/java-new in the Rserve source package. The old client is still supplied in java-old but its use is strongly discouraged as it's not tested anymore.

• fast - no initialization of R is necessary
• binary transport - the transport protocol sends R objects as binary data, not just R text output.
• automatic type conversion - most R data types are converted into native data types, e.g. the result of rnorm(10) will be double[10] in C/Java. Java client also provides classes for new R types such as RBool, RList etc.
• persistent - each connection has its own namespace and working directory. Every object you create is persistent until the connection is closed. The client doesn't have to fetch or store intermediate results.
• client independence - since the client is not linked to R there are no threading issues like in RSJava etc.
• security - Rserve provides some basic security by supporting encrypted user/password authentication with server challenge. Rserve can be also configured to accept local connections only.
• file transfer - the Rserve protocol allows to transfer files between the client and the server. This way Rserve can be used as a remote server even for task such as generating plot images etc.
• configurable - one configuration file is used to control settings and to enable/disable features such as authorization, remote access or file transfer.

• Rserve provides no callback functionality. Your application could implement callbacks via TCP/IP and the R sockets but it is not a part of Rserve.
• Rserve is not a telnet frontend to R. The printed output is not transported (except via capture.output). Rserve uses binary protocol for transport of objects for better speed.
• Rserve is thread safe across connections, but eval methods are not thread safe within one connection. This means that multiple threads should not use the same connection unless they guarantee that no eval calls are run in parallel.