Session limitations
An openOBD session has certain limitations to take into account. We will present this information on this page. When something appears to be missing or is unclear, please contact support.
Session timeout
There are several reasons why a session might end because of a timeout.
Authentication timeout
| Metric | Value |
|---|---|
| Authentication timeout | 60 seconds |
When a session is created, but has not been authenticated within 60 seconds, the session will automatically be closed. The same timeout applies to function contexts. If a function context is created, but has not been authenticated within 60 seconds, the function context will be closed.
Stream idle time
| Metric | Value |
|---|---|
| Stream idle time | 3600 seconds |
When a session has an open stream that does not communicate any data, e.g. openControlStream(), the maximum idle time is 60 minutes.
That means that when there is no user interaction for one hour, the stream will be closed. This will currently result in ending the session.
When there is communication within an hour the connection will stay alive.
Maximum session duration
| Metric | Value |
|---|---|
| Maximum session duration | 14400 seconds |
At the moment the maximum session duration is 4 hours. After this time a session is not guaranteed to keep running. In the future we will implement measures to be able to extend this window and officially register for more computation time.
Communication channels
| Metric | Value |
|---|---|
| Number of communication channels | 32 |
The J-ReX can parallely manage 32 channels at any given moment. What does this mean for openOBD users? When carrying out a service where communication is required to be carried out on multiple channels parallely it is important to keep in mind this limitation. For example, when carrying out communication via ISO-TP channels, if more than 32 channels are registered the backend can only guarantee reliable transmission of ISO-TP messages of the last 32 channels. This does not mean that the other channels are forgotten, but they are set in an inactive state. A workaround for this limitation is to create channels using batches where every batch does not exceed more than 32 ensuring reliable transmission of messages.
Active streams
| Metric | Value |
|---|---|
| Maximum active streams | 128 |
A session can support a maximum of 128 active streams at any given time. Any additional streams will be unable to communicate with the server. It is therefore important to close any streams that are no longer being used.
Connection monitoring
| Metric | Value |
|---|---|
| Socket timeout | 30 seconds |
The connection monitor service allows users to monitor the state of the connection, i.e., the internet stability (latency), the VCI state (online or offline) and
also indicating whether the connection is healthy. In connector information, the field connected indicates the VCI state. It is updated (from
true to false and vice versa) after a delay of 30 seconds when the socket is lost/timeout due problems related to network connectivity.