diff --git a/specification/application/conventions.tex b/specification/application/conventions.tex index be5710d..d8cd62a 100644 --- a/specification/application/conventions.tex +++ b/specification/application/conventions.tex @@ -12,8 +12,8 @@ \subsection{Node identifier distribution} Valid values of node-ID range from 0 up to a transport-specific upper boundary which is guaranteed to be above 127 for any transport. -The two uppermost node-ID values are reserved for diagnostic and debugging tools; -these node-ID values should not be used in fielded systems. +Node-ID values of 126 and 127 are reserved for diagnostic and debugging tools. +These values should not be used in fielded systems. \subsection{Service latency} diff --git a/specification/introduction/introduction.tex b/specification/introduction/introduction.tex index fbcc9b3..e18e007 100644 --- a/specification/introduction/introduction.tex +++ b/specification/introduction/introduction.tex @@ -241,6 +241,8 @@ \subsection{v1.0 -- work in progress} across multiple repositories and code can be generated from a union of said folders. \item Cyphal/UDP and Cyphal/serial transport specifications have been introduced. + + \item Minor adjustments of the transport layer definitions. \end{itemize} \subsection{v1.0-beta -- Sep 2020} diff --git a/specification/transport/abstract.tex b/specification/transport/abstract.tex index 16737bf..b907f77 100644 --- a/specification/transport/abstract.tex +++ b/specification/transport/abstract.tex @@ -480,22 +480,22 @@ \subsubsection{Transfer-ID}\label{sec:transport_transfer_id} The transfer-ID value of every emitted transfer is determined by sampling the corresponding counter keyed by the session specifier of the transfer; afterwards, the counter is incremented by one. -The initial value of a transfer-ID counter shall be zero. +When the transfer-ID counter reaches the maximum value defined for the concrete transport, +the next increment resets its value to zero. +Transports where the number of distinct transfer-ID values is not less than $2^{48}$ are said to have +\emph{monotonic transfer-ID}. +Those with narrower transfer-ID counters are said to have \emph{cyclic transfer-ID}; +the number of unique transfer-ID values is referred to as \emph{transfer-ID modulo}. + +The initial value of a cyclic transfer-ID counter shall be zero. +The initial value of a monotonic transfer-ID counter should be zero. Once a new transfer-ID counter is created, -it shall be kept at least as long as the node remains connected to the transport network; -destruction of transfer-ID counter states is prohibited\footnote{% +it should be kept at least as long as the node remains connected to the network.\footnote{% The number of unique session specifiers is bounded and can be determined statically per application, so this requirement does not introduce non-deterministic features into the application even if it leverages aperiodic/ad-hoc transfers. }. -When the transfer-ID counter reaches the maximum value defined for the concrete transport, -the next increment resets its value to zero. -Transports where such events are expected to take place during operation are said to have \emph{cyclic transfer-ID}; -the number of unique transfer-ID values is referred to as \emph{transfer-ID modulo}. -Transports where the maximum value of the transfer-ID is high enough to be unreachable under all conceivable -practical circumstances are said to have \emph{monotonic transfer-ID}. - \emph{Transfer-ID difference} for a pair of transfer-ID values $a$ and $b$ is defined for monotonic transfer-ID as their arithmetic difference $a-b$. For a cyclic transfer-ID, the difference is defined as the number of increment operations that need to be applied @@ -673,7 +673,6 @@ \subsubsection{Definitions} Implementations may define this value statically according to the application requirements. Implementations may automatically adjust this value per session at runtime as a function of the observed transfer reception interval. -Transfer-ID timeout values greater than 2 (two) seconds are not recommended. Implementations should document the value of transfer-ID timeout or the rules of its computation. \emph{Transport frame reception timestamp} specifies the moment of time when the frame is received by a node. @@ -692,9 +691,9 @@ \subsubsection{Behaviors} Unintentional duplications may be introduced by various artifacts of the transport network. }. -For a given session specifier, a successfully reassembled transfer that is temporally separated from -any other successfully reassembled transfer under the same session specifier by more than the transfer-ID timeout -is considered unique regardless of its transfer-ID value. +For a given session specifier, a successfully reassembled transfer that is +temporally separated from any other successfully reassembled transfer under the same session specifier +by more than the transfer-ID timeout is considered unique regardless of its transfer-ID value. If the optimal transfer-ID timeout value for a given session cannot be known in advance, it can be computed at runtime on a per-session basis\footnote{% @@ -703,6 +702,13 @@ \subsubsection{Behaviors} The parameters of such computation are to be chosen according to the requirements of the application, but they should always be documented. +The transfer-ID timeout used with service response transfers should be zero\footnote{% + With a non-zero transfer-ID timeout, responses may be lost if the server responds to multiple requests + from the same client not in the order of their arrival. + There is no risk of response duplication because the client will retire the pending request entry + once its first response is received, ignoring subsequent duplicates. +}. + \begin{remark} Low transfer-ID timeout values increase the risk of undetected transfer duplication when such transfers are significantly delayed due to network congestion, diff --git a/specification/transport/udp/udp.tex b/specification/transport/udp/udp.tex index 38b1633..3076431 100644 --- a/specification/transport/udp/udp.tex +++ b/specification/transport/udp/udp.tex @@ -373,6 +373,14 @@ \subsection{Maximum transmission unit} which is allowed as long as such behavior is opaque to the Cyphal/UDP end systems. }. +In multi-frame transfers, the payload size of all frames except the last one shall be the same. +The payload size of the last frame shall be greater than zero and not greater than that of the preceding +frames\footnote{% + The same-MTU constraint for all frames except the last is necessary to enable efficient reassembly of + multi-frame transfers with frames arriving out-of-order, including the case of frames interleaving between + adjacent transfers. +}. + \subsection{Real-time and resource-constrained systems} It is anticipated that real-time and/or resource-constrained systems may implement Cyphal/UDP