Files
rippled/src/ripple/protocol
Nik Bougalis 433feade5d Automatically determine the node size:
The `[node_size]` configuration parameter is used to tune various
parameters based on the hardware that the code is running on. The
parameter can take five distinct values: `tiny`, `small`, `medium`,
`large` and `huge`.

The default value in the code is `tiny` but the default configuration
file sets the value to `medium`. This commit attempts to detect the
amount of RAM on the system and adjusts the node size default value
based on the amount of RAM and the number of hardware execution
threads on the system.

The decision matrix currently used is:

|         |   1  | 2 or 3 |   ≥ 4  |
|:-------:|:----:|:------:|:------:|
|  > ~8GB | tiny |   tiny |   tiny |
| > ~12GB | tiny |  small |  small |
| > ~16GB | tiny |  small | medium |
| > ~24GB | tiny |  small |  large |
| > ~32GB | tiny |  small |   huge |

Some systems exclude memory reserved by the the hardware, the kernel
or the underlying hypervisor so the automatic detection code may end
up determining the node_size to be one less than "appropriate" given
the above table.

The detection algorithm is simplistic and does not take into account
other relevant factors. Therefore, for production-quality servers it
is recommended that server operators examine the system holistically
and determine what the appropriate size is instead of relying on the
automatic detection code.

To aid server operators, the node size will now be reported in the
`server_info` API as `node_size` when the command is invoked in
'admin' mode.
2021-06-03 10:58:24 -07:00
..
2020-06-30 09:15:37 -07:00
2020-12-04 12:45:12 -08:00
2021-01-20 11:30:03 -08:00
2021-06-01 15:37:15 -07:00
2020-09-01 08:58:57 -07:00
2021-06-03 10:58:24 -07:00
2020-05-05 16:05:22 -07:00
2017-06-08 21:37:22 -07:00
2020-09-01 08:58:57 -07:00
2021-03-11 14:35:30 -08:00
2021-01-09 13:50:07 -08:00
2015-07-29 11:56:05 -04:00
2020-12-04 12:45:12 -08:00
2020-12-04 12:45:12 -08:00
2020-12-04 12:45:12 -08:00
2020-12-04 12:45:12 -08:00
2021-06-01 15:37:15 -07:00
2020-05-05 16:05:22 -07:00

protocol

Classes and functions for handling data and values associated with the Ripple protocol.

Serialized Objects

In ripple objects transmitted over the network must be serialized into a canonical format. The prefix "ST" refers to classes that deal with the serialized format of ripple objects.

The term "Tx" or "tx" is an abbreviation for "Transaction", a commonly occurring object type.

Optional Fields

Our serialized fields have some "type magic" to make optional fields easier to read:

  • The operation x[sfFoo] means "return the value of 'Foo' if it exists, or the default value if it doesn't."
  • The operation x[~sfFoo] means "return the value of 'Foo' if it exists, or nothing if it doesn't." This usage of the tilde/bitwise NOT operator is not standard outside of the rippled codebase.
    • As a consequence of this, x[~sfFoo] = y[~sfFoo] assigns the value of Foo from y to x, including omitting Foo from x if it doesn't exist in y.

Typically, for things that are guaranteed to exist, you use x[sfFoo] and avoid having to deal with a container that may or may not hold a value. For things not guaranteed to exist, you use x[~sfFoo] because you want such a container. It avoids having to look something up twice, once just to see if it exists and a second time to get/set its value. (Real example)

The source of this "type magic" is in SField.h.