| Bit No. | Meaning | Additional Fields |
|---|---|---|
| 0 | Additional Address Information Follows | variable length (see below) |
| 1 | Priority Follows | 2 octets (see below) |
| 2 | A Protocol ID for a higher-level protocol follows | 2 octets (see below) |
| 3 | Window size | |
| 4-5 | Unused | Unused |
| 6 | This packet is a sequenced control packet only; it should not be returned to the application by the ARDP library | None |
| 7 (high order) | Please Acknowledge this Packet | None |
| Value | Meaning | Additional Fields | |
|---|---|---|---|
| 0 | No Option Specified | None | |
| 1 | Client to server: Cancel Request. Server to client: Connection refused. | None | |
| 2 | Reset peer's received-through count. | Specified in octets 7-8 | |
| 3 | Packets received beyond received-through | The rest of the header after additional data for octet 11 flags is an arbitrary number of octets. These are bit-vectors specifying which packets beyond the received-through specified in this packet have been received by the sender of this packet. For example, if the received-through is set to 43, then we know that packet 44 has not been received. The low order bit of the first octet of the additional field will be turned on if packet 45 has been received, and off if it has not. The high-order bit will be turned on if packet 52 has been received, and off if it has not. Similarly, the low-order bit of the second octet of additional information will be turned on if packet 53 has been received, and so on. The recipient of this information may choose to ignore it and use a simpler resend strategy. Similarly, this information is never required to be sent. | |
| 4 | Redirect (used by servers):The client should send any unacknowledged packets already sent and all subsequent packets in this message to a new addresss. This is designed to be used as a load-shedding device. In one common case, this will be the entire response a server gives to a request, and the client will resend the entire request to a new server; in the other common case, this will be used in conjunction with option 6 or 7. | 6 octets. The first 4 octets are the IP address of the new server, in network byte order. The next 2 octets are the UDP port to which the request should be sent, also in network byte order. | |
| 5 | Redirect and notify (used by servers). Like option 4, but the client's network layer should also notify its caller that all subsequent requests intended for the old server should be sent to the new server instead. | Same as option 4. | |
| 6 | Forwarded: This request was received from a client, and the sender is a server forwarding it to the recipient for processing. The recipient should pretend that it received this message from the sender indicated by the additional fields, not from the real sender of this message. (If implemented, this request should be accepted only from one of a group of trusted hosts.) This option is intended to be used by a central server which distributes requests to several subsidiary servers which do the actual work of processing the request, but which use the central server as a contact point. Presumably, it is cheaper for the central server to forward the request to the subsidiary servers over a local area network rather than for the client (who may be quite far away) to retransmit it. The central server has done the job of notifying the original client (through option 4 or 5) that further requests and retransmissions should go to the new server. | 6 octets: The IP address and port of the original sender of this message, as in number 4. | |
| 7 | Forwarded; Please notify: Like option 6, but the receiving server should notify the client of the switch (through option 4 or 5) | 6 octets: The IP address and port of the original sender of this message, as in number 4. | |
| 8 | ARDP version obsolete: We get this message when the peer knows we are using an ARDP version that it does not understand. This message is only sent in response to an outstanding ARDP request. This is the version-specific BAD-VERSION message. The ARDP peer can only send this back if it knows enough about the recipient's ARDP version so that it can recognize the version information in the BAD-VERSION message recipient's original message. If the peer doesn't recognize the original message's version, then it sends back a version-independent BAD-VERSION message. (This is a message whose first octet is zero.) | none | |
| 9-252 | Undefined | Undefined | |
| 253 | Request Queue Status | 1 octet. If bit 0 (low order) is set, the position in the queue is requested. If bit 1 is set, the estimated time until this request will be completed is requested. The recipient may ignore this option. | |
| 254 | Response to 253. | 1 octet of flags, followed by 1 or 2 additional fields. If bit 0 (low order) of the flags is set, the position in the queue is returned as a 2 octet network byte order representation of an unsigned quantity. A value of \hexnum{FFFF} (all bits turned on) means a queue position of \hexnum{FFFF} or further. (We do not expect this value to ever be used, but it is included for the sake of completeness.) If bit 1 of the flags is set, the estimated time until this request will be completed is returned as a 4-octet network byte order unsigned value, representing a time in seconds. A value of \hexnum{FFFFFFFF} (all bits turned on) means a time of \hexnum{FFFFFFFF} seconds or more. (We do not expect this to ever be used). | |
| 255 | Reserved for future expansion. | Undefined |
First, additional data fields specific to the flags in octet 11 should be specified.
Its length does not include the two octets that specify type and length. The following octets contain the address information itself, and its format is dependent upon the type of address information.