This website is no longer actively supported. Please see the Ripple Developer Center for up-to-date documentation and other resources.

Rippled

From Ripple Wiki
Jump to: navigation, search

Rippled

Rippled is the server component of the Ripple network. The source code is available at: https://github.com/ripple/rippled

If you are planning a significant Ripple based business, please contact partners@ripple.com to see if Ripple Labs can be of assistance.

Overview

Launch rippled as a server:

rippled options

Launch rippled as a command line tool to issue JSON-RPC commands:

rippled rpc_command args ...

rippled is the reference implementation of a Ripple p2p server.

rippled is able to do the following:

  • Act as command line tools to issue RPC commands to a server.
  • Perform validation of ledgers to keep the network secure and operating.
  • Talk to peers to help the network communicate.
  • Provide a trusted websocket and JSON-RPC API to back end applications.
  • Serve a websocket API to thin clients on public Internet.
  • Act as a proof of work server.

rippled is written in C++.

See also:

Mailing List

There is a mailing for rippled announcements and discussion. All rippled operators and API users should subscribe:

Technical specifications

Websocket compatibility: websocketpp

Server Requirements

Rippled server deployments should meet the following hardware requirements:

  • 4 GB RAM
  • Ledger database grows by 5 GB daily. Minimum of 50 GB is recommended.

Amazon EC2 instances:

  • m3.medium with SSD is fine for keeping up with the network and processing transactions.
  • m3.large with SSD is recommended for handling clients and doing pathfinding.

At least 500 IOPS is recommended for rippled's database partition.

Command Line Options

--

Disable parsing of command line options for all further arguments.

For example to pass -1 to a command:

# rippled -- command -1

--conf=path

Specify the location of the configuration file: rippled.cfg

The config directory is the directory containing the rippled.cfg file. The data directory is a the subdirectory named dbs.

Windows and no --conf

The config directory is the same directory as the rippled program. The data directory is a the subdirectory named dbs.

Other OSes and no --conf

This file will be looked for in these places in the following order:

  1. ./rippled.cfg
  2. $XDG_CONFIG_HOME/ripple/rippled.cfg

If rippled.cfg, is found in the current working directory, the directory will be used as the config directory. Otherwise, the data directory is a the subdirectory named dbs.

Otherwise, the data directory data is: $XDG_DATA_HOME/ripple/

Notes:

  • $XDG_CONFIG_HOME defaults to $HOME/.config
  • $XDG_DATA_HOME defaults to $HOME/.local/share

--help, -h

Display help for command line options and RPC commands.

--load

Load the locally stored ledger.

--net

Get the ledger from the network.

rippled will:

  1. Connect to the network.
  2. Determine the current ledger.
  3. Begin filling in its ledger database in reverse from the current ledger.
    • Before retrieving a ledger from the network, it will check its local database.
    • The [ledger_history] configuration in rippled.cfg can be used to configure the amount of history maintained.

--quiet, -q

Reduce diagnostic messages.

--standalone, -a

Run in a testing mode.

Testing mode:

--start

Start the ledger from scratch.

--unittest, -u

Execute the built in unit tests and exit. This is useful to make sure rippled is sane after porting, installation, or upgrading.

This is the format of the command:

rippled --unittest[=parameter]

Where =parameter is optional. When called without a parameter, all available unit tests which are not specially marked to be run manually are run and reported.

parameter has the following formats:

  • <name>
  • <package>.
  • .<testname>
  • <package>.<testname>

If <name> is specified and names an existing package, this will run all tests in the package not marked as manual. If <name> does not specify a package, this will run the first test whose name matches, including manual tests.

If <package>. is used, this will run all tests in that package not marked as manual. If <package> does not exist, no tests are run.

With .<testname>, it will run the first test whose name matches, including manual tests.

The form <package>.<testname> is used to unambiguously run a specific test from the given package, including manual tests.

Note that none of the name comparisons are case-sensitive.

Special Tests

There are some useful built in tests which are run manually.

These two tests can be used to test continuous integration servers:

beast.Pass This test always passes

beast.Fail This test always fails

print This test just prints out the list of available tests.

At the time of this writing, this is what --unittest=print produces:

sh-3.1$ ./rippled --unittest=print

print.print : List available unit tests

        beast.AbstractFifo

[manual] beast.FatalError

        beast.SemanticVersion

[manual] print.print [manual] beast.Pass [manual] beast.Fail

        beast.UnitTestUtilities
        beast.File
        beast.RandomAccessFile
        beast.JSON
        beast.Random
        beast.MemoryStream
        beast.LexicalCast
        beast.TextDiff

[manual] beast.TrackedMutex

        beast.Workers

[manual] beast.ChildProcess

        beast.GZIP

[manual] beast.HttpClient

        beast.TestPeer
        beast.boost

[manual] beast.BinaryEncoding

        beast.UnsignedInteger

[manual] beast.KeyvaDB [manual] beast.ParsedURL

        beast.IPEndpoint
        beast.String
        beast.Atomic

[manual] beast.ServiceQueueTiming

        beast.ServiceQueue

[manual] beast.Debug

        ripple.JsonCpp

[manual] ripple.PeerFinder [manual] ripple.TestOverlay [manual] ripple.Validators [manual] ripple.FatalErrorReporter

        ripple.RangeSet
        ripple.StringUtilities
        ripple.NodeStoreBackend
        ripple.NodeStoreBasics
        ripple.NodeStore

[manual] ripple.NodeStoreTiming

        ripple.LoadFeeTrack
        ripple.CKey

[FORCED] ripple.BuildInfo

        ripple.RippleAddress
        ripple.RippleIdentifier
        ripple.Serializer
        ripple.SerializedObject
        ripple.STAmount
        ripple.MultiSocket

[manual] ripple.ProofOfWork

        ripple.SerializedTransaction
        ripple.SHAMap
        ripple.SHAMapSync
        ripple.Ledger

Summary: 1 suites, 1 cases, 1 tests, 0 failures.

rippled uses the Beast UnitTest framework.

--verbose, -v

Increase log level.

--version

Display the build version of the rippled executable.

Command line agent for sending RPC commands

rippled can be used as a command line agent for sending JSON-RPC calls to a Ripple server.

Most servers will not accept remote RPC commands.

To issue commands against the Ripple network, first set up a local rippled server and enable the RPC interface.

rippled.cfg:

# [rpc_ip]:
#   IP address or domain to bind to allow insecure RPC connections.
#   Defaults to not allow RPC connections.
#
# [rpc_port]:
#   Port to bind to if allowing insecure RPC connections.
[rpc_ip]
127.0.0.1

[rpc_port]
8088

Configure a rippled.cfg to contact the a rippled server:

rippled.cfg:

# [rpc_ip]:
#   IP address or domain to bind to allow insecure RPC connections.
#   Defaults to not allow RPC connections.
#
# [rpc_port]:
#   Port to bind to if allowing insecure RPC connections.
[rpc_ip]
127.0.0.1

[rpc_port]
8088

Then issue RPC commands as described in RPC API. For example:

rippled server_info

Technical FAQ

Can I copy the dbs?

Yes, but with caution.

Different instances of rippled should not derive from the same DBs.

In particular, the DBs contain the identity of the node.

Can I delete the dbs?

If you have a custom UNL list that you have manually created via unl_add, they will be lost. The best way to keep a custom UNL list is to maintain it in validators.txt.

Otherwise, it is harmless to remove the DBs. As of rippled version 0.27.0, rippled can be configured to automatically rotate the ledger and free up database space via online_delete.

https://wiki.ripple.com/Online_deletion

Troubleshooting

What is "SNTPClient:NFO SNTP: Alarm condition"?

This is a problem reported by an SNTP server (time server) that Rippled is using to keep its internal clock synchronized. Rippled will just ignore this server so long as it continues to report an error condition.

If you're using an SNTP pool (which the server uses with the example configuration) it will often include a few bad servers, causing this condition. This is harmless so long as there are still plenty of working time servers in the pool.

If you specifically configured a small number of time servers, this means one of those servers does not think it can provide accurate time. If you cannot fix the server, you should use a different server.