Share via

3.2.1.5.3 Sliding Window Algorithm

  • Article

[C706] sections 9.5.5, 10.1, and 10.2 allow conforming implementations broad latitude in implementing the sliding window algorithm for REQUEST and RESPONSE fragments. The Windows behavior is compatible with clients and servers that use other windowing implementations conforming to [C706]. The following section specifies the implementation of the sliding window algorithm.

Packet Transmission Behavior. A client call sends fragments in the following three cases:

  1. When the call is first instantiated, the Send Window (Call) and its properties are initialized and the client sends a burst of fragments.

  2. When a FACK or NOCALL-with-body is received from the server. The Send Window (Call) is updated and the client sends a burst of fragments.

  3. When the Packet Retransmission Timer is triggered (for more information, see section 3.2.2.2.1). The client halves the Send Window (Call) Burst_length property and sends a burst of fragments.

When the client or server must send a burst of fragments, it attempts to send a number of fragments equal to the Burst_length property of the Send Window (Call) ADM element. The sender first attempts to extend the window by sending never-before-sent fragments. All fragments except the last are sent with the PF_NOFACK flag set. The last fragment sent clears the PF_NOFACK flag unless (a) it is the final fragment of the call data, or (b) it is overlapping a previous async call of the activity (that is, the PF2_UNRELATED flag is set). Otherwise, it too is sent with the PF_NOFACK flag. If fewer than Burst_length are sent because the call data is too short or the Outbound Fragment Window property of the Send Window (Call) ADM element limit is reached, the Burst_length is halved. If no fragments at all are sent, the lowest unacknowledged fragment is resent with the PF_NOFACK flag cleared.

Response to Packets:

When a packet with PF_NOFACK cleared is received, the recipient sends a FACK with a version-zero body. The max_tdsu field is set to the maximum PDU length for the transport (for more information, see section 2.1.2). The max_frag_size field is set to the maximum unfragmented packet length for the transport (for more information, see section 2.1.2). The window_size field is calculated by dividing a version-specific constant by the number of calls currently using the port.<78> For client ports, the number of calls is typically one, but might be higher if multiple asynchronous calls are in progress. If the resulting window size is less than one, it is set to one. If the resulting window size is greater than 32, it is set to 32. The serial_num field is set to the current value of the Send Window (Call) ADM element's Receive serial number property. The selack_num, selack, and header fragnum fields are set based on the fragments received, as specified in [C706] section 12. When an RPC receives a fragment with a length signifying a Maximum PDU Length larger than the current value in the Send Window, the implied length is calculated by rounding the total packet length down to the nearest multiple of 8. The activity's Maximum PDU Length is then set to the lower of this rounded value and the local transport limit. Therefore, the new value takes effect with the next call of the activity.