[prev in list] [next in list] [prev in thread] [next in thread]
List: coda-announce
Subject: RPC2-2.4 released
From: Jan Harkes <jaharkes () cs ! cmu ! edu>
Date: 2006-10-18 19:53:02
Message-ID: 20061018195302.GA2745 () delft ! aura ! cs ! cmu ! edu
[Download RAW message or body]
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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic