ltp
Licklider Transmission Protocol (LTP) communications library
- Provided by: ion-doc (Version: 3.2.1+dfsg-1.1)
- Source: ion
- Report a bug
Licklider Transmission Protocol (LTP) communications library
#include "ltp.h"
typedef enum
{
LtpNoNotice = 0,
LtpExportSessionStart,
LtpXmitComplete,
LtpExportSessionCanceled,
LtpExportSessionComplete,
LtpRecvGreenSegment,
LtpRecvRedPart,
LtpImportSessionCanceled
} LtpNoticeType;
[see description for available functions]
The ltp library provides functions enabling application software to use LTP to send and receive information reliably over a long-latency link. It conforms to the LTP specification as documented by the Delay-Tolerant Networking Research Group of the Internet Research Task Force.
The LTP notion of engine ID corresponds closely to the Internet notion of a host, and in ION engine IDs are normally indistinguishable from node numbers including the node numbers in Bundle Protocol endpoint IDs conforming to the "ipn" scheme.
The LTP notion of client ID corresponds closely to the Internet notion of "protocol number" as used in the Internet Protocol. It enables data from multiple applications -- clients -- to be multiplexed over a single reliable link. However, for ION operations we normally use LTP exclusively for the transmission of Bundle Protocol data, identified by client ID = 1.
clientServiceData must be a "zero-copy object" reference as returned by zco_create(). Note that LTP will privately make and destroy its own reference to the client service data object; the application is free to destroy its reference at any time.
redLength indicates the number of leading bytes of data in clientServiceData that are to be sent reliably, i.e., with selective retransmission in response to explicit or implicit negative acknowledgment as necessary. All remaining bytes of data in clientServiceData will be sent as "green" data, i.e., unreliably. If redLength is zero, the entire client service data unit will be sent unreliably. If the entire client service data unit is to be sent reliably, redLength may be simply be set to LTP_ALL_RED (i.e., -1).
On success, the function populates *sessionId with the source engine ID and the "session number" assigned to transmission of this client service data unit and returns zero. The session number may be used to link future LTP processing events, such as transmission cancellation, to the affected client service data. ltp_send() returns -1 on any error.
Returns 0 on success, -1 on any error (e.g., the indicated client service is already being held open by some other application task).
The value returned in *data is always a zero-copy object; use the zco_* functions defined in "zco.h" to retrieve the content of that object.
When the notice is an LtpRecvGreenSegment, the ZCO returned in *data contains the content of a single LTP green segment. Reassembly of the green part of some block from these segments is the responsibility of the application.
When the notice is an LtpRecvRedPart, the ZCO returned in *data contains the red part of a possibly aggregated block. The ZCO's content may therefore comprise multiple service data objects. Extraction of individual service data objects from the aggregated block is the responsibility of the application. A simple way to do this is to prepend the length of the service data object to the object itself (using zco_prepend_header) before calling ltp_send, so that the receiving application can alternate extraction of object lengths and objects from the delivered block's red part.
The cancellation of an export session may result in delivery of multiple LtpExportSessionCanceled notices, one for each service data unit in the export session's (potentially) aggregated block. The ZCO returned in *data for each such notice is a service data unit ZCO that had previously been passed to ltp_send().
ltp_get_notice() always blocks indefinitely until an LTP processing event is delivered.
Returns zero on success, -1 on any error.