(Illustration by Gaich Muramatsu)
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.Received on 2006-10-18 15:56:19