ARDP Frequently Asked Questions

How does ARDP compare to existing transport protocols?

ARDP is designed for a request/response style of interaction.
ARDP is lighter-weight than TCP regarding connection setup and tear-down costs.
ARDP is built on UDP, the User Datagram Protocol on top of IP. Unlike UDP, ARDP supports multiple independent connections.
An ARDP server can have thousands of queued requests. This is used by heavily loaded services, such as the archie servers.
ARDP V1 carries and processes security information in the transport layer.

What is ARDP's acknowledgment policy and mechanism?

ARDP uses both implicit and explicit acknowledgments. Clients and servers use the received through field (octets 7 and 9 in V0, and 8 and 9 in V1) to piggyback acknowledgments in data packets. The received through value indicates the sequence number through which all packets have been received by the sender of the packet.

Servers and clients also send explicit acknowledgments to each other. For instance, the server sends an ACK back to the client when the server receives a multi-packet request from the client. This is done through the ardp_acknowledge() call (ardp_accept() calls ardp_acknowledge()).

Note that the server only ACKs the first packet of a multi-packet request if it receives a duplicate of it. If the client times out (default timeout period is set to 4 seconds), the client will retransmit the request's first packet. If the server receives this retransmitted first packet, the server will then detect that it is a duplicate packet of an outstanding request, and will only then ACK it.

The server can explicitly request an ACK from the client by setting bit 7 of octet 11 (option flags) in V0 and bit 0 of octet 1 in V1. This is the case when the server sends the last packet of a window, or if the server sends the last packet of a reply and the client hasn't acknowledged the reduction of a previously requested wait (see ardp_respond()).

What is ARDP's timeout and retransmission policy?

A client checking for replies retransmits unacknowledged packets. In ardp_pr_actv() it checks whether the peer's received through is smaller than the total number of packets already sent. In that case, it schedules the retransmission for after it detects the receipt of an unsequenced control packet.

What are ARDP's flow control mechanisms?

The client and the server maintain both receive and transmit windows. The default client and server transmit window is 16 packets.

The client can advertise its receive window to the server. The server will then use this value as its transmit window. The client can also reset its receive window size to the server, who will go back using its default transmit window size.

What queues does the ISI ARDP implementation manage?

ARDP clients and servers maintain several queues. The server maintains the following request queues:

ardp_partialQ : holds incomplete requests, missing one or more packets.
ardp_pendingQ : holds pending requests.
ardp_runQ : holds requests currently in progress.
ardp_doneQ : holds processed requests.

On the client side, the following queues are maintained:

ardp_activeQ : holds active requests, that have been or are being transmitted, but where the server's complete reply has not been received. When they are completed, they are moved to the ardp_completeQ.
ardp_completeQ : Holds completed requests. A request may be completed because a complete reply was successfully received or because of failure, such as a retransmission timeout.
Completed requests are removed from ardp_completeQ as soon the application calls ardp_retrieve() to retrieve the results. Client applications call ardp_retrieve() explicitly or via other ARDP API functions that also retrieve results.

The queues are also discussed in the ARDP API

What functions can an ARDP server application use to check for requests?

The server checks for new requests and/or replies to its own requests using ardp_get_nxt(), ardp_get_nxt_nonblocking(), and ardp_get_nxt_all().

ardp_get_nxt() returns a request to be processed by the server, and blocks of there are no requests. It executes a select loop calling ardp_get_nxt_nonblocking().
ardp_get_nxt_nonblocking() returns the next request to be processed by the server; if there is none, it returns NOREQ. It calls ardp_accept().
ardp_get_nxt_all() (available in the client and server) returns either the next reply or the next request to be processed by the server. It blocks if there aren't any replies or requests ready to process.It calls ardp_retrieve_nxt_nonblocking() to check for replies, and ardp_get_nxt_nonblocking() to check for requests.
ardp_get_nxt_all_timeout() (client and server) We re-wrote ardp_get_nxt_all() to make it more general. We added a timeout and priority options and called it ardp_get_nxt_all_timeout(). The ttwait parameter gives the timeout period in microseconds, and priority can be either ardp_port , in which case ardp_get_next_all_timeout() checks for replies before requests, or ardp_srvport or ardp_prvport , which gives priority to requests over replies.

These functions are further described in the ARDP API.