What's new in RPC2

- Adam Goode found several endianess issues in the encryption code on a
  big-endian (PPC) system. One of which actually turned out to be an
  incorrect initialization of the AES-CCM counter block on little-endian
  systems. This release corrects the initialization, and will force
  clients with an older version of librpc2 to use AES-CBC encryption.

- SFTP transfers would abort when an already acknowledged packet was
  received a second time. This resulted in a stalled data transfer and
  an unnecessary client disconnection.

- We didn't account for server processing delay in the retransmission
  time calculation. This was not a problem on a fast network because the
  minimum delay was clamped to 300ms. It did however occur frequently on
  slow and/or high latency connections, mostly in cases where such early
  retransmissions are more costly.

- Incoming connection requests were queued until worker threads are
  available to authenticate the users and complete the handshake.
  However as clients stop waiting after a minute or so, the server would
  end up trying to respond to clients that have already aborted their
  connection attempt. Instead of queueing, we now send back a busy to
  tell the client to try again later. This avoids long delays while the
  server is trying to catch up with the backlog of aborted connection
  requests.

- Optionally embed a Lua 5.1 interpreter, the prebuilt Debian and FC5
  packages are build with this option enabled (configure --with-lua).

  When the Lua interpreter is linked in, RPC2 will check the file
  /etc/rpc2.lua once every 5 seconds to see if a script is available
  and/or updated. This location can be overridden by setting the
  RPC2_LUA_SCRIPT environment variable. Several places in the
  send/receive paths can be overridden by providing a suitable Lua
  function. Several example scripts are installed in /usr/share/rpc2.
  The script is automatically disabled when it cannot be parsed or when
  a runtime error is encountered.

  The currently scriptable functionality is focussed on simulating poor
  network connectivity and overriding/replacing the builtin roundtrip
  (retransmission) time calculation and bandwidth estimator.

  Basic Lua libraries (math/string) are made available to the script.
  The 'print(...)' function writes it's arguments separated by tabs to
  the error logfile. There is also a 'time()' object which represents a
  struct timeval and supports simple operations such as addition,
  subtraction, multiplication and division.

  The following functions can be provided by scripts,

delay, color = fail_delay_tx(addr, size, color)
delay, color = fail_delay_rx(addr, size, color)

    Introduce failures and or packet delays in the transmit and receive
    paths. The arguments provide some information about the packet, such
    as which address/port we're sending it to, the size in bytes of the
    packet and the 'color'.

    The returned delay defines how long we should wait before sending
    (or receiving) the packet. If delay is 'nil' the packet is dropped.
    The 'color' of the packet can be changed by returning a numeric
    value (0-255), it is left unmodified when 'nil' is returned.

rtt_init(host)

    This function will be called whenever a host with no previous
    estimates is discovered. This can be used to initialize the per-host
    estimates so that the other rtt_ functions do not have to check if
    the table was correctly initialized. The table will have one
    initialized field 'host.name' which contains the formatted
    ipaddress/port of the peer.

rtt_update(host, elapsed, bytes_tx, bytes_rx)

    Called whenever a packet has been received. host is a table that can
    be used to store estimated values for the current host. elapsed is
    the measured roundtrip time, and bytes_tx/bytes_rx contain the
    number of bytes of the outgoing and incoming packets.

    This function is expected to update the current roundtrip time and
    bandwidth estimates in the host table.

rto = rtt_retryinterval(host, retry, bytes_tx, bytes_rx)

    Called whenever we want to send a packet, should return the
    estimated time it takes to expect the response + some (exponential)
    backoff when we are sending a retransmission. The bytes_rx value
    is in many cases a rough estimate because we don't really know how
    large the response will be. The retry argument indicates how many
    times we've already tried to send this request packet. The requested
    maximum number of retries and maximum timeout values are available
    in the global variables RPC2_RETRIES and RPC2_TIMEOUT.

    If the response is 0, rpc2 will this fall back on it's own estimate.
    Return 'nil' to stop retransmissions the packet (at the moment it
    actually falls back on the rpc2 internal estimate, and will only
    abort once retry >= RPC2_RETRIES).

rto = rtt_getrto(host, bytes_tx, bytes_rx)

    Called when rtt_retryinterval is not defined, should return the
    estimated time it takes to expect the response.
    If the response is 'nil' or 0, RPC2 will use it's own estimate.

bandwidth_tx, bandwidth_rx = rtt_getbandwidth(host)

    Not used by rpc2 itself, but called when the application asks for
    the current bandwidth estimates. The only application that currently
    cares is venus, which will use this value to decide whether it
    should switch to weakly or strongly connected operation and how much
    it should try to reintegrate at a time.