Client session timer¶
Requirements governing the client’s tS3_Client timer, which keeps the servers a client
has moved out of the default session in that session.
Two ways to keep a session alive¶
ISO 14229-2:2021 9.5 Table 6 gives the client two ways of keeping servers in a non-default
session, and the paragraph before it requires the client to distinguish them. In the first,
a functionally addressed TesterPresent is transmitted each time tS3_Client expires,
whatever else the client is doing, and 9.6 Table 8 allots one timer for the whole client
however many sessions it has activated. In the second, confined to physical communication,
every request the client sends on a channel stops the timer and every completed exchange
restarts it, a physically addressed TesterPresent being transmitted only where the timer
expires with nothing else sent; Table 8 allots one timer per point-to-point communication.
Throughout this document the first is functional keep-alive and the second physical
keep-alive. The mode is fixed when the client instance is created (UDSS_LLR_0149).
Beside each timer the client holds one fact: in functional keep-alive the keeping-alive
fact, that the client is keeping some session alive; in physical keep-alive a session
fact per physical channel, that the channel’s server is in a non-default session. The fact
is needed because a timer that has expired and awaits the confirmation of the TesterPresent
is stopped while the session is still being kept alive; without it, a request marked as the
keep-alive and sent in the default session would start the timer.
When the timer expires the client delivers a keep-alive indication to the application,
an output the caller retrieves as UDSS_LLR_0011 provides, on the same footing as the
response-timing indication of UDSS_LLR_0148. In functional keep-alive it carries no
addressing; in physical keep-alive it carries the channel’s identity. The session layer
cannot compose the TesterPresent itself, UDSS_LLR_0073 forbidding it; the application
does, as it does the repeat that Client error handling leaves to it.
This document uses physical channel, functional channel and request in progress
as the client response timing document’s preamble defines them, with UDSS_LLR_0121
stating when a channel exists and UDSS_LLR_0128 enumerating when a request ceases to be
in progress, first indication and completion as UDSS_LLR_0045 defines them, and
solicited as UDSS_LLR_0065 defines it.
What ordinary traffic does to the functional timer¶
In functional keep-alive, nothing. The physical mode’s answer is the opposite and lives in
UDSS_LLR_0160 and UDSS_LLR_0161: every request stops the channel’s timer and every
completed exchange restarts it. Table 6’s functional column names two events only, the
confirmation of the session change and the confirmation of the functionally addressed
TesterPresent, so a functionally addressed request that is not the keep-alive changes
nothing, and the client needs the keep-alive classification of UDSS_LLR_0065 to tell
the two apart.
Assumptions of use¶
Two obligations on the caller are not requirements, because the standard states them as what the client does rather than as constraints the session layer can check. They are recorded as assumptions of use in the qualification repository, as the client response timing document records its one-request-per-channel model.
The application answers a keep-alive indication by transmitting a TesterPresent whose
classification states keep-alive: in functional keep-alive a functionally addressed one
with expected response count none, in physical keep-alive a physically addressed one on
the indicated channel, with or without a response required. The standard names no functional
address for the keep-alive, so the address is the application’s choice, and
UDSS_LLR_0157 accepts the confirmation on any functional channel.
A client in physical keep-alive changes sessions with physically addressed requests, one per
channel. Table 6’s physical column is headed physical communication only, and
UDSS_LLR_0159 is scoped to a physical channel, so a functionally addressed
DiagnosticSessionControl sent in that mode engages nothing: no TesterPresent follows, and
the servers it moved leave the session when tS3_Server expires. The client cannot do
otherwise, not knowing which physical channels the responders sit on.
What this document does not cover¶
ISO 14229-2:2021 10.3 Figure 19 key k postpones the keep-alive while tP3_Client_Func is
running, and the same applies to a physically addressed TesterPresent while
tP3_Client_Phys is. That is Client request spacing’s, which postpones by
rejecting the S_Data.req and reporting the time remaining; nothing in this document
changes, the timer being stopped between the indication and the confirmation either way.
ISO 14229-2:2021 9.7 Table 9 states what the client does after a failed transmission, a
failed reception or a response timeout: repeat the request, at most twice. Those obligations
belong to Client error handling. Table 9 also restarts tS3_Client on each of
those events where the request was a physically addressed, sequentially transmitted
TesterPresent. Two of those restarts coincide with rows of Table 6 and the third does not;
UDSS_LLR_0161 transcribes all three.
What the client concludes about a channel’s session once Table 9’s repeats are exhausted is
also Client error handling’s. Nothing in this document clears a channel’s session
fact where the server has simply stopped answering: UDSS_LLR_0163 clears it on a
confirmed return to the default session, and the keep-alive release of UDSS_LLR_0184
clears it on the application’s say-so, but a server that has gone silent leaves the fact
standing here. The repeat count that bounds the repeats is UDSS_LLR_0173’s.
Table 5 requires the tS3_Client reload value to be smaller than tS3_Server. That is
a value the caller chooses under UDSS_LLR_0040 and supplies under UDSS_LLR_0042, a
performance obligation of the same class the response timing documents exclude.
Which session’s timing parameters apply is settled by the application, as the client response timing document states.
The timer’s state¶
The client shall operate in one of two keep-alive modes: functional keep-alive, in which
a functionally addressed TesterPresent is transmitted each time Clause 9.5 requires a periodically transmitted, functionally addressed TesterPresent to be distinguished from a sequentially transmitted, physically addressed one, which is only transmitted in the absence of any other request. Table 6 states the timer’s start conditions in one column per handling, and Table 8 allots the timers each needs. The mode is set for the client instance rather than per channel. Table 6’s functional
column is headed physical and functional communication, so the functional keep-alive
already serves the client’s physical channels; a client mixing the two would need two
timers on one channel for nothing. The mode is fixed at creation because the standard
treats the handling as a property of the deployment, Table 8 allotting timers “when
using” one TesterPresent or the other, and gives a change no meaning; it is not one of
the protocol parameters |
In functional keep-alive the client shall maintain a single Table 8 allots a single timer where the functional TesterPresent is used, with no further timers per activated session. The functional timer and fact are fixed in size — the storage has exactly one value —
and are nonetheless supplied by the caller, by value, with the instance:
|
In physical keep-alive the client shall maintain a single Table 8 allots a single timer for each point-to-point communication. The per-channel timers and facts live in the channel’s storage for the reason
|
In functional keep-alive the client shall have one Supplying a The reload parameter follows the timer. Table 5 states that the |
On creation of the instance, no Rationale: the initial state follows Table 6, whose functional column starts the timer
only for a non-default session: in the default session nothing is kept alive. It is
stated because none of the requirements |
After the client instance is created, and while a physical channel exists, the state of
the client’s Rationale: a closed list of the requirements that may change the timers and facts is what
makes a “changes nothing” claim elsewhere in the set checkable, and what lets
|
Functional keep-alive¶
In functional keep-alive, while the Table 6’s functional column starts the timer on the The second sentence is Table 8: a single timer suffices and no further timer is needed per activated session. A restart would stretch the interval for the servers already being kept alive, and the running timer already serves the newly activated session. The guard is on the timer rather than on the fact so that a keep-alive left stopped by an
unanswered indication, as |
In functional keep-alive, while the keeping-alive fact holds and the Table 5 defines The session layer signals and the application acts: The timer expires when the elapsed time reaches the parameter, as The standard makes the keep-alive the application’s obligation, as it makes Table 9’s
repeat. Postponing the TesterPresent while |
In functional keep-alive, while the keeping-alive fact holds, on Table 6’s functional column restarts the timer on the Table 6 describes that confirmation as of the TesterPresent “transmitted each time the
The channel must be functional for Table 6’s wording and for the reason A |
Low-Level Requirement: Functional keep-alive disengages on return to the default session UDSS_LLR_0158
|
In functional keep-alive, while the keeping-alive fact holds, on Rationale: the standard states no end condition for the client’s timer. Table 5 defines
The channel must be functional, though After a functionally addressed session change for which responses are required, some
server may have refused the change. Reading the responses is the application’s job under
|
Physical keep-alive¶
Every requirement in this section is scoped to one physical channel: its timer, its channel session fact, and the requests and indications on it.
In physical keep-alive, while a physical channel’s session fact does not hold, on either
of the following on that channel the client shall set the fact and start the channel’s
Table 6’s physical column has two initial-start rows: the confirmation of the
DiagnosticSessionControl request where no response is required, and the reception of its
response where one is. Figure 13 shows the initial start only at key b, the conflicting
key recorded below; its keys g and j show the same two events as subsequent starts under
Table 6 names the request and the response without qualification; both bullets act only
on a message carrying a session selection. That narrows the text. Under Both bullets narrow the text again, to a selection that is not the default session.
Table 6 states that qualifier — “This is only true if the session type is a non-default
session” — in its functional column alone, not in the physical column these rows come
from. It is read across because Figure 13 key b also starts The guard on the fact is what separates this requirement from |
In physical keep-alive, while a physical channel’s session fact holds, on producing a
Figure 13 key e states the stop on the client’s transmission of any request message, naming the physically addressed TesterPresent as included. Table 6 has no stop row for the client’s timer; the key is the standard’s only statement of it, and 9.5’s description of the physically addressed TesterPresent as transmitted only in the absence of any other request depends on it. The |
In physical keep-alive, while a physical channel’s session fact holds, on any of the
following on that channel, except where
The first four are Table 6’s subsequent-start rows in the physical column. Figure 13
key g shows the first and keys j, n and r the third; the second and fourth rest on
Table 6 alone. The fifth is Table 9’s response timeout row, which restarts Table 9 also restricts its transmission-error and reception-error restarts to the TesterPresent case, where Table 6’s rows for the same events are unrestricted. The second and fourth bullets follow Table 6. Table 6’s third row applies “in case a response is required”, which is read as naming a
response to a request the client sent: the Table 6’s third row says any response message, and the third bullet takes a final
response only. That narrows the text, and deliberately: a response-pending negative
response does not restart the timer. Clause 9.5 describes the physically addressed
TesterPresent as transmitted only in the absence of any other request, and the enhanced
response window that a response-pending message opens, The exception for |
In physical keep-alive, while a physical channel’s session fact holds and its
Table 5 defines The indication carries the channel and not a source address: a channel is identified by
the client’s own outbound addressing, as Expiry is at reaching the parameter for the reason |
Low-Level Requirement: Physical keep-alive disengages on return to the default session UDSS_LLR_0163
|
In physical keep-alive, while a physical channel’s session fact holds, on either of the
following on that channel the client shall clear the fact and stop the channel’s
Rationale: as for |