Binary R server

Rserve acts as a socket server (TCP/IP or local sockets) which allows binary requests to be sent to R. Every connection has a separate workspace and working directory. Client-side implementations are available for popular languages such as C/C++ and Java, allowing any application to use facilities of R without the need of linking to R code. Rserve supports remote connection, user authentication and file transfer. A simple R client is included in this package as well.


NEWS/Changelog for Rserve

1.7-3 2013-08-21 o the handling of server configuration modes has been inconsistent for some combinations (mostly affected were combinations involving WebSockets upgrade and OC mode on HTTP/WS servers). Also the websockets.qap.oc configuration option has been misspelled.

o	HTTPS->WSS upgrade is now supported

o	mkdist -i installs the built package, use -c for check

o	Windows compatibility has been restored thanks to
David Champagne from Revolution Analytics

1.7-2 2013-08-12 o when uid/gid is changed, create a new tempdir() and set its permissions as well as the wokring directory's owner to match.

o	bugfix: if the first command is not any of the eval family
the Rserve may respond with an additional, spurious error

o	deamonized server would record incorrect pid when pid.file
is used (i#5). The pid is now removed on clean sutdown.

o	added support for keep.alive configuration option - it is
global to all servers and if enabled the client sockets are
instructed to keep the connection alive by periodic messages.

1.7-1 2013-07-02 o remove a spurious character that prevented compilation on Suns

o	add OPENSSL_INCLUDES precious variable that can be used to
point to non-standard location of OpenSSL headers

o	check the usability of OpenSSL headers before enabling TLS

o	added the choice of GPLv2 or GPLv2 with OpenSSL linking exception


*** ---- HEADLINE NEWS ---- *** new protocols: HTTP, HTTPS, WebSockets and TLS/QAP *** added protocol switching (from QAP to TLS/QAP) via CMD_switch *** The R client was moved to RSclient package *** New in-session server support with run.Rserve() *** Out-of-band messages via self.oobSend() *** user-based uid/gid switch, MD5/SHA1 stored passwords *** preliminary IPv6 support; RSA secure authentication *** .Rserve.done global env hook for optiopnal cleanup *** auth.function setting to allow custom authentication *** Object-capability mode for hardened, secure services *** ---- END - see below for details ----

o	This is the first release in the new 1.x Rserve series. Many
of the Rserve internals have been re-written or cleaned
up. The original protocol remains the same (so all clients
that worked with Rserve 0.6 will continue to work), but the
suite of available protocols has been extended (see below).

o	added support for multiple protocols in Rserve:

    ** QAP **
this is the original Rserve protocol used in Rserve 0.x
series. It works over TCP/IP and unix sockets. It is
enabled by default and can be disabled using
"qap disable" configuration directive.

** HTTP **
this is very similar to the built-in R http server except that
on unix it forks on connection so it allows parallel separate,
persistent connections. It requires a worker function
.http.request to be defined in the session which will handle
incoming requests. This allows the use of facilities like
FastRWeb without an external webserver. This protocol is
disabled by default and can be enabled by setting "http.port"
configuration directive to the desired port to listen to.
(Also see TLS support below for https server).

The http.raw.body configuration option (default is false which
results in the same behavior as Rhttpd) can be used to force
passing body in raw form to the handler (useful for the
FastRWeb handler which does its own parsing).

** WebSockets **
this protocol is used by HTML5 web browsers for direct access
to R with a persistent connection. This allows implementation
of websites that have a dedicated R session (and could be used
as an R console). There are two subprotocols supported by

  -- WebSocket(*, "QAP") --
  this is a tunnel for the original QAP protocol through
  WebSockets. It requires a browser capable of binary
  WebSockets protocol (version 01 or higher). It allows very
  efficient data transfer, typically by loading ArrayBuffers
  directly into GPU or CPU.
  It is disabled by default and can be enabled using
  "websockets.qap enable" configuration directive.
  (If no subprotocol is specified, QAP is assumed)

  -- WebSocket(*, "text") --
  this is a very simplistic protocol using plain text frames
  to send input to R and output from R directly as text. It
  acts essentially as an R console. This protocol works with
  any WebSockets implementation including version hybi-00 and
  It is disabled by default and can be enabled using
  "websockets.text enable" configuration directive.

  NOTE: The textual WebSockets protocol does NOT provide any
  authentication mechanism, so use with extreme care as you
  are essentially giving any user with a web browser access to
  R and thus to the shell.
In addition to enabling each or both subprotocols, the port on
which the WebSockets server should listen must be specified in
the configuration using "websockets.port" directive, for
example "websockets.port 8080". Alternatively, the HTTP server
can be enabled to allow connection upgrade to WebSockets on
the same port with "http.upgrade.websockets enable"

NOTE: remember that the default in Rserve is to disallow
remote connections, so you may need to use "remote enable" in
order to use WebSockets or HTTP in practice, since the point
is to serve remote machines. Typically, if both QAP and either
HTTP or WebSockets are used, it is recommended to use QAP on a
local unix socket for better access control.

o	Rserve now supports SSL/TLS connections on QAP, HTTP and WS
protocols. The TLS key/CA entries are common for all
protocols. The relevant new configuration directives are:

  tls.key <private key PEM file>
  tls.cert <server certificate PEM file> <CA PEM file issuing the above certificate>

SSL/TLS can be used in several ways: with separate port for
TLS connections or by switching protocol form a regular QAP
connection using CMD_switch with "TLS" as argument. The latter
can be enabled using

  switch.qap.tls enable

Enabled switching is advertized by Rserve with the presence
of a "TLS" entry in the ID string. Keys and other TLS entries
must be initialized in order for TLS to be enabled.

Dedicated TLS servers can be enabled by specifying the port
for the corresponding protocol:

  qap.tls.port <port>        - for Rserve/QAP
  http.tls.port <port>       - for HTTPS
  websockets.tls.port <port> - for WebSockets

(there are synonyms "https.port" for "http.tls.port" and
 "tls.port" for "qap.tls.port", however, the *.tls.port
 versions are preferred for clarity)

The use of TLS protocols is encouraged where sensitive data
is transmitted or when requiring secure authentication. For
QAP protocol, using TCL/QAP with SHA1 passwords (also new, see
below) is the currently recommended way where authorization is
required. The only drawback is increased CPU utilization
during transfers casued by the encryption and the fact that
TLS-enabled clients must be used. See also RSA secure
authentication (CMD_keyReq + CMD_secLogin) for a different
method if only the authentication step is to be encrypted.

When enabling TLS tls.key and tls.cert are mandatory,
is optional to establish CA chain of trust (whether this is
needed depends on the client and the certificate). To generate
a key and self-signed certificate, you can use something like

  openssl genrsa -out server.key 2048
  openssl req -new -key server.key -out server.csr
  openssl x509 -req -days 365 -in server.csr \
              -signkey server.key -out server.crt

NOTE: TLS services are started **in addition** to any other
servers, i.e., if you want to enable TLS/QAP only, you have to
set tls.qap.port but also add "qap disable" to disable the
plain Rserve access.

o	QAP servers (classic Rserve QAP, QAP/TLS and WebSocket/QAP)
support object-capability (OC) mode in which all Rserve
commands are disabled except for CMD_OCcall. All messages
including the initial handshake are always QAP and the initial
message defines capabilities (here opaque references to
closures) that can be called. This mode can be enabled using

  qap.oc enable            ## for Rserve QAP and QAP/TLS
  websockets.qap.oc enable ## for WebSockets/QAP

In this mode the configuration *must* define a function
oc.init (typically using eval or source configuration
directives) which has to supply OC references that can be used
in calls. If the evaluation of oc.init() fails, the connection
is closed immediately. The use of invalid OC references or any
other commands other than CMD_OCcall results in immediate
connection termination. This allows creation of hardened,
secure services that can disallow arbitrary code execution.

NOTE: this mode is inherenty incompatible with all classic
Rserve clients. The first four bytes of the initial packet are
"RsOC" instead of "Rsrv"

o	Rserve can now be started from within an existing R session
using run.Rserve() command. This allows the user to prepare a
session "by hand", run Rserve from within that session and go
back to the session (by shutting down the server or sending an
interrupt). This allows the use of Rserve even without the
presence of libR.

o	Rserve now supports out-of-band (OOB) messages. Those can be
sent using the self.oobSend() [one-way] and self.oobMessage()
[roundtrip] functions from within code that is evaluated in
Rserve child instances. OOB messages are not used by Rserve
itself but offer asynchronous notification to clients that
support it (one typical use are WS-QAP1 tunnels	to web
browsers that allow status updates as R code is evaluated).

o	Rserve accepts additional command line arguments:
--RS-source <file>   (same as "source <file>" in cfg file)
--RS-enable-remote   (same as "remote enable" in cfg file)
--RS-enable-control  (same as "control enable" in cfg file)

o	The Rserve package no longer includes the R client. It has
been moved to a separate package "RSclient" so that it can be
used on machines separate from the server.

o	There was a bug in QAP storage estimation affecting pairlists,
possibly resulting in buffer overflows. This should be fixed
and an error message will be printed when such overflows are
detected in the future (which hopefully won't happen).

o	Bugfix: command line parsing would skip over some arguments

o	Passwords file can contain MD5 or SHA1 hash of a password
instead of the plaintext password for non-crypt
authentication. In that case the hash must be lowercase	hex
representation with preceding $ sign, so for example user
"foo" with password "bar" would have an entry
foo $62cdb7020ff920e5aa642c3d4066950dd1f01f4d
You can use
  echo -n 'password' | openssl sha1
to obtain the SHA1 hash of a password (openssl md5 for MD5
hash - MD5 is probably more common but less secure than
SHA1). This feature makes sure that passwords are not stored
in plain text and thus are safe from local attacks.

o	Rserve now has the ability to change uid/gid according to the
user that has been authenticated. The following settings
concern this feature (unix-only):

   auto.uid {enable|disable} [disable]
   auto.gid {enable}disable} [disable]
   default.uid <uid> [none]
   default.gid <gid> [none]

The auto.uid/gid directives enable setuid/setgid based on
user's uid/gid. In case no uid/gid is specified with the
username, the default.uid/gid settings will be used. If there
is no uid/gid in the username and no defaults are specified,
the user's authentication will fail. User's uid/gid can be
specified in the passwords file by appending /uid,gid to the
username. If gid is not specified, uid will be used for both
uid and gid. So for example user "foo" (from the above MD5
example) with uid=501 would have an entry on the passwords

   foo/501 $37b51d194a7513e45b56f6524f2d51f2

For this to work, Rserve must be started as root. However,
with auto.uid enabled it is safe to do so since Rserve will
prevent any R access until authenticated. You should, however,
use a client capable of secure RSA authentication or use secure
connection such as QAP/TLS as to not send password in
cleartext over the wire.

o	Rserve can now be run in a mode where each connection has a
different uid and/or gid such that separate client instances
are isolated. This allows more restricted setup in cases where
instances may not be trusted and need to be sandboxed. The
following configuration directives are associated with this

   random.uid {enable|disable} [disable]
   random.gui {enable|disable} [disable]
   random.uid.range {<from>..<to>} [32768..65540]

If random.uid is enabled and random.gid disable then only the
uid of the process is changed. If both are enabled then the
gid is set to match the value of the uid. random.gid cannot be
enabled without random.uid.

To support sandboxing, the permissions on the working
directory can be specified using

   workdir.mode <mode>

o	If any kind of client-process uid switching is enabled in the
configuration, the permissions on the working directory will
match the uid of the process. Also the working directories are
now named by the process ID to facilitate cleanup.

o	Rserve now supports secure authentication even outside of
SSL/TLS. There are two new commands that can be used by the

CMD_keyReq   - requests an authentication key from the server
               that will be used to perform a secure
               login. The kind of the requested key is
               specified as a parameter. Currently, only
               "rsa-authkey" is supported which returns server
               authentication key (authkey) and a RSA public
               key which must be used to encode the authkey
               and the authentication information (see below).
	       The RSA key can be compared on the client side
               to ensure the authenticity of the server.

CMD_secLogin - secure login. It consists of an encrypted data
               stream that will authenticate the user. In the
               case of the "rsa-authkey" method, the stream
               consists of the authkey and the login +
               password, all of which must be encrypted using
               server's RSA key.

The RSA key on the server (Rserve) side is specified using

   rsa.key <RSA private key file>

configuration file directive. The file is expected to be in
PEM format. You can generate such file, e.g., with:

   openssl genrsa -out server.key 4096

where 4096 is the key size in bits. A public key can be
extracted from the private key using

   openssl rsa -pubout -in server.key -out server_pub.key

The clients can pre-share the public key by other means to
compare it to the key received from the server as to verify
its authenticity. This will prevent them from sending the
authentication information to rogue servers.

NOTE: if the rsa.key directive is missing, Rserve will
generate a key on the fly when asked for RSA authentication -
although this allows encrypted transmission and thus is safe
from sniffing, it is not safe from man-in-the-middle attacks
where a rogue server intercepts the request and sends its own
public key. Therefore the use of the rsa.key directive is
highly recommended.

The RSA authentication enables the client to a) check the
authenticity of the server (by comparing the RSA public key)
and b) send authentication information encrypted. This method
is highly recommended in cases where a full TLS/SSL encryption
of the entire connection would be too expensive (i.e. in cases
where the data is large and the security of the transported
data is not crucial).

o	Rserve has a preliminary IPv6 support. Rserve must be
	installed with --enable-ipv6 configure flag to enable it in
the Rserve build. In order to start all servers on IPv6 add

   ipv6 enable

to the configuration file. The option is global, i.e. once
enabled it applies to all servers that support it. Note that
not all features work with IPv6 yet - detaching sessions
(they will use IPv4 for re-attach) and remote client filtering
only work with IPv4 at this point.

o	Rserve now binds only to the loopback interface in
"remote disable" mode. This is safer and prevents remote DoS
attacks. Previously, Rserve would bind on all interfaces and
check the peer IP address. If desired, you can replicate the
old behavior by adding

   remote enable

to the configuration (if you don't know the difference then
you don't need this -- if you actually need this, then you
probably want to add more "allow" entries for the machine's
other interfaces as well).

o	If a function .Rserve.done() is defined in the global
environment, it will be run after a clean connection
shutdown. This allows custom code to be run when a client
connection is closed.

o	If a function .Rserve.served() is defined in the global
environment of the server, it will be run after a client
connection has been served. For forked servers this is just
after the fork(), for co-operative servers this is after the
client conenction has been closed. It is guaranteed that no
other client is served before the call so it can be used to
manage resources that are unsafe to share with forked
processes (e.g. sockets etc.).

o	The server and client process can be tagged with extra
information in argv[0] so it is possible to distinguish the
server and children. This behavior can be enabled using

    tag.argv enable

Note, however, that this not always possible and it will have
impact on programs that use argv[0] such as killall.

o	Added configuration option pid.file and command-line option
--RS-pidfile which instructs Rserve to write its process id
(pid) into that file at startup.

o	Added configuration directives http.user, https.user and
websockets.user which take a username and perform
setuid/setgid/initgroups immediately after forking.
This minimizes the amount of code that is run with
elevated privileges in cases where user switching is desired.

o	Added configuration directive

   daemon disable

which can be used to prevent Rserve from daemonizing. It has
effect only in builds of Rserve that support daemonization.
Note that -DNODAEMON build flag disables daemonization
entirely and can be used in any Rserve version.

o	All commands based on eval now also accept DT_SEXP in addition
to DT_STRING. In such case the parse step is skipped and the
expression is evaluated directly. The intended use of this
functionality is to evaluate language constructs and thus
allow calls with both reference and inlined arguments.

o	QAP decoding is slightly more efficient and avoids protection
cascades. QAP_decode() has now only one argument and it	is
guaranteed to not increase the protection stack when returning
(which implies that it is the responsibility of the caller to
protect the result if needed).

o	Both QAP encoding and decoding now use native copy operations
on little-endian machines which can increase the speed
considerably when the compiler cannot do this optimization
on its own (most commoly used compilers don't).

o	Assigning logical NAs now uses the proper NA_LOGICAL value
that is also recognized by R. (PR#276)

o	Forked child processes will now close all server sockets so
that any server can be restarted without closing existing

o	Signal handling has been streamlined: the server process
captures HUP, TERM and INT which will lead to clean
shutdown. Child processes restore signal handlers back to R so
that regular R signal handling rules apply. Note that
interrupt during eval will result in RESP_ERR with code 127
even if try() is used.

--- In order to support new ideas a major re-organization of Rserve --- --- has been started - almost 10 years after the first release. --- --- It is time to look ahead again with a new major version. The --- --- protocol will remain compatible so 1.x series can be used to --- --- replace the previous 0.x series ---

0.6-8 2012-02-20 o added RSserverEval() and RSserverSource() control commands in the R client as well as ctrl parameter to RSshutdown().

o	added new facility that allows R scripts running in Rserve to
issue control commands if allowed. This feature must be
enabled in the Rserve configuration file using

r-control enable

This will make self.ctrlEval() and self.ctrlSource() functions
available to code that is running within the Rserve
instance. It is also possible to use this feature without
explicitly loading the Rserve package via
.Call("Rserve_ctrlEval", paste(text, collapse='\n'))
.Call("Rserve_ctrlSource", as.character(file))
although this may change in the future.

0.6-7 2012-01-17 o fix processing of login information IMPORTANT: this fixes a serious security hole in the remote login mechanism! If you rely on authentication, please make sure you update your Rserve immediately! (Thanks to Daniel Faber for reporting)

o	add a namespace to make R 2.14+ happy

o	work around broken readBin() in R 2.14.0 that errors
on unsigned integers (affects R client only)

0.6-6 2011-12-10 o fix a bug that can cause heap corruption due to incorrect addressing in padding of symbols. Unless extremely long symbol names are used it is unlikely to have a real effect in practice, but in theory it could be used to zero targetted parts of the heap. Thanks to Ralph Heinkel for reporting.

o	fix Rserve() call on Windows with quote=FALSE and more than
one argument.

o	clarify that sisocks.h is under LGPL 2.1 as well as the other
headers used by clients.

o	add support for plain S4 objects (S4SEXP) in assignments
(Note: derived S4 objects - those using other native SEXP type
as a base - cannot be supported properly, becasue there is no
way to distinguish them from S3 objects!)

o	Unsupported types in CMD_assign will no longer crash R.
The resulting object is always NULL and an error is printed on
the R side.

0.6-5 2011-06-21 o use new install.libs.R custom installation script in R 2.13.1 to install binaries

o	install clients by default on Windows as well

o	multi-arch binaries are no longer installed with the arch suffix
in the package root. The canonical place is libs$(R_ARCH) instead.
For now Rserve.exe/Rserve_d.exe are still installed in the root
but they will be also removed in the future as they are not
multi-arch safe.

0.6-4 2011-05-19 o make all buffers capable of using 64-bit sizes. This means that clients can use more that 4Gb of data on 64-bit platforms when communicating with Rserve, provided the buffer limits are either disabled or configured to be high enough. Note that this does not change the limitations in R with respect to vector lengths so you still can only use up to 2^31-1 elements.

o	bug fix: contrary to the documentation scalar logicals were sent
in the old XT_BOOL format instead of XT_ARRAY_BOOL

o	work around several issues introduced in R 2.13.0 for Windows

Rserve() now also allows arguments to be passed to system() for
more fine-grained control of the environment, mostly to work
around bugs and incompatible changes to system() on Windows
in R 2.13.0 (commonly used options are invisible=FALSE to get
back to a more reasonable pre-2.13.0 behavior and wait=TRUE if
using R 2.13.0 that has broken wait=FALSE support).

o	In Rserve() startup wrapper, args are now quoted automatically
if quote=TRUE is set. For backward compatilility args are not
quoted by default if they consist of just one string.

0.6-3 2011-01-17 o bug fix: the child process could get stuck in the server loop after some abnormal return from the child connection code Thanks to David Richardson for reporting.

o	set R_ARCH automatically on Windows if a multi-arch R is
detected (such as CRAN binaries since R 2.12.0)

o	add R_ARCH support in Rserve() on Windows to locate the
proper binary

o	bug fix: C++ client did not handle new-style lists (introduced
in Rserve 0.5) properly. Thanks to Carl Martin Grewe for

0.6-2 2010-09-02 o add support for NAs in character vectors by using a special "\xff" string. Any string beginning with '\xff' is prepended by additional '\xff' to remove ambiuguity and clients should remove leading '\xff' accordingly. (Note that UTF-8 encoded strings never contain '\xff' so in most uses it never occurs).

The Java client has been updated accordingly and represents
NA strings with null.

o	add a new config file option "interactive" that allows to run
Rserve in interactive or non-interactive mode across platforms.
Previously Windows ran in non-interactive mode and unix in
interactive mode. Non-interactive mode is useful if you want
to prevent R from soliciting user input, but it requires error
option to be set if you don't want to quit R on all errors
(i.e., something like options(error=function() NULL) will do)

Note: on unix the interactivity flag can only be set *after* R
initialization (due to limitation in R) so you still may have
to pass flags like --no-save in order to appease R.

o	more Windows fixes - Rserve uses R's own initialization in
recent R versions. This also fixes issues with Win64 and more
recent toolchains.
Note that both Widnows and unix now behave consistently with
respect to interactive mode - the default is now interactive
for both platforms but can be changed in the config file.

0.6-1 2010-05-24 o add a safety margin to the send buffer to avoid crashes when size estimates are off (e.g., due to re-coding)

o	added a very primitive PHP client

o	Win64 fixes by Brian Ripley

o	added new configuration options:
su {now|server|client} - switches user either immediately
as the config file is loaded ("now", default and always the
behavior of Rserve before 0.6-1), when the server is ready
("server") or when a client is spawned ("client"). The
latter is useful to restrict clients from sending signals
to the server process.

uid, gid config options are interpreted accordingly to
the su value.

cachepwd - {no|yes|indefinitely} - allows Rserve to cache
the password file. "no" = read it at each authorization
(default and behavior before 0.6-1), "yes" = read it when
a client is spawned before su, "indefinitely" = read it
just after the config file (most efficient but changes
are only active after re-start). "yes" has only effect
in unix and can be used to restrict permissions on the
password file such that client code has no access to it
(do does "indefinitely" but can be used anywhere).

0.6-0 2009-10-27 o added support for control commands CMD_ctrlEval, CMD_ctrlSource and CMD_ctrlShutdown. Those commands provide control over the server process. The side-efect of eval and source are then available to all future connections.

Control commands are only available if they are enabled, e.g.,
with the config file entry "control enable". In addition if
authorization is required or the passwords file is set only
designated users will have control access (see next point).

Note that enabling control commands will make Rserve use at
least one file descriptor per active child process, so you may
want to adjust the maximum number of file descriptor in your
system if you expect hundreds of concurrent clients.

o	The passwords file format has been enhanced to give
finer-granularity control over the user authorization.

Only users with "@" prefix can issue control commands. The
prefix is not part of the user name for authentication

In addition, if the password file contains an entry
starting with "*" it will be interpreted as blank
authorization, i.e. any username/pwd will authenticate. This
may be useful in conjunction with control prefix, e.g., the
following file would give blank authorization to all users but
only the user "joe" will be able to use control commands:

@joe foobar

o	Windows build cleanup (thanks to Brian Ripley)

o	fixed decoding of XT_RAW (it advanced too far), this affected
the use of XT_RAW as non-last element only (thanks to Saptarshi
Guha for reporting)

o	don't advertize ARuc if not supported (this bug only affected
systems without crypt support with plaintext enabled and
required authorization)

o	add assign support for logical vectors

0.5-3 2009-01-25 o fix SET_VECTOR_ELT/SET_STRING_ELT mismatches

o	set object flag when decoding objects that have
a "class" attribute (fixes issues with S3 objects that
were passed from the client to the server).

o	set S4 bit for pure S4 objects (S4SEXP). No other S4
objects are supported because there is no way to tell
that an assembled object is really an S4 object

o	added string encoding support (where R supports it)
The string encoding can be set in the configuration file
(directive "encoding"), on the command line with --RS-encoding
or within a session by the client command CMD_setEncoding.

This means that strings are converted to the given encoding
before being sent to the client and also all strings from the
client are assumed to come from the given encoding.
(Previously the strings were always passed as-is with no
conversion). The currently supported encodings are "native"
(same as the server session locale), "utf8" and	"latin1". The
server default is currently "native" for compatibility with
previous versions (but may change to "utf8" in the future, so
explicit use of encoding in the config file is advised).

If a server is used mainly by Java clients, it is advisable to
set the server encoding to "utf8" since that it the only
encoding supported by Java clients.

For efficieny it is still advisable to run Rserve in the same
locale as the majority of clients to minimize the necessary
conversions. With diverse clients UTF-8 is the most versatile
encoding for the server to run in while it can still serve
latin1 clients as well.

0.5-2 2008-10-17 o fix a bug in CMD_readFile and CMD_setBufferSize that resulted in invalid buffer sizes (one of the ways to trigger the bug was to attempt to read a small number of bytes with readFile). Thanks to H. Rehauer for reporting.

o	ignore attributes if they are not in a LISTSXP - there seem
to be other uses of the ATTRIB entry in conjunction with
character hashes in recent R versions. (BR #76)

o	adapt C++ client to changes in 0.5 (at least to the point
where the demo1 code works)

o	add support for XT_VECTOR_EXP in assignments

o	improve protection for vectors

o	report "remote" setting in --RS-settings

o	updates in the REngine Java client, added documentation

0.5-1 2008-07-22 o fix build issue with R 2.7.x on Windows

o	mergefat now works properly and uses cp if there is no lipo
(this fixes multi-arch issues on Mac OS X and makes sure that
Rserve/Rserve.dbg are installed even on non-Mac systems)

0.5-0 2008-07-21 o added CMD_serEval and CMD_serAssign which are highly efficient when talking to R clients as they don't need any intermediate buffer. The corresponding R client functions RSeval and RSassign have been re-written to use this new API.

o	deprecate scalar types in the protocol

o	add more efficient storage for dotted-pair lists
and symbol names

o	add support for complex numbers

o	new Java client: REngine
it is more flexible than JRclient and it can be used with
other Java/R engines such as JRI. Also it has a much more
clean API and better exeption handling.
- allow NaNs to be passed in raw form to R, i.e. double
  NAs can be created using
  (nice methods for this should follow)

o	C++ client was moved to src/client/cxx

JRclient: o change the representation of lists to generic named vectors (class RList)

o	change the ways attributes are accessed

0.4-7 2007-01-14 o relax DLL versions checking on Windows

o	added more sophisticated implementation of RSassign
in R client to support larger data. Nevertheless, due to
limitations in R, objects must be serializable to
less than 8MB to be assignable via RSassign.

o	added more robust error handling in the R client

o	fixed compilation on systems with custom include dir
(such as Debian)

o	JRclient is now part of the Rserve package.
See clients.txt for details.
It is not compiled by default (but installed when
--with-client is specified), because we cannot assume the
existence of a Java compiler.

0.4-6 2006-11-30 o fixed bug in RSeval when handling large objects

o	minor fix in RSassign

o	add an endianness hack for Windows in case config.h is not
included properly

0.4-5 2006-11-29 o added --with-server option (by default enabled). When disabled, the server itself is not built. When enabled, R must provide R shared library, i.e. it must have been compiled with --enable-R-shlib.

o	added --with-client option (by default disabled). When
enabled, the C/C++ client is built and installed in the
package. It will be copied in the "client" directory of the
package and contains all files necessary for building a
client application.

This option has no effect on the R client which is always
built and installed.

o	Windows version of Rserve now builds and installs both debug
(Rserve_d.exe) and regular (Rserve.exe) version of Rserve. In
addition, the Rserve function can now be used to launch Rserve
even on Windows.

o	endianness detection now prefers information from the compiler
macros thus allowing cross-compilation. Use -D_BIG_ENDIAN_ or
-D_LITTLE_ENDIAN_ to override it if necessary.

o	allows universal build on Mac OS X

o	adapt to R_ParseVector interface change in R-devel

0.4-4 2006-11-15 o first release on CRAN

o	added support for RAW type (both in and out)

o	added rudimentary client support (thanks to David Reiss for
his contributions) and documentation

Previous major releases:

0.4 2005-08-31 * added support for sessions

0.3 2003-10-07 * new format for boolean arrays last version: 0.3-18 (2005-08-28)

0.2 2003-08-21 * support for large objects

0.1 2002-07-06 * first release

Reference manual

It appears you don't have a PDF plugin for this browser. You can click here to download the reference manual.


1.7-3.1 by Simon Urbanek, 2 years ago

Browse source code at

Authors: Simon Urbanek <[email protected]>

Documentation:   PDF Manual  

Task views: Numerical Mathematics, Web Technologies and Services, Model Deployment with R

GPL-2 | file LICENSE license

Suggests RSclient

System requirements: libR, GNU make

Imported by RestRserve, acumos.

Suggested by FastRWeb.

See at CRAN