| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
In dlt_daemon_client_send_all_multiple(), while in the loop,
the connection to client may be destroyed by recursive call to
dlt_daemon_close_socket(). So in some scenario we still use the removed
connection, which is unexpected behavior.
Solution: loop on the fds array and find the client connection
corresponds to.
Signed-off-by: Vo Trung Chi <Chi.VoTrung@vn.bosch.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When it fails to send a log message to connected client, daemon
tries to store the remaining partial message to internal ring
buffer and send again later. When calculating the number of bytes
which were sent to client, it had a bug which it keeps on
incrementing instead of initializing the variable on every message,
which never reached to the condition mentioned above and had a
possibility to overflow and access invalid memory. On the other hand,
daemon doesn't need to store the unsent partial message, as the socket
to the client will be closed on failure and the sent partial message
will be dropped anyways.
This commit removes the lines where the daemon tries to store the
partial message to ring buffer. With this, variable bytes_sent is
now removed.
Related commit: 2262f8b Made socket send reliable
Signed-off-by: Saya Sugiura <ssugiura@jp.adit-jv.com>
|
|
|
|
|
| |
Signed-off-by: Christoph Lipka <clipka@jp.adit-jv.com>
Signed-off-by: Vo Trung Chi <Chi.VoTrung@vn.bosch.com>
|
|
|
|
| |
Signed-off-by: Christoph Lipka <clipka@de.adit-jv.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gateway
Logstorage
Event Handler
Signed-off-by: Christoph Lipka <clipka@de.adit-jv.com>
Signed-off-by: S. Hameed <shameed@jp.adit-jv.com>
Signed-off-by: Aditya Paluri <venkataaditya.paluri@in.bosch.com>
Signed-off-by: Saya Sugiura <ssugiura@jp.adit-jv.com>
Signed-off-by: ManikandanC <Manikandan.Chockalingam@in.bosch.com>
|
|
|
|
|
|
|
|
| |
Made TCP socket send reliable by storing the unsent/partial message
in the ring buffer. This will avoid the corrupted messages/Gaps in
Viewer side
Signed-off-by: ManikandanC <Manikandan.Chockalingam@in.bosch.com>
|
|
|
|
| |
Signed-off-by: Manikandan C <mchockalingam@de.adit-jv.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to change the default buffer size for log message creation via
environment variable:
export DLT_LOG_MSG_BUF_LEN=<value>
Instead of using a static buffer with size of 1390 bytes, the buffer is
allocated dynamically with the specified value.The max size is restricted to approx 65k.
Signed-off-by: Christoph Lipka <clipka@de.adit-jv.com>
Signed-off-by: ManikandanC <Manikandan.Chockalingam@in.bosch.com>
|
|
|
|
| |
Signed-off-by: ManikandanC <Manikandan.Chockalingam@in.bosch.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The poll system call is now used in the daemon to enable DLT use in
POSIX compliant systems. Also added introduced new unregister_app macro
to avoid missing of logs in startup buffer.
Signed-off-by: Frederic Berat <fberat@de.adit-jv.com>
Signed-off-by: ManikandanC <Manikandan.Chockalingam@in.bosch.com>
Signed-off-by: Saya Sugiura <ssugiura@jp.adit-jv.com>
Signed-off-by: S. Hameed <shameed@jp.adit-jv.com>
|
|
|
|
|
|
|
|
|
| |
* IPC: Unix socket added
The user can select either FIFO or UNIX socket as IPC between user library and daemon through CMakelist option.
Socket path configurable for both FIFO and Unix Socket now configurable in CMake
Signed-off-by: Christoph Lipka <clipka@de.adit-jv.com>
Signed-off-by: ManikandanC <Manikandan.Chockalingam@in.bosch.com>
|
|
|
| |
Prevention for occasional corrupted messages caused mostly due to system high load.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In dlt_daemon_send_all_multiple, if the connection was broken, we closed
it before getting the next available connection. This must be avoided by
having a temporary next pointer.
The same kind of problem is valid for pointers coming from the epoll
interface. The kernel can provide back connection pointer that are not
valid any longer. Therefore, we need to use an ID instead of the pointer
value to retrieve the connections.
Signed-off-by: Frederic Berat <fberat@de.adit-jv.com>
Signed-off-by: Christoph Lipka <clipka@jp.adit-jv.com>
|
|
|
|
|
|
|
|
|
| |
It might happen that an event is part of the epoll event queue that
belongs to a connection which was destroyed before the event is handled.
Due to this, the event handling main loop might stop and the daemon
exits. This misbehavior is fixed with this patch.
Signed-off-by: Christoph Lipka <clipka@jp.adit-jv.com>
|
|
|
|
|
|
| |
Unit tests for DLT Daemon connection and event handling
Signed-off-by: Christoph Lipka <clipka@jp.adit-jv.com>
|
|
|
|
|
|
|
|
|
|
| |
The receiver structures have been removed from the dlt-daemon structure,
they are now part of the connection.
The overall usage of the receiver structrure has also been reviewed in
the daemon.
Signed-off-by: Frederic Berat <fberat@de.adit-jv.com>
Change-Id: I7cf80d79ed73bd6d4f370bb3f278d26ccc9d8d7a
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MultiNode allows to connect DLT Daemons running on different operating systems,
e.g. in a virtualized environment. The central component is the Gateway DLT
Daemon which connects external DLT Clients, like the DLT Viewer running on a
host computer, with Passive DLT Daemons running on nodes without a physical
connection to external DLT clients. The Gateway DLT Daemon itself acts as a
DLT client when connecting to a Passive DLT Daemon.
To use the Gateway functionality, it has to be enabled in dlt.conf:
GatewayMode = 1
All communication between passive nodes and DLT Viewer has to be send via the
Gateway node. The Gateway node forwards log messages coming from passive nodes
to all connected DLT clients. It also forwards command and control requests
coming from DLT clients to the corresponding passive node.
The Gateway DLT Daemon read a configuration file (dlt_gateway.conf) at startup
with information about Passive DLT Daemon connections. Afterwards, the
Daemon will try to connect to the passive DLT Daemons. If the connection cannot
be established after the configured timeout, the Gateway DLT Daemon will give up
connecting.
The configuration file has to contain the following information about a passive
node:
[PassiveNode1]
IPaddress = 192.168.2.35
Port = 3490
EcuID = ECU2
Connect = OnStartup
; timeout in seconds
Timeout = 10
Precondition is, that the passive node is configured with the correct ECU id,
ECU2 in this case. If the passive node sends messages with another than
configured ECU id, the Gateway DLT Daemon will shut down the connection.
It is also possible to connect to a passive DLT daemon using the
dlt-passive-node-ctrl application. In this case "Connect=OnDemand" has to be
configured in the configuration file.
To connect to PassiveNode1, "dlt-passive-node-ctrl -n ECU2 -c 1" has to be
executed.
With "dlt-passive-node-ctrl -s" the status of passive node connections can be
retrieved.
Signed-off-by: Christoph Lipka <clipka@jp.adit-jv.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Control applications running in the same Linux OS should be able to communicate
with the DLT Daemon via a socket connection.
To be able to do that, the DLT Client library need to be extended. DLT
Clients connected via this UNIX socket are not handled as normal DLT
Clients and no log messages will be forwarded to them. This avoids
problems in situations when a control application is connected to the
DLT Daemon before any other 'real' DLT Client (e.g. DLT Viewer) is
connected. In this situations, all already stored log messages are
flushed to the control application and therefore lost, because the
control application most likely ignore all incoming messages besides the
one in which it is interested in.
Signed-off-by: Christoph Lipka <clipka@jp.adit-jv.com>
|
|
The event handling has been reworked in order to use epoll and
restructure the code.
There are 2 new structures.
The DltConnection which contains all basic connection information, like
the type, the file descriptor, and the receiver structure corresponding.
The DltEventHandler that manages the DltConnections and the associated
events.
The concept is basically the following. The daemon will create different
connections, serial connections, socket connections, fifos etc ... Each of
them will then register itself to the event handler, and give it the
ownership of this connection. From this point in time, the daemon can act
on the connections.
Once an event is triggered, the event handler will call the connection
specific callback, creates new connections when clients arrives,
and potentially destroy the connection in case of hangup.
On exit, the daemon cleanup the event handler, which leads to the
destruction of the connections.
The work there is a first step for a global restructuring. Several
modification will follow, in order to rationalize the different daemon
structures, and avoid variable and code duplication.
Signed-off-by: Frederic Berat <fberat@de.adit-jv.com>
|