Client request spacing¶
Requirements governing the client’s tP3_Client_Phys and tP3_Client_Func timers,
which bound how soon the client may transmit the next request on a channel.
Why the client waits¶
ISO 14229-2:2021 10.3 states the reason. A server may interpret the requests it receives on
a design-specific polling schedule rather than as they arrive, and that schedule can be
slower than the network. A client that transmits its next request the moment the previous
exchange appears complete can therefore reach a server that is still consuming the previous
request, which then drops the new one; Figure 18 shows the case. Clause 10.3 answers it with
a minimum time between the end of one request and the start of the next, in two parameters.
tP3_Client_Phys applies to a physically addressed request for which no response is
required, because without a response the client cannot observe that the server has finished.
tP3_Client_Func applies to any functionally addressed request, because a server that
does not support the request may never answer it. Where a physically addressed request
required a response, the response itself shows that the server has finished, and 10.3 lets
the next request follow immediately after that response has been completely received.
The spacing timer and its parameter¶
Throughout this document, a channel’s spacing timer is the single timer ISO 14229-2:2021
9.6 Table 7 allots to it for this purpose, and its spacing parameter is the protocol
parameter the timer is loaded with: tP3_Client_Phys on a physical channel,
tP3_Client_Func on a functional one. It is a timer in the sense Timer model
gives, and this document uses that document’s five words for it. Clause 10.3 calls a running
spacing timer active and its expiry timed out; ISO 14229-2:2021 9.2 Table 3 types both
spacing parameters “Timer reload value”, as it types the parameters of tP_Client, and
9.6 Table 7 allots each channel a timer for them, so the standard’s active is this set’s
running and nothing turns on the difference in words. Its expiry stops it and does nothing
else: the whole effect of a spacing timer is a condition on the next transmission.
A T_Data.conf belongs to the channel named by the addressing of the S_Data.req that
UDSS_LLR_0059 associates with it, the route UDSS_LLR_0135 uses, and an
S_Data.req belongs to the channel its own addressing names. On the outbound side,
therefore, no caller identification of the channel is needed. This document uses physical
channel, functional channel and the identity of a channel as UDSS_LLR_0121 and the
client response timing document’s preamble define them, and expected response count and
none as UDSS_LLR_0065 defines them.
Postponement is rejection¶
Clause 10.3 requires a request that arrives while the spacing timer is running to be
postponed until the timer has timed out. This layer postpones by rejecting the
S_Data.req (UDSS_LLR_0171) and reporting how long the timer has left
(UDSS_LLR_0172). It can do nothing else: UDSS_LLR_0013 forbids retaining the
payload, so the request cannot be queued, and UDSS_LLR_0001 forbids acting on its own,
so it cannot be transmitted later. UDSS_LLR_0015 makes the rejection recoverable, a
caller that retries after the reported time obtaining what a well-timed call would have.
Transmitting after that time is the application’s, on the model UDSS_LLR_0156 states for
the keep-alive; it is recorded as an assumption of use in the qualification repository that
the application transmits, after the reported time, the request the standard obliges it to
send, the repeat that 9.7 Table 9 requires or the TesterPresent that answers a keep-alive
indication.
The keep-alive is one such request: rejected while the channel’s spacing timer is running and transmitted after the reported time, which is the postponement 10.3 Figure 19 keys k to m show of the functionally addressed TesterPresent, key p naming the delay.
What this document does not cover¶
The parameter values. ISO 14229-2:2021 9.2 Table 4 sets the floor of both parameters at
tP2_Server_Max plus the network delay, in two pairs differing by ΔtP2_Max and
ΔtP6_Max. Clause 10.3 a) and b) instead state each value as a tP2_Server_Max — the
addressed server’s for tP3_Client_Phys, the worst case over the functionally addressed
servers for tP3_Client_Func — omitting the delay Table 4 adds; Table 4’s minimum
governs. The caller chooses the values under UDSS_LLR_0040, as it chooses every other
timing parameter.
Table 4’s footnote on the maximum. The maximum time the client waits before its next request
is at its discretion, provided that in a non-default session tS3_Server is kept active
in the servers. That is an obligation on the caller of the same class as the tS3_Client
reload staying below tS3_Server, which the client session timer document excludes.
Clause 10.3’s condition that the next request follows a previous one that was completely
handled, and its note defining completely handled. That is the one-request-per-channel
assumption of use the client response timing document records. UDSS_LLR_0171 adds a
rejection condition and grants no permission.
ISO 14229-2:2021 9.7 Table 9’s repeat obligations. Client error handling. This document supplies the wait Table 9’s request transmission row names, by starting the spacing timer on the failed confirmation and rejecting the repeat until the timer has expired.
Clause 10.3’s permission for a physically addressed request that required a response to be
followed immediately after the complete reception of its response. Honoured by
UDSS_LLR_0169 starting nothing for such a request on a successful transmission.
Figure 18, which motivates the parameters, and 10.3’s closing paragraph on the server’s interpretation rate, which is the server documents’ concern.
The spacing timer¶
The client shall maintain a single spacing timer for each logical communication channel,
in the channel’s storage under Table 7 requires a single timer per logical physical communication channel for
The storage is the caller’s for the reason |
Each channel shall have a spacing parameter supplied as a protocol parameter under
Table 3 defines both parameters as a minimum time for the client to wait and types each a
timer reload value, the typing |
A channel’s spacing timer shall run from a start under The timer expires when the elapsed time reaches the value it was loaded with rather than
when it exceeds it. Table 3 states the parameter as a minimum time to wait, which a
request at exactly that time satisfies, and 10.3 postpones only until the timer has timed
out; the bound is on this side’s own conduct. Table 9’s “after the time
|
When a channel is opened its spacing timer shall not be running. Rationale: the initial state is stated for the reason |
While a channel exists, the state of that channel’s spacing timer shall be changed only
as Rationale: nothing beyond those two requirements and the timer’s own expiry changes it.
Clause 10.3 states the timer’s whole effect as a condition on the next transmission, so a
timer that has expired is one that no longer forbids anything, and |
Starting the timer¶
Low-Level Requirement: Physical spacing starts on a confirmed request needing no response UDSS_LLR_0169
|
On a physical channel, on either a Clause 10.3 a) starts The second condition widens 10.3’s “successfully transmitted”. It comes from 9.7 Table
9’s request transmission row, which has the client repeat a request whose transmission
failed after A confirmation arriving while the timer is already running restarts it, 10.3 stating the
start without condition. There is no exception for a confirmation that returns the
channel to the default session: 10.3 a) applies in any diagnostic session, so that
confirmation starts the spacing timer while |
On a functional channel, on any Clause 10.3 b) starts The failed confirmation widens 10.3’s “successfully transmitted”, from Table 9’s request
transmission row as A confirmation arriving while the timer is already running restarts it, 10.3 stating the start without condition. The functional keep-alive’s confirmation starts this timer, Figure 19 key n. |
The next request¶
Low-Level Requirement: A request on a channel whose spacing timer is running is rejected UDSS_LLR_0171
|
On an Clause 10.3 a) and b) allow the next request on a channel only where the spacing timer is
no longer running, and otherwise require the transmission to be postponed until the timer
has timed out; Figure 19 key f has the client wait for Clause 10.3 conditions the postponement on the new request following a previous one
that was completely handled, and that condition is not stated here. After a start under
The rejection is per channel, where 10.3 and Table 3 speak of the next physically- or
functionally-addressed request without naming a channel. That narrows the text, on the
warrant of Table 7, which allots the timers per channel, of 10.3 a), which values the
physical parameter for the addressed server, and of Figure 20 key c, which transmits a
functionally addressed TesterPresent while a physical channel’s The keep-alive TesterPresent, functionally or physically addressed, is rejected like any
other request, and Figure 19 keys k to m show that keep-alive is held back until
|
A rejection under Rationale: 10.3 postpones the request until the timer has timed out but gives the application no way to learn when that is, and Figure 19 key p names the delay that results. |