Opened on 02/20/19 at 10:44:49
Last modified on 04/03/20 at 14:57:50
#3695 assigned project
Add UDP transfer of event recording data
Reported by: | Sebastian Huber | Owned by: | Sebastian Huber |
---|---|---|---|
Priority: | normal | Milestone: | Indefinite |
Component: | tool | Version: | |
Severity: | normal | Keywords: | |
Cc: | Blocked By: | ||
Blocking: |
Description
Currently, the event recording data can be transferred via TCP from the RTEMS target to a host computer, see rtems_record_start_server() and https://lists.rtems.org/pipermail/devel/2019-January/024640.html.
The TCP is sometimes not the best choice to transfer this information. A UDP transfer should be added on a best effort basis, e.g. lost packages are not retransmitted. The receiver should hand over the package loss information to potential high level consumers.
Change History (3)
comment:1 follow-up: 2 Changed on 02/20/19 at 21:48:34 by Chris Johns
comment:2 Changed on 02/21/19 at 06:23:49 by Sebastian Huber
Replying to Chris Johns:
Replying to Sebastian Huber:
The TCP is sometimes not the best choice to transfer this information. A UDP transfer should be added on a best effort basis, e.g. lost packages are not retransmitted.
Are we converging on the need for a common transport interface and service? I have this interface in libdebugger ...
https://git.rtems.org/rtems/tree/cpukit/include/rtems/debugger/rtems-debugger-remote.h
I would welcome UDP, termios, bare BSP IO, even USB. I am fine with this interface moving and growing.
It should be suitable as a GSoC project. Designing such a more general purpose interface needs a lot of experience.
One option is to simply connect to the lttng tools, e.g. lttng-relayd.
The receiver should hand over the package loss information to potential high level consumers.
I do not understand this sentence.
With UDP a 32bit value at the start is worth the extra overhead. A few high order bits can be flags, for example overflow, resync, etc and the remainder a sequence number to let the remote know if data has been lost.
For the receiver, it should be clear if the data loss happens because the target ring buffer overflowed or packets are lost during transport.
comment:3 Changed on 04/03/20 at 14:57:50 by Sebastian Huber
Milestone: | → Indefinite |
---|
Replying to Sebastian Huber:
Are we converging on the need for a common transport interface and service? I have this interface in libdebugger ...
I would welcome UDP, termios, bare BSP IO, even USB. I am fine with this interface moving and growing.
I do not understand this sentence.
With UDP a 32bit value at the start is worth the extra overhead. A few high order bits can be flags, for example overflow, resync, etc and the remainder a sequence number to let the remote know if data has been lost.