Reliable, efficient transmission control for networks that suck.
Airhook is a reliable data delivery protocol, like TCP. Unlike TCP, Airhook gracefully handles intermittent, unreliable, or delayed networks. Other features include session recovery, queue control, and delivery status notification.
Inspired by life with CDPD, Airhook works well in environments that leave TCP gasping for air.
Warning: Airhook is a defunct project, no longer maintained, never really implemented properly in the first place. The idea doesn't even really make sense any more -- modern wireless networks are much faster and include link level retransmission and congestion control. This page is kept here for historical reference purposes only.
An implementation of the Airhook protocol is available as an ANSI C library suitable for use with any network transport and operating system. Included with the library are Unix utilities to proxy TCP via Airhook over UDP, so you can use protocols like HTTP and SSH with Airhook.
Implementation source code is available (tarballs, CVS) under the terms of the GNU General Public License.
Library documentation and a protocol reference are available online.
Airhook is best described by comparison with TCP.
TCP uses retransmission timeouts with exponential backoff to detect packet loss.
Airhook continuously transmits small status packets to keep both endpoints aware of connection status; lost data packets are transmitted immediately when (and only when) their absence is reported. Status packets are transmitted with an adjustable frequency set to 1 Hz by default, and are sent infrequently (or not at all) when the connection is quiescent. Data packets also include status information, so recovery happens very rapidly when a packet is lost during active transmission.
Airhook recovers immediately from packet loss, "dropout" periods, and extended disconnection.
TCP transmits a continuous stream of bytes. Message-oriented applications must introduce their own framing.
Airhook transmits delimited small messages (micropackets). The Airhook protocol implementation may transmit several micropackets in a single physical packet, but framing is preserved. Stream-oriented applications must divide their stream into micropackets for transmission and concatenate micropackets on receipt.
An application using the standard TCP "sockets" interface must send data blindly into the pipe. Once data is written to the buffer, the application has no idea whether or when it was sent or confirmed; if the data becomes stale (no longer relevant) after it is buffered but before it is sent, the application can do nothing. Applications must implement their own acknowledgement protocols, and real-time applications must accept the inefficient transmission of stale data.
Airhook offers status notifications for each micropacket sent. The application is notified when the packet is sent, if it is retransmitted, and when receipt confirmation is received. The application can cancel transmission of any micropacket whose data has become stale.
TCP combines guaranteed single delivery, order preservation, flow control and congestion control in each session.
Airhook provides guaranteed single delivery and congestion control in each session. Applications may establish their own order preservation and flow control protocols as needed (examples are provided). Applications are free to combine multiple "streams" within a single Airhook session.
By obviating the need for multiple connections between the same hosts, Airhook can efficiently share congestion control knowledge and session status metadata.
TCP is usually implemented in the operating system kernel and layered directly on IP.
For portability, the Airhook implementation distributed here is a user-mode library, generally used with UDP.
TCP for Wide Area Wireless Networks (WTCP) includes an in-depth study of transmission control on CDPD. The authors modify TCP to use probe packets and selective ACK instead of retransmission timers. The implementation is unfortunately not available.
The Stream Control Transmission Protocol is another alternative to TCP. Unfortunately, it uses the same retransmission and congestion control means as TCP, but it does provide applications more flexibility and greater control over the transport.
The Chaotic Nature of TCP Congestion Control is a fascinating paper on the difficulty of the congestion control problem, even under good conditions.
CM: The Congestion Manager is an interesting project (and Internet standards track protocol) to manage congestion control for all flows to or from a host, regardless of individual TCP streams or UDP protocols. I'd love to use CM with Airhook, but it's not really in a usable state.
Reliable Forwarder Daemon and ROCKS each take a different, TCP-only approach to maintaining reliability in the face of long-term intermittency by reconnecting every few seconds if no data has been received.