#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 in reply to:  description ; Changed on 02/20/19 at 21:48:34 by 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.

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.

comment:2 in reply to:  1 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
Note: See TracTickets for help on using tickets.