Client error handling¶
Requirements governing what the client does when a request’s transmission fails, its reception fails, or its response window expires, as ISO 14229-2:2021 9.7 Table 9 requires.
What the client can do about an error¶
ISO 14229-2:2021 9.7 Table 9 names three error events for the client and states a handling
for each. The session layer already signals all three. A failed transmission reaches the
application as the S_Data.conf that UDSS_LLR_0039 produces, its S_Result
carrying the error value UDSS_LLR_0056 reserves for a lower layer’s report. A failed
reception reaches it as the S_Data.ind that UDSS_LLR_0036 produces for every
T_Data.ind, successful or not; clause 8.10 requires the error result to be issued to the
service user on the receiving side as on the sending one, which is why that requirement
admits no exception. A response timeout reaches it as the response-timing indication of
UDSS_LLR_0148, which clause 9.1.2 requires flagged to the application layer.
The repeat itself is the application’s. The session layer retains no payload
(UDSS_LLR_0013) and performs no I/O (UDSS_LLR_0001), so it cannot retransmit a
request; it signals and the application acts, the division UDSS_LLR_0100,
UDSS_LLR_0117 and UDSS_LLR_0148 make for the timers. What the set enforces is the
three constraints Table 9 places around the repeat. The spacing Table 9 requires before the
repeat of a failed transmission, and only there, is Client request spacing’s;
this document cites it and does not restate it. The cap of two repeats is
UDSS_LLR_0177’s. Finishing the responses still arriving on a functional channel is
UDSS_LLR_0178’s. Each is a rejection under UDSS_LLR_0015, the only means a layer
with no I/O has of postponing or forbidding a transmission, and UDSS_LLR_0179 makes the
report say which constraint blocked the request.
The repeat and its marker¶
The session layer cannot recognise a repeat from the data, UDSS_LLR_0073 forbidding it,
so the application declares one with the repeat marker UDSS_LLR_0065 defines, as it
declares its keep-alive. Table 9 counts service request transmissions from the request whose
handling first failed, three in the worst case.
The keep-alive is outside the count. In physical keep-alive a TesterPresent can go out
between a failure and its repeat, UDSS_LLR_0161 restarting tS3_Client on the failed
confirmation, and were it an unmarked request it would reset the count and leave the repeats
unbounded. UDSS_LLR_0065 therefore makes keep-alive and repeat exclusive.
Table 9 does not exempt the keep-alive, so its own repeats are bounded by the application,
an obligation recorded below.
What the count does not check is that a repeat follows a failure. Enforcing that would need
a per-channel record of whether one is owed, which no requirement keeps; a request the
application wrongly marks repeat is therefore counted against a cap it will not reach,
which costs the application repeats it was entitled to and costs the set nothing.
Responses still arriving¶
Table 9’s functional cells oblige the client to completely receive any response message in
progress at a timeout or a failure before it repeats, and the cell for a timeout with an
unknown number of responding servers before further requests of any kind. Whether a response
is in progress is what an open start-of-message records, and only the session layer sees
start-of-message indications, clause 7.3 keeping them from the application.
UDSS_LLR_0141 accordingly retains an entry whose start-of-message is open past the end
of the request and releases every other fact; UDSS_LLR_0178 rejects a request on the
channel while any such entry remains. Each retained entry closes on the T_Data.ind that
completes its message, which reaches the application as an S_Data.ind under
UDSS_LLR_0036, so that indication is the application’s cue that the wait has ended.
Unlike UDSS_LLR_0171’s rejection, this one carries no time to retry: the wait ends on an
event, not after an interval.
Only the unknown-count cell attaches the wait to further requests of any kind; the
known-count cell and the reception cell attach it to the repeat alone, at the instant of the
timeout or the error. UDSS_LLR_0178 applies the wide reading to all three and declares
the widening: the set keeps no record of which event ended the exchange, and a fact per
channel recording it would buy only the right to send a different request into responses
still arriving.
Giving a server up¶
Table 9 stops at the third transmission and says nothing of what the client concludes,
while the state this set keeps persists on its own: a request in progress whose completion
never comes, a repeat count at two, a physical channel’s session fact keeping tS3_Client
restarting for a server that stopped answering, a functional keep-alive running after the
last server was returned physically. The channel reset of UDSS_LLR_0180 is the caller’s
exit from what a channel keeps, and the keep-alive release of UDSS_LLR_0184 is its exit
from the keep-alive state, which in functional keep-alive is not per channel. They are
separate acts because they answer different situations: unwedging a channel whose responses
never completed must not cost the application its sessions with every other server, which
in functional keep-alive a single release does.
Both are acts of the caller, as the completion report of UDSS_LLR_0074 is, and neither
a primitive nor a protocol parameter. A client in functional keep-alive necessarily
has the functional channel its TesterPresent goes out on, UDSS_LLR_0157 requiring that
message’s confirmation to arrive on one.
Assumptions of use¶
Obligations Table 9 places on the application, recorded here and assessed in the qualification repository rather than written as requirements:
the application marks each repeat of a request other than the keep-alive TesterPresent
repeatand marks no other request so, and marks a repeated keep-alive TesterPresentkeep-aliveagain, so thatUDSS_LLR_0157andUDSS_LLR_0161restarttS3_Clienton it as ISO 14229-2:2021 9.5 Table 6 and 9.7 Table 9 require of the repeated TesterPresent;it repeats only after a failed
S_Data.conf, a failedS_Data.indor a response-timing indication, and not after a timeout on a functional channel whose expected response count wasunknown, which Table 9 makes the ordinary end of the exchange;it remembers the expected response count it declared on a request,
UDSS_LLR_0148’s indication not carrying it and Table 9’s two functional timeout cells demanding opposite actions;it bounds its keep-alive repeats itself, the count excluding them;
it resets a channel when it gives a server up, and expects the completion of a message the reset cut short to be delivered as the first indication of a single-frame message;
a client in functional keep-alive has a functional channel allocated, and a deployment with several functional channels does not release functional keep-alive while any server still relies on it.
What this document does not cover¶
The tS3_Client restarts Table 9’s physical cells require where the failed request was a
physically addressed, sequentially transmitted TesterPresent. UDSS_LLR_0161 transcribes
all three.
The wait Table 9’s request transmission row places before the repeat of a failed
transmission. UDSS_LLR_0169 to UDSS_LLR_0171, as the first section says.
Table 10, the server’s error handling. UDSS_LLR_0092, UDSS_LLR_0093 and
UDSS_LLR_0094.
What the application concludes after the third failure. The standard says nothing, and the set gives the application the reset and the release and no rule for when to use them.
The transport layer’s own retries beneath a single T_Data.req, which are below this
layer and invisible to it: one T_Data.conf reports one transmission, however the
transport achieved or failed it.
What the application does with a message indicated on a reset channel.
The repeat count¶
Each logical communication channel, physical or functional, shall have a repeat
count in the channel’s storage under Rationale: ISO 14229-2:2021 9.7 Table 9’s last row bounds the client’s error handling to
two repeats, three transmissions in the worst case, and a layer that sees every request
go past can check it. ISO 14229-2:2021 9.6 Table 7 allots the client timers only and no
storage for the count, so this requirement is derived: the set follows the behaviour the
table states and records that the resource table omits it. It joins the class of
constraints the standard makes checkable while allocating nothing for them, which
Open questions inventories and which The storage is the caller’s for the reason |
When the channel is opened the count shall be zero. Rationale: the initial state is stated for the reason |
While a channel exists, its repeat count shall be changed only as Rationale: the rule |
On an
Rationale: ISO 14229-2:2021 9.7 Table 9 states only the cap, a maximum of two repeats and
three transmissions in the worst case. It names no count, no event that starts one and no
marker, so the mechanism by which a layer that cannot read the message tracks the repeats
is the set’s own, as the count of The keep-alive is outside the count, and that is a declared reading: Table 9 does not
exempt it. In physical keep-alive a TesterPresent can be transmitted between a failure
and its repeat, |
On an Table 9’s last row has the client’s error handling performed at most two times, so that
the worst case is three transmissions of the request. The |
Responses still arriving¶
Low-Level Requirement: A functional channel finishes receiving before it carries another request UDSS_LLR_0178
|
On an Table 9’s two functional timeout cells and its functional reception cell each oblige the
client to completely receive the response messages in progress before it continues.
Declared widening. Only the cell for a timeout with an unknown number of responding
servers attaches the wait to further requests of any kind; the known-count cell and the
reception cell attach it to the repeat alone, at the point in time of the timeout or of
the error. This requirement applies the wider reading to all three, because the set keeps
no record of which of the three events ended the exchange, and a fact per channel to
record it would buy only the right to send a different request into responses still
arriving. The requirement is accordingly conditioned on neither the |
Low-Level Requirement: A rejection for a spent count or a response still arriving states which UDSS_LLR_0179
|
Where the client rejects an Rationale: the two causes here call for opposite actions from the application, waiting
for the next completion under |
Giving a server up¶
The session layer shall accept a channel reset from the caller identifying one logical communication channel. On a channel reset the client shall:
The reset shall produce no output to the application and none to the transport layer. Rationale: ISO 14229-2:2021 9.7 Table 9 ends at the third transmission and the standard
says nothing of what the client concludes, while the state this set keeps per channel
persists on its own: a request in progress whose completion never comes, an entry
The fifth effect exists because nothing else restarts the physical keep-alive once the
application has reset the channel. The effects above are the state a reset clears or restarts, and the list is closed so
that a document adding state per channel must amend this requirement to say whether the
reset clears it. What it deliberately leaves: the protocol parameters of The reset is neither a primitive nor a parameter but an act of the caller, as the
completion report of |
On a channel reset under Rationale: the association’s only exits are the ones |
A Rationale: the confirmation is delivered because the transport’s report of the outcome
is real and Starting no response window matters because, without it, the confirmation of a request
transmitted before the reset and confirmed after it would start a response window under
Everything else the confirmation does is left to happen, because the message went out: the server may still be consuming it, so 10.3’s spacing wait is owed where it applies; and it may enter or leave a session on it, so the keep-alive requirements follow the message rather than the reset. |
A reset identifying a channel the client does not have shall be rejected as
Rationale: naming a channel that does not exist is a caller error, not an input, for the
reason |
The session layer shall accept a keep-alive release from the caller identifying one logical communication channel. On a keep-alive release:
In every other case the release shall change nothing. The release shall produce no
output to the application and none to the transport layer. A release identifying a
channel the client does not have shall be rejected as Rationale: the standard names no end for the client’s keep-alive other than the return
to the default session that It is a separate act from the channel reset of The functional condition reads a release on a functional channel as the application
abandoning functional keep-alive as a whole. ISO 14229-2:2021 9.6 Table 8’s single
timer cannot be scoped to the servers behind one functional address, so nothing narrower
can be stated, exactly as |